Abstrakt

Cílem tohoto dokumentu je stanovit konvence, jejichž dodržování usnadní vybudování ekosystému propojených otevřených dat v rámci veřejné správy České republiky. Propojená data představují nejvyšší standard publikace dat na webu a jeho dosažení odstraní řadu překážek ve využívání dat veřejné správy.

Dokument začíná principy propojených dat, dále stanovuje pravidla, jak mají v rámci České republiky vypadat identifikátory IRI jednak obecně, a jednak pro vybrané referenční entity. Dále je popsán datový model RDF a jeho serializace a pravidla pro přenos RDF dat pomocí protokolu HTTP(S) přes Internet. Diskutovány jsou vhodné slovníky pro vybrané typy dat a následně také pravidla pro metadata propojených dat. Na závěr doporučujeme formulace do smluv s dodavateli systémů pracujících s propojenými daty.

Úvod

Propojená data jsou ideální způsob publikace dat na webu. Jsou inspirována způsobem fungování dnešního webu složeného z webových stránek a jsou také podepřena řadou doporučení konsorcia W3C, které v této formě vydává webové de facto standardy. Cílem publikace dat jako propojených dat je odstraňovat překážky mezi publikací a užitím dat. Je toho dosahováno několika základními způsoby:

Globální identifikace a lokalizace datových entit
Žádný jiný způsob publikace dat na webu neumožňuje globální a jednoznačnou identifikaci a lokalizaci jednotlivých datových položek.
Sémantický popis dat
Žádný jiný způsob publikace dat nedosahuje takové úrovně popisu významu dat jako propojená data.
Jednotný formát
Propojená data používají jednotný formát reprezentace dat, což velmi usnadňuje práci s nimi.
Integrace
Propojená data jsou na web vystavována již integrována s jinými datovými zdroji pomocí linků. Toto přesouvá integrační zátěž od konzumenta dat k poskytovateli, který má pro integraci lepší znalosti a zdroje.

Aby bylo možno na tyto výhody dosáhnout, je třeba dodržovat základní sadu konvencí pro propojená data, které jsou popsány v tomto dokumentu. Podobný dokument pro svá propojená data vydala například standardizační organizace GS1.

Principy propojených dat

Propojená data (angl. Linked Data) je sada principů, které umožňují publikovat data na webu tak, že se mohou odkazovat na jiná data publikovaná tímto způsobem, a to jednotným způsobem, bez ohledu na zdroj ze kterého data pochází. Tuto sadu principů formuloval Tim Berners-Lee, vynálezce sítě WWW. Principy odpovídají tomu, jak funguje dnešní web dokumentů - webových stránek. Jsou 4 a zní takto:

  1. Všechny entity se pojmenovávají pomocí IRI.
  2. Používejte HTTP(S) IRI, aby mohli lidé a aplikace přistupovat k informacím o entitách pomocí stávajícího protokolu HTTP(S).
  3. Když někdo na takové IRI přistoupí, poskytněte data o entitě v RDF.
  4. Přidejte do dat odkazy na jiná, související data, aby se uživatelé mohli dozvědět více.

Pravidla pro tvorbu IRI

Identifikátor IRI je strukturovaný. V této sekci je jeho struktura popsána, spolu s pravidly pro jednotlivé části IRI, a to jak na obecné úrovni, tak konkrétně pro vybrané referenční datové sady. Sekce začíná vymezením pojmů URI, IRI a URL.

URI, IRI, URL

Tato část slouží k vyjasnění zkratek URI, IRI a URL.

URI - Uniform Resource Identifier

URI označuje typ identifikátoru, který je definovaný dokumentem RFC 3986 [[!rfc3986]]. Omezením tohoto typu identifikátoru je použitá znaková sada ASCII [[!rfc0020]], která umožňuje použití pouze znaků anglické abecedy. Byl používán, mimo jiné, v datovém modelu RDF verze 1.0, a je stále používán na nejnižší úrovni komunikace protokolem HTTP [[!rfc7540]].

IRI - Internationalized Resource Identifier

Identifikátor typu IRI definovaného v dokumentu RFC 3987 [[!rfc3987]] na rozdíl od URI umožňuje použití znaků kódování UTF-8, což umožňuje, aby součástí IRI byly např. znaky české abecedy. Je použit ve standardu RDF verze 1.1 používaném k publikaci propojených otevřených dat. Pro použití v protokolu HTTP jako URI se Unicode znaky kódují pomocí procentového kódování.

URL - Uniform Resource Locator

URL označuje URI nebo IRI použitelné nejen k identifikaci objektů, ale i k určení jejich umístění a způsobu přístupu k nim v rámci sítě Internet. Jedná se tedy zejména o funkční rozdíl, syntaxe je stejná. Definován je v nyní již zastaralém dokumentu RFC 1738 [[rfc1738]]. Aktuálně probíhá standardizace sjednocující pojmy URI, IRI a URL [[!URL]].

V příkladech uvedených v této specifikaci používáme IRI. Není zde tedy předpoklad, že by tato IRI fungovala jako URL a umožňovala dereferenci.

Obecná pravidla pro tvorbu IRI

Obecnou strukturu IRI ilustruje tento řetězec: schéma://doména/cesta/identifikátor.

Schéma IRI

  • Používá se HTTPS s výjimkou již existujících slovníků používajících HTTP.
  • Pro zajištění přístupu k reprezentaci zdroje identifikovaného pomocí HTTPS IRI je třeba mít TLS certifikát pro použití na webovém serveru. Lze využít vlastní SSL/TLS certifikáty (např. pro EV), nebo lze zdarma využít službu Let’s Encrypt.

Doménové jméno v IRI

  • Využije se nějaké, které má instituce pod kontrolou a tedy může zajistit přístup k reprezentaci zdroje identifikovaného IRI. Například tedy data.cssz.cz.
  • Vhodné subdomény jsou zejména lod, data, linked apod.
  • V současné době není možné využívat v doménových jménech pod doménou .cz diakritiku. Jedinou výjimkou je web, který se problematikou diakritiky v doménových jménech zabývá, https://www.háčkyčárky.cz. V jiných top level doménách diakritiku použít lze v rámci standardu IDN - Internationalized Domain Name a kódování Punycode [[rfc3492]].
  • V následujícím textu bude zvolenou doménu označovat <doména>.

Jazyková pravidla v cestě IRI

IRI by mělo sloužit jen jako rozlišující identifikátor zdrojů. Jako takový by se koncovým uživatelům nemělo zobrazovat. Místo něj se obvykle zobrazují lidsky čitelné názvy zaznamenané v datech daného zdroje. Z tohoto pohledu je jeho tvar irelevantní. Nicméně pro snadnější orientaci zejména vývojářů aplikací a datových analytiků je dobré být v tvorbě IRI konzistentní. Poskytovatele tedy čekají rozhodnutí popsaná v následujících částech, dále označovaná jako systém pojmenovávání.

Jazyk a diakritika

V cestě v IRI lze použít 4 varianty pojmenovávání. Jsou uvedeny v pořadí od nejvhodnějšího po nejméně vhodné.

České s diakritikou

Standard pro IRI je z roku 2004, IRI se jako identifikátor zdrojů v RDF používá od verze RDF 1.1 z roku 2014. Všechny moderní nástroje pro práci s RDF již s IRI počítají, a tedy není třeba se obávat použití diakritiky v cestě IRI. Pokud by nějaký nástroj s diakritikou v IRI pracovat neuměl, není možné ho považovat za vhodný, a tento nedostatek by měl být nahlášen tvůrcům nástroje k řešení.

Použití češtiny v cestě IRI má několik výhod, a to zejména menší počet nutných transformací pro jeho tvorbu, lepší čitelnost a zabránění duplicit vzniklých vynecháním diakritiky. Zejména pro klíčové datové sady infrastruktury propojených dat veřejné správy je tato varianta nejvhodnější.

Anglické

Pro datové sady, u nichž se počítá s tím, že s nimi v hojné míře budou pracovat zahraniční vývojáři aplikací, lze použít v cestě IRI anglické ekvivalenty. Zábranou zde může být absence dostupného kvalifikovaného překladu do angličtiny.

České bez diakritiky

Tuto variantu použijte jen v případě nutnosti. Všechny relevantní nástroje by měly být schopny pracovat s kódováním UTF-8 v IRI. Pokud potřebujete pracovat s nástrojem, který toto neumí, je třeba se v první řadě pokusit nástroj opravit, chybu v něm nahlásit, a až v pokud není zbytí, podřídit pravidla tvorby IRI a zvolit pro ně češtinu bez diakritiky.

Kombinované

Tuto variantu použijte jen v případě nutnosti. Všechny relevantní nástroje by měly být schopny pracovat s kódováním UTF-8 v IRI. Pokud potřebujete pracovat s nástrojem, který toto neumí, je třeba se v první řadě pokusit nástroj opravit, chybu v něm nahlásit, a až v pokud není zbytí, podřídit pravidla tvorby IRI a zvolit pro ně češtinu bez diakritiky.

Jednotné a množné číslo

Další rozhodnutí se bude týkat toho, zda se v cestě IRI bude používat pro druh či seznam entit množné či jednotné číslo. Varianty:

  • https://<doména>/zdroj/datové-sady/1
  • https://<doména>/zdroj/datová-sada/1
  • https://<doména>/resource/dataset/1
  • https://<doména>/resource/datasets/1

Varianta v množném čísle je vhodnější vzhledem ke kompatibilitě s principy REST API, které se uplatňují u systémů postavených nad specifikací Linked Data Platform [[LDP]]. Tam se používá IRI kontejneru https://<doména>/zdroj/datové-sady pro získání seznamu jeho členů, např https://<doména>/zdroj/datové-sady/1.

Styl nahrazování mezer

Mezera není povolený znak v IRI. Pro víceslovné názvy věcí je tedy nutné zvolit systém pro jejich reprezentaci, přičemž lze zvolit různý styl pro různé příležitosti. Vybrat lze z následujících stylů:

  • UpperCamelCase
  • lowerCamelCase
  • train-case, kebap-case
  • snake_case

Umístění, pro která je třeba jeden ze stylů zvolit, jsou:

  • Část IRI reprezentující množinu věcí
    • https://<doména>/zdroj/DatovéSady/1
    • https://<doména>/zdroj/datovéSady/1
    • https://<doména>/zdroj/datové-sady/1
  • Část IRI reprezentující třídu
    • https://<doména>/slovník/DatováSada
    • https://<doména>/slovník/Datová-sada
  • Část IRI reprezentující vlastnost
    • https://<doména>/slovník/id-transakce
    • https://<doména>/slovník/IdTransakce
  • Část IRI reprezentující pojmenovanou věc
    • https://<doména>/zdroj/MojeDatováSada
    • https://<doména>/zdroj/Moje-datová-sada
    • https://<doména>/zdroj/moje-datová-sada

Část cesty IRI první úrovně

V části cesty IRI první úrovně se rozlišují identifikátory následujících typů RDF zdrojů:

  • slovníky,
  • datové instance,
  • další...
Základ IRI pro RDF zdroje popisující prvky slovníků

Všechna IRI RDF zdrojů popisující prvky slovníků začínají:

  • https://<doména>/slovník/ při použití češtiny
  • https://<doména>/ontology/ při použití angličtiny
Základ IRI pro RDF zdroje popisující datové instance

Všechna IRI RDF zdrojů popisujících datové instance začínají:

  • https://<doména>/zdroj/ při použití češtiny
  • https://<doména>/resource/ při použití angličtiny

Část cesty druhé úrovně v IRI

V části cesty IRI druhé úrovně se nachází IRI slug názvu typu datové entity vytvořený dle zvoleného systému pojmenovávání.

Části cesty dalších úrovní v IRI

Další části cesty v IRI odpovídají principům hierarchického IRI, nebo jeho zkrácené verzi.

Zkracování cesty v IRI

Pro některé typy hierarchických struktur lze v cestě IRI použít zkratku, pokud nezpůsobí kolizi IRI pro různé entity.

Pravidla pro tvorbu části identifikátoru v IRI

Poslední část IRI je identifikátor dané entity, který jí odliší od ostatních entit daného typu, se stejnou cestou IRI. Příkladem pro datovou sadu může být identifikátor 3757779, ze kterého pak vznikne IRI konkrétní datové sady: https://data.gov.cz/zdroj/datová-sada/3757779.

Existují 3 typy identifikátorů, které lze na tomto místě použít, přičemž platí, že čím stálejší a ze znalosti identifikované entity odvoditelnější, tím lepší.

Umělý identifikátor

Zdrojová data o entitách často již obsahují nějaké umělé identifikátory entit - identifikátory, které nijak nesouvisí s vlastnostmi entity v reálném světě a vznikají zanesením záznamu o entitě například do databáze. Pokud jsou tyto identifikátory dostatečně neměnné, lze je použít pro tvorbu IRI.

Identifikátor vytvořený z dat

Pokud není k dispozici žádný umělý identifikátor entity, je třeba vytvořit unikátní IRI z dat, které jsou k dispozici. Příkladem může být IRI pro pozorování, jehož identifikátor prum-vek-u-nove-priznanych-duchodu-dle-druhu/2015/pk_pensions_t1/t vznikl spojením IRI slugu názvu datové kostky a IRI slugů hodnot na dimenzích, které ho identifikují: https://data.cssz.cz/resource/observation/prum-vek-u-nove-priznanych-duchodu-dle-druhu/2015/pk_pensions_t1/t.

Pokud je potřeba tvořit IRI slug z volného textu, je třeba dbát na to, že například mezera není povolený znak v IRI. Hodit se může funkce jazyka SPARQL ENCODE_FOR_URI, která z volného textu dělá text použitelný v IRI. Identifikátor lze vytvořit také například z pořadí elementu ve zdrojových XML datech nebo z pořadí řádku ve zdrojové tabulce.

Náhodný identifikátor

Pokud žádná z výše uvedených možností není proveditelná, poslední a nejhorší možností je použití náhodného identifikátoru. Ten od sebe sice rozliší entity, ale je nestabilní, tj. při každém generování dat se pro jednu entitu vytvoří jiný identifikátor. Pro generování náhodných identifikátorů se hodí GUID/UUID, například 12793f14-57a6-4077-aba6-2558114b3da2, který pak lze použít v IRI entity: https://data.gov.cz/zdroj/datová-sada/12793f14-57a6-4077-aba6-2558114b3da2.

Pro generování náhodného identifikátoru v jazyce SPARQL lze využít funkci STRUUID.

Pravidla pro tvorbu IRI vybraných objektů pro přístup k datům

Kromě pravidel pro IRI datových entit je dobré mít i pravidla pro URL pro přístup k datům.

IRI SPARQL endpointu

Doporučeným URL pro SPARQL endpoint je https://<doména>/sparql.

Datová sada ke stažení

Pro danou datovou sadu ke stažení jsou doporučená URL:

  • https://<doména>/soubor/<id-datové-sady>.<přípony>
  • https://<doména>/dump/<id-datové-sady>.<přípony>

Kde přípona se volí dle zvolené RDF serializace:

  • .ttl pro Turtle [[!turtle]]
  • .trig pro TriG [[!trig]]
  • .jsonld pro JSON-LD [[!json-ld]]
  • .nt pro N-Triples [[!n-triples]]
  • .nq pro N-Quads [[!n-quads]]
  • .rdf pro RDF/XML [[!rdf-syntax-grammar]]

Volitelně lze soubory ke stažení komprimovat pomocí Gzip, což přidává druhou příponu .gz.

IRI zdrojů v referenčních datových sadách

V této sekci definujeme pravidla pro tvorbu IRI entit ve vybraných referenčních datových sadách. Tato IRI jsou jednoznačným, globálním identifikátorem těchto entit a je třeba je používat ve všech otevřených datech, která se na ně jakkoliv odkazují - propojených i nepropojených.

Registr územní identifikace, adres a nemovitostí (RÚIAN)

Pro Registr územní identifikace, adres a nemovitostí (RÚIAN) jsou stanovena Metadatovým profilem ČR verze 4.0 pravidla tvorby IRI pro jednotlivé typy prvků. Datové sady v podobě propojených dat se na objekty RÚIAN odkazují výhradně pomocí těchto IRI. Tato pravidla jsou následující:

  1. Šablonou IRI je: https://linked.cuzk.cz/resource/ruian/<zkratka>/<kód>
  2. <zkratka> je část cesty IRI pro typ prvku RÚIAN
  3. <kod> je část cesty IRI pro kód prvku RÚIAN

Prvky RÚIAN s přiřazenými IRI jsou následující:

Adresní místo
Zkratka: adresni-misto
Příklad IRI: https://linked.cuzk.cz/resource/ruian/adresni-misto/16135661
Část obce
Zkratka: cast-obce
Příklad IRI: https://linked.cuzk.cz/resource/ruian/cast-obce/40151
Katastrální území
Zkratka: katastralni-uzemi
Příklad IRI: https://linked.cuzk.cz/resource/ruian/katastralni-uzemi/539643
Kraj (1960)
Zkratka: kraj-1960
Příklad IRI: https://linked.cuzk.cz/resource/ruian/kraj-1960/31
Městská část/obvod
Zkratka: momc
Příklad IRI: https://linked.cuzk.cz/resource/ruian/momc/501298
Městský obvod Prahy
Zkratka: mop
Příklad IRI: https://linked.cuzk.cz/resource/ruian/mop/108
Obec, vojenský újezd
Zkratka: obec
Příklad IRI: https://linked.cuzk.cz/resource/ruian/obec/502235
Okres
Zkratka: okres
Příklad IRI: https://linked.cuzk.cz/resource/ruian/okres/3209
Správní obvod obce s rozšířenou působností
Zkratka: orp
Příklad IRI: https://linked.cuzk.cz/resource/ruian/orp/19
Parcela
parcela
Příklad IRI: https://linked.cuzk.cz/resource/ruian/parcela/17099648010
Správní obvod obce s pověřeným obecním úřadem
pou
Příklad IRI: https://linked.cuzk.cz/resource/ruian/pou/3727
Region soudržnosti
Zkratka: region-soudrznosti
Příklad IRI: https://linked.cuzk.cz/resource/ruian/region-soudrznosti/19
Základní sídelní jednotka
Zkratka: zsj
Příklad IRI: https://linked.cuzk.cz/resource/ruian/zsj/40151
Správní obvod Prahy
Zkratka: spravni-obvod
Příklad IRI: https://linked.cuzk.cz/resource/ruian/spravni-obvod/108
Stát
Zkratka: stat
Příklad IRI: https://linked.cuzk.cz/resource/ruian/stat/1
Stavební objekt
Zkratka: stavebni-objekt
Příklad IRI: https://linked.cuzk.cz/resource/ruian/stavebni-objekt/16016696
Ulice
Zkratka: ulice
Příklad IRI: https://linked.cuzk.cz/resource/ruian/ulice/425320
Volební okrsek
Zkratka: volebni-okrsek
Příklad IRI: https://linked.cuzk.cz/resource/ruian/volebni-okrsek/26651
Kraj (VÚSC)
Zkratka: vusc
Příklad IRI: https://linked.cuzk.cz/resource/ruian/vusc/108

Registr práv a povinností (RPP)

IRI pro entity z registru práv a povinností nejsou v době psaní tohoto výstupu fixovány. Nicméně je třeba počítat při tvorbě propojených dat s tím, že fixovány budou a tento vývoj sledovat.

Registr osob (ROS)

IRI pro entity z registru osob nejsou v době psaní tohoto výstupu fixovány. Nicméně je třeba počítat při tvorbě propojených dat s tím, že fixovány budou a tento vývoj sledovat.

Číselníky z Evropských slovníků (EU Vocabularies)

Web EU Vocabularies (evropské slovníky) zastřešuje sadu řízených číselníků a tezaurus EuroVoc. Položky z těchto číselníků je třeba používat všude kde to dává smysl, tedy všude, kde data obsahují koncept pokrytý daným číselníkem. Aktuálně existující číselníky zahrnují následující témata (anglické názvy):

Datový model RDF pro reprezentaci propojených dat

Pro reprezentaci propojených dat se používá datový model RDF - Resource Desrciption Framework [[!rdf11-concepts]]. Aktuální verze 1.1 byla vydána konsorciem W3C v roce 2014. Jedná se o grafový datový model, tj. data jsou reprezentována jako uzly a hrany v grafu, kde uzly reprezentují entity a datové hodnoty, a hrany reprezentují jejich propojení. Takový graf se dá popsat pomocí množiny trojic <uzel 1, hrana, uzel 2>, které říkají, že existuje entita uzel 1, existuje entita uzel 2 a jsou propojeny hranou hrana. V RDF se jednotlivým částem každé trojice říká subjekt, predikát a objekt, a trojice říká, že objekt je hodnotou vlastnosti predikát nějaké entity subjekt. Objektem může být primitivní hodnota (řetězec, datum, číslo, …) nazývaná literál, nebo jiná entita. Subjektem je vždy entita. Entity a predikáty identifikujeme pomocí jejich IRI.

Tímto způsobem lze reprezentovat jakákoliv data v RDF.

Serializace RDF

Popsaný datový model je třeba umět serializovat, tj. zapsat například do souboru, nebo v nějaké formě přenést přes Internet. Standardních serializací RDF je 7 a v této sekci jsou stručně představeny. Jejich plná dokumentace je dána jejich specifikací.

N-Triples

Serializace N-Triples [[!n-triples]] je doporučení konsorcia W3C z roku 2014. Jedná se o nejpřímočařejší RDF serializaci, která je již ukázána na příkladu v minulé sekci. IRI jednotlivých částí trojice se uzavřou do ostrých závorek < a > a trojice se ukončí tečkou. Pokud je objektem literál, uzavře se jeho hodnota do uvozovek ". IRI datového typu literálu se připojuje za znaky ^^. Tedy:

Soubor s RDF serializací N-Triples má příponu .nt. Tato serializace se hodí tam, kde záleží na jednoduchosti a rychlosti zpracování a nezáleží tolik na lidské čitelnosti a na velikosti dat.

Turtle

Serializace Turtle [[!turtle]] je doporučení konsorcia W3C z roku 2014. V serializaci N-Triples se řada IRI nebo jejich částí neustále opakuje, navíc tato serializace není příliš čitelná pro lidi. Serializace Turtle tedy přidává optimalizace vedoucí k lepší lidské čitelnosti a úspoře počtu znaků. Znak středník ; říká, že následující trojice má stejný subjekt jako aktuální, a tedy stačí specifikovat pouze nový predikát a objekt.

Znak čárka , říká, že následující trojice má stejný jak subjekt, tak predikát a tedy stačí specifikovat pouze nový objekt.

Dále se stále opakují některé části IRI, například ty, které identifikují predikáty z jednoho slovníku, nebo entity patřící do stejného nadřazeného prvku. Pro tyto případy serializace Turtle zavádí tzv. prefix - krátce pojmenovaná část IRI, kterou lze použít pro zkrácený zápis IRI v dokumentu.

Soubor s RDF serializací Turtle má příponu .ttl.

N-Quads

Serializace N-Quads [[!n-quads]] je doporučení konsorcia W3C z roku 2014 a rozšiřuje serializaci N-Triples o čtvrtou složku, IRI pojmenovaného grafu, do kterého daná trojice patří. V následujícím příkladu obě trojice patří do stejného pojmenovaného grafu s IRI <https://sociálnísíť.cz/uživatelé> .

Soubor s RDF serializací N-Quads má příponu .nq.

TriG

Serializace TriG [[!trig]] je doporučení konsorcia W3C z roku 2014. Stejně jako serializace Turtle zavádí zkratky do serializace N-Triples, serializace TriG stejným způsobem rozšiřuje serializaci N-Quads. Jedná se tedy zároveň o rozšíření serializace Turtle o podporu pojmenovaných grafů.

Soubor s RDF serializací TriG má příponu .trig.

JSON-LD

Serializace JSON-LD [[json-ld]] je doporučení konsorcia W3C z roku 2014. Jedná se o serializaci RDF v syntaxi JavaScript Object Notation (JSON) [[!ECMA-404]], která je již známa velkému počtu stávajících vývojářů webových aplikací. Hlavní motivací pro tuto serializaci je tedy možnost poskytovat jedním způsobem propojená data jak vývojářům, kteří znají pouze JSON, tak vývojářům znalým technologií propojených dat. Mapování hodnot z JSON do RDF je specifikováno v klíči @context, který mohou JSON vývojáři ignorovat.

Soubor s RDF serializací JSON-LD má příponu .jsonld.

RDF/XML

Serializace RDF/XML [[!rdf-syntax-grammar]] je doporučení konsorcia W3C z roku 2014 a specifikuje, jak zapsat datový model RDF do XML dokumentů. Historicky se jedná o první RDF serializaci, nicméně v dnešní době ztrácí na významu, jelikož je lidsky poměrně nečitelná, přidává složitost pravidel pro XML dokumenty a zpracování softwarem, který rozumí XML ale nerozumí RDF se již nepředpokládá.

Soubor s RDF serializací RDF/XML má příponu .rdf.

RDFa

Serializace RDFa [[!rdfa-core]] je doporučení konsorcia W3C z roku 2015 a specifikuje, jak lze datový model RDF zapsat do atributů běžných HTML dokumentů [[html53]]. To nalezne uplatnění tam kde je požadováno, aby lidsky čitelný zápis v HTML byl doplněn o strojově čitelné informace ve stejném dokumentu, s minimalizací opakování stejných dat pro obě reprezentace. Následuje příklad úryvku HTML dokumentu anotovaného pomocí RDFa.

Pravidla pro přenos propojených dat po Internetu

Propojená data staví na existujících principech uplatňovaných na dnešním webu lidsky čitelných dokumentů - webových stránek. Pro přenos dat je tedy používán protokol HTTP [[rfc7540]], avšak v řadě případů je jeho použití nedostatečné, či dokonce chybné. Jedná se zejména o správný obsah HTTP hlavičky Content-Type, který musí odpovídat formátu přenášených dat. Při přenosu RDF dat se tedy uplatňují následující hodnoty, dle použité RDF serializace:

Dále by měla hlavička Content-Type obsahovat explicitní specifikaci použitého UTF-8 kódování. Celá tedy pak vypadá například takto: text/turtle;charset=utf-8.

Vzhledem k tomu, že RDF serializace jsou textové dokumenty, je vhodné používat při jejich přenosu kompresi, například gzip [[rfc1952]]. Komprimovaný obsah pak doprovází hlavička Content-Encoding s hodnotou gzip.

V rámci protokolu HTTP může klient požadovat data v konkrétní RDF serializaci, například pokud jde o SPARQL dotaz zaslaný na SPARQL endpoint či webový server zprostředkovávající dereferenci IRI zdroje - poskytnutí RDF dat při přístupu na dané IRI. Ten by měl rozumět HTTP hlavičce Accept s hodnotou specifikující MIME typ požadované serializace.

Pravidla pro výběr slovníků pro vybrané typy dat

V minulých sekcích tohoto dokumentu je popsán datový model RDF, jeho serializace a způsob přenosu takových dat po Internetu. Nedílnou součástí propojených dat je ale i standardizace jejich obsahu pomocí tzv. slovníků - popisů významu jednotlivých tříd a predikátů pro daný typ dat.

Obecným pravidlem pro tvorbu reprezentace propojených dat je, že je třeba se snažit data pokrývat především již existujícími slovníky. Teprve v případě, že ještě neexistuje vhodný slovník pro popis nějaké části publikovaných dat, je možné si dodefinovat svůj slovník, který je ovšem třeba opět řádně publikovat, aby ho mohli použít ostatní. Pro vyhledání existujících slovníků existuje registr Linked Open Vocabularies (LOV). Nejvíce používané typy dat a slovníky pro jejich reprezentaci jsou ilustrovány v následujících kapitolách. Závazné jsou však jejich originální specifikace.

Číselníky - Simple Knowledge Organization System (SKOS)

Číselníkem je typicky plochý seznam položek, kde každá má minimálně kód a název. Číselníky se mohou používat například jako seznam možných hodnot pro různé vlastnosti datových entit, což lze využít pro formuláře pro zadávání dat, aplikace vizualizující data apod. Pro reprezentaci číselníků v propojených datech se používá slovník SKOS.

Simple Knowledge Organization System (SKOS) [[!skos-reference]] je doporučení W3C z roku 2009. Základním stavebním kamenem je třída skos:Concept, která reprezentuje obecnou myšlenku. V kontextu číselníků reprezentuje jednu položku číselníku. Třída skos:ConceptScheme pak reprezentuje číselník jako celek, a jednotlivé položky jsou do něj přiřazeny pomocí predikátu skos:inScheme. Každá položka číselníku má svůj kód (skos:notation), který se typicky používá i pro poslední část jejího IRI, a sadu názvů:

Pomocí slovníku SKOS lze zachytit kromě plochých seznamů i hierarchie. Položky se do hierarchie seskupují pomocí následujících predikátů:

Statistická data - The RDF Data Cube Vocabulary

The RDF Data Cube Vocabulary (DCV) [[!vocab-data-cube]] je doporučení W3C z roku 2014 pro reprezentaci datových kostek v datovém modelu RDF. Datový model DCV je kompatibilní s datovým modelem SDMX. Základním stavebním kamenem je třída qb:Observation reprezentující pozorování. Pozorování je identifikováno pomocí hodnot na dimenzích (qb:DimensionProperty) datové kostky. Naměřené hodnoty jsou k pozorování připojeny pomocí měr (qb:MeasureProperty), a každá hodnota pozorování může být dále specifikována pomocí atributů (qb:AttributeProperty). Množina pozorování se stejnými dimenzemi, mírami a atributy tvoří datovou kostku. Specifikace datové struktury (qb:DataStructureDefinition) kostky říká, jaké dimenze, míry a atributy datová kostka používá.

V příkladu je uvedeno jedno pozorování eg:o3 patřící do datové kostky eg:dataset-le1. Jedná se o očekávanou dobu dožití eg:lifeExpectancy pro muže (hodnota sdmx-code:sex-M dimenze sdmx-dimension:sex), v kraji Monmouthshire (hodnota ex-geo:monmouthshire_00pp dimenze eg:refPeriod) mezi roky 2004 a 2007 (hodnota http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y dimenze eg:refPeriod).

Metadata

Stejně důležitý jako samotný obsah datových sad je jejich správný metadatový popis.

DCAT, DCAT-AP

Data Catalog Vocabulary (DCAT) [[!vocab-dcat]] je doporučení W3C z roku 2014.

Evropská unie si doporučení DCAT přizpůsobila tzv. aplikačním profilem DCAT-AP v1.2 [[!dcat-ap]], který blíže specifikuje jednak to, které číselníky se mají používat pro které vlastnosti, a také to, které vlastnosti jsou povinné, doporučené a volitelné. Česká republika se řídí tímto standardem, a pro publikaci propojených dat se tedy doporučuje tato data popisovat pomocí DCAT-AP v1.2. Národní katalog otevřených dat (NKOD) používá tento standard pro reprezentaci metadat o datových sadách. Pro příklad popisu datové sady dle DCAT-AP v1.2 slouží právě NKOD.

VoID

VoID je poznámka zájmové skupiny [[!void]] v rámci W3C z roku 2011. Datové sady propojených dat se krom DCAT a DCAT-AP v1.2 dále popisují dle slovníku VoID, který poskytuje detailnější vlastnosti pro popis propojených dat. Zejména umožňuje popsat přístup k datům přes SPARQL endpoint, ukázat na vzorovou entitu v datové sadě a případně také zaznamenat statistky o datové sadě, jako jsou počty trojic, počty tříd, počty vlastností apod.

Obvykle se IRI RDF distribuce popsané DCAT-AP použije i jako IRI datové sady popsané slovníkem VoID z praktických důvodů i přesto, že toto použití vykazuje jisté známky sémantické nekonzistence.

Slovníky

Slovníky samotné jsou také strojově čitelná RDF data, stejně jako každá jiná propojená data. Pro definici jednotlivých slovníků se také používají slovníky - jednodušší RDF Schema (RDFS) [[!rdf-schema]] a složitější Web Ontology Language (OWL) [[!owl2-overview]].

RDF Schema

RDF Schema 1.1 [[!rdf-schema]] je doporučení W3C z roku 2014 a slouží k jednoduchému popisu tříd a vlastností a také k tvorbě jednoduchých hierarchií dědičnosti tříd a vlastností. Ke každé třídě a vlastnosti je možno specifikovat její název a popis, pro vlastnosti pak navíc definiční obor a obor hodnot.

V příkladu je definice vlastnosti "Počet podlaží", její název, definiční obor (stavební objekt) a obor hodnot, kterým je kladné celé číslo.

OWL

Web Ontology Language 2 [[!owl2-overview]] je doporučení W3C z roku 2012 pro tvorbu ontologií. Umožňuje modelovat i velmi složité sémantické vztahy. V prostředí propojených dat se nejvíce používá predikát owl:sameAs, který říká, že 2 IRI identifikují stejnou entitu reálného světa. Toto užití je ilustrováno následujícím příkladem.

Doporučení pro zadavatele systémů podporujících publikaci dat v podobě propojených dat

Relevantní specifikace a zdroje informací pro každého dodavatele jsou tato otevřená formální norma a všechny její normativní reference.

Vzory pro tvorbu IRI

Nedílnou součástí návrhu reprezentace 5* otevřených dat jsou pravidla pro tvorbu IRI RDF zdrojů. Měla by zahrnovat zejména doménu, na které budou data v RDF podobě dostupná a dále pravidla pro tvorbu dalších částí IRI. Ty obsahují zejména informaci zda se používá angličtina, nebo čeština, jak se rozliší zdroje od definic tříd a vlastností ve slovnících, jak se vytváří části IRI tvořené více slovy, např. pomocí kebap-case, apod.

Použití slovníků dle Linked Open Vocabularies

Při návrhu 5* reprezentace otevřených dat je třeba pečlivě zvažovat, jakými třídami a vlastnostmi budou data modelována. Speciálně platí pravidlo, že pokud už někdo nějakou třídu či vlastnost definoval a používá, a tato významem sedí na publikovaná data, je vhodné ji použít a nikoliv definovat vlastní. Tím se zvyšuje použitelnost této části publikovaných dat. Takto tvořené slovníky jsou zpravidla registrovány na serveru Linked Open Vocabularies, ty nejpoužívanější jsou pak publikovány konsorciem W3C.

Publikace a dostupnost vlastnoručně definovaných vlastností a tříd

Pokud se při návrhu 5* reprezentace otevřených dat definují nové vlastnosti a nové třídy, je třeba je řádně popsat pomocí slovníku RDFS či OWL a tento popis taktéž vystavit v podobě 5* otevřených dat. Pokud jsou tyto třídy a vlastnosti takové povahy, že by je mohl použít i někdo jiný, je vhodné je také opatřit metadaty a zaregistrovat na serveru Linked Open Vocabularies (LOV).

Dostupnost souborů ke stažení

Základním způsobem zveřejňování 5* otevřených dat je jejich poskytnutí ve formě RDF dumpu, tj. souboru ke stažení v jedné ze standardních RDF serializací, tj. Turtle, TriG či JSON-LD. Volitelně může být použita komprese gzip.

Dostupnost SPARQL endpointu

Publikace 5* otevřených dat v podobě veřejného SPARQL endpointu může být velmi náročná na hardwarové prostředky, a není bezpodmínečně nutná, uživatelé 5* otevřených dat si mohou stáhnout RDF dump a použít pro dotazování vlastní SPARQL endpoint. Pokud bude SPARQL endpoint vyžadován, pak lze použít tento text.

Dereferencovatelnost IRI RDF zdrojů

Při přístupu na IRI RDF zdroje si klient znalý 5* reprezentace otevřených dat říká i o RDF serializaci, ve které si přeje data dostat, a to pomocí hlavičky Accept protokolu HTTP, ve které uvede požadovaný Media type (MIME Type), např. text/turtle. Stejného principu lze použít i pro prezentaci 5* dat v lidsky čitelné HTML podobě, kdy při přístupu na IRI RDF zdroje uvede webový prohlížeč v Accept hlavičce HTML Media Type, tj. text/html.