Jak mám jako poskytovatel použít otevřené formální normy

Otevřené formální normy (OFN) jsou technická doporučení zaměřená na vybrané datové sady. Zajišťují, že stejná data publikovaná různými poskytovateli je možné jednodušeji využívat nezávisle na tom, kdo data poskytuje. Pro poskytovatele otevřených dat, kteří jsou povinnými subjekty dle zákona č. 106/1999 Sb. o svobodném přístupu k informacím, jsou však tato doporučení závazná dle § 4b odst. 1. Cílem tohoto návodu je poskytnout pro poskytovatele dat návod, jak správně Otevřené formální normy použít a na co v datech nezapomínat.

Seznam existujících OFN a jejich stav, tj. zda jsou v přípravě a mohou se měnit, nebo zda jsou vydané, naleznete v příslušné sekci Portálu o datech. Jak již bylo řečeno v úvodu, používání OFN ve smyslu § 3a odst. 3 zákona č. 106/1999 Sb., o svobodném přístupu k informacím je pro poskytovatele otevřených dat dle § 4b odst. 1 zákona č. 106/1999 Sb. o svobodném přístupu k informacím závazné. V době psaní návodu byly vydány 4 OFN, které jsou zaměřeny na obce. Jedná se o Turistické cíle, Sportoviště, Události a Aktuality.

Odpovídají má data tématicky existující OFN?

Prvním krokem při publikaci otevřených dat je uvědomění si, o čem publikovaná data jsou. Existuje pro dané téma OFN? Pokud ano, pak je třeba se jí řídit, aby byla publikovaná data interoperabilní, tj. aby aplikace, které konzumují data dle dané OFN, nemusely být upravovány pro zpracování různých proprietárních formátů dat.

Pokud otevřená formální norma pro moje téma ještě neexistuje ani v rozpracovaném stavu, pak se dostáváme mimo záběr tohoto návodu. Tuto situaci popíšeme někdy příště. Nyní pouze řekneme, že i tak je třeba použít alespoň tzv. sdílené specifikace, které standardizují podobu často se opakujících částí dat, a že vzniklou datovou sadu je třeba dokumentovat stylem a obsahem, který odpovídá stylu a obsahu OFN.

Pro zbytek návodu předpokládáme, že publikovaná data tématicky odpovídají některé z vydaných či rozpracovaných OFN.

OFN a sdílené specifikace

Otevřené formální normy jsou vydávány systematicky tak, že stejné typy věcí jsou specifikovány pouze jednou, jako tzv. sdílené specifikace. Příkladem může být časová specifikace, která je použita v jedné OFN jako otevírací doba sportoviště a v jiné OFN jako plán vývozu kontejneru na sklo. Samotné možnosti časové specifikace jsou ale stejné, a tedy specifikovány ve zvláštním dokumentu.

V přehledových obrázcích v OFN jsou tyto typy entit označeny rámečkem s šedě podbarveným nadpisem. V době psaní článku je vydána sdílená specifikace pro základní datové typy zahrnující celé číslo, desetinné číslo, datum, čas, datum a čas, řetězec, text, URL, cenu a množství. Dále je vydána sdílená specifikace pro Věc, což je společný předek všech typů entit definovaných v OFN a sdílených specifikacích a definuje identifikátor ve formě IRI, název, popis, čas zneplatnění apod. Tyto položky lze tedy použít pro libovolný typ datové entity. Dále jsou dostupné konkrétní sdílené specifikace pro adresy, bezbariérovost, časovou specifikaci, digitální objekty, kontakty, lidi a osoby, umístění či vstupné.

Datový formát předepsaný OFN

Otevřená formální norma, např. pro turistické cíle, specifikuje, že data budou publikována ve formátu JSON, který je specifikován dokumentem ECMA-404 a dále upřesněn dokumentem RFC 8259, a musí být validní vůči JSON schématu, které je součástí OFN v sekci Příklady. Položky, které jsou v datech obsaženy, pak musí svým významem odpovídat jejich popisu v sekci Specifikace dané OFN. Poskytovatel tedy musí zařídit převod dat z existujícího formátu, pokud data ve formátu požadovaném OFN zatím nejsou. Tím je zajištěno, že data budou zpracovatelná aplikacemi využívajícími OFN bez další transformace.

Všechny položky specifikované v OFN jsou nepovinné. Pokud tedy poskytovatel pro některou z předepsaných položek nemá data, tak ji zkrátka nevyužije. Naopak také platí, že do dat dle OFN lze přidávat vlastní data, i když v OFN popsána nejsou. V tom případě ale výsledný soubor musí zůstat validní vůči JSON schématu specifikovaném v OFN. Rozšíření musí využívat sdílené specifikace a musí být řádně zdokumentováno specifikací rozšiřujících položek a rozšířeným JSON schématem v podobném stylu, jako je samotná OFN.

Zároveň ale platí, že každá OFN má uveden tzv. minimalistický příklad, u kterého by již vynechání libovolné položky učinilo taková data nepoužitelnými.

Příklad: Datová sada turistických cílů bude JSON soubor vystavený na webu, validní vůči JSON schématu https://ofn.gov.cz/turistické-cíle/2020-07-01/schémata/turistické-cíle.json - validitu lze ověřit např. v nástroji JSON Schema Validator.

Identifikátory IRI

Každá datová entita publikovaná dle OFN má svůj identifikátor ve tvaru IRI - Internationalized Resource Identifier (RFC 3987) - v JSON klíči "iri". Používání IRI pro identifikací věcí v otevřených datech je velmi důležité. Zajišťuje totiž, že dvě různé věci publikované v různých datových sadách různých poskytovatelů nebudou nikdy identifikovány pomocí stejného identifikátoru. To se jinak běžně děje - není těžké si představit, že turistický cíl v jedné datové sadě je identifikován např. "tc23", což je ale shodou okolností použito také jako identifikátor jiného turistického cíle jiného poskytovatele, a také jako identifikátor ozubeného kolečka v nějakém systému výrobního závodu. Na základě identifikátoru "tc23" pak vlastně vůbec nevíme, která věc je takto identifikována. Používání IRI tak usnadňuje integraci dat z více zdrojů a zvyšuje datovou interoperabilitu, což je hlavním cílem OFN.

Používání IRI pro identifikaci entit v otevřených datech není třeba se bát. Každý poskytovatel má již nyní registrovánu svojí doménu minimálně pro svojí webovou prezentaci. Tuto doménu lze v nejjednodušším případě použít i pro tvorbu identifikátorů pro datové entity vyčleněním části cesty IRI k tomuto účelu, např. https://www.poskytovatel.cz/data/. Alternativně lze pro účely identifikace datových entit zřídit subdoménu, např. https://data.poskytovatel.cz.

Pro entity daného typu, např. turistické cíle, pak lze vyčlenit další část cesty IRI, a tedy pro konkrétní turistický cíl použít např. https://data.poskytovatel.cz/turistické-cíle/1234. Zde je třeba zdůraznit, že se jedná pouze o identifikátor (IRI), nikoliv lokátor (URL). Tedy minimálně z počátku není třeba řešit, aby IRI https://data.poskytovatel.cz/turistické-cíle/1234 "někam vedlo", tj. aby uživatel při přístupu na něj například pomocí webového prohlížeče dostal nějaká data, nebo viděl nějakou stránku. Jedinou funkci, kterou IRI v tomto případě má, je funkce rozlišovací, identifikační. Tedy pokud jsou dvě věci identifikovány stejným IRI, jedná se záměrně o stejnou věc. Naopak, dvě různé věci budou identifikovány dvěma různými IRI.

Pro zajištění pořádku v přidělování IRI jednotlivým datovým entitám poskytovatelům doporučujeme si pro něj stanovit pravidla. Ta budou obsahovat specifikace použité domény a případné dělení prostoru cesty IRI jak mezi jednotlivé typy entit, tak např. dle administrativního uspořádání poskytovatele - např. po jednotlivých odděleních. Jednou přidělená IRI by měla být co nejstabilnější, aby se na ně mohli uživatelé dat spolehnout. Je tedy třeba je volit pečlivě, dle stanovených pravidel.

Ač jsou všechny položky v OFN vždy nepovinné, správné používání IRI pro identifikaci entit, o kterých data jsou, je velmi důležité, a mělo by být využito vždy - nic tomu totiž nebrání a výhody jsou jasné.

Data měnící se v čase

Data se v čase mění a při jejich publikaci na webu je třeba s tím počítat. Datové položky přibývají, ubývají a mění se, a uživatelé dat musí být schopni tyto skutečnosti snadno zjistit. Pro časový okamžik vytvoření či změny záznamu o věci jako např. o turistickém cíli, slouží položky Vytvořeno a Aktualizováno. Složitější situace je ale u informování uživatelů o zrušení záznamu o nějaké věci, což se liší podle předpokládané frekvence aktualizace datových sad - datové sady aktualizované občas a datové sady aktualizované často.

Datové sady aktualizované občas

Datovou sadou aktualizovanou občas je například seznam sportovišť či turistických cílů, kde se nepředpokládá, že by ubývaly a přibývaly třeba několikrát denně, nebo že by se již předem vědělo, do kdy je daný turistický cíl relevantní.

Pokud nějaká věc přibude, je pro uživatele snadné tuto skutečnost zjistit - v datech nalezne věc s novým IRI, kterou dříve neviděl. Pokud ale naopak některá věc zmizí, je třeba uživatele na tuto skutečnost explicitně upozornit. Jinak by totiž musel pokaždé kontrolovat celou datovou sadu oproti jejímu minulému stavu, zda nějaké věci nechybí, přičemž by nebylo jasné, zda chybějící věci například jen dočasně nevypadly z exportu. K explicitnímu označení odstraněné věci tedy slouží položka Zneplatněno, která obsahuje časový okamžik zneplatnění záznamu o věci. Použije se tak, že záznam o věci, například turistickém cíli, z datové sady nezmizí. Zůstane v ní navždy se svým IRI, jen místo všech ostatních položek zůstane pouze položka Zneplatněno. Uživatelům je tak jasné, že někdy existoval např. turistický cíl identifikovaný https://data.poskytovatel.cz/turistické-cíle/1234, ale byl zrušen. Této technice se někdy říká také tombstone - náhrobek.

Příklad:

{
    "iri": "https://data.poskytovatel.cz/hrady/Karlštejn",
    "typ": "Turistický cíl",
    "zneplatněno": {
        "typ": "Časový okamžik",
        "datum_a_čas": "2020-12-01T08:00:00+02:00"
    }
}

Datové sady aktualizované často

Datovou sadou aktualizovanou často je například seznam aktualit. U těch bývá dopředu jasné, jak dlouho jsou relevantní, a uživatelé předpokládají, že se datová sada bude měnit často. Nemá také smysl pro takovou datovou sadu navždy držet identifikátory již nerelevantních novinek jako v minulém případě, protože brzy by většina takové datové sady obsahovala již nerelevantní data.

V tomto případě se využije položka Relevantní do, která obsahuje časový okamžik, do kterého je daná věc relevantní. Tedy již v okamžiku přečtení takové položky si může uživatel naplánovat její opětovné smazání.

Katalogizace datové sady využívající OFN

V okamžiku, kdy máme datovou sadu dle OFN vypublikovánu jako soubor ke stažení na webu a máme ověřeno, že je validní vůči JSON schématu v dané OFN, je třeba datovou sadu zaregistrovat v Národním katalogu otevřených dat, kde je nutné uvést, že datová sada je publikována dle dané OFN. Podle této informace totiž budou datovou sadu hledat aplikace, které s daty dle této OFN budou umět pracovat. V aktuální verzi NKOD je třeba specifikovat URL konkrétní verze konkrétní otevřené formální normy, např. https://ofn.gov.cz/turistické-cíle/2020-07-01/ - jako odkaz na dokumentaci datové sady. V připravované aktualizaci NKOD již bude pro tento účel zvláštní pole Specifikace.