Child pages
  • Návrh technickej špecifikácie štandardov pre Open Data
Skip to end of metadata
Go to start of metadata

Upozornenie

Aktuálna verzia

Táto pracovná verzia bola uzavretá. Na budúcich verziách sa pracuje na stránke Návrh metodiky a štandardu pre sprístupňovanie a prepojiteľnosť strojovo spracovateľných dát

Návrh technickej špecifikácie štandardov pre zverejňovanie datasetov v SR. Návrh sa inšpiruje a koordinuje výstupmi pracovnej skupiny, ktorá rieši agendu Otvoreného vládnutia u splnomocnenca vlády SR pre rozvoj občianskej spoločnosti na Úrade vlády a tie6 v7stupmi z pracovnej skupiny PS3 Standardizacnej komisie MF SR.

Návrh možno prebrať a po relevatných úpravách ustanoviť ako špecifikáciu pre subjekt, ktorý bude podľa nej zverejňovať údaje. Subjektom sa zvyčajne myslí organizácia verejnej správy.


Časť 1: Datasety a zverejňovanie

V tomto dokumente sú uvedené požiadavky na štandardy sprístupňovanie údajov v rámci siete Internet filozofiou Open Data. Popisuje štandardy týkajúce sa samotného sprístupňovania údajov.

Údaje sú vždy súčasťou určitého dátového zdroja (datasetu). Dataset je ucelená skupina údajov, vytvorená a udržiavaná za určitým účelom. Dátové zdroje verejnej správy sú vytvárané za účelom podpory služieb verejnej správy, služieb vo verejnom záujme alebo verejných služieb. Jednotlivé agendy súvisiace s výkonom verejnej správy môžu obsahovať viaceré dátové zdroje. Charakteristickým znakom dátového zdroja je jeho samostatná použiteľnosť (výpovedná hodnota) nezávisle od iných dátových zdrojov. Ďalšími znakmi popisujúcimi dátový zdroj sú názov, účel (zameranie), typy spracúvaných údajov a vzťahy medzi nimi, formát údajov a podobne – tzv. metadáta.

Sprístupnenie dátového zdroja zabezpečuje jeho správca na základe vlastného rozhodnutia a pomocou vlastných prostriedkov (t.j. napr. portáli otvorených dát budú uložené len katalógy, nie samotné údaje).

Tento dokument definuje minimálne štandardy, ktoré by mali spĺňať datasety verejnej správy zverejnené ako Open Data. Základná požiadavka na spôsob sprístupnenia údajov je, aby údaje boli automatizovane strojovo spracovateľné. Štandardy sú vytvorené na dosiahnutie tejto požiadavky. Toto kritérium je pre minimálne štandardy základným merítkom splnenia požiadavky na sprístupnenie údajov.

(TODO: upresniť, ktorých organizácií sa toto týka, lebo úplne všetkých asi nie) Zároveň sú správcovia dátových zdrojov povinní dodržiavať zákon č.275/2006 Z.z. o ISVS vznp. (ďalej "zákon") a príslušné štandardy pre ISVS vydané MF SR ( §2 ods.3 písm. a) zákona). Na základe §3 ods.4 písm. d) „povinné osoby, ktoré sú správcami, sú povinné sprístupňovať verejnosti údaje z informačných systémov verejnej správy, ak osobitný predpis neustanovuje inak“ a e) „povinné osoby, ktoré sú správcami, sú povinné sprístupňovať alebo na požiadanie poskytnúť bezplatne iným povinným osobám údaje z informačných systémov verejnej správy potrebné na ich činnosť, ak osobitný predpis) neustanovuje inak“ zákona všetky ISVS už sú na sprístupňovanie údajov pripravené. To znamená, že iniciatíva data.gov.sk je skôr organizačnou záležitosťou. Štandardy pre ISVS aktuálne obsahuje Výnos MF SR č.312/2010 Z.z. (ďalej "výnos").

Všetky používané štandardy musia byť otvorené a technologicky neutrálne ( §6 ods.1 zákona).

Časť 2: Formáty údajov

Rozlišujeme dva základné spôsoby sprístupnenia:

  1. prístup k súborom s údajmi - ide o pasívny spôsob prístupu, kde server sprístupní "naraz" celý blok údajov (súbor), vyhľadávanie v údajoch je ponechané na používateľa
  2. prístup cez aplikačné rozhranie (API) - ide o aktívny prístup, kde používateľ zadáva serveru dotazy na konkrétne požadovaná údaje, ktoré server po spracovaní dotazu vyhľadá a odošle

URI

TODO: doplnit, o.i. aj podla D7.1.3 - Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC

Formáty súborov

Prípustné nie sú:

  • tabuľky vyjadrené v textovom súbore
  • proprietárne formáty tabuľkových súborov - napr. XLS
  • súbory obsahujúce aktívne prvky tabuliek (napr. makrá, vzorce)
  • iba obalenie nevhodného súboru do XML

API

  • ide o prístup ku aplikácii spravujúcej bázy údajov o datasete
  • minimálne požiadavky:
  • odporúčané formáty: ako vyššie (vo formátoch súborov) ale navyše aj vo formáte RDF (Turtle, RDF/XML, ...) cez SPARQL endpoint

Prípustné nie sú:

  • nekonzistentné či neúplné dáta
  • nekonzistentné či neúplné API (ak napríklad obsahuje funkciu "getItem()" ale neobsahuje "listItems()")
  • nekonzistentná či neúplná dokumentácia k API
  • nevysvetlené a neohlásené výpadky funkčnosti API

Časť 3: Štruktúra údajov

Štruktúra údajov pre dátový zdroj:

  • dátum, ku ktorému sú údaje platné, alebo informácia, že ide o aktuálne údaje v čase prístupu
  • odporúčané: dátum najbližšej aktualizácie (pokiaľ nejde o sprístupnenie vždy aktuálnych údajov)
  • sprístupnenie doplňujúcich informácií, ktoré majú napomôcť automatizovanému spracovaniu údajov dátového zdroja:
    • schémy údajov - pokiaľ schéma údajov (t.j. členenie dátového zdroja na typy údajov, konkrétne záznamy a vzťahy medzi týmito entitami) nie je triviálna
    • popis typov položiek - najmä v prípade, ak sú používané netypické dátové typy, číselníkové typy, skratky, zložené dátové typy a pod.
    • popis formátov v ktorých je dátový zdroj sprístupňovaný - napr. formáty súborov
    • popis možných nepravidelností v štruktúre

V prípade, že je správcovi údajov známe, že niektoré údaje sú neaktuálne, nesprávne, alebo neúplné, tieto údaje musia byť označené spôsobom umožňujúcim automatizovane ich odlíšiť od aktuálnych, správnych, alebo úplných údajov (o.i. to znamená, že prítomnosť takýchto údajov nie je sama osebe dôvodom na nesprístupnenie dátového zdroja).

Jednotlivé položky údajov ukladať spôsobom:

  • umožňujúcim ich lokalizáciu (najmä odlíšenie od iných položiek) v rámci dátového zdroja
  • čítanie automatizovaným spôsobom
  • rovnakým spôsobom pre všetky dátové vety v určitom dátovom zdroji (dátová veta je množina súvisiacich položiek opisujúcich určitý objekt)

Prípustné nie sú:

  • formáty určené na čítanie pre používateľa, ktoré neumožňujú automatizované spracúvanie údajov (napr. web aplikácia)
  • nepravidelný formát dátovej vety
  • nemožnosť izolovať z dátovej vety/súboru konkrétne položky

Časť 4: prístup k údajom

Údaje sa sprístupňujú prostredníctvom sieťovej infraštruktúry ( §3 ods.2 písm. j) zákona), v sieti Internet.

Dátový zdroj musí mať určitú lokáciu, ktorá je stabilná:

  • vyjadrená pomocou URL (resp. iného konkrétneho identifikátora, ak ide o prístup iným protokolom)
  • zmena lokácie nastáva iba vo výnimočnom prípade, napr. pri zmene formátu údajov, nasadzovaní nového webového sídla

Prístupu sa venujú štandardy pre prepojenie, najmä §3, §4, §5 výnosu a štandardy pre prístup k elektronickým službám, najmä §9 výnosu a štandardy pre webové služby, §11 výnosu.

Server musí vyhodnocovať požiadavky na prístup bezstavovo, t.j. požiadavka je vyhodnotená bez ohľadu na spracovanie predchádzajúcich požiadaviek. Prípustné sú aj viaceré "pohľady" na údaje. Pod pohľadom rozumieme spoločne prezentovanú časť dátového zdroja, spravidla ide o na dátovom zdroji vykonanú reštrikciu (filter) určitých položiek, objektov, alebo vzťahov medzi objektmi - napr. ak z dôvodu ochrany osobných údajov nie je možné sprístupniť celý dátový zdroj, je prezentácia rôznych pohľadov žiadanou alternatívou.

Prípustné nie sú:

  • "roztrúsené" umiestnenie údajov - napr. potreba preklikávania "stránok", parsovanie údajov zo stránok
  • prvky určené na ovládanie používateľom - napr. tlačítka, grafické prvky
  • požadovaná identifikácia, autentifikácia, či iná práca s používateľom

(TODO: čosi na tému:

  • redirecty: HTTP 301 a 302 - dôležité pre vyššie spomenutú "stabilnú lokáciu"
  • range requesty - dôležité napr. pre download veľkých CSV, v ktorých sa len dopĺňajú nové údaje na koniec súboru, kedy možno preskočiť začiatok súboru, ktorá bola stiahnutá uz skôr
  • caching: HTTP hlavicky Cache-Control, Expires, ... v odpovedi, If-Modified-Since v poziadavke, atď. aby sa efektívnejšie využil webserver, na ktorom sa dataset publikuje

)

TODO

Po sfinalizovani premiestnit dokument do Liferay portalu, do sekcie komunity Open Data.

  • No labels

4 Comments

  1. Zdravim, neviem nakolko to tu je aktualne, ale skusim to tu ozivit. 

    Presiel som ten aktualny navrh a tu su nejake postrehy, ktore vychadzaju z realizacie mojich projektov nad verejnymi databazami:

    • Najviac mi chyba specifikacia na API, ktore bude riesit zmeny dat. Toto je kamen urazu vsetkych sucastnych portalov kde su verejne data. To, ze je tam bordel, data su neuplne alebo naskenovane to nie je az take hrozne, to sa este da zvladnut, ale ako zistit ci nebol nejaky dokument medzicasom aktualizovany ked ich su tam miliony je seriozny problem. Podla mna takyto endpoint musi byt povinny. 
      • Napriklad: Vrat mi vsetko co sa zmenilo od datumu xyz (v klude strankovane po rozumnom pocte, nech to nie je vykonnostny problem)
    • V tej ceskej verzii (co poslal ivan hore) je moznost vyberu medzi 3 sposobmi pristupu k datam: jeden celok, casove prirastky alebo online pristup. Osobne by som trval v kazdom pripade na moznosti stiahnut data cele + sledovat zmeny alebo prirastky. To, ze spravia nejake API nad tym co bude online je fajn, ale pri vsetkych mojich projektoch s verejnymi datami (a neni ich malo) som dopadol tak, ze som musel tie data mat vsetky u seba a spracovat ich specificky pre svoje potreby.
    • Platnost udajov (jednak formalna a dvak odkedy bola zverejnena) je podla mna informacia, ktora musi byt uvedena za kazdu cenu. Taktiez jednoznacny identifikator (ICO) pri subjektoch, ktore ho maju. Na tom aby boli data uplne by som osobne asi netrval, realne si myslim, ze by to mohlo sposobit, ze sa bude toho potom zverejnovat menej, kedze s tym bude viac prace. Na druhej strane je mozne, ze sa na to bude viac kaslat. Som otvoreny diskusii, nie je to definitiva.
    • Osobne mi nevadi ani autentifikovany pristup, pokial by bol umozneny kazdemu a bezplatne. Z technologickeho hladiska je to vhodna forma ochrany, aby ich jeden pouzivatel nevytazoval nadmieru. Treba vsak zvazit nakolko je povolene vyuzivat rate limiting, aby sa to nestalo nepouzitelnym.
    • Ochrana captchou a tak je zakazana - to je asi jasne.
    • OWL, RDF si pamatam z cias mojej akademickej kariery a osobne si myslim, ze je to strasny overkill. Jedinu vyhodu co z toho vidim je, ze budu mat entity jednoznacny identifikator. V praxi je to vsak pri firmach ICO a pri ludoch je to IMHO cista utopia. Tie data nebude nikto udrziavat, toboz nie napriec statnymi instituciami, museli by sa tam zverejnovat roky narodenia alebo rodne cisla. Neviem si to uplne predstavit, rad sa vsak necham vyviest z omylu.

    Tazko sa tato wiki sleduje, je to tu velmi roztrusene a neviem co je este zive a co nie.



    1. Kedze s tymto zapasime uz dlhsie, dovolil som si spisat, aky mame stav: Open Data specifikacia - stav k marcu 2013 (je to zial/nastastie "uzavrete" pre komunitu, kedze z objektivnych aj subjektivnych dovodov sme zatial nedosiahli uroven otvorenosti LKML, kde si v pohode verejne vynadaju a stale je to konstruktivne (smile) ).

      Zakladna poznamka je asi taka, ze na zaciatok chceme cosi rychlo, lacno a "good enough". Aby aspon prva sada datasetov sla von v "good enough" kvalite, lebo zatial je to bieda. Nasledne by sme v iteraciach doplnali, upresnovali, ... na zaklade coho sa vylepsia uz vypustene datasety a zverejnia dalsie nove. A popri tom stale davat pozor, aby sme neziadali privela, na com by to mohlo zakapat.

      K jednotlivym bodom:

      • efektivna propagacia zmien: Ano, jednoznacne. S tym suvisia aj HTTP hlavicky (kesovanie, ...), Range requesty, ... Trosku sirsie a prepletenejsie ale skor v zmysle "viacero alternativ".
      • platnost udajov: Opat jednoznacne ano. Ale ... (smile)
      • regulovanie pristupu: Tzv. API key su bezne (k API), naopak login + heslo ... asi tazko (a to aj keby sme mali elektronicky obciansky - hint: "regulovanie" vs. "open").
      • OWL, RDF: Ma to potencial vyriesit napr. de-duplikaciu dat (kedy urad X zverejnuje dataset, v ktorom ma udaje z uradu Y: dnes ich duplikuje, s urcitou latenciou a chybovostou). Dalsou silnou strankou by mal byt lahsi vyvoj aplikacii pracujucich s viac datasetmi (napr. graf rozpoctu pre celu EU, ktory by ciastkove data tahal zo statnych a municipalnych urovni a vdaka Linked Data by odpadla velka cast ETL procesu). Tot ale zatial naozaj domena vyskunikov, nie praxe. Uvidime.
    2. Dik za pripomienky. Vacsinu som sa pokúcil zapracovat do návrhu pre pracovnú skupinu PS 3. V pondelok by sa mala prediskutovat prvá verzia. Dokument ako taký nepôjde do výnosu. Pojde tam len posledná kapitola Návrh zmien textácií vo výnose a metodickom pokyne, ktorá ale vypadne ako dorivát celého dokumentu.