NEJVYŠŠÍ SPRÁVNÍ SOUD Moravské nám. 6, 657 40 Brno, tel: 542 532 311, ID datové schránky: wwjaa4f fax: 542 532 361, e-mail: podatelna@nssoud.cz PŘEDBĚŽNÉ TRŽNÍ KONZULTACE 1. ÚVOD Nejvyšší správní soud (dále též zadavatel ) připravuje výběrové řízení na veřejnou zakázku malého rozsahu s názvem Vývoj, dodávka a podpora webových stránek a vyhledávacího nástroje pro databázi soudních rozhodnutí. Před vyhlášením zakázky se zadavatel rozhodl vést níže specifikované předběžné tržní konzultace. Jejich účelem je zvýšení transparentnosti výběrového řízení a získání relevantních a objektivních informací o možnostech trhu tak, aby zadavatel mohl následně optimálně nastavit zadávací podmínky popsané veřejné zakázky malého rozsahu. 2. CÍL VEŘEJNÉ ZAKÁZKY Cílem veřejné zakázky je vytvoření webových stránek Nejvyššího správního soudu, včetně vyhledávacího nástroje pro databázi soudních rozhodnutí (dále též vyhledávač ). Vyhledávač bude sloužit jak vnitřním uživatelům (soudcům a asistentům), tak i vnějším uživatelům (široké veřejnosti). Pro vnější uživatele však bude obsah a rozsah databáze soudních rozhodnutí oproti vnitřním uživatelům omezen. 3. FORMA A PRŮBĚH PŘEDBĚŽNÝCH TRŽNÍCH KONZULTACÍ Účast v předběžných tržních konzultacích je otevřená. Účastnit se jich mohou zejména všichni potenciální zájemci o předmětnou veřejnou zakázku malého rozsahu (dále jen dodavatelé ). V rámci zvýšení informovanosti o zahájení předběžných tržních konzultací zadavatel současně adresně oslovil několik konkrétních dodavatelů (viz bod 4). Předběžné tržní konzultace budou probíhat písemně v době od 11. do 22. října 2017. Odpovědi na níže uvedené otázky zadavatele (viz bod 8) stejně jako případné upřesňující či doplňující dotazy mohou dodavatelé zasílat na e-mailovou adresu ptk@nssoud.cz. Odpovědi zadavatele na případné upřesňující či doplňující dotazy ze strany dodavatelů budou v průběhu předběžných tržních konzultací zveřejňovány na webových stránkách www.nssoud.cz (v sekci O soudu Veřejné zakázky Předběžné tržní konzultace). Průběh a výsledek předběžných tržních konzultací bude následně zaznamenán v samostatné zprávě, která bude součástí zadávací dokumentace. 1
4. OSLOVENÍ DODAVATELÉ Zadavatel dopisem ze dne 11. 10. 2017 adresně upozornil na zahájení předběžných tržních konzultací níže uvedené dodavatele: AutoCont CZ a.s. (IČ: 47676795, adresa: Hornopolní 3322/34, Moravská Ostrava, Ostrava, 702 00, e-mail: obchod@autocont.cz, web: www.autocont.cz) CNS a.s. (IČ: 26129558, adresa: Nad Šafranicí 574, Mělník, 276 01, e-mail: podatelna@cns.cz, web: www.cns.cz) E LINKX a.s. (IČ: 25847180, adresa: Novoveská 1262/95, Mariánské Hory, Ostrava, 709 00, e-mail: obchod@elinkx.cz, web: http://elinkx.cz) GEOVAP, spol. s r.o. (IČ: 15049248, adresa: Čechovo nábřeží 1790, Pardubice, 530 03, e- mail: info@geovap.cz, web: www.geovap.cz) GORDIC spol. s r.o. (IČ: 47903783, adresa: Erbenova 2108/4, Jihlava, 586 01, e-mail: gordic@gordic.cz, web: www.gordic.cz) NESS Czech s.r.o. (IČ: 45786259, adresa: V Parku 2335/20, Praha 4, 148 00, e-mail: nesscz@ness.com, web: http://nesstech.com) TESCO SW a.s. (IČ: 25892533, adresa: tř. Kosmonautů 1288/1, Hodolany, Olomouc, 779 00, e-mail: tescosw@tescosw.cz, web: www.tescosw.cz) Wolters Kluwer ČR, a. s. (IČ: 63077639, adresa: U Nákladového nádraží 3146/6, Praha 3, 130 00, e-mail: obchod@wolterskluwer.cz, web: www.wolterskluwer.cz) 5. POPIS STÁVAJÍCÍHO STAVU V současné době Nejvyšší správní soud provozuje webové stránky vytvořené v proprietárním redakčním systému na hardwaru (HW) ve vlastní správě a součástí těchto webových stránek je i vyhledávací nástroj, prostřednictvím něhož mohou uživatelé vyhledávat soudní rozhodnutí. Tento vyhledávač pracuje s daty přejímanými přímo z Informačního systému Nejvyššího správního soudu (ISNSS). Data pro webový vyhledávač jsou uložena v databázi (DB) na fyzickém serveru odděleném od stávajícího ISNSS firewallem. Informační systém ISNSS zvolená data sám posílá k uložení do DB na webový server. Webový server, data pro webovou prezentaci, jakož i data pro vyhledávač jsou uložena na serveru přímo dostupném z internetu. Webové stránky Nejvyššího správního soudu vznikly v roce 2010. S rozvojem informačních technologií došlo k technickému zastarání současné podoby webu, která způsobem zpracování informací a jejich grafickou prezentací již nereflektuje požadavky kladené na vzhled, strukturu a funkcionalitu moderních webových stránek a nenaplňuje tak podmínky uživatelské přívětivosti. 2
Stejně tak nevyhovující je i stávající vyhledávací nástroj, který neumožňuje kvalitní fulltextové vyhledávání v databázi soudních rozhodnutí. Obr. 1. Schéma stávajícího stavu 6. POPIS POŽADOVANÉHO STAVU Zadavatel usiluje o vytvoření zcela nových webových stránek, jejichž součástí bude i nový vyhledávací nástroj pro prohledávání databáze soudních rozhodnutí. V rámci tohoto nového řešení chce zadavatel oddělit ISNSS, jenž je dnes provázán s webovými stránkami a vyhledávacím nástrojem, neboť data do webové DB jsou nyní zasílána přímo z ISNSS. Zadavatel chce také zcela eliminovat možné ovlivnění správné funkce webových stránek, jakož i vyhledávače, ze strany ISNSS a to tak, že plánuje změnit roli stávajícího ISNSS z aktivní na čistě pasivní. Zadavatel plánuje vytvoření univerzálního API na straně ISNSS, které bude představovat obecné rozhraní pro systém nových webových stránek a vyhledávače, resp. vyhledávačů (pro vnitřní uživatele a pro vnější uživatele viz dále). Nové řešení webových stránek a vyhledávače bude samo aktivně získávat data z ISNSS přes jasně definované API. Takto získávaná data budou muset být někde ukládána (zřejmě do DB) pro potřeby jejich použití na webových stránkách, potažmo vyhledávacím nástrojem. Přístup k datům ISNSS přes API rozhraní umožní, aby navrhované řešení nových webových stránek a nového vyhledávacího nástroje bylo nezávislé na konkrétní platformě operačního systému (OS) i nezávislé na konkrétně použité DB pro ukládání dat získávaných z ISNSS. Data, která se mají z ISNSS (přes API) získávat jsou složena jednak z konkrétních dat, uložených v databázových tabulkách (např. čísla, znaky, příznaky, celé texty) a dále pak i z celých dokumentů v různých formátech (např. DOC, DOCX, PDF), kdy v ISNSS jsou tyto dokumenty uloženy v dokumentové knihovně. Zadavatel požaduje, aby nový vyhledávací nástroj byl umístěn, resp. aby byl dostupný na dvou místech současně, a to na intranetu a extranetu NSS (pro vnitřní uživatele) a na internetu jako součást webových stránek zadavatele (pro vnější uživatele). Zadavatel připraví, jak na vnitřní síti intranetu, tak i v části sítě dostupné z internetu potřebný HW pro instalaci a provoz webových stránek a vyhledávacího nástroje. 3
Vyhledávač pro vnitřní uživatele (dostupný z intranetu a extranetu), jakož i vyhledávač pro vnější uživatele (dostupný z internetu), budou mít možnost nezávislé konfigurace, a to tak, že bude možno určit, ve kterých datech ten který vyhledávač bude moci hledat a stejně tak bude možno určit, jaká data bude jeden i druhý vyhledávač následně uživatelům prezentovat jako výsledek svého vyhledávání. Z pohledu zadavatele tedy mohou být oba vyhledávací nástroje identické, avšak ve vyhledávači dostupném z internetu musí být možnost omezit jak rozsah zadávání vyhledávání, tak i výsledky vyhledávání. Data, která se budou přesunovat z ISNSS za firewall, budou definovaným způsobem významně omezena oproti datům, která budou k dispozici pro vnitřní vyhledávač. Jinými slovy, některá data dostupná pro vnitřní vyhledávač se nesmí dostat k vnějším uživatelům (tj. mimo intranet/extranet NSS). Oba dva vyhledávací nástroje (vnitřní-intranetový a vnější-internetový) budou provozovány na různém HW odděleném firewallem. Je tedy na zvážení dodavatele, zda data pro oba vyhledávače umístí na jedno místo (typicky DB na straně intranetu), anebo použije dvě DB, tedy pro každý vyhledávač jinou. Univerzální API rozhraní bude získávat data z ISNSS přímo z DB typu MS SQL. Firewall mezi intranetem a serverem otevřeným do internetu má porty otevřené výhradně pro přenos http protokolu. Webové stránky ani vyhledávací nástroj nesmí být závislé na typu použitého webového prohlížeče a ani na jeho verzi. Zadavatel se domnívá, že navrhované řešení webových stránek a vyhledávacího nástroje by se mělo skládat minimálně z agenta pro získávání dat z ISNSS přes API, z řídícího engine, dále z DB a z webového serveru. Zadavatel nevylučuje použití některé části společné pro vnitřní i vnější webové stránky a pro vnitřní i vnější vyhledávací nástroj. Obr. 2. Schéma požadovaného stavu ideový návrh řešení 4
Vyhledávací nástroj bude umožňovat hledání jednak v konkrétních datech parametrech (z DB tabulek) a také bude mít implementovány možnosti bohatého fulltextového vyhledávání. Vyhledávač musí být vytvořen a optimalizován tak, aby byla zajištěna vysoká rychlost odezvy na uživatelský dotaz, přičemž tato nesmí být významně ovlivňována složitostí, rozsahem či kombinací zadaných vyhledávacích podmínek. Fulltextové vyhledávání bude využívat implicitní a explicitní syntaxi, tj. slova nebo fráze bude možno do fulltextového pole zadat volně (bez uvozovek) a v tom případě bude vyhledávač hledat zadaná slova nebo fráze, včetně jejich tvarů (implicitní syntaxe), anebo slova nebo fráze bude možno do fulltextového pole zadat v uvozovkách (např. právní jistota ) a v tom případě bude vyhledávač tato slova nebo fráze hledat přesně v zadaném tvaru (explicitní syntaxe). Vyhledávač bude umět lemmatizovat, tj. vyhledávat všechny tvary slova, avšak bez předpon, což se týká i záporů (tj. u slovesa koupit, vyhledávač nevyhledá tvary sloves zakoupit, nakoupit, nekoupit apod., tato slova bude proto nutno hledat samostatně, případně v kombinaci se slovem koupit). Lemmatizace se týká pouze implicitní syntaxe (tj. volně zadaných slov bez uvozovek). Vyhledané dokumenty se setřídí dle relevance k zadaným kritériím. Výsledky setříděné dle relevance budou vypsány s nejvíce relevantním dokumentem na prvním místě. Při fulltextovém vyhledávání bude možno použít přinejmenším tyto logické operátory a všechny jakkoliv vzájemně kombinovat: I. Konceptuální operátory: Konceptuální operátory spojují jednotlivé prvky dotazu do větších celků. Vyhledané dokumenty jsou následně tříděny podle stupně relevance. Popis konceptuálních operátorů: AND: Vybere dokumenty, které obsahují všechny zadané prvky hledání. ACCRUE: Vybere dokumenty, které obsahují alespoň jeden ze zadaných prvků hledání. OR: Vybere dokumenty, ve kterých se vyskytuje alespoň jeden zadaný prvek hledání. II. Poziční operátory: Poziční operátory určují relativní umístění určitých slov v dokumentu, tj. aby byl dokument vybrán, musí být daná slova uvedena ve stejné frázi, odstavci nebo větě. Pokud jsou operátory blízkosti kumulovány, bude jako první použit ten, který má nejširší rozsah, což je fráze, a jednotlivá slova se mohou objevit uvnitř operátorů SENTENCE nebo PARAGRAPH, a operátor SENTENCE se může objevit v rámci operátoru PARAGRAPH. Popis pozičních operátorů: PHRASE: Vybere dokumenty, které obsahují zadanou frázi. SENTENCE: Vybere dokumenty, které obsahují všechna zadaná slova v jedné větě. 5
PARAGRAPH: Vybere dokumenty, které obsahují všechna zadaná slova v jednom odstavci. NEAR: Vybere dokumenty, které obsahují dané termíny hledání blízko sebe. NEAR(N): Vybere dokumenty, které obsahují dvě nebo více slov ve vzdálenosti N počtu slov od sebe, kde N je celé číslo do 1000. III. Modifikátory: Modifikátory dále specifikují chování operátorů. S operátorem lze např. použít modifikátor CASE pro určení, že při výběru bude brán zřetel i na velikost písmen. Popis modifikátorů: CASE: Hledání se provádí s ohledem na velikost písmen. NOT: Vyloučí dokumenty obsahující slova nebo fráze. ORDER: Určuje pořadí, ve kterém se prvky hledání musí vyskytnout v dokumentu. IV. Závorky ve výrazech: Závorky určují pořadí, v jakém má být výraz zpracován. Informace mezi závorkami je čtena první, poté je následně čtena informace vně závorek. Pokud uživatel nepoužije závorky, budou se operátory implicitně vyhodnocovat v tomto pořadí (podle blízkosti): NEAR SENTENCE PARAGRAPH AND OR NOT. V. Zástupné znaky: (např.) OTAZNÍK [?] může představovat libovolné písmeno. (např.) HVĚZDIČKA [*] může představovat libovolný počet písmen. 7. OBECNÉ TEZE ŘEŠENÍ Obecné API: Musí splňovat současné bezpečnostní normy a standardy. Musí být technologicky univerzálním rozhraním nezávislým na platformě operačního systému i databázového serveru. Pro komunikaci s API bude použito standardní REST API, JSON, OATH2 apod. Pojistky a zabezpečení proti neoprávněnému přístupu k datům z ISNSS budou implementovány přímo v API. Odstínění provozu vyhledávače od provozu klíčové části ISNSS: 6
Získávání dat pro vyhledávač nesmí ovlivnit výkonost ISNSS, zabezpečení limitů zatížení bude implementováno přímo v API. Bude jasně definovaná zodpovědnost zadavatele v provozu ISNSS a API, dodavatel pak bude zodpovídat za vše ostatní. Změny v ISNSS nesmí ovlivnit chod vyhledávače. U požadavků na úpravy ISNSS bude potřeba revidovat i API. API bude umožňovat automatické testování rozhraní při nasazení nových verzí ISNSS. Dodavatel bude nezávislý na strukturách ISNSS, bude mít možnost vlastního návrhu řešení a datových struktur dle svých potřeb. Indexace dokumentů dle požadavků uživatelů na podrobnost vyhledávání bude v režii dodavatele, bez ovlivnění ISNSS. 8. OTÁZKY S ohledem na přípravu popsané veřejné zakázky, která by měla zcela změnit funkci a princip současného fungování přenosu dat z ISNSS směrem k webovým stránkám a vyhledávacímu nástroji, si Vás dovolujeme oslovit s následujícími dotazy: [1] Obsahují navrhované vlastnosti, funkcionality či postupy takové skutečnosti, jež by mohly zapříčinit příliš nákladnou nebo obtížně proveditelnou realizaci? Pokud ano, uveďte konkrétně nedostatky navrhovaného řešení. [2] Je reálným, vhodným a efektivním návrh využití principu spojení stávajícího ISNSS s novým vyhledávacím nástrojem přes obecné API? Pokud ne, uveďte konkrétně nedostatky navrhovaného řešení. [3] Je reálným, vhodným a efektivním řešením přenesení aktivity pro získávání dat z ISNSS zcela na nový vyhledávací nástroj? Pokud ne, uveďte konkrétně nedostatky navrhovaného řešení. [4] Je reálný a správný předpoklad zadavatele o složení a minimální funkční konfiguraci navrhovaného řešení webových stránek a vyhledávacího nástroje? Pokud ne, uveďte konkrétně nedostatky navrhovaného řešení. [5] Je některá platforma OS vhodnější než jiná pro použití v tomto konkrétním případě? Pokud ano, uveďte která a proč. [6] Je některý webový server vhodnější než jiný pro použití v tomto konkrétním případě? Pokud ano, uveďte který a proč. [7] Je některý typ DB vhodnější než jiný pro použití v tomto konkrétním případě? Pokud ano, uveďte který a proč. [8] Je reálné, vhodné a efektivní vytvoření vyhledávacího nástroje v navrhovaném rozsahu vyhledávacích funkcí? Pokud ne, uveďte konkrétně nedostatky řešení. 7