Tutoriál : Otevřená a propojitelná data veřejné správy

Martin Nečaský1
Jan Kučera2
Jakub Klímek1,3
“Otevírání a
propojování dat”
Tutoriál
Otevřená a propojitelná data veřejné správy
Aktivity, postupy, návod
6.6.2014
Matematicko-fyzikální fakulta
Univerzita Karlova v Praze1
Fakulta informatiky a statistiky
Vysoká škola ekonomická v Praze2
Fakulta informačních technologií
Česke vysoké učení technické3

6.6.2014
Obsah
1. Analýza a výběr dat k uveřejnění
2. Propojitelná data (Linked Data – LD)
3. Výběr a návrh vhodných ontologií
4. Návrh způsobu přístupu k datům
5. Export dat do formátu LD a jejich publikace
6. Aplikační využití LD
7. Katalogizace dat
Tutoriál: Otevírání a propojování dat 2

6.6.2014
Přístupy k identifikaci datových sad k otevření (1/2)
• Analýza datových sad dostupných v rámci
organizace
• Výběr vhodných datových sad k otevření
• Prioritizace a sestavení plánu otevírání vybraných
datových sad
Přístup top-down
Výhody Nevýhody
• Lepší poznání dostupných datových
sad
• Plánování a vyhodnocování postupu
• Výsledky analýzy dat mohou být
využity pro zlepšení řízení dat v
organizaci
• Od rozhodnutí publikovat otevřená
data do publikace prvních datových
množin uplyne více čas
• Výsledky analýzy dat nemusí přinést
výstupy přímo využitelné
potenciálními uživateli dat

6.6.2014
Přístupy k identifikaci datových sad k otevření (2/2)
• Výběr jedné či několika málo datových sad a jejich publikace
• Zpravidla bez podrobné analýzy
• Výběr např. podle častých dotazů dle zák. č. 106/1999 Sb.
• Postupné rozšiřování publikovaných datových sad a zlepšování
kvality publikovaných dat
• Rozšiřování nabídky dat na základě zpětné vazby uživatelů
• Rozšiřování dostupných dat o historická dat
• Postupné zlepšování metadat
• ...
Přístup bottom-up
Výhody Nevýhody
• Rychlá publikace prvních datových
sad
• Pokud jsou datové sady využívány
může organizace rychle získávat
zkušenosti a podněty od uživatelů
• Ne vždy musí být zřejmé, kterými
datovými sadami je vhodné začít

6.6.2014
Analýza datových sad
• Identifikace existujících datových sad
• U každé datové sady by měl být předmětem
analýzy:
• Obsah, včetně analýzy kvality stávajících dat
• Metadata
• Přínosy
• Rizika, včetně legislativních
• Pracnost

6.6.2014
Analýza obsahu datové sady
• Analýza obsahu datové sady by se měla zaměřit na:
• Stávající strukturu/schéma datové sady
• Identifikaci vhodných standardních schémat
• Určení identifikátorů – předpoklad pro následnou tvorbu identifikačních URI
• Určení stávajících a cílových formátů dat
• Určení, zda budou publikovány přírůstky dat nebo kompletní export k
určitému datu
• Určení cílové periodicity publikace datové sady
• Kvalitu datové sady – identifikace nedostatků v kvalitě a potřebného čištění
• Možnosti automatizace publikace – lze datovou sadu publikovat automaticky
v cílovém formátu a periodicitě přímo z informačního systému?
• U datové sady by mělo být také zhodnoceno, zda ji již
nepublikuje jiný orgán veřejné správy
• Zamezení zbytečným duplicitám
• Datové sady přebírané z jiných zdrojů – odkaz na primární zdroj místo
publikace převzaté datové sady

6.6.2014
Interní datový katalog
• Analýzu potenciálních datových sad k otevření
usnadňuje interní datový katalog
• Pokud v organizaci již existuje, lze využití existující metadata
• Pokud neexistuje, lze během analýzy vytvořit alespoň
jednoduchý katalog např. pomocí Excelu nebo podobného
nástroje
• Metadata pořízená během analýzy mohou být
později využita pro vytvoření katalogizačních
záznamů veřejně dostupného katalogu
• Interní datový katalog může obsahovat bohatší
metadata, než veřejně dostupný katalog
• Interní klasifikace, stupně důvěrnosti a přístupu k datové sadě...

6.6.2014
Potenciálních přínosy otevřených dat
• (P1) posílení
transparentnosti,
• (P2) podpora
ekonomického růstu,
• (P3) zlepšení služeb
veřejné správy,
• (P4) podpora opětovného
použití dat,
• (P5) zlepšení vnímání
veřejné správy veřejností,
• (P6) zlepšení procesů a dat
veřejné správy,
• (P7) zamezení chyb
vzniklých při práci s daty
• (P8) snížení počtu dotazů
dle zák. č. 106/1999 Sb.
• (P9) pořádek ve vlastních
datech
• (P10) možnost
transparentně informovat
veřejnost o subjektech,
které neplní své zákonné
povinnosti
• (P11) zvýšení hodnoty dat
• (P12) budování dobrého
jména

6.6.2014
Analýza přínosů
• Kroky analýzy přínosů
• Určení očekávaných přínosů publikace otevřených dat
• Určení, pomocí jakých datových množin lze požadovaných
přínosů dosáhnout
• Kvantifikace očekávaných přínosů, pokud kvantifikaci lze provést
• Pokud nelze provést kvantifikaci přínosu, je alespoň vhodné
kvalitativně přínos popsat
• Stanovení metrik a indikátorů pro vyhodnocování dosažení
přínosů

6.6.2014
Potenciální rizika otevřených dat
• (R1) Zveřejnění dat v rozporu se zákonem
• (R2) Riziko porušení ochrany obchodního
tajemství
• (R3) Riziko porušení ochrany osobních údajů
• (R4) Zveřejnění nevhodných dat či informací
• (R5) Dezinterpretace dat
• (R6) Absence konzumentů dat
• (R7) Překrývání dat

6.6.2014
Analýza rizik (1/5)
• Kroky analýzy rizik
• Identifikace legislativy upravující pořízení dat a nakládání s datovou
sadou
• Identifikace případných smluv vztahujících se k datové sadě
• Identifikace a vyhodnocení omezení publikace datové sady
vyplývající z legislativy, příp. ze smluv
• Identifikace a vyhodnocení dalších možných negativních dopadů
publikace datové sady mimo porušení zákonných a smluvních
povinností
• Formulace předpokladů pro správnou interpretaci dat a zhodnocení
rizika dezinterpretace dat
• Identifikace potenciálních skupin uživatelů dat a zhodnocení rizika
absence konzumentů dat
• Identifikace stejných či obdobných datových sad a zhodnocení rizika
překrývání dat
• Celkové zhodnocení rizikovosti datové sady a návrh opatření pro
eliminaci či omezení pravděpodobnosti nebo negativního dopadu
rizik

6.6.2014
• Identifikace legislativy upravující pořízení dat a nakládání s datovou sadou
• Jaké právní přepisy upravují pořízení dat?
• Jaké právní přepisy upravují nakládání s daty?
• Identifikace případných smluv vztahujících se k datové sadě
• Byla data pořízení na zakázku?
• Vykonává práva k datové sadě nějaký subjekt na základě smlouvy?
• Identifikace a vyhodnocení omezení publikace datové sady vyplývající z
legislativy, příp. ze smluv
• Zákonná omezení publikace dat (R1)
• Brání související legislativa publikaci dat?
• Omezuje související legislativa, jak nakládat s datovou sadou?
• Dopadají případné legislativní omezení na publikaci dat?
• Obchodní tajemství (R2)
• Mají data povahu obchodního tajemství?
• Osobní údaje (R3)
• Obsahují data osobní údaje?
• Je dáno zákonné zmocnění osobní údaje publikovat?
• Příp. je publikace dat v souladu se souhlasem subjektu údajů s jejich zpracováním?
• Smluvní vztahy
• Brání publikaci dat uzavřené smlouvy?
• Má příp. OVM smluvně zajištěno právo data publikovat, je-li to relevantní?

6.6.2014
• Identifikace a vyhodnocení dalších možných negativních dopadů
publikace datové sady mimo porušení zákonných a smluvních
povinností (R4)
• Jaké další negativní dopady může publikace datové sady mít?
• Např. negativní publicita v důsledku nízké kvality publikovaných
dat
• Formulace předpokladů pro správnou interpretaci dat a zhodnocení
rizika dezinterpretace dat (R5)
• Co je potřeba znát pro správnou interpretaci dat?
• Např. použitá metoda výpočtu HDP
• Jaká jsou omezení publikované datové sady?
• Např. zahrnuté/nezahrnuté skupiny subjektů v šetření

6.6.2014
• Identifikace potenciálních skupin uživatelů dat a
zhodnocení rizika absence konzumentů dat (R6)
• Jaké skupiny uživatelů mohou potenciálně datovou sadu využít?
• Lze určit míru zájmu jednotlivých skupin?
• Např. na základě dotazů, jejichž předmět se dotýká oblasti/tématu
datové sady
• Identifikace stejných či obdobných datových sad a
zhodnocení rizika překrývání dat (R7)
• Jaké datové sady jedné organizace se překrývají s analyzovanou
datovou sadou?
• Jaké datové sady jiných orgánů VS se překrývají s analyzovanou
datovou sadou?

6.6.2014
• Celkové zhodnocení rizikovosti datové sady a návrh opatření pro eliminaci či
omezení pravděpodobnosti nebo negativního dopadu rizik
• Určení pravděpodobnosti rizik a jejich míry dopadu pro jednotlivé datové
sady
• Možná opatření pro zmírnění rizik
• Anonymizace/agregace dat (R1, R2, R2)
• Pokud nelze poskytnout data primární kvůli požadavkům na jejich ochranu, je
vhodné zvážit, zda lze publikovat alespoň anonymizovaná data či statistiky
• Návrh vhodné komunikační strategie (R4, R6)
• Určení jak bude o datové sadě informováno, identifikovat potenciální negativní
reakce a připravit odpovědi
• Oslovení cílových skupin uživatelů dat
• Vytvoření vhodných metadat a doplňujících informací (R5)
• Uvést do metadat popis předpokladů a omezení využití dat
• Publikovat doplňující informace – např. metodiku pořízení a zpracování dat,
použité výpočty, definice ukazatelů apod.
• Vhodné vymezení datové sady a propojení na související datové sady (R7)
• Vymezení datové sady s ohledem na minimalizaci překryvů s jinými datovými
sadami
• Využití již publikovaných datových sad
• Propojování na související datové zdroje

6.6.2014
Odhadování pracnosti
• Faktory ovlivňující pracnost publikace datové sady
• Složitost datové množiny – náročnost převodu datové množiny
ze stávajícího formátu/ů do cílového formátu/ů
• Dobře strukturovaná data vs. nestrukturovaná data
• Jednoduché soubory MS Excel bez maker, obrázků a sloučených
buněk vs. soubory MS Excel „k tisku“ (sloučené buňky, odsazení
prázdnými buňkami, různé formátování mezi roky atd.) či s makry
• Potřeba anonymizace dat
• Lze provést automaticky?
• Potřeba manuálních úprav dat před publikací
• Velikost datové sady
• Relevantní zejména, pokud je třeba provádět manuální kontroly
anonymizace/transformace
• Cílová periodicita publikace
• Periodicky je třeba opakovat manuální operace přípravy dat
• Může být třeba upravovat katalogizační záznamy

6.6.2014
Výběr datových sad k publikaci ve formátu
otevřených propojitelných dat (1/3)
• Vstupem pro výběr je katalog potenciálních datových sad
k otevření
• Postup výběru
1. Určení atributů, podle kterých budou určeny priority
• Zájem o data – např. na základě analýzy dotazů dle zák. č. 106/1999
Sb., na základě vlastního šetření apod.
• Stávající formáty dat – strojová čitelnost
• Dostupný popis schématu dat
• Přínosy
• Rizikovost
• Odhadovaná pracnost
• Z hlediska publikace otevřených a propojitelných dat pak
• Identifikátory/klíče
• Potenciál propojování – odhad počtu datových sad, na které lze
uvažovanou datovou sadu napojit (propojování na existující klasifikace a
číselníky), nebo kolik datových sad se může potenciálně napojit na
uvažovanou datovou sadu (velký potenciál u referenčních údajů, jako jsou
adresní body, nebo údaje v obchodním rejstříku)

6.6.2014
• Postup výběru – pokračování
2. Určení vah atributů
3. Vyloučení datových sad, které nelze publikovat jako otevřená
data
4. Seřazení datových sad na základě sledovaných atributů a jejich
vah
5. Úpravy pořadí datových sad podle potřeby, příp. úprava vah
kritérií a opakování kroku 4
6. Výběr finální množiny datových sad k otevření, příp. rozdělení
všech publikovatelných datových sad dle priorit do jednotlivých
etap publikace otevřených dat

6.6.2014
• Po výběru datových sad k otevření by mělo
následovat vytvoření plánu publikace
• Rozplánování jednotlivých etap publikace
• Určení případných projektů a dalších aktivit
• Sestavení rámcového harmonogramu realizace etap/projektů

6.6.2014
Podmínky užití / licencování
• Kromě technické otevřenosti je třeba zajistit i právní
otevřenost publikovaných datových sad
• Je třeba zvolit vhodnou licenci pro datové sady nebo
formulovat vlastní licenci či podmínky užití dat
• Používání standardních licencí jako jsou např. licence Creative Commons v4
usnadňují využití datových sad uživateli
• Vlastní podmínky užití by měly být formulovány pouze, pokud standardní
licence nevyhovují potřebám poskytovatele dat
• I vlastní podmínky užití by měly vyhovovat Open Definition
• http://www.opendefinition.org/
• Je třeba zveřejnit znění podmínek užití dat, resp. informovat
uživatele, že data jsou zpřístupněna pod zvolenou standardní
licencí
• V rámci metadat datové sady je třeba uvést odkaz na znění
podmínek užití/licence
• Jednoznačné určení, jakými podmínkami užití se řídí užití každé datové sady
• Následováním odkazu může uživatel snadno zjistit plné znění podmínek
užití/licence

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Dostupnost dat na současném webu
(demonstrace na příkladu státních kontrol)
Web nabízí řadu dat o kontrolách.
Můžeme s nimi efektivně (strojově)
pracovat?
• Data o kontrolách a související data
jsou publikována v různých
dokumentech mnoha organizacemi
a na mnoha místech.
• Dokumenty jsou téměř vždy určeny
pro lidi, ne pro strojové zpracování.
• Souvislosti nejsou dostatečně
popsány a zaznamenány.
http://www.eagri.cz
Kontroly SVS
Kontroly ČIZP
http://www.cizp.czhttp://www.potravinynapranyri.cz/
Kontroly SŽPI
Kontroly ČOI
http://www.coi.cz
Regionální statistiky ČSÚ
http://www.czso.cz
RÚIAN
http://www.cuzk.cz
ARES
http://www.mfcr.cz
Sbírka zákonů
http://portal.gov.cz http://www.szrcr.cz
RPP

6.6.2014
Dostupnost dat na současném webu
(demonstrace na příkladu státních kontrol)
Jak nalézt odpovědi na následující
otázky?
• Kontroly provedené v okrese
Semily u subjektů provozující obor
činnosti „Pronájem a půjčování
věcí movitých“
• Kontroly provedené v rámci
agendy „Odpadové hospodářství“
• Počty kontrol a objemy pokut v
okresech přepočtené na 1000
obyvatel
http://www.eagri.cz
Kontroly SVS
Kontroly ČIZP
http://www.cizp.czhttp://www.potravinynapranyri.cz/
Kontroly SŽPI
Kontroly ČOI
http://www.coi.cz
Regionální statistiky ČSÚ
http://www.czso.cz
RÚIAN
http://www.cuzk.cz
ARES
http://www.mfcr.cz
Sbírka zákonů
http://portal.gov.cz http://www.szrcr.cz
RPP

6.6.2014
Co jsou propojitelná data (Linked Data)?
• Principy propojitelných dat (angl. Linked Data) umožňují
vytvořit ekosystém webových služeb (aplikací), které
publikují, obohacují a využívají data o entitách v jednom
globálním sdíleném datovém prostoru (tzv. Web dat).
Sdílený globální prostor dat na Webu
(Web of Data)
Služba 1
Služba 2
Služba 3
Služba 4
Služba 5
Služba 4

6.6.2014
Propojitelná data - Principy
 Principy propojitelných dat vycházejí z jednoduchých
principů, na kterých je postaven současný web (tvořený
webovými stránkami a odkazy mezi nimi)
1. Identifikujte webové stránky pomocí http:// URL
2. Používejte URL tak, aby je ostatní mohli vyhledat v
síti WWW, přistupovat k němu a odkazovat se na něj.
3. Pokud někdo k URL stránky přistoupí, poskytněte mu
obsah stránky ve formátu HTML.
4. Do svojí stránky vložte odkazy na URL souvisejících
stránek, abyste ji umístili do kontextu a umožnili
procházení stránek v rámci sítě WWW.

6.6.2014
Propojitelná data - Principy
 Propojitelná data jsou data publikovaná na webu podle 4
jednoduchých principů:
1. Identifikujte entity pomocí http:// URL.
2. Používejte URL tak, aby jej ostatní mohli vyhledat v
síti WWW, přistupovat k němu a odkazovat se na
něj.
3. Pokud někdo přistoupí k URL entity, poskytněte data
o ní ve formátu RDF ke stažení nebo prostřednictvím
RDF datového API (SPARQL).
4. V datech o entitě poskytněte odkazy na URL
souvisejících entit, abyste k entitě doplnili její
kontext a umožnili procházení entit v rámci sítě
WWW.

6.6.2014
Identifikace entit pomocí URL
• Entity identifikujeme pomocí http:// URL
• URL bychom měli mít pod svojí kontrolou
• tj. mělo by být v rámci naší internetové domény
• např. v rámci domény coi.cz
• Pro URL entit bychom měli vyčlenit speciální sub-
doménu
• tj. doménu třetího řádu, např. data.coi.cz
• URL entity by mělo být transparentní a relativně snadno
zrekonstruovatelné
• doporučujeme následující schéma:
http://data.[domena].cz/resource/[typ-entity]/[id-entity]
• např.:
http://data.coi.cz/resource/kontrola/01020304

6.6.2014
Identifikace entit pomocí URL - příklad
coi.cz/org/12345678
coi.cz/kontrola/01020304
ČOI
eagri.cz/subjekt/12345678
eagri.cz/kontrola/A7C4Q7
SVS
gov.cz/zakon/2001/185
gov.cz/zakon/2001/185/66/4
Sbírka zákonů
cuzk.cz/okres/3608
cuzk.cz/adresa/16961561
RÚIAN
szrcr.cz/agenda/A1186
szrcr.cz/cinnost/CR8608
RPP
mfcr.cz/rzp/12345678
ARES
czso.cz/region/cz0514
ČSÚ

6.6.2014
Vyhledání a přístup k entitě
• Volíme URL ve schématu http, které se běžně používá
pro URL webových stránek
• Možnost vyhledat entitu a přistoupit k její reprezentaci je
pak zajištěno přímo HTTP protokolem
• Pokud klient vydá požadavek na přistoupení k URL, je pomocí
mechanismů HTTP protokolu nalezen příslušný server (DNS, IP,
atd.) a požadavek je mu doručen (např. pomocí metody GET).
• Je nutné zajistit, že URL entity není virtuální, ale opravdu
je k němu na serveru přiřazen nějaký obsah.
• Zde ale není žádný rozdíl oproti webovým stránkám.
• Na existující URL se může kdokoliv odkazovat a
směrovat tak uživatele WWW k entitě.
• Opět není žádný rozdíl oproti webovým stránkám.

6.6.2014
Vyhledání a přístup k entitě - příklad
coi.cz/org/12345678
coi.cz/kontrola/01020304
ČOI
eagri.cz/subjekt/12345678
eagri.cz/kontrola/A7C4Q7
SVS
cuzk.cz/okres/3608
cuzk.cz/adresa/16961561
RÚIAN
czso.cz/region/cz0514
ČSÚ
- Datum kontroly : 29.3.2013
- Kontrolovaný subjekt : 12345678
- Sankce : 30.000 CZK
- Číslo domovní : 51
- Ulice : Riegrovo náměstí
- Město : Semily
- PSČ : 513 01

6.6.2014
Reprezentace entity ve formátu RDF
• Standard konsorcia W3C
• Vyvinut pro účely reprezentace dat publikovaných
na webu, které mají charakter sítě
• Uzly sítě = entity, o kterých chceme na webu publikovat data
• Vazby v síti = souvislosti mezi entitami
• Základní RDF je tvrzení v podobě trojice
subjekt predikát objekt
• subjekt = URL entity o níž něco tvrdíme
• predikát = vlastnost, které se tvrzení o entitě týká
• objekt = hodnota vlastnosti

6.6.2014
Reprezentace entity ve formátu RDF - příklad
51301
psč
číslo
domovní název
okres
kraj
název
cuzk.cz/adresa/
16961561
51
cuzk.cz/ulice/
547239
ulice
Riegrovo
náměstí
cuzk.cz/obec/
576964
cuzk.cz/okres/
3608
cuzk.cz/kraj/
78
obec
Semily
Semily
Liberecký
kraj
název
název
název
cuzk.cz/adresa/
16961234
cuzk.cz/adresa/
16961242
ulice
ulice …
cuzk.cz/ulice/
546771
obec
cuzk.cz/ulice/
546607
obec
…

6.6.2014
<cuzk.cz/adresa/16961561> <číslo-domovní> "51" .
<cuzk.cz/adresa/16961561> <psč> "51301" .
<cuzk.cz/adresa/16961561> <ulice> <cuzk.cz/ulice/547239> .
<cuzk.cz/ulice/547239> <název> "Riegrovo náměstí" .
<cuzk.cz/ulice/547239> <obec> <cuzk.cz/obec/576964> .
<cuzk.cz/obec/576964> <název> "Semily" .
<cuzk.cz/obec/576964> <okres> <cuzk.cz/okres/3608> .
<cuzk.cz/okres/3608> <název> "Semily" .
<cuzk.cz/okres/3608> <kraj> <cuzk.cz/kraj/78> .

6.6.2014
<cuzk.cz/adresa/16961561> <číslo-domovní> "51" ;
<psč> "51301" ;
<ulice> <cuzk.cz/ulice/547239> .
<cuzk.cz/ulice/547239> <název> "Riegrovo náměstí" ;
<obec> <cuzk.cz/obec/576964> .
<cuzk.cz/obec/576964> <název> "Semily" ;
<okres> <cuzk.cz/okres/3608> .
<cuzk.cz/okres/3608> <název> "Semily" ;
<kraj> <cuzk.cz/kraj/78> .

6.6.2014
Více k reprezentaci entit v RDF
• Pro každou entitu bychom také měli specifikovat její typ,
tzv. třídu.
• Entita může mít přiřazeno libovolné množství různých tříd
• Třídu specifikujeme pomocí speciální trojice
subjekt a třída
• subjekt = URL entity, jejíž třídu specifikujeme
• a = klíčové slovo
• třída = URL třídy
• Třída je také identifikována svým URL, který je pro ni
vyhrazen
• Lze zavádět nové třídy (s vlastními URL) a nebo využívat
třídy z existujících slovníků tříd (tzv. ontologií)

6.6.2014
Více k reprezentaci entit v RDF – příklad
<cuzk.cz/adresa/16961561> a <schema.org/PostalAddress> ;
<psč> "51301" ;
<číslo-domovní> "51" ;
<ulice> <cuzk.cz/ulice/547239> .
<cuzk.cz/ulice/547239> a <schema.org/Place>, <cuzk.cz/ontology/Ulice> ;
<název> "Riegrovo náměstí" ;
<obec> <cuzk.cz/obec/576964> .
<cuzk.cz/obec/576964> a <schema.org/AdministrativeArea>,
<cuzk.cz/ontology/Obec> ;
<název> "Semily" ;
<okres> <cuzk.cz/okres/3608> .
<cuzk.cz/okres/3608> a <schema.org/AdministrativeArea>,
<cuzk.cz/ontology/Kraj> ;
<název> "Liberecký kraj" ;
<kraj> <cuzk.cz/kraj/78> .

6.6.2014
Více k reprezentaci predikátů v RDF
• Podobně jako třídy, jsou i predikáty identifikovány
svými URL, které jsou pro ně vyhrazeny
• Lze zavádět nové predikáty (s vlastním URL) a nebo
využívat predikáty z existujících ontologií

6.6.2014
Více k reprezentaci predikátů v RDF – příklad
<cuzk.cz/adresa/16961561> a <schema.org/PostalAddress> ;
<schema.org/postalCode> "51301" ;
<cuzk.org/cisloDomovni> "51" ;
<cuzk.cz/ulice> <cuzk.cz/ulice/547239> .
<cuzk.cz/ulice/547239> a <schema.org/Place>, <cuzk.cz/ontology/Ulice> ;
<purl.org/dc/terms/title> "Riegrovo náměstí" ;
<cuzk.cz/ontology/obec> <cuzk.cz/obec/576964> .
<cuzk.cz/obec/576964> a <schema.org/AdministrativeArea>,
<cuzk.cz/ontology/Obec> ;
<purl.org/dc/terms/title> "Semily" ;
<cuzk.cz/ontology/okres> <cuzk.cz/okres/3608> .
<cuzk.cz/okres/3608> a <schema.org/AdministrativeArea>,
<cuzk.cz/ontology/Kraj> ;
<purl.org/dc/terms/title> "Liberecký kraj" ;
<cuzk.cz/ontology/kraj> <cuzk.cz/kraj/78> .

6.6.2014
Více k reprezentaci predikátů v RDF – příklad
@prefix s: <http://schema.org/>
@prefix cuzk: <http://data.schema.org/ontology/>
@prefix dc: <http://purl.org/dc/terms/>
<cuzk.cz/adresa/16961561> a s:PostalAddress ;
s:postalCode "51301" ;
cuzk:cisloDomovni "51" ;
cuzk:ulice <cuzk.cz/ulice/547239> .
<cuzk.cz/ulice/547239> a s:Place, cuzk:Ulice ;
dc:title "Riegrovo náměstí" ;
cuzk:obec <cuzk.cz/obec/576964> .
<cuzk.cz/obec/576964> a s:AdministrativeArea, cuzk:Obec ;
dc:title "Semily" ;
cuzk:okres <cuzk.cz/okres/3608> .
<cuzk.cz/okres/3608> a s:AdministrativeArea, cuzk:Kraj ;
dc:title "Liberecký kraj" ;
cuzk:kraj <cuzk.cz/kraj/78> .

6.6.2014
Propojování souvisejících entit z různých zdrojů
• Předchozí příklady ukázaly, že RDF data publikovaná
jedním zdrojem (např. RÚIAN publikovaný v
doméně cuzk.cz) sestávají z entit a propojení mezi
nimi.
• Stejným způsobem, pomocí RDF trojic, lze
propojovat entity napříč různými zdroji a doménami.

6.6.2014
Propojování souvisejících entit z různých zdrojů – příklad
51301
s:postalCode
cuzk:číslo-domovni
dc:title
cuzk:okres
cuzk:kraj
cuzk.cz/adresa/
16961561
51
cuzk.cz/ulice/
547239
cuzk:ulice
Riegrovo náměstí
cuzk.cz/obec/
576964
cuzk.cz/okres/
3608
cuzk.cz/kraj/
78
cuzk:obec
Semily
Semily
Liberecký kraj
coi.cz/kontrola/
01020304
dc:title
dc:title
dc:title
s:location
RÚIAN
ČOI
eagri.cz/kontrola/
A7C4Q7
SVS
s:location

6.6.2014
Propojování souvisejících entit z různých zdrojů – příklad
cuzk:okres
cuzk:kraj
cuzk.cz/adresa/
16961561
cuzk.cz/ulice/
547239
cuzk:ulice
cuzk.cz/obec/
576964
cuzk.cz/okres/
3608
cuzk.cz/kraj/
78
cuzk:obec
coi.cz/kontrola/
01020304
RÚIAN
ČOI
eagri.cz/kontrola/
A7C4Q7
SVS
czso.cz/region/
cz0514
ČSÚ
czso.cz/fact/
cz0514/2013
czso:refLocation
data.gov.uk/day
/2007-12-31
czso:refLocation
s:location
s:location
cuzk:hasLAU
9999
czso:
populace

6.6.2014
Propojování reprezentací stejné entity
• Ve světě propojitelných dat se může snadno stát, že
dva různí vydavatelé dat přiřadí stejné entitě
reálného světa svoje vlastní (různé) URL.
coi.cz/org/
12345678
ČOI
eagri.cz/subjekt/
12345678
SVS
mfcr.cz/rzp/
12345678
ARES
mvcr.cz/ros/
12345678
ROS

6.6.2014
Propojování reprezentací stejné entity
• RDF nabízí konstrukci pro specifikaci tvrzení, že dvě URL
reprezentují stejnou entitu:
subjekt owl:sameAs object
• subjekt = URL entity
• owl:sameAs = standardizovaný predikát jazyka OWL specifikující, že
dvě URL reprezentují stejnou entitu reálného světa
• třída = URL entity
coi.cz/org/
12345678
ČOI
eagri.cz/subjekt/
12345678
SVS
mfcr.cz/rzp/
12345678
ARES
mvcr.cz/ros/
12345678
ROS
owl:sameAs
owl:sameAs
owl:sameAs

6.6.2014
Kde data publikovat a jak je konzumovat?
ČOI SVS
Aplikace
ČSÚ
RÚIAN
linked.opendata.cz

6.6.2014
Propojitelná data v ČR – linked.opendata.cz
Rejstříky
ARES
Výzkumné
projekty
Veřejné
zakázky
Orgány
veřejné moci
Agendy
OVM
Úplná znění
zákonů
Soudní
rozhodnutí
ČOI
kontroly
RÚIAN
adresy
ČSÚ
demografie
MFČR
rozpočty
ČSÚ
volby
SÚKL
léčiva
MZČR
Ceny léčiv
RÚIAN
budovy
RÚIAN
katastr
Výsledky
VaVaI
Registr
smluv
NUTS
a LAU
RÚIAN
regiony
Soudy
ČR
ČSÚ další
statistiky
ČSÚ
strany
ČSSZ
statistiky
SDMX
Životní
prostředí
Školství
Léčiva
ve světě
???

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Pojem ontologie
• Ontologie (někdy též nazývaná slovník) definuje sadu
predikátů a tříd, kterou mohou vydavatelé dat využívat ve
svých datových sadách reprezentovaných ve formátu RDF.
• Ontologie je opět specifikována ve formátu RDF.
• Pomocí RDF trojic definuje svoje predikáty a třídy.
• Ontologie jako množina RDF trojic je typicky publikována jako
datový soubor na WWW síti pod svým vlastním URL = URL
ontologie
@prefix gr: <http://purl.org/goodrelations/v1#>
gr:BusinessEntity a rdfs:Class ;
rdfs:label "Organizace" .
gr:name a rdf:Property ;
rdfs:label "název" .

6.6.2014
Ontologie jako podpora opakovatelné
použitelnosti dat
• Cílem je umožnit co nejvíce opakovatelnou
použitelnost datové sady napříč softwarovými
aplikacemi.
• Aby co nejvíce softwarových aplikací rozumělo našim datům a
přitom nebylo nutné, aby programátoři složitě data
transformovali.
• Pro splnění tohoto cíle bychom se tedy měli snažit
ve svých RDF datech co nejvíce používat predikáty a
třídy definované existujícími ontologiemi a až potom
vytvářet vlastní ontologie.

6.6.2014
Výběr z existujících ontologií
• Obecné ontologie
• DublinCore
• ontologie pro metadatový popis entit, zavádí predikáty pro metadatové vlastnosti jako je
název, popis, datum vzniku, autor, jazyk, apod.
• Simple Knowledge Organization System (SKOS)
• Ontologie pro popis taxonomií
• Doménově specifické ontologie
• GoodRelations
• Ontologie pro popis produktů, nabídky a poptávky
• RegOrg
• Ontologie pro popis organizací registrovaných v národních registrech
• PublicContracts
• Ontologie pro popis veřejných zakázek
• LEX Ontology
• Ontologie pro popis legislativních dokumentů
• Friend-of-a-Friend
• Ontologe pro popis vazeb mezi lidmi
• Vše-pokrývající ontologie
• http://schema.org/
• Iniciativa společností vyvíjejících webové vyhledávače
• Snaha o pokrytí co největšího množství tříd a predikátů
• Katalog ontologií - http://lov.okfn.org

6.6.2014
Použití existujících ontologií v datech
@prefix skos: <http://www.w3.org/2004/02/skos/core#>
@prefix gr: <http://purl.org/goodrelations/v1#>
<coi.cz/check-action/01020304> a s:CheckAction ;
s:result <coi.cz/sanction/54889> ;
s:instrument <gov.cz/zakon/1992/634> ;
s:object <mfcr.cz/res/123456789> .
<coi.cz/sanction/54889>
dc:valid "2012-06-19" ;
gr:hasPriceSpecification <coi.cz/sanction/54889/price-specification> ;
skos:notation "54889" .
<coi.cz/sanction/54889/price-specification> a gr:PriceSpecification ;
gr:hasCurrency "CZK" ;
gr:hasCurrencyValue "5000" .

6.6.2014
Definice vlastní ontologie
@prefix coi: <http://data.coi.cz/ontology/>
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
coi:Fine a rdfs:Class ;
rdfs:label "Pokuta" .
coi:Sanction a rdfs:Class ;
rdfs:label "Sankce" .
coi:checkActionDate a rdf:Property ;
rdfs:label "Datum kontroly" .

6.6.2014
Použití vlastní ontologie v datech
@prefix skos: <http://www.w3.org/2004/02/skos/core#>
@prefix coi: <http://data.coi.cz/ontology/>
<coi.cz/check-action/01020304> a s:CheckAction ;
s:result <coi.cz/sanction/54889> ;
s:instrument <gov.cz/zakon/1992/634> ;
s:object <mfcr.cz/res/123456789> ;
coi:checkActionDate "2012-05-03" .
<coi.cz/sanction/54889> a coi:Sanction ;
dc:valid "2012-06-19" ;
gr:hasPriceSpecification <coi.cz/sanction/54889/price-specification> ;
skos:notation "54889" .
<coi.cz/sanction/54889/price-specification> a gr:PriceSpecification,
coi:Fine ;
gr:hasCurrency "CZK" ;
gr:hasCurrencyValue "5000" .

6.6.2014
Ontologie – „Light“ přístup ke standardizaci
• Ontologie jsou blízké světu datových standardů –
zavádějí prvky (třídy a predikáty), které by měla
používat široká odborná veřejnost používat.
• Ontologie ale nejsou tak striktní jako standardy
• Např. ve světě HTML je nutné používat předem definované
elementy (tagy). Pro formulář nutno použít element <form> a
pro položku formuláře element <input>.
• Toto ve světě ontologií neplatí.

6.6.2014
• Začněme u jednoduchého příkladu se specifikací názvu entity.
• Predikát pro název entity zavádějí nezávisle na sobě různé
ontologie:
• ontologie DublinCore (http://purl.org/dc/terms/, dc:)
• dc:title
• ontologie Schema.org (http://schema.org/, s:)
• s:name
• ontologie GoodRelations (http://purl.org/goodrelations/v1#, gr:)
• gr:name
• Nejedná se však o striktně vyžadované standardy
• pro specifikaci názvů entit ve své datové sadě mohu zvolit libovolný z výše
uvedených predikátů
• nebo mohu definovat svůj vlastní predikát pro názvy entit
@prefix my: <http://priklad.cz/moje/ontologie>
my:nazev a rdf:Property ;
rdfs:label "název" .

6.6.2014
• Aplikace X umí interpretovat predikáty ontologie
DublinCore. Následující trojici tedy správně
interpretuje jako název entity
<cuzk.cz/obec/576964>:
<cuzk.cz/obec/576964> dc:title "Semily" .
• Ten samý kód ale nerozumí dalším ontologiím
(schema.org, GoodRelations, moje vlastní ontologie)
• Aplikace tedy nepracuje správně s daty reprezentovanými dle
mojí ontologie, ani s daty reprezentovanými podle dalších
ontologií.

6.6.2014
• Jazyk pro specifikaci ontologií pro tyto případy nabízí
řešení, které umožňuje v rámci definice predikátu v
ontologii specifikovat, že predikát je sémanticky
ekvivalentní jinému predikátu (z jiné ontologie)
• To samé lze specifikovat pro třídy, pomocí
owl:equivalentClass
@prefix my: <http://priklad.cz/moje/ontologie>
my:nazev a rdf:Property ;
rdfs:label "název" ;
owl:equivalentProperty dc:title, gr:name, s:name .

6.6.2014
Využití ontologií na úrovni ****
dc:title dc:valid gr:hasCurrencyValue
Natural 95 2014-06-06 37.80
Natural 95 2014-06-05 37.75

6.6.2014
Ontologie – postup
• Návrh datového modelu
• ER diagramy, UML diagramy tříd
• Analýza existujících ontologií a snaha pokrýt co největší
počet prvků mého datového modelu třídami a predikáty
existujících ontologií
• http://lov.okfn.org
• Tam, kde se pokrytí nepodařilo, je nutné definovat nové
třídy a predikáty ve své vlastní ontologii
• Pokud se časem ukáže, že přeci jen jiná vhodná
ontologie existuje (např. časem vznikne pod hlavičkou
dostatečně silného konsorcia), není nutné transformovat
svoje data
• stačí provést mapování pomocí konstrukcí
owl:equivalentProperty či owl:equivalentClass

6.6.2014
Ontologie – nástroje pro návrh
• Volně dostupný software
• Váš oblíbený textový editor
• Protégé
• http://protege.stanford.edu/
• Neon toolkit
• http://neon-toolkit.org/
• Placený software
• TopBraid Composer
• http://www.topquadrant.com/tools/modeling-topbraid-composer-
standard-edition/

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Dump
• Datový soubor odkazovaný na webové stránce
• RDF datový model, různé syntaxe
• N-triples
• RDF/XML
• N3/Turtle
• JSON-LD
• RDFa
• http://rdf-translator.appspot.com/

6.6.2014
N-Triples RDF Syntax
<http://data.coi.cz/resource/check-action/221211240203501>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://schema.org/CheckAction> .
<http://purl.org/dc/terms/date>
"2012-11-23+02:00"^^<http://www.w3.org/2001/XMLSchema#date> .
<http://schema.org/location>
<http://data.coi.cz/resource/check-action/221211240203501/postal-address> .
s:CheckAction
221211240203501
postal-address
s:location
2012-11-23
dcterms:date

6.6.2014
RDF/XML RDF Syntax
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:schema="http://schema.org/"
xmlns:dcterms="http://purl.org/dc/terms/">
<schema:CheckAction rdf:about="http://data.coi.cz/resource/check-action/221211240203501">
<dcterms:date rdf:datatype="http://www.w3.org/2001/XMLSchema#date">
2012-11-23+02:00
</dcterms:date>
<schema:location rdf:resource="http://data.coi.cz/resource/check-
action/221211240203501/postal-address" />
</schema:CheckAction>
</rdf:RDF>
s:CheckAction
221211240203501
postal-address
s:location
2012-11-23
dcterms:date

6.6.2014
Turtle RDF Syntax
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix schema: <http://schema.org/> .
a schema:CheckAction ;
dcterms:date "2012-11-23+02:00"^^xsd:date ;
schema:location <http://data.coi.cz/resource/check-
action/221211240203501/postal-address> ;
.
s:CheckAction
221211240203501
postal-address
s:location
2012-11-23
dcterms:date

6.6.2014
JSON-LD RDF Syntax
[
{
"@id": "http://data.coi.cz/resource/check-action/221211240203501",
"@type": [
"http://schema.org/CheckAction"
],
"http://purl.org/dc/terms/date": [
{
"@type": "http://www.w3.org/2001/XMLSchema#date",
"@value": "2012-11-23"
}
],
"http://schema.org/location": [
{
"@id": "http://data.coi.cz/resource/check-action/221211240203501/postal-address"
}
]
}
]
s:CheckAction
221211240203501
postal-address
s:location
2012-11-23
dcterms:date

6.6.2014
RDFa Syntax
<div xmlns="http://www.w3.org/1999/xhtml"
prefix=" schema: http://schema.org/
rdf: http://www.w3.org/1999/02/22-rdf-syntax-ns#
dcterms: http://purl.org/dc/terms/
xsd: http://www.w3.org/2001/XMLSchema#
rdfs: http://www.w3.org/2000/01/rdf-schema#">
<div typeof="schema:CheckAction" about="http://data.coi.cz/resource/check-
action/221211240203501">
Informace o kontrole provedené
<span property="dcterms:date" datatype="xsd:date" content="2012-11-23">
23. listopadu 2012
</span>
na adrese
<div rel="schema:location" resource="http://data.coi.cz/resource/check-
action/221211240203501/postal-address">
...
</div>
</div>
</div>
s:CheckAction
221211240203501
postal-address
s:location
2012-11-23
dcterms:date

6.6.2014
API: SPARQL Endpoint
• Interface pro pokládání dotazů
• Primárně pro aplikace, lze i pro lidi
• Jazyk SPARQL - http://www.w3.org/TR/sparql11-query/

6.6.2014
SPARQL 1.1
prefix dcterms: <http://purl.org/dc/terms/> .
prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
prefix schema: <http://schema.org/> .
SELECT *
WHERE
{?s ?p ?o}
{
?s a schema:CheckAction ;
dcterms:date ?date ;
schema:location ?location ;
.
}
schema:location
<http://data.coi.cz/resource/check-
.
s date location
http://data.coi.cz/resource/check-
action/221211240203501
"2012-11-23+02:00"^^xsd:date http://data.coi.cz/resource/check-
action/221211240203501/postal-address

6.6.2014
SPARQL 1.1
prefix dcterms: <http://purl.org/dc/terms/> .
prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
prefix schema: <http://schema.org/> .
CONSTRUCT
{
.
}
WHERE
{
schema:location ?location ;
.
}
schema:location
<http://data.coi.cz/resource/check-
.
.

6.6.2014
API: SPARQL Endpoint
• Triplestore
• Openlink Virtuoso
• OpenRDF Sesame
• Apache Jena Fuseki
• 4Store
• BigData
• Wrapper nad relační databází
• D2RQ
• R2RML – W3C recommendation

6.6.2014
API: Dereferencovatelná HTTP URI
WWW SPARQL
Aplikace
PROXY
HTMLHTML RDF
http://www.coi.cz http://data.coi.cz/resource/check-action/221211240203501

6.6.2014
HTML podoba surových RDF dat

6.6.2014
Možnosti přístupu k RDF datům
1. Dump
• Soubor na webové stránce
• Každý si může stáhnout a dotazovat se nad svým serverem
• Minimální nároky na HW poskytovatele
• Zájemce o data musí provozovat vlastní RDF databázi
2. Dereferencovatelná HTTP URI
• Podmínka pro 5* Open data – Linked Data
• Umožňuje získat RDF data k entitě pomocí URI
• Umožňuje získat HTML podobu dat pro uživatele
• Obsluha požadavku = jednoduchý dotaz do databáze
• Střední nároky na HW poskytovatele
3. Otevřený SPARQL Endpoint
• Umožňuje libovolné dotazování nad databází poskytovatele
• Potenciálně vysoké nároky na HW poskytovatele – dotazy mohou být složité
• Nejvyšší komfort pro konzumenty dat

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Extract Transform Load (ETL)
Excel
WWW
XML
Transform
Internal
DB

6.6.2014
Transformační metody
• V prvním kroce přímý převod do RDF
• <http://linked.opendata.cz/resource/temp/row/4>
• <http://linked.opendata.cz/resource/temp/column/1>
• „1234“
• 6.6.2014
• Nám. W. Churchilla 4
• Umožňuje dotazování nad jednotným datovým modelem
• Počet entit
• Kardinality vlastností
• Mezní či průměrné hodnoty

6.6.2014
Transformační metody
• Konkrétní nástroj záleží na zdrojovém formátu
• Relační databáze, komplexní tabulková data => D2RQ, R2RML
=> Turtle
• Excel, CSV, jednoduchá tabulková data => Tarql => Turtle
• XML => XSLT, XQuery => RDF/XML, Turtle
• HTML => Java + JSoup => Turtle
• A nebo
• UnifiedViews
• Tabulkové soubory
• Excel, DBF, CSV
• XML soubory
• RDF soubory

6.6.2014
Základní čištění dat
• Základní pročištění už během převodu do RDF
• Přiřazení datových typů a převod na správný formát
• Datumy - <datum>06-06-2014</datum>
• "2014-06-06"^^xsd:date
• Strukturování strukturovatelných dat, osamostatnění entit
• Adresy - <adresa>nám. W. Churchilla 4, 130 67 Praha 3</adresa>
:adresa a schema:PostalAddress ;
schema:streetAddress "nám. W. Churchilla 4" ;
schema:postalCode "13067" ;
schema:location "Praha 3" ;
.

6.6.2014
Převod dle zvolených slovníků
• Konstrukce RDF dat dle zvolených slovníků a
ontologií z dat převedených přímou metodou
• SPARQL transformace
• U jednodušších datových sad lze oba kroky spojit

6.6.2014
Propojování a čištění na úrovni LOD
• Linkování na existující datové sady
• Adresy -> Adresní místa RÚIAN
:adresa a schema:PostalAddress ;
schema:streetAddress "nám. W. Churchilla 4" ;
schema:postalCode "13067" ;
schema:location "Praha 3" ;
.
http://ruian.linked.opendata.cz/resource/adresni-mista/21788561
• Entity s IČ
http://linked.opendata.cz/resource/business-entity/CZ28978714
• Může proběhnout verifikace dat proti linkovaným
datovým sadám
• Jmenuje se firma stejně?
• Má region stejný počet obyvatel?
• …

6.6.2014
Publikace dat
• Vystavit vlastní data
• Dumpy a metadata
• http://linked.opendata.cz
• Dereferencovatelná URI
• http://ruian.linked.opendata.cz/resource/adresni-
mista/21788561
• SPARQL endpoint
• http://linked.opendata.cz/sparql
• Metadata
• Záznam do katalogu

6.6.2014
Publikace dat

6.6.2014
UnifiedViews: ETL zaměřené na RDF

6.6.2014
UnifiedViews: Přímý převod do RDF

6.6.2014
5: UnifiedViews: Převod dle slovníků

6.6.2014
UnifiedViews: Publikace dumpu

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Jak budovat aplikace nad LOD?
ČOI SVS
Aplikace
ČSÚ
RÚIAN
linked.opendata.cz

6.6.2014
Aplikace LékováEncyklopedie.cz
• http://www.lekovaencyklopedie.cz
• Kombinace propojených dat z různých
zdrojů
• Přímé dotazování aplikací pomocí jazyka
SPARQL

6.6.2014
Data pro LékováEncyklopedie.cz

6.6.2014
Architektura LékováEncyklopedie.cz – příprava dat
LOD zdroje o
léčivech
non-LOD
zdroje o
léčivech
LOD o léčivech
RDF databázový server
(OpenLink Virtuoso)
Transformace dat
(nástroj UnifiedViews)
Uložení dat
http://opendata.cz/sparql/
ehealth.php
(52 mil. RDF trojic)

6.6.2014
Architektura LékováEncyklopedie.cz – aplikace
SPARQL endpoint
(OpenLink Virtuoso)
Aplikační back-end
(Java, knihovna Apache Jena)
Aplikační front-end
(JavaScript, prohlížeč)
SPARQL dotazy – 10-100 ms na dotaz (1 jádro CPU, 16GB RAM)
(prostřednictvím HTTP protokolu)
(OpenLink Virtuoso)
JSON dokumenty
(HTTP protokol)

6.6.2014
Aplikace VýsledkyKontrol.cz
• http://www.vysledkykontrol.cz
• Prezentace výsledků kontrol ČOI
(připraveno i pro další inspekční orgány)
• Indexace propojených dat pomocí
Apache SOLR a využití jeho prostředků k
dotazování aplikací

6.6.2014
Architektura VýsledkyKontrol.cz – příprava dat
data.coi.cz
(OpenLink Virtuoso)
Apache SOLR
Uložení dat
Indexace dat

6.6.2014
Architektura VýsledkyKontrol.cz – indexace dat
• Indexace RDF dat pomocí Apache SOLR
• Výběr atributů k indexaci
• Sestavení JSON souboru s hodnotami indexovaných atributů
• Nahrání do instance serveru Apache SOLR
{
"ID": "311305270030301",
"checkActionID": "311305270030301",
"checkActionResource": "coi.cz/check-action/311305270030301",
"street": "Kafkova 8",
"postalCode": "77900",
"locality": "Olomouc",
"region": "Olomoucký kraj",
"lng": 17.2288441,
"lat": 49.5748354,
"coords": "49.5748354 17.2288441",
"agentResource": "http://www.coi.cz/",
"checkDate": "2013-05-27T00:00:00Z",
"businessEntityResource": "mfcr.cz/business-entity/CZ27103391",
"businessEntityName": "Květiny Novák Praha a.s.",
"businessEntityID": "27103391"
}

6.6.2014
Architektura VýsledkyKontrol.cz – aplikace
SPARQL endpoint
(OpenLink Virtuoso)
Aplikační back-end
Aplikační front-end
(JavaScript, prohlížeč)
SPARQL dotazy
(OpenLink Virtuoso)
JSON dokumenty
Apache SOLR

6.6.2014
Vizualizace LOD v nástroji Payola
• http://live.payola.cz
• Experimentální nástroj vyvíjený na MFF UK a
doplňovaný studenty s dalších fakult (FIS VŠE, FIT
ČVUT)
• Federované dotazování pomocí SPARQL na různé
zdroje LOD
• Vizualizace získaných dat pomocí řady různých
zásuvných modulů
• Mapové vizualizace
• Vizualizace hierarchií
• Vizualizace statistických dat (datových kostek)
• Vizualizace grafových (síťových) dat

6.6.2014
• Orgány veřejné moci na mapách Google (odkaz)

6.6.2014
• Pokuty (ČOI) v okresech a letech na 1000 obyvatel
(odkaz)

6.6.2014
(odkaz)

6.6.2014
ČOI
kontroly
ČSÚ
demografieNUTS
a LAU
RÚIAN
regiony
Pro zájemce jsou v příloze coi-sparql.txt uvedeny
SPARQL dotazy, které jsou pro vizualizaci využity.
http://live.payola.cz/analysis/82eb1c03-f6d6-4ec0-b245-909986bac0ff

6.6.2014
Obsah
7. Katalogizace dat

6.6.2014
Datový katalog a katalogizace dat
• Datový katalog
• Množina katalogizačních záznamů popisujících datové
množiny (metadata).
• Obsah datového katalogu by měl být spravován a průběžně
aktualizován
• Usnadňuje uživatelům vyhledávání požadovaných datových
množin, které mohou být publikovány na různých místech.
• Katalogizace otevřených dat
• Systematické vytváření a údržba katalogizačních záznamů

6.6.2014
Přínosy katalogizace otevřených dat (1/3)
• Usnadnění vyhledávání otevřených dat
• Bez katalogu je obtížné datové sady vyhledat
• Roztříštěnost na mnoha webových stránkách
• Nejednotné umístění v rámci webových stránek
• Chybějící klasifikace datových sad
• Jednotné místo přístupu k otevřeným datům
• Katalog umožňuje vyhledávat datové sady napříč orgány VS
• Datové sady jsou klasifikovány

6.6.2014
• Usnadnění využití otevřených dat
• Bez metadat je náročnější datové sady využít
• Potřeba analyzovat datové schéma – některé datové sady mohou
obsahovat datové položky, jejichž význam není na první pohled
zřejmý a pochopení potřebuje např. znalost příslušné legislativy
• Nejasná omezení dat – riziko dezinterpretace
• Nejasné podmínky užití
• Metadata pomáhají pochopit strukturu a význam dat
• Metadata pomáhají pochopit, o čem data jsou i o čem data
nejsou – omezení rizika dezinterpretace
• Metadata informují uživatele, jaké jsou podmínky užití dat

6.6.2014
• Usnadnění komunikace poskytovatelů s uživateli
• Metadata informují uživatele, kdo je poskytovatelem dat
• Datové katalogy, resp. portály často slouží i jako nástroj
komunikace poskytovatelů s uživateli
• Informování uživatelů o nových či změněných datových sadách
• Umožnění zasílání námětů na nové datové sady k otevření
• Zpřístupnění seznamu doposud nepublikovaných datových sad a
prioritizace datových sad k otevření s přihlédnutím k preferencím
potenciálních uživatelů
• Umožnění poskytování zpětné vazby – upozorňování na chyby v
datech a metadatech a tím i podpora kontinuálního zlepšování
kvality

6.6.2014
Datový katalog Evropské unie
Zdroj: http://open-data.europa.eu/en/data/
Vyhledávání podle
oblíbených témat

6.6.2014
Datový katalog Velké Británie
Zdroj: http://data.gov.uk/data/search
Vyhledávání podle
stupňů otevřenosti

6.6.2014
Datový katalog Velké Británie
Zdroj: http://data.gov.uk/dataset/uk-open-access-non-vosa-sites
Stažitelný soubor
Téma
Licence
Název
Další metadata
Stupeň otevřenosti
Zpětná vazba

6.6.2014
Datový katalog Slovenska
Zdroj: http://data.gov.sk/

6.6.2014
Experimentální datový katalog ČR
Zdroj: http://cz.ckan.net/

6.6.2014
Experimentální datový katalog ČR
Zdroj: http://cz.ckan.net/dataset/labour_cost_regional_statistics_comparison
Klasifikace
Název
Dvoujazyčný
popis
Stažitelné
soubory
Další metadata

6.6.2014
Datové katalogy v EU
• Příklady národních datových katalogů
• data.gov.uk
• data.gov.sk
• Příklady nadnárodních datových katalogů v EU
• open-data.europa.eu - datový portál Evropské unie
• publicdata.eu – agreguje katalogizační záznamy z národních
katalogů
• Standardizace obsahu datových katalogů
• DCAT Application Profile for data portals in Europe
• Základem je DCAT – připravované doporučení konsorcia W3C
• Doplněno např. o řešení problému vícejazyčnosti, určení
doporučených slovníků a číselníků atd.
115Tutoriál: Otevírání a propojování dat
Zdroj: https://joinup.ec.europa.eu/system/files/project/DCAT-AP_Final_v1.00.pdf

6.6.2014
Struktura katalogizačního záznamu
• Název datové sady
• Popis
• Periodicita aktualizace
• Datum aktualizace
• Poskytovatel dat
• Kurátor
• Jméno osoby/název útvaru
• Kontaktní email – email na osobu kurátora nebo odpovědnou osobu útvaru
• Odpovědný útvar – útvar či organizační jednotka poskytovatele dat, která za datovou sadu
odpovídá
• Klasifikace – seznam vhodných konceptů z taxonomie EUROVOC, u každého konceptu jsou
uvedeny následující atributy
• Název konceptu – úplný název konceptu v jazyce záznamu
• Odkaz na koncept – odkaz na webovou stránku konceptu z webového portálu taxonomie
• Související geografické území – identifikace geografického území, ke kterému se vztahují data
uvedená v katalogizačním záznamu, může být uvedeno vícekrát
• Název území dle RÚIAN
• Kód území dle RÚIAN
• Odkaz na podmínky užití
• Sekce datových souborů tvořící datovou sadu
• Odkazy na datové soubor (či soubory, pokud je datová sada periodicky aktualizována) doplněný o následujícími
metadata
• Název souboru dat
• Formát dat
• Velikost souboru v bytech
• Datum publikace souboru
• Schéma popisující strukturu datového souboru/ů

6.6.2014
Datový katalog ČTÚ (1/3)
Zdroj: http://www.ctu.cz/otevrena-data/katalog-otevrenych-dat-ctu.html
Přehled datových sad
Hlavní stránka katalogu ČTÚ

6.6.2014
Zdroj: http://www.ctu.cz/otevrena-data/katalog-otevrenych-dat-ctu.html?action=detail&data_id=5
Společná metadata
datové sady
Metadata datového
souboru
Detail datové sady

6.6.2014
Sloupec Název Význam
1 číslo VTA Číslo veřejného telefonního automatu
2 kraj Kraj, ve kterém je veřejný telefonní automat umístěn
3 okres Okres, ve kterém je veřejný telefonní automat umístěn
4 obec Obec, ve které je veřejný telefonní automat umístěn
5 část obce Část obce, ve které je veřejný telefonní automat umístěn
6 ulice Ulice, ve které je veřejný telefonní automat umístěn
7 upřesnění umístění
Poznámka k upřesnění umístění veřejného telefonního
automatu, např. že se nachází u zastávky MHD, nebo u
kašny
Dokumentace schématu – příklad
Zdroj: http://www.ctu.cz/common/open_data/5/06_verejne_telefonni_automaty_v_univerzalni_sluzbe_dle_rozhodnuti_cj_157150_2012_610_schema__1.csv

6.6.2014
Data Catalog Vocabulary (DCAT)
• Strojově čitelný formát pro datové katalogy
• Využívá formát RDF
• Doporučení W3C
• http://www.w3.org/TR/vocab-dcat/
• Cílem je umožnit výměnu metadat mezi datovými
katalogy
• Standardizace datového schématu usnadňuje
budování decentralizovaných datových katalogů
• Je umožněna tvorba profilů
• Přizpůsobení schématu specifickým potřebám
• Příklad profilu
• DCAT Application Profile for data portals in Europe

6.6.2014
DCAT
Zdroj: http://www.w3.org/TR/vocab-dcat/

6.6.2014
DCAT – příklad (1/3)
:statisticka-data-z-personalni-oblasti-ctu
a dcat:Dataset ;
dct:title "Statistická data z personální oblasti ČTÚ" ;
dct:modified "2014-04-03"^^xsd:date ;
dct:accrualPeriodicity <http://purl.org/cld/freq/annual> ;
dcat-cz:curator :opendata-ctu-cz ;
dcat-cz:responsibleOrganizationalUnit :odbor-personalni ;
dct:spatial <http://ec.europa.eu/eurostat/ramon/rdfdata/nuts2008/CZ00> ;
dct:publisher :ctu ;
dct:language <http://id.loc.gov/vocabulary/iso639-1/cs> ;
dcat:theme <http://eurovoc.europa.eu/140664> ;
dcat:theme <http://eurovoc.europa.eu/143004> ;
dcat:keyword "Personální informace" ;
dcat-cz:schema-documentation
<http://www.ctu.cz/common/open_data/8/10_statisticka_data_z_personalni_oblasti_schema.
zip> ;
dcat:distribution: 10_statisticka_data_z_personalni_oblasti_2013_ ;
dcat:distribution: 10_statisticka_data_z_personalni_oblasti_2012_ ;
.

6.6.2014
:10_statisticka_data_z_personalni_oblasti_2013_
a dcat:Distribution ;
dcat:downloadURL
<http://www.ctu.cz/common/open_data/8/custom/10_statisticka_data_z_personalni_oblasti_2013_.
7z> ;
dct:title "10_statisticka_data_z_personalni_oblasti_2013_" ;
dcat:mediaType "text/csv" ;
dcat:byteSize "2530"^^xsd:decimal ;
dct:issued "2014-04-16" ;
dct:licence <http://www.ctu.cz/otevrena-data/podminky-uziti.html> ;
.
:10_statisticka_data_z_personalni_oblasti_2012_
a dcat:Distribution ;
dcat:downloadURL
<http://www.ctu.cz/common/open_data/8/custom/10_statisticka_data_z_personalni_oblasti_2012_.
7z> ;
dct:title "10_statisticka_data_z_personalni_oblasti_2012_" ;
dcat:mediaType "text/csv" ;
dcat:byteSize "5170"^^xsd:decimal ;
dct:issued "2014-04-16" ;
dct:licence <http://www.ctu.cz/otevrena-data/podminky-uziti.html> ;
.

6.6.2014
:ctu
a org:Organization ;
skos:prefLabel "Český telekomunikační úřad" ;
skos:altLabel "ČTÚ" ;
foaf:homapage <http://www.ctu.cz/> ;
org:hasMember :opendata-ctu-cz ;
org:hasSubOrganization :odbor-personalni ;
.
:odbor-personalni
a org:Organization ;
skos:prefLabel "Odbor personální" ;
org:subOrganizationOf :ctu ;
.
:opendata-ctu-cz
a foaf:Agent ;
foaf:mbox "opendata@ctu.cz" ;
org:memberOf :ctu ;
.

Děkujeme za
pozornost
Otevřená a propojitelná data veřejné správy
Aktivity, postupy, návod
6.6.2014
Martin Nečaský
necasky@ksi.mff.cuni.cz
Jan Kučera
jan.kucera@vse.cz
Jakub Klímek
klimek@fit.cvut.cz

Tutoriál : Otevřená a propojitelná data veřejné správy

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Tutoriál : Otevřená a propojitelná data veřejné správy

Ähnlich wie Tutoriál : Otevřená a propojitelná data veřejné správy (20)

Mehr von Martin Necasky

Mehr von Martin Necasky (9)

Tutoriál : Otevřená a propojitelná data veřejné správy

Hinweis der Redaktion