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.
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:
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.
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:
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.
Tato část slouží k vyjasnění zkratek URI, IRI a URL.
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]].
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 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.
Obecnou strukturu IRI ilustruje tento řetězec: schéma://doména/cesta/identifikátor.
data.cssz.cz.
lod, data, linked apod.
<doména>.
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í.
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é.
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ší.
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.
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.
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.
České s diakritikou
Anglické
České bez diakritiky
Kombinované
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/1https://<doména>/zdroj/datová-sada/1https://<doména>/resource/dataset/1https://<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.
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ů:
UpperCamelCaselowerCamelCasetrain-case, kebap-casesnake_caseUmístění, pro která je třeba jeden ze stylů zvolit, jsou:
https://<doména>/zdroj/DatovéSady/1https://<doména>/zdroj/datovéSady/1https://<doména>/zdroj/datové-sady/1https://<doména>/slovník/DatováSadahttps://<doména>/slovník/Datová-sadahttps://<doména>/slovník/id-transakcehttps://<doména>/slovník/IdTransakcehttps://<doména>/zdroj/MojeDatováSadahttps://<doména>/zdroj/Moje-datová-sadahttps://<doména>/zdroj/moje-datová-sadaV části cesty IRI první úrovně se rozlišují identifikátory následujících typů RDF zdrojů:
Všechna IRI RDF zdrojů popisující prvky slovníků začínají:
https://<doména>/slovník/ při použití češtinyhttps://<doména>/ontology/ při použití angličtinyVšechna IRI RDF zdrojů popisujících datové instance začínají:
https://<doména>/zdroj/ při použití češtinyhttps://<doména>/resource/ při použití angličtinyV čá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í.
Další části cesty v IRI odpovídají principům hierarchického IRI, nebo jeho zkrácené verzi.
Pro některé typy hierarchických struktur lze v cestě IRI použít zkratku, pokud nezpůsobí kolizi IRI pro různé entity.
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ší.
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.
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.
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.
Kromě pravidel pro IRI datových entit je dobré mít i pravidla pro URL pro přístup k datům.
Doporučeným URL pro SPARQL endpoint je https://<doména>/sparql.
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.
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.
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í:
https://linked.cuzk.cz/resource/ruian/<zkratka>/<kód><zkratka> je část cesty IRI pro typ prvku RÚIAN<kod> je část cesty IRI pro kód prvku RÚIANPrvky RÚIAN s přiřazenými IRI jsou následující:
adresni-mistohttps://linked.cuzk.cz/resource/ruian/adresni-misto/16135661cast-obcehttps://linked.cuzk.cz/resource/ruian/cast-obce/40151katastralni-uzemihttps://linked.cuzk.cz/resource/ruian/katastralni-uzemi/539643kraj-1960https://linked.cuzk.cz/resource/ruian/kraj-1960/31momchttps://linked.cuzk.cz/resource/ruian/momc/501298mophttps://linked.cuzk.cz/resource/ruian/mop/108obechttps://linked.cuzk.cz/resource/ruian/obec/502235okreshttps://linked.cuzk.cz/resource/ruian/okres/3209orphttps://linked.cuzk.cz/resource/ruian/orp/19https://linked.cuzk.cz/resource/ruian/parcela/17099648010https://linked.cuzk.cz/resource/ruian/pou/3727region-soudrznostihttps://linked.cuzk.cz/resource/ruian/region-soudrznosti/19zsjhttps://linked.cuzk.cz/resource/ruian/zsj/40151spravni-obvodhttps://linked.cuzk.cz/resource/ruian/spravni-obvod/108stathttps://linked.cuzk.cz/resource/ruian/stat/1stavebni-objekthttps://linked.cuzk.cz/resource/ruian/stavebni-objekt/16016696ulicehttps://linked.cuzk.cz/resource/ruian/ulice/425320volebni-okrsekhttps://linked.cuzk.cz/resource/ruian/volebni-okrsek/26651vuschttps://linked.cuzk.cz/resource/ruian/vusc/108IRI pro entity z registru práv a povinností jsou definovány následujícím seznamem.
https://rpp-opendata.egon.gov.cz/odrpp/zdroj/agenda/A[kód agendy]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/agenda/A1046https://rpp-opendata.egon.gov.cz/odrpp/zdroj/činnost/A[kód agendy]/CR[kód činnosti]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/činnost/A1046/CR6072https://rpp-opendata.egon.gov.cz/odrpp/zdroj/orgán-veřejné-moci/[identifikátor orgánu veřejné moci]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/orgán-veřejné-moci/00007064https://rpp-opendata.egon.gov.cz/odrpp/zdroj/datová-schránka/[identifikátor datové schránky]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/datová-schránka/6bnaawphttps://rpp-opendata.egon.gov.cz/odrpp/zdroj/pracoviště/[číslo pracoviště]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/pracoviště/5953https://rpp-opendata.egon.gov.cz/odrpp/zdroj/soukromoprávní-uživatel-údajů/[identifikátor soukromoprávního uživatele údajů]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/soukromoprávní-uživatel-údajů/28195604.9999https://rpp-opendata.egon.gov.cz/odrpp/zdroj/kategorie-ovm/[identifikátor kategorie]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/kategorie-ovm/KO13https://rpp-opendata.egon.gov.cz/odrpp/zdroj/kategorie-spuú/[identifikátor kategorie]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/kategorie-spuú/KU4https://rpp-opendata.egon.gov.cz/odrpp/zdroj/A[kód agendy]/CR[kód činnosti]/[identifikátor orgánu veřejné moci]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/A[kód agendy]/CR[kód činnosti]/[identifikátor soukromoprávního uživatele údajů]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/role/A4293/CR49389/00007064https://rpp-opendata.egon.gov.cz/odrpp/zdroj/úkon/U[identifikátor úkonu]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/úkon/U61https://rpp-opendata.egon.gov.cz/odrpp/zdroj/působnost/A[kód agendy]/[identifikátor orgánu veřejné moci]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/působnost/A[kód agendy]/[identifikátor soukromoprávního uživatele údajů]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/působnost/A397/00509671https://rpp-opendata.egon.gov.cz/odrpp/zdroj/smlouva/[identifikátor smlouvy]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/smlouva/811/2016/OVVhttps://rpp-opendata.egon.gov.cz/odrpp/zdroj/rozhodnutí/[číslo jednací]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/rozhodnutí/19/2/2016https://rpp-opendata.egon.gov.cz/odrpp/zdroj/objekt-subjekt/[kód objektu nebo subjektu údajů]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/objekt-subjekt/101-1https://rpp-opendata.egon.gov.cz/odrpp/zdroj/údaj/[kód údaje]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/údaj/101-1-1https://rpp-opendata.egon.gov.cz/odrpp/zdroj/oprávnění-k-přístupu-k-údajům/A[kód agendy]-A[kód objektu nebo subjektu údajů]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/oprávnění-k-přístupu-k-údajům/A1046-A101-1https://rpp-opendata.egon.gov.cz/odrpp/zdroj/oprávnění-k-přístupu-k-údajům/A[kód agendy]-A[kód objektu nebo subjektu údajů]/[kód údaje]https://rpp-opendata.egon.gov.cz/odrpp/zdroj/oprávnění-k-přístupu-k-údaji/A1046-A101-1/101-1-1IRI 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.
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):
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.
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í.
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.
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.
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.
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.
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.
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.
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.
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é.
Content-Type
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:
application/n-triplestext/turtleapplication/n-quadsapplication/trigapplication/ld+jsonapplication/rdf+xml
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.
Content-Encoding
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.
Accept
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.
Pro propojená otevřená data platí, že jednotlivé zdroje a přístupové body (SPARQL endpointy) musí podporovat techniku Cross-Origin Resource Sharing (CORS) (anglicky), která umožňuje přístup k datům aplikacím běžícím ve webovém prohlížeči. Pokud technika podporována není, jedná se o špatnou praxi, jelikož je to překážou ve volném použití 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í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ů:
skos:prefLabel)skos:altLabel)skos:hiddenLabel)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ů:
<p1> skos:narrower <p2> - položka p2 je významově užší než položka p1skos:narrowerTransitive - jako skos:narrower, ale platí tranzitivně<p1> skos:broader <p2> - položka p2 je významově širší než položka p1skos:broaderTransitive - jako skos:broader, ale platí tranzitivně
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).
Stejně důležitý jako samotný obsah datových sad je jejich správný metadatový popis.
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 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 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 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.
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.
Relevantní specifikace a zdroje informací pro každého dodavatele jsou tato otevřená formální norma a všechny její normativní reference.
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.
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.
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).
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.
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.
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.