S novým rokem spatřila světlo světa první verze e-Sbírky, dlouho očekávané části projektu eSeL (e-Sbírka a e-Legislativa). Nebudeme teď řešit mnohaleté odklady, jak (ne)používá jednotnou doménu gov.cz nebo jaký je její vztah k soukromým projektům, jako jsou Zákony pro lidi nebo Beck-online. Ambice tohoto textu jsou mnohem užší, podobně jako v minulých textech se podívám na to, jaká otevřená data projekt nabízí a jak jsou použitelná pro koncové uživatele.
e-Sbírka je totiž krom webového rozhraní – zde si můžete představit výše zmíněné soukromé portály – také poskytovatelem otevřených dat, takže si kdokoliv může jít na web a stáhnout si kompletní data k aktuálně platné i historické legislativě. Teoreticky to zní lákavě, ale bohužel praxe je poněkud odlišná.
TIP: Projektu e-Sbírka se věnujeme také v textu: Co nabízí nová e-Sbírka a jak se s ní pracuje?
Hledáme otevřená data
V sekci pro otevřená data na webu e-Sbírky se dovídáme řadu obecných informací o otevřených datech. Nejde ale o informace k otevřeným datům e-Sbírky, jde o texty vykopírované z portálu Digitální a informační agentury (DIA) o otevřených datech – konkrétně definice otevřených dat je vykopírovaná ze sekce Otevřená data blíže, výpis podmínek je ze stránky Co jsou otevřená data? Zde je poměrně evidentní, že autor této části dokumentace jen překopíroval existující texty bez snahy jim nějak porozumět a zpracovat je – nejenže text postrádá formátování, vlastní data e-Sbírky mnoho ze zmiňovaných podmínek nesplňují.
Jednou z podmínek je, že data musí být „evidovaná v Národním katalogu otevřených dat (NKOD) jako přímé odkazy na datové soubory“, což tato sada nesplňuje. Místo toho musí člověk jít na odkázanou stránku s daty (mimochodem na jinou doménu než samotná e-Sbírka), která je poměrně spartánská. Jde o nejlínější možné zpracování, o prostý seznam odkazů na soubory vygenerovaný webovým serverem, uživatel se nedozví vůbec nic o tom, co dané soubory reprezentují.
V tuto chvíli asi nejednoho uživatele napadne hledat dokumentaci, schémata, diagramy, cokoliv. Je to ostatně jedna z kvalit, kterou samotní autoři webu zmiňují na výše zmíněné úvodní stránce – sami ji však nenabízí. (Soukromě se mi podařilo dokumentaci obstarat, ale žádná dokumentace v ní není obsažena.)
Vzhledem k absenci dokumentace se musíme sami poprat se zvláštní dualitou JSON a JSON-LD dat. Jeden by řekl, že JSON-LD bude bohatší formát než JSON, obsahující tzv. linked data metadata. Do jisté míry je to pravda, ale v současné implementaci je toto obohacení poměrně omezené. LD data mají navíc jeden klíč v kořenovém slovníku, jinak jsou soubory naprosto identické. Máte tak třeba 10 GB velký soubor, který je poskytován dvakrát, v jednom případě má navíc cca 1 kilobajt metadat. Marginálně menší soubor je tak naprosto zbytečný. Na jednu stranu bizarní situace, na druhou vlastně příjemné překvapení. Když jsme se minule dívali na práci stejného dodavatele, publikoval drtivou většinu dat zbytečně, nyní je to jen polovina.
Už tedy víme, že polovinu datasetů můžeme ignorovat, stáhneme tedy všechny JSON-LD datasety. Na první pohled možná překvapí vysoká míra komprese (cca 1:25, tedy největší soubor má komprimovaný cca gigabajt, ale po rozbalení přes 27 GB), ale to je dáno velmi upovídaným formátem JSON. Normálně by to nevadilo, je běžné data zpracovávat iterativně, jenže dodavatel řešení volbou formátu tuto možnost významně ztížil.
Místo formátu, který by umožňoval proudové zpracování, dodavatel zvolil strukturu, která vybízí k načtení celého souboru do paměti (a málokterá implementace dovolí tuto strukturu zpracovávat postupně), což u souboru, který má 27 gigabajtů, jde na běžném hardwaru velmi těžko.
Může to znít jako banalita, jde ale o klíčový nedostatek otevřených dat e-Sbírky. Všechny ostatní limitace jde nějakým způsobem vyřešit, ale pokud běžný uživatel narazí na takto gigantická data, bude mít velké potíže je jakkoliv zpracovat. Není to poprvé, kdy na tento problém narážíme – v otevřených datech Justice jsme narazili na řádově podobně velká data, naštěstí se nabízelo technické řešení, které umožnilo čtení dat s přijatelnou paměťovou náročností. Exporty z e-Sbírky takový přístup aktivně znemožňují a je otázka, jaký přístup zpracování dat dodavatel pro své uživatele plánoval.
Nabízí se hned další otázka – pokud je tak náročné data zpracovat, bylo náročné je i vygenerovat? Pozorným čtením textové reprezentace těchto dat si všimneme, že jednotlivé objekty mají jiné formátování než metadata. Dodavatel tak očividně nepoužil žádnou knihovnu na serializaci celého datového souboru (což je standardní postup pro zajištění zpracovatelnosti dat) – iterativně vypisoval jednotlivé objekty, protože sám nejspíš pocítil tíži velikosti jednotlivých souborů. (Naopak u malých číselníků je formátování konzistentní v celém souboru, tam dodavatel správně použil knihovnu.) Dodavatel si tak byl nejspíš vědom náročnosti zpracování takového formátu, ale i tak se rozhodl přenést tuto tíži na uživatele otevřených dat.
Když se vrátíme k dokumentaci na úvodní stránce, stojí tam, že otevřená data musí být „připravena s cílem co nejsnazšího strojového zpracování programátory apod.“. Struktura dat e-Sbírky je v přímém rozporu s tímto tvrzením (a existuje možnost, že data jsou i v rozporu se zákonnou definicí otevřených dat, kde je podrobně formulovaný strojově čitelný formát, který otevřená data musí splňovat).
Při pohledu na tuto situaci by mě zajímalo, zda se nějaká ze stran – zadavatel, dodavatel či někdo z testujících – před spuštěním pokusila tato data použít. Jakýkoliv uživatel totiž musí narazit na problémy zde zmíněné.
Implikace
Co mají být ze zákona snadno nalezitelná a snadno strojově zpracovatelná data, je ve skutečnosti nedokumentovaná směs obtížně zpracovatelných exportů. V praxi to znamená, že jakýkoliv uživatel těchto dat bude vyžadovat IT pracovníky, a i ti se budou dost zapotí, aby data zpracovali.
Možnou odezvou k této náročnosti může být, že málokdo potřebuje kompletní datasety (a nejspíš to bude pravda) a že pro širší odbornou veřejnost tu je REST API. S hodnocením API je třeba si počkat, protože toto API je uzavřené jen pro registrované a schválené uživatele. Bude třeba poslat žádost Ministerstvu vnitra datovou schránkou a uvést účel použití a předpokládaný počet dotazů. Tato žádost ještě není k dispozici, otevře se veřejnosti až 15. ledna, takže těžko hodnotit. Samotné uzavření systému je ale další z naprosto zbytečných překážek.
Co s tím
První krokem by měla být oprava výše zmíněných nedostatků – přidání kvalitní dokumentace, zalistování v NKOD, úprava stránky se seznamem datasetů. U samotné struktury dat je pak základem udělat data buď proudově zpracovatelná, anebo je rozdělit na dostatečně malé kusy pro hardwarově nenáročné zpracování koncovými uživateli.
Z hlediska formátu se nabízí NDJSON (či JSONL), který nabízí efektivní zpracování gigantických souborů s daty. Špatnou volbou by nebylo ani nechvalně známé XML, které streamové zpracování standardně umožňuje a ani dodavateli není cizí (v otevřených datech Justice poskytuje XML datasety, které mají vyšší jednotky gigabajtů). Dodavatel má zkušenost i s nabízením souboru pro každou entitu zvlášť – u otevřených dat ze systému ARES.
Poněkud bizarně nejsou datasety nabízeny v tabulkové formě (např. jako CSV). Bizarně, protože data jsou v tuto chvíli uložena v relační databázi a není přehnané předpokládat, že velká část zpracovatelů je do relační databáze opět uloží.
Pro vlastní potřeby jsem si připravil skript, který data umožní zpracovat i na strojích, které nedisponují vysokými desítkami gigabajtů operační paměti, které jsou jinak pro zpracování dat v podstatě nutné za použití standardních nástrojů. Poněkud paradoxně nemohu pravidelně automaticky kontrolovat, že stále funguje (je závislý na způsobu exportu dat), protože se ministerstvo vnitra rozhodlo blokovat přístup k otevřeným datům ze serverů mimo Evropskou unii.
Proč to takto dopadlo?
Je smutné, že jsme se po tolika letech odkladů spuštění e-Sbírky dostali do tohoto stavu. Máme tu více než 800stránkový návrh technického řešení, projekt byl přirovnán k vývoji vozu Bugatti, rozpočet dosáhl vysokých stovek milionů korun, projekt se připravuje mnoho let.
Nejhorší na celé věci je, že výše zmíněné chyby odhalí skoro libovolný odborník v řádu minut, maximálně nízkých jednotek hodin. Je otázka, zda problémem je, že se testování omezilo na minimum, nebo zda byl dodavatel hluchý k připomínkám. Bez viny samozřejmě není ani zadavatel, který dílo převzal a k začátku roku narychlo pustil do světa (byť víme, že to bylo i kvůli návaznosti na evropskou dotaci).
Problémy jsou to ale (místy snadno) řešitelné, tak uvidíme, jak se k tomu postaví obě strany projektu. U hlavního dodavatele – Asseco Central Europe – máme bohaté zkušenosti s jeho prací – ostatně jeho implementaci otevírání Justice nebo systému ARES jsme zde na Lupě již dokumentovali. Mnoho se od té doby nezlepšilo.
- Chcete mít Lupu bez bannerů?
- Chcete dostávat speciální týdenní newsletter o zákulisí českého internetu?
- Chcete mít k dispozici strojové přepisy podcastů?
- Chcete dostávat exkluzivní tištěný speciál Lupa 3.0?
- Chcete získat slevu 1 000 Kč na jednu z našich konferencí?
Staňte se naším podporovatelem
ČLÁNKY DO MAILU