datagov-cz / nkod Goto Github PK

Registrační formuláře pro registraci datové sady a registraci nového lokálního katalogu otevřených dat neobsahuje informaci, že proces registrace po odeslání vygenerovaného souboru datovou zprávou trvá 24 hodin. Často se tak registrující subjekt kontaktuje správce v NKODu a zjišťuje, zda registrace byla úspěšná. S touto informací si registrující subjekt může lépe plánovat mediální kampaň a odstranit nejasnosti při spuštění.

Dobrý den,
na konferenci „OpenData ve VS 2018“ byla během prezentace p. Klímka v části „nový portál data.gov.cz“ zmíněna funkcionalita kontroly a vyhodnocování stavu registrovaných datových sad. Z krátkého popisu jsem pochopil, že se pravděpodobně jedná o periodicky spouštěný program (nebo sadu programů/skriptů), který provádí kontroly dostupnosti datové sady, kvality publikování dat z technického pohledu (např. zabezpečení, šifrování atd.) i kvalitu publikovaných dat samotných. Z výsledků je následně vytvářena statistika.
Napadlo mne, že kromě zmíněných funkcí (a pravděpodobně mnoho dalších) by program mohl v případě zásadní chyby nebo změny stavu zasílat notifikační email na adresu subjektu, který datovou sadu publikuje. Emailová adresa by byla publikujícím subjektem zadávána v metadatech datové sady.
Nejzásadnějším důvodem k odeslání notifikace je zejména nedostupnost datové sady. Nicméně i o dalších změnách publikovaných dat by bylo možné notifikovat - jako je např. změna hodnocení, větší změna počtu publikovaných položek, atd. Změnu by bylo možno vyhodnotit porovnáním naměřených dat se statistikami z předcházejícího běhu.
Návrh je určen zejména pro dohledová oddělení/centra zdrojových informačních systémů a zkrácení reakční doby v případě výpadků publikování otevřených dat.

S pozdravem
Tomáš Tóth

požadavek na typ položky časového rozlišení v metrech dcat:temporalResolution je xsd:duration.

NKOD nicméně na výstupu tutp položku předává s jiným obsahem (natypovaným jako xsd:duration).

Dle vyjádření zástupců NKOD je toto problém způsobený chybou implemenmtace v použité RDF databázi OpenLink Virtuoso .

Problém se projeví jako chyba při vstupní kontrole v návazných katalozích a je potřeba ji opravit a to:

• odstraněním této položky z NKOD a formuláře či
• lokální opravou / patchem knihovny Virtuoso

Příklad výstupu (https://data.gov.cz/sparql):

PREFIX dcat: <http://www.w3.org/ns/dcat#> 
PREFIX dct: <http://purl.org/dc/terms/> 

SELECT DISTINCT ?datova_sada ?nazev ?rozl 
WHERE 
{GRAPH ?g 
	{ ?datova_sada a dcat:Dataset; dct:title ?nazev; dcat:temporalResolution ?rozl. } 
} 
LIMIT 100

Distribuce datových sad se mohou lišit pouze formátem dat, tedy se musí jednat o stejná data, ale například v jedné distribuci v XML a v druhé v CSV. Některé datové sady jako například RÚIAN jsou poskytovány s malou granularitou, tedy například po obcích, kterých je cca 6500. Je požadováno, aby tyto datové sady bylo možné sdružovat do datových sérií, o kterých by šlo hovořit jako o celku, který se skládá z jednotlivých datových (pod)sad.

V současnosti NKOD, ale ani DCAT či DCAT-AP datové série nepodporuje. Tohoto problému jsou si tvůrci těchto standardů vědomi.

• Jako dočasné řešení byl stanoven návod k použití (implementation guideline), který říká, že pokud se dá předpokládat, že uživatel bude chtít k sérii přistupovat jako k celku, lze dočasně porušit pravidlo o distribucích, a jednotlivé soubory ke stažení dát jako distribuce k jedné datové sadě. Nevýhody jsou jasné, je to porušení pravidla a k jednotlivým souborům pak nelze přidat metadata, která by u distribuce běžně byla přítomna. Tento přístup aktuálně používá ČÚZK, například pro sérii RÚIAN: současnost, kompletní datová sada - stav
• Pojem datové série zmiňuje GeoDCAT-AP - datová sada může mít přiřazen typ http://inspire.ec.europa.eu/metadata-codelist/ResourceType/series - toto řešení je ale na úrovni předchozí implementation guideline
• Vztahy mezi datasety obecně se řeší v rámci revize DCAT

Pokud má datová sada svou stránku v rámci LKOD, bylo by užitečné na ni odkazovat v NKOD.

NKOD by měl podporovat vícejazyčná metadata. Tedy pokud poskytovatel dat ve svém lokálním katalogu (LKOD) bude mít vícejazyčná metadata, měla by se objevit i v NKOD a posléze v Evropském datovém protálu EDP.

Možnosti řešení:

• Implementace harvestace LKOD přímo pomocí DCAT-AP

Představuju si to tak, že mi to ukáže nějaký číslo, kolik sad bylo nataženo, u kolika bylo varování a u kolika se vyskytla chyba. Ty not-OK kategorie se potom rozepíšou, takže uvidím, kde máme špatně datum, kde nám chybí popis atd.

Klidně jen mailem. Plus by se to mohlo publikovat jako datová sada Ministestva vnitra ;)

Všiml jsem si, že v NKOD se změnil namespace OVM - což tuším udělá nepříjemnosti všem, kdo si vytahují seznam datasetů za konkrétní poskytovatele.

Tuším, že se změnily i jiné věci, ale tuto jsem identifikoval jako příčinu rozbití kódu...

Starý: https://data.gov.cz/zdroj/ovm/
Nový: https://rpp-opendata.egon.gov.cz/odrpp/zdroj/orgán-veřejné-moci/

Stálo by za to o tom někde informovat, aby uživatelé dokázali rozklíčovat chybu?

Zároveň by pak bylo fajn upravit kód v tutoriálu.

Aktuálně katalogizační záznam datové sady v NKOD obsahuje povinně neřízená klíčová slova a volitelně témata ze slovníku EuroVoc.

Navrhujeme rozšíření katalogizačního záznamu o anotaci pomocí čísla agendy, které se datová sada týká. Toto rozšíření umožní lepší monitorování pokrytí státní správy otevřenými daty a lepší vyhledatelnost souvisejících datových sad. Čísla agend budou provozovatelem NKOD mapována na evropský číselník datových témat vyžadovaný DCAT-AP.

Po kliknutí na anglickou vlaječku vpravo nahoře na data.gov.cz nefunguje přepnutí do anglické verze. Nefunguje to ve Mozile Firefox ESR 52.9.0 ani v IE 11 verze 11.0.9600.18893.

Funguje to ale v Google Chrome Verze 67.0.3396.99

Tato data (https://monitor.statnipokladna.cz/) momentálně nejsou nijak katalogizována a jediný způsob, jak získat jejich metadata, je z nezdokumentovaného API webového front endu. Výsledek je, že URLs datových exportů se mohou bez varování změnit (což se právě stalo) a není způsob, jak takové změny detekovat. V takovém případě se všechny systémy závislé na těchto datech bez varování rozbijí (což se právě stalo).

Po kliknutí na kličové slovo u datasetu například "Rastrový podklad", tak se dostanu na výčet všech datových sad v NKOD bez to, aniž by byly vyfiltrovány datové sady oštítkované jako Rastrový podklad. Správně to má vést https://data.gov.cz/datové-sady?klíčová-slova=Rastrový%20podklad

V katalogu se nezobrazuje datum posledního harvestu metadat datasetu a poslední aktualizace datové sady. Dá se diskutovat, které všechny datumy by se daly do NKOD zobrazovat.

Umožnit distribuci typu OpenAPI

V současnosti je třeba k datové sadě vybrat jeden prvek RÚIAN jako její územní pokrytí.
Do budoucna je třeba mít prvků více a umožnit zadávat navíc i prvky mimo RÚIAN (eu číselníky a další).

Požadavek na typ položky prostorové rozlišení v metrech dcat:spatialResolutionInMeters je xsd:decimal.

NKOD nicméně na výstupu tutp položku předává jako xsd:double.

dle vyjádření zástupců NKOD je toto problém způsobený v použitou knihovnou rdf4j, která v nasazené verzi samovolně změní reprezentaci čísla a tím i datový typ z "12"^^xsd:decimal na "1.2E1"^^xsd:double.

Problém se projeví jako chyba při vstupní kontrole v návazných katalozích a je potřeba ji opravit a to:

• odstrraněním této položky z NKOD a formuláře (stejně ji nikdo nepoužívá) či
• lokální opravou / patchem knihovny rfd4j

Potřeba/popis workflow uživatele:

1. chci jednorázově stáhnout metadata k nějak definované množině datasetů (např. podle poskytovatele, klíčového slova, tématu); metadata by měla obsahovat kromě lidsky čitelného popisu (název poskytovatele, název a popis sady) i nějaký pointer směrem k distribuci.
2. poté, co se pohrabu v katalogu staženém v kroku 1 se chci v co nejmenším počtu requestů dostat od záznamu v sadě popsané výše distribuci (napadá mě varianta např. přímo v metadatech k datasetu zveřejnit URL nejnovější distribuce).

Alternativně u 1 může být vyhledávání v některých polích spíš než stažení sady podle atributů, ale to není velký rozdíl.

V podstatě to může vypadat podobně jako API, ze kterého tahá data současný web front end NKOD. Jen by to mělo být zdokumenované, stabilní a o možná o malinko jednodušší (viz např. bod 2 výše).

Ideálně upřednostnit obsloužení typického discovery <> use workflow před ontologickou úplností; dokumentaci raději ve slovech než v kompletních URI atd.

Na seznamu datových sad podle poskytovatele se při kliknutí na tlačítko "Zobrazit další" nenačtou další datové sady. Tedy ze strany 1 na stranu 2. Tlačítko se proklikne ale stránka se neposune na číslo dva.

https://data.gov.cz/datov%C3%A9-sady?poskytovatel=https%3A%2F%2Frpp-opendata.egon.gov.cz%2Fodrpp

%2Fzdroj%2Forg%C3%A1n-ve%C5%99ejn%C3%A9-moci%2F00006947

Nyní je možné mít pouze jedno, což neumožňuje například linkování jak schématu z OFN, tak svého, rozšířeného v případě přidání vlastních položek.

Povinným atributem datové sady je periodicita aktualizace dle normy ISO 8601.

Jaká je prosím správná hodnota pro datové sady, jejichž distribuce jsou vloženy jen jednorázově, případně jsou aktualizovány nepravidelně/občasně?

Na workshopu byla prezentována potřeba specifikovat podmínky užití ve čtyřech kategoriích, přičemž v každé jsou na výběr jen dvě možnosti:

• distribuce neobsahuje data chráněná v této kategorii
• distribuce je chráněná a uvolněná pod konkrétní licencí, která je určená kategorií - např. pro autorská práva je to CC-BY

Jak se bude postupovat u distribucí, které budou chráněné a uvolněné za jiných podmínek, než je licence uvedená ve druhém bodu? Např. jiná varianta CC, nebo úplně jiná (volná) licence.

Pokud by se SW pro NKOD doplnil o uživatelské účty, mohl by se využít i jako LKOD, což by využila řada OVM.

Aktuálně je možné zobrazit pouze datové sady v dané sérii po navigaci z detailu série. Neb série obsahují, nebo by měli, podobné datové sady, bylo by zajímavé tuto informaci využít ke snížení počtu zobrazených položek v seznamu datových sad.

V kódu CKANu lze nalézt mapování pole format na MIME type¹. V případě, že má pole mimetype u zdroje hodnotu null, mohlo by se při sklizni vyvodit z pole format dle tohoto mapování.

Při filtrování datové sady skrze kalendář Od-Do u poskytovale datové sadě nevidím nově zkataligozvané datové sady. Ačkoliv vím, že datové sady byla před několika dny přidány.

Ahoj,
mám zájem o získání URL jednotlivých datových souborů v téhle sérii, jde o třicet souborů, které se ale aktualizují čtvrtletně, tak bych rád měl nějaký kód, který si vždy najde 30 aktuálních URL z NKODu.

Jaký je dobrý způsob, jak se k těmto URL dostat (JSON, CSV, XML, cokoliv čitelného)? Nerad bych stahoval celý katalog, ale věřím, že to půjde přes API. Zkoušel jsem váš GraphQL endpoint, ale bez dokumentace s příklady mám problém z něj cokoliv smysluplného dostat (resp. nenašel jsem tam filtr na sérii a vlastně ani nevím, zda těch 30 datový sad jsou jedním datasetem nebo více nebo jak ta struktura funguje).

Díky za pomoc,
O.

Na MF dle směrnice katalogizujeme i takové datové sady, kde bylo rozhodnuto o jejich nepublikaci. K takové datové sadě je vytvořen katalgizační záznam a připojeny důvody, proč nebyla publikována.

Tyto sady bychom také rádi publikovali v rámci NKOD.

Formuláře NKOD nyní umožňují přiřadit jedno téma z EU číselníku datových témat. To ale často nestačí, je potřeba umožnit přiřadit témat více.

Registr dotací odkazuje na nedostupné datové sady https://opendata.mfcr.cz/topics/dotace.html

V Národním katalogu není možné filtrovat datové sady podle druhy datové služby, pomocí které jsou poskytovány. Není plánováno rozšíření, které by to umožňovalo stejně jako je tomu u formátů?

Pokud je v CKAN API jako podmínky užití uvedeno https://data.gov.cz/podmínky-užití/volný-přístup/, není to strukturováno tak, jako minulý odkaz na PVS.

Zaznamenal jsem dva dny po sobě podivnou situaci, kdy SPARQL endpoint vrací v odpovědi na jednoduchý dotaz "všechny sady od ČSÚ" (níže) v rozpětí minut různé počty řádek - napřed 15, pak 5, pak 4, pak 1 a po čase zase všech 723. Přihodilo se to včera i dnes (s jinými počty vrácených řádků).

Pochopitelně nedokážu popsat, jak to zreplikovat, ale raději reportuji. Doslova jsem jen pouštěl ten stejný dotaz dokola v rozhraní na data.gov.cz/sparql; přes HTTP request z mé aplikace se to chovalo stejně (tj. stejné dotazy dvěma jinými cestami ve stejný čas generovaly stejné chybné odpovědi).

Pokud něco dělám špatně, budu rád za upozornění. Zkoušel jsem i jiné kódy poskytovatelů a tam se to zdálo v pořádku, ale netestoval jsem to tak důkladně.

Dotaz:

PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX ovmr: <https://rpp-opendata.egon.gov.cz/odrpp/zdroj/orgán-veřejné-moci/>

 SELECT ?dataset_iri
 WHERE {
   GRAPH ?g {
     ?dataset_iri dcterms:publisher ovmr:00025593
   }
} LIMIT 1000

V případě že má poskytovatel dat větší množství datových sad by měl NKOD poskytnout mechanizmus pro harvestování pouze změněných metadatových záznamů.

To by vyžadovalo:

• Definici mechanizmu komunikace hranice, od které má harvestace probíhat
• Implementaci mechanizmu na straně poskytovatele dat (LKOD)
• Implementaci mechanizmu na straně NKOD

K diskuzi:

• Je takové řešení opravdu potřeba?
• Jaký přesně problém na straně poskytovatele vzniká?
• Je to počet HTTP požadavků? Existuje měření, které by ukazovalo že je to pro webserver skutečný problém?

Výhodou stávajícího řešení je bezestavovost, a tedy jednoduchost NKOD.

Možnosti řešení:

• Poskytování DCAT-AP dat LKOD přes SPARQL endpoint

WFS služby mají přístupový bod ve tvaru např. https://services.cuzk.cz/wfs/inspire-cp-wfs.asp. V tomto případě se odezva vrací s kódem 400, protože v požadavku chybí základní povinné parametry. Z pohledu standardu pro WFS je tento stav správně, ale na NKOD se potom objevuje u přístupového bodu informace o nedostupnosti služby (viz obr.).

Bylo by potřeba upravit NKOD tak, aby se v těchto případech informace (a ikona) o nedostupnosti nezobrazovala.