Upozornenie

Návrh sa stal súčasťou Výnosu Ministerstva financií Slovenskej republiky o štandardoch pre informačné systémy verejnej správy

Toto je pracovná verzia.
Oficiálny výstup pracovnej skupiny je tu verzia.

 

Návrh vychádza z Východiská - Výnos Ministerstva financií Slovenskej republiky z 8. septembra 2008 č. MF/013261/2008-132

1. Úvod

Vzhľadom na veľký potenciál rozšírenia princípov definovaných pre OpenData aj pre iné oblasti, navrhujeme rozšíriť tému štandardov pre OpenData na celú oblasť sprístupňovania a vzájomnú prepojiteľnosť strojovo spracovateľných dát.

Tento dokument definuje minimálne štandardy, ktoré musia spĺňať dáta a datasety verejnej správy. 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.

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 je skôr organizačnou a štandardizač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).

2. Slovník pojmov / terminológia

http://www.informatizacia.sk/terminologia/3480s

Otvorené údaje - potrebné definície:

a)   datasetom (alt. "kolekcia údajov") - samostatne použiteľnou ucelenou skupinou súvisiacich údajov, vytvorenou a udržiavanou za určitým účelom a uloženou spoločne podľa rovnakej schémy,

b)      dátovým zdrojom - pôvodné miesto evidencie datasetu,

jh

Zákon o eGovernmente: referenčným údajom údaj objektu evidencie, ktorý je uvedený v zozname referenčných registrov

 

pôvodný zákon o eGov:

referenčným údajom údaj, ktorý je vo vzťahu k objektu evidencie jedinečný a vedený na jedinom mieste; referenčný údaj je určený najmä na zaistenie zdrojovej hodnoty pre príslušnú informáciu o objekte evidencie v informačných systémoch verejnej správy, pričom ku každému referenčnému údaju existuje práve jeden typ referenčného údaja

 

otázka je, či to nemá byť skôr miestom...

c)       odkazovo prepojenými údajmi (Linked Data)

jh

alternatívy sú ešte:

prepojenými údajmi / prepojiteľnými / odkazovateľnými  / odkazovo zviazanými /

...

  • Alt 1: ...konceptuálny model, pri ktorom sú údaje prepojené...
  • Alt 2: ...údaje, ktoré sú prepojené...
    • Alt 1-2A: ...prostredníctvom hypertextových odkazov
    • Alt 1-2B: ...prostredníctvom URI adresácie
    • Alt 1-2C: ...prostredníctvom adresácie identifikátormi typu URI

d)      metaúdajmi štruktúrované údaje obsahujúce informácie o iných, primárnych údajoch; metaúdaje sú určené najmä na vyhľadávanie, katalogizáciu a využívanie primárnych údajov


3. Kvalita dátového zdroja

Metodika hodnotenia kvality dátových zdrojov je odvodené z W3C metodiky 5 Stars (5 hviezdičiek) pre OpenData a prispôsobená potrebám štandardov ISVS v SR v kontexte všetkých strojovo spracovateľných dát. Táto definícia kvality je potom sprísnená pre kontext OpenData a Linked Data.

Vyhodnotenie kvality dátového zdroja a dosiahnutie aspoň stanovenej minimálnej úrovne je jednou zo základných podmienok pre realizáciu OpenData.

Hodnotenie dátových zdrojov vychádza z predpokladov ako:

  • strojová spracovateľnosť dátového zroja,
  • poskytovanie štrukturovanej informácie,
  • licenčná otvorenosť a nezávislosť od konkrétnej sw aplikácie,
  • štandardizovaný prostriedok na popis štruktúry dátového zdroja - schéma a prípadne sémantika,
  • prepojiteľnosť obsahu dátového zdroja s inými dátovými zdrojmi.


Dátový zdroj:

1 hviezdičkaje dostupný na webe a je aktuálny
★★2 hviezdičky1 hviezdička ★ + jeho obsah je štrukturovaný
★★★3 hviezdičky2 hviezdičky ★★ + otvorený formát nezávislý na konkrétnom proprietárnom programovom vybavení (SW)
★★★★4 hviezdičky3 hviezdičky ★★★ + URL dátového zdroja je jednoznačné a nemenné
★★★★★5 hviezdičiek4 hviezdičky ★★★★ + dáta sú linkované na iné dátové zdroje


Z hľadiska tejto metodiky je pre určenie kvality datasetu potrebné posúdiť minimálne nasledovné aspekty:

  • formát údajov datasetu (viď. kap. 6)
  • popis obsahu datasetu (viď. kap. 7)
  • identifikáciu objektov datasetu (viď. kap. 8)
  • spôsob prístupu k údajom (viď. kap. 9)


Príklady:

Viac informácií na:

TODO: Kvalitu datasetov hodnoti standardizacna komisia pri MF SR. Toto naformulovat jasne, presne a "slovnikom" vynosu. Resp. teda toto (kto a ako) je napisane v nejakom vynose - ak ano, tu na to odkazat a doplnit ten vynos o tuto cast. Alebo treba tuto cast zapracovat do Príručky hodnotiteľa štandardov.
=LI: ^toto nebude fungovať, komisia nemá takýto mandát a ani organizačne to nie je reálne, v týchto štandardoch by som asi neriešil kto kvalitu ohodnotí

4. Minimálne štandardy pre OpenData

V súčasnom stave realizácie konceptu OpenData vo verejnej správe SR (napr. žiadné dáta nie sú dostupné v kvalite Linked Data) je potrebné nastaviť požadovanú úroveň štandardov pragmaticky "dostatočne nízko" tak, aby výsledkom bolo čo najširšie realizácie OpenData základnej myšlienky - zverejnenie údajov formou vhodnou na strojové spracovanie. (T.j. ak by naopak štandardy boli príliš reštriktívne, hrozí riziko odmietnutia spolupráce na OpenData koncepte zo strany mnohých inštitúcií.) Z tohto dôvodu navrhujeme nasledovný postup:

  • stanoviť minimálne štandardy, po ktorých splnení bude možné považovať sprístupnené údaje za súčasť OpenData - detaily sú uvedené v tejto kapitole nižšie
  • metodicky popísať odporúčané štandardy pre spôsob sprístupnenia údajov, ktorý považujeme v súčasnosti za technologicky a sémanticky správnu úroveň - detaily sú uvedené v nasledujúcej kapitole "Linked Open Data"
  • tieto štandardy určiť ako záväzné na obdobie do najbližšej ďalšej aktualizácie Výnosu o štandardoch ISVS, t.j. prakticky na 2 roky a v priebehu tohto obdobia rozpracovávať aktualizáciu štandardov a cieľového stavu
  • významným faktorom pre úspech konceptu OpenData je zvyšovanie povedomia (na strane povinných osôb, ale aj používateľov/spracovateľov údajov) o jednotlivých cieľoch, štandardoch, technologických postupoch atď. - táto téma však presahuje rámec štandardov pre ISVS

Minimálne požiadavky, ktoré musí spĺňať určitý dátový zdroj, aby prístup k nemu bolo možné označiť za OpenData, sú nasledovné:

  1. Z hľadiska hodnotenia kvality musí dátový zdroj byť hodnotený na úrovni ★★★ (3 hviezdičky) alebo vyššie - t.j. túto úroveň musia spĺňať súčasne všetky aspekty hodnotenia kvality údajov: formát sprístupnených údajov, úroveň popisu údajov, identifikácia objektov aj spôsob prístupu k údajom.
  2. Dátový zdroj musí byť uvedený v katalógu a musia byť k nemu uvedené všetky požadované popisné údaje (metadáta) - viď. kap. =.
  3. Údaje sú prístupné (neformálne povedané) "pod otvorenou licenciou" - t.j. právne aspekty prístupu a používania údajov sú realizované spôsobom popísaným v kap. =.
  4. =? Požiadavka na aktuálnosť/aktualizáciu/rozlišiteľnosť updatu údajov.

=čo s týmto?

=Odporúča sa používať hlavne formáty a technológie vytvorené nad formátom XML s popísanou štruktúrou XML pomocou jazyka XSD vrátane popisov sémantiky jednotlivých XML elementov a atribútov.
=V prípade že existujú, je vhodné pri tvorbe štruktúry XML využiť dátové prvky definované Výnosom MF SR.

 

5. Linked Open Data

Z dôvodu stále narastajúceho objemu strojovo spracovateľných dát z rôznych zdrojov je nutné hľadať formy vzájomnej prepojiteľnosti dát. Riešením je poskytovanie vzájomne prepojiteľných dát (Linked Data).

Dáta je vhodné publikovať tak, aby prepojiteľnosť umožňovali. Prepojiteľnosť je možné charakterizovať nasledujúcimi technologickými princípmi:

  • Konkrétne a abstraktné objekty majú priradené jednoznačné URI ako jednoznačné identifikátory.
  • Používajú sa iba HTTP URI tak, aby webové prehliadače a aplikácie mohli k URI pristupovať a získať informácie o príslušnom objekte.
  • Konkrétne HTTP URI daného objektu poskytuje dáta o objekte v strojovo spracovateľnej forme vo formáte RDF - Resource Description Framework.
  • Dáta o objekte obsahujú prepojenie na iné objekty znovu pomocou jednoznačných HTTP URI.

Je potrebné pridŕžať sa odporúčani W3C Best Practices for Publishing Linked Data, ktorých aktuálny draft je publikovaný na adrese https://dvcs.w3.org/hg/gld/raw-file/default/bp/index.html .

Linkovanie údajov prebieha v spolupráci (v koorinácii) s komunitným projektom W3C SWEO Linking Open Data (http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenData) s cieľom previazať novo publikované datasety s už existujúcimi - v kontexte otvorených dát napr. s datasetmi previazanými vrámci projektu Linking Open Data cloud (http://lod-cloud.net/).

Vzájomne prepojiteľné dáta predstavujú chcenú úroveň kvality otvorených údajov ★★★★★ 5  hviezdičiek.

TO DO

Treba prebehnúť a zapracovať návrh z PS1 pre štandardy prepojiteľných dát.

TODO

Linked data vo formátoch RDF (Turtle, RDF/XML, ...), OWL, SKOS, ...

6. Formát údajov dátového zdroja


V tejto kapitole je uvedený popis formátov, v ktorých sú sprístupňované údaje (obsah) datasetu. Formát údajov je jedným zo základných parametrov, na základe ktorých sa vyhodnocuje kvalita datasetu.

Pre realizáciu OpenData sprístupnenia údajov je možné použiť iba formáty špecificky uvedené v tejto kapitole (vyjma tabuľku porovnania všetkých formátov).

Pre OpenData koncept je dôležitou požiadavkou použitie takých formátov a spôsobu sprístupnenia údajov, aby bolo možné údaje ďalej automatizovane strojovo spracúvať. Za týmto účelom musia byť použité iba otvorené a technologicky neutrálne formáty (v opačnom prípade by dochádzalo k diskriminácii určitej skupiny používateľov údajov) a údaje musia byť štruktúrované tak, aby sa dali jednoducho automatizovane identifikovať (spomedzi ostatných údajov) a práca s nimi bola uniformná (rovnaká pre všetky položky určitého typu). Samozrejmou požiadavkou je dodržiavanie záväzných pravidiel pre ISVS, ktoré sú obsiahnuté napr. vo Výnose MF SR č.312/2010 Z.z.

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

6.1 Porovnanie formátov

Táto kapitola obsahuje informatívnu tabuľku porovnávajúcu formáty z viacerých aspektov dôležitých pre OpenData koncept. Sú v nej uvedené aj formáty, ktoré nie sú štandardami pre ISVS v SR. Jednotlivé parametre popisujúce formát sú uvádzané ako maximálna možná hodnota dosiahnuteľná pri použití daného formáty. (napr. formát RDF s použitím externých ontológií dosahuje kvalitu 5hviezdičiek, v prípade použitia interných ontológií 4hviezdičky.... atď)

FormátNezávislosť
na aplikácii
Zápis v
štrukturovanej podobe
Popis
štruktúry
dát
Popis
sémantiky
dát

Prepojiteľnosť,
linkovanie

Súlad so
štandardami
ISVS
Maximálne
hodnotenie kvality
PDFÁnoNieNieNieNieTextové dokumenty1 hviezdička ★
DOC, DOCXNieNieNieNieNieNie (iba ako doplnkový)1 hviezdička ★
RTF, ODTNieNieNieNieNieTextové dokumenty1 hviezdička ★
TXTÁnoNieNieNieNieTextové dokumenty2 hviezdičky ★★
(X)HTMLÁnoČiastočneNieNieNieTextové dokumenty2 hviezdičky ★★
XLS(X), ODSNieČiastočneNieNieNieNie (iba ako doplnkový)2 hviezdičky ★★
CSVÁnoÁnoČiastočneNieNieNavrhovaný3 hviezdičky ★★★
JSONÁnoÁnoČiastočneNieNieNavrhovaný3 hviezdičky ★★★
XMLÁnoÁnoÁnoNieNieNavrhovaný4 hviezdičky ★★★★
RDF, OWL
(vlastné ontológie)
ÁnoÁnoÁnoÁnoÁnoNavrhovaný4 hviezdičky ★★★★

RDF, OWL  
(štandardizované ontológie)

ÁnoÁnoÁnoÁnoÁnoNavrhovaný5 hviezdičiek ★★★★★

Formát: Meno alebo skratka formátu alebo rodiny formátov.

Nezávislosť na aplikácii: Formát nie je viazaný na konkrétnu platformu alebo prostredie.

Zápis v štruktúrovanej podobe: Existencia metajazyka na popis formátu, napr. schéma pre XML atď.

Popis sémantiky dát: Existencia formálnej sémantiky pre použitie daného formátu, napr. RDF Semantics

Prepojiteľnosť, linkovanie: Kvalita podpory formátu pre vzájomnú prepojiteľnosť dát, napr. podpora riadených slovníkov a vytváranie vzťahov medzi dátami.

Kvalita: Hodnotenie kvality dátového zdroja je popísané v časti "3. Kvalita dátového zdroja" a predstavuje maximálnu úroveň kvality dosiahnuteľnú pomocou daného formátu.

6.2 CSV

Formát "Comma Separated Values" (CSV) je popísaný v technickej špecifikácii RFC 4180 .

Ide o jednoduchý súborovo orientovaný textový formát, ktorý je určený na reprezentáciu tabuľky údajov (v jednom súbore je uložená práve jedna tabuľka). Každý riadok súboru reprezentuje jeden dátový záznam z tabuľky (riadok), položky dátového záznamu (stĺpce tabuľky) sú oddelené znakom "," (čiarka, U+002C).

Z hľadiska hodnotenia kvality údajov (viď. kap. 3) môže byť dátový zdroj používajúci formát údajov CSV hodnotený maximálne stupňom kvality ★★★ (3 hviezdičky).

Pri použití formátu CSV je potrebné mimo rámca RFC4180 dodržať nasledovné pravidlá:

  • použitá MUSÍ byť znaková sada Unicode / UCS (podľa normy ISO/IEC 10646) v kódovaní UTF-8 (podľa tech.špecifikácie RFC 3629)
  • súbor NESMIE obsahovať na začiatku signatúru BOM (znak U+FEFF kódovaný ako 0xEF, 0xBB, 0xBF - viď. kap. 6 špecifikácie UTF-8), t.j. každý znak U+FEFF bude interpertovaný ako súčasť dát
  • identifikácia typu súboru pri prenose cez sieť Internet (t.j. hlavička "Content-Type" viď. kap. 7) MUSÍ byť uvedená, a to s hodnotou "text/csv; charset=UTF-8"

  • meno súboru by MALO byť ukočené príponou ".csv"
  • konce riadkov MUSIA byť v súbore označené znakom U+000A (LF), alebo dvojicou znakov U+000A, U+000D (CR LF), iné označenia NESMÚ byť použité
  • riadky začínajúce znakom "#" (mriežka, U+0023) sú považované za komentáre a pri čítaní súboru NESMÚ byť interpretované ako údaje; začiatok komentára vo vnútri riadka (t.j. riadok obsahujúci aj údaje aj komentár) NESMIE byť použitý; ak prvá položka riadku začína znakom U+0023, MUSÍ byť táto položka uzavretá do úvodzoviek (viď. kap. 2 bod 5 špecifikácie CSV)
  • význam prázdnej položky dátového záznamu (t.j. ak medzi oddeľovačmi nie je žiadny znak, čo je v súbore viditeľné ako dvojica bezprostredne nasledujúcih znakov U+002C - ",,", alebo riadok začínajúci znakom ",") MUSÍ byť interpretovaný ako "chýbajúci údaj"; ak je potrebné v súbore uviesť položku "prázdny reťazec" MUSÍ byť reprezentovaná dvojicou znakov U+002C , U+002C U+0022 (t.j. prázdny reťazec ohraničený úvodzovkami)
  • ak súbor obsahuje v prvom riadku názvy položiek dátového záznamu (viď. kap. 2 bod 3 špecifikácie CSV) MUSÍ byť táto skutočnosť uvedená v popise údajov a súčasne MUSÍ byť do identifikácie typu súboru pri prenose cez sieť Internet doplnené pole "header=present"; zároveň všetky názvy položiek v rámci jedného súboru MUSIA byť rôzne
  • znaky medzera a tabulátor (U+0020, U+0009, tzv. biele znaky) MôŽU byť pri čítaní interpretované voľne (t.j. reťazec bielych znakov môže byť konvertovaný na iný reťazec bielych znakov, resp. pri teste zhody sú všetky reťazce bielych znakov ekvivalentné); ak je potrebné presne zachovať v rámci položky určitý reťazec bielych znakov, MUSÍ byť táto položka uzavretá do úvodzoviek (viď. kap. 2 bod 5 špecifikácie CSV)
  • ak položka dátového záznamu obsahuje číslo v desatinnom tvare obsahujúcom ako oddeľovač desatinnej časti znak "," (čiarka, U+002C), MUSÍ musí byť táto položka uzavretá do úvodzoviek

=overiť kompatibilitu najmä s Excel

Popis údajov (schéma) nie je súčasťou špecifikácie CSV a nie je ani uložený v súbore v týmto formátom, musí byť teda uvedený separátne. Použitý MUSÍ byť popis v súlade s kap. 5.

Ak je použitý textový popis (viď. kap.5.1) treba dodržať nasledovné pravidlá:

  • všetky položky dátového záznamu MUSIA byť v schéme popísané
  • referencovanie jednotlivých položiek MUSÍ byť realizované pomocou ich poradových čísel tak, ako sú uvedené v súbore s údajmi vo formáte CSV, kde prvý stĺpec má číslo 1, alebo, ak v súbore vo formáte CSV je uvedený v prvom riadku názov položiek, MôŽE byť referencovanie realizované pomocou týchto názvov

Ak je použitý popis pomocou schémy XSD (viď. kap. 5.2), treba dodržať nasledovné pravidlá:

  • =tu treba navrhnúť schému tabuľky, niečo ako aj teraz vie robiť napr. Oracle cez generateXMLSchema
  • všetky pravidlá pre textový popis uvedené vyššie MUSIA byť dodržané

Upozorňujeme, že častokrát používané "vylepšenia" formátu CSV, napr. oddeľovače iné ako U+002C, položky s "pevnou dĺžkou", alebo proprietárne formáty pre popis údajov (napr. súbor schema.ini) nie sú podporované a nespĺňajú vyššie uvedený štandard.

6.x =? JSON

Formát "JavaScript Object Notation" (JSON) je popísaný v technickej špecifikácii RFC 4627.

Ide o jednoduchý, otvorený textový formát, ktorý je určený na výmenu dát medzi aplikáciami.

Z hľadiska hodnotenia kvality údajov (viď. kap. 3) môže byť dátový zdroj používajúci formát údajov JSON hodnotený maximálne stupňom kvality ★★★ (3 hviezdičky).

Pri použití formátu JSON  je potrebné mimo rámca RFC 4627 dodržať nasledovné pravidlá:

  • použitá MUSÍ byť znaková sada Unicode / UCS (podľa normy ISO/IEC 10646) v kódovaní UTF-8 (podľa tech.špecifikácie RFC 3629)
  • súbor NESMIE obsahovať na začiatku signatúru BOM (znak U+FEFF kódovaný ako 0xEF, 0xBB, 0xBF - viď. kap. 6 špecifikácie UTF-8), t.j. každý znak U+FEFF bude interpertovaný ako súčasť dát
  • identifikácia typu súboru pri prenose cez sieť Internet (t.j. hlavička "Content-Type" viď. kap. 7) MUSÍ byť uvedená, a to s hodnotou "application/json; charset=UTF-8"

  • meno súboru by MALO byť ukočené príponou ".json"

Popis údajov (schéma) nie je súčasťou špecifikácie JSON, ale existuje public draft  JSON Schema -  http://json-schema.org/documentation.html

 

 

6.3 XML podľa schémy

=tento formát zodpovedá "dátovým prvkom" podľa aktuálne platným štandardom pre ISVS

=dátový prvok musí mať štruktúru podľa stanovenej schémy (XSD), popis schém v samostatnej kap. (viď. nižšie)

=toto by malo spracovať MF, keďže to zodpovedá súčasným štandardom: dátové prvky/číselníky

=cieľový formát je asi XML 1.0 / 5.ed

=tento formát môže dosiahnuť kvalitu max. 4 hviezdičky ★★★★ 

 

6.4 RDF =premenovať?

=de facto hovoríme o RDF/XML, t.j. W3C RDF-CAS

=tejto kapitoly sa ujal Datalan, viď návrh z PS1 pre štandardy prepojiteľných dát a RDF – Resource Description FrameworkVyhodnotenie kritérií pre posudzovanie štandardov

= RDF dosahuje úroveň 4 hviezdičky ★★★★ bez vyžitia externých ontológií,

=  a úroveň 5 hviezdičiek ★★★★★ v prípade, že sa využívajú URI identifikátori externých zdrojov (externé ontológie, či externé URI), čo je označované ako Linked Data.

RDF je štandardizovaný model pre dátovú výmenu pomocou web technológií. RDF zabezpečuje prepojiteľnosť dát aj v prípadoch použitia rôznych dátových schém a zároveň zabezpečuje podporu postupného vývoja a zmien v dátových schémach bez potreby zásahu do samotných dát.

Umožňuje zápis grafových (sieťových) dát. Umožňuje zachytiť ľubovolné štrukturované dáta v strojovo spracovateľnej podobe. Ponúka štandardizovaný spôsob zápisu štruktúry a sémantiky dát. Je založený na známych princípoch webu umožňujúcich prepájanie súvisiacich dát z rôznych zdrojov.

RDF rozširuje linkovanie webových objektov definovaných jednoznačnými URI pridaním relácií medzi objektmi. Jednoznačná relácia dvoch objektov (dve jednoznačné URL linky popisujúce objekty) je definovaná treťou jednoznačnou URL linkou popisujúcou samotnú reláciu. Takýto vzťah nazývame "triple". (viac info napr. http://en.wikipedia.org/wiki/Resource_Description_Framework) Pomocou tohto modelu je možné spájať štrukturované a čiastočne štrukturované dáta, definovať medzi nimi vzťahy a zdieľať ich pre rôzne aplikácie.

Ide o základný prvok tzv. Prepojiteľných strojovo spracovateľných dát (Linked Data) štandardizovaný na úrovni W3C.

Aktuálne špecifikácie štandardov W3C.

(strikethrough = u zapracovane do Návrh metodiky a štandardu pre sprístupňovanie a prepojiteľnosť strojovo spracovateľných dát)

7. Popis obsahu dátového zdroja

V tejto kapitole sú uvedené spôsoby zachytenia a popisu obsahu datasetu, t.j. jeho vnútornej štruktúry, položiek z ktorých sa skladá a ich typov. Spôsob popisu obsahu datasetu je jedným zo základných parametrov, na základe ktorých sa vyhodnocuje kvalita datasetu.

Pre realizáciu OpenData sprístupnenia údajov je možné použiť iba spôsoby popisu obsahu datasetu špecificky uvedené v tejto kapitole.

7.1 Textový popis

=toto je cielené pre CSV, kde sa popis nedá spraviť formálnejšie

=popisom je tabuľka, v ktorej je pre každú typovú položku ("stĺpec") datasetu uvedené:

  • poradové číslo v položky
  • (voliteľne) meno položky ("meno stĺpca")
  • popis objektu, ktorý táto dátová položka obsahuje (napr. "meno a priezvisko fyzickej osoby")
  • dátový typ položky (napr. "celé číslo", "text")
  • (voliteľne) ohraničenia pre hodnotu položky (napr. "nie viac ako 255")
  • (voliteľne) poznámka

=pri tomto spôsobe popisu údajov je možné dosiahnuť maximálne stupeň ★★★ (3 hviezdičky) kvality datasetu

 

7.2 XSD

=XSD, je už v súčasnosti štandardom pre popis dátových prvkov

=tento spôsob popisu je cielený pre formát XML na základe schémy

=toto by mohlo spracovať MF, keďže to zodpovedá súčasným štandardom: dátové prvky/číselníky

=pri tomto spôsobe popisu údajov je možné dosiahnuť maximálne stupeň ★★★★ (4 hviezdičky) kvality datasetu

7.3 RDF ontológie

=tejto kapitoly by sa mohol ujať Datalan

=toto je max. 5 hviezdičiek ★★★★★ viď 6.4.

8. Identifikácia objektov

V tejto kapitole sú uvedené spôsoby identifikácie objektov v položkách datasetu. Spôsob identifikácie objektov je jedným zo základných parametrov, na základe ktorých sa vyhodnocuje kvalita datasetu.

Pre realizáciu OpenData sprístupnenia údajov je možné použiť iba spôsoby identifikácie objektov špecificky uvedené v tejto kapitole.

=ako sa vyhodnotí kvalita DS kde niečo je podľa číselníku, niečo podľa URI?

8.1 Identifikácia hodnotou

=chceme toto vôbec?

=objekty sú identifikované vložením hodnoty požadovaného atribútu, napr. údaj "adresa" obsahuje textvoú informáciu "Nám. Ľ. Štúra 7"

Identifikáciu objektov hodnotou iba ak nie je možné použiť metódu identifikácie s vyššim stupňom kvality.

Ak je identifikácia hodnotou použitá pre nasledovné typy objektov, dataset môže byť hodnotený maximálne stupňom kvality ★★★ (3 hviezdičky):

  • pre objekt existuje centrálne schválený číselník, alebo
  • objekt je referenčným údajov v niektorom referenčnom registri

Nevýhody identifkácie objektov hodnotou:

  • náchylnosť k chybám, preklepom
  • v rôznych datasetoch/situáciách môže byť hodnota zapisovaná ináč (napr. "Pekníkova 56", "Pekníkova ul. 56", "Pekníkova ulica 56", "Pekníkova 56/2356" atď.)
  • z vyššie uvedených vyplýva problematická prepojiteľnosť údajov, vnútorná aj vonkajšia
  • rovnako je výrazne zhoršená možnosť kontroly správnosti údajov a štruktúr údajov

8.2 Číselník

=toto je cielené pre CSV a XML
=dnes je to rozpracované pre dátové prvky

=toto by mohlo spracovať MF, keďže to zodpovedá súčasným štandardom: dátové prvky/číselníky

=toto je max. 4 hviezdičky ★★★★ 

8.3 URI

=ak niečo riešiť, tak prioritne referenčné registre

=toto nech rieši partia čo dáva návrhy na URI štandardy

=toto je max. 5 hviezdičiek ★★★★★

URI a aktivita PS1

Tejto aktivite sa čiastočne venuje aktivita pána Miroslava Lišku, ktorý predložil v rámci ps1 návrh.

 

9. Prístup k údajom (prenos údajov - termín)

V tejto kapitole uvádzame základné spôsoby prístupu k údajom, t.j. metódu, akým spôsobom sa dostanem k údajom, transportné protokoly.
Rozlišujeme dva základné spôsoby sprístupnenia:
  1. dáta sprístupnené ako jeden celok v jednom, alebo v skupine súborov s údajmi - ide o pasívny spôsob prístupu, kde server sprístupní "naraz" celý blok údajov (súbor/súbory) v definovanom formáte,
  2. prístup cez aplikačné rozhranie (API) - ide o aktívny prístup, kde používateľ, alebo aplikácia zadávajú serveru dopyty na konkrétne požadovaná údaje, ktoré server po spracovaní dopytu vyhľadá a odošle v štandardizovanom formáte.

Ku spôsobu prístupu "súbor s údajmi" štandardom pre ISVS je v súčasnosti HTTP, FTP.

Ku API: k tomuto asi iba

 

10. Metadáta - popis dátových zdrojov

=tu sa rozoberajú metadáta samotného dátového zdroja (t.j. nie metadáta údajov/obsahu)

=správnosť / záväznosť údajov

Minimálna štruktúra údajov popisujúca dátový zdroj:

  • názov dátového zdroja,
  • dátum, kedy bol dátový zdroj prvý krát zverejnený,
  • údaje o aktuálnosti dátového zdroja / údajov,
    • =dátum, kedy bola aktuálna verzia dátového zdroja zverejnená,
    • =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),
  • jednoznačný identifikátor (IČO) pri subjektoch, ktoré ho majú,
  • jednoznačné URL sprístupneného dátového zdroja,
  • =typ licencie,
  • 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).

TODO: Refaktorovat: Treba popisat, ake atributy k datasetu musi uviest zverejnovatel/povinna osoba (zdrojove URL, licencia, ...) ktore atributy (a ako - metodika) doplni spravca data katalogu (napr. 5start rating). To sa tyka vsetkych datasetov statnej spravy napr. aj pre interne potreby statnej spravy, t.j. aj neverejne (nie Open Data). Nasledne, ak chce dataset postupit do "Open Data" kategorie, tak musime povedat ze "Open Data rating musi byt aspon 3 hviezdičky ★★★, email byt vyplneny musi, licencia moze byt len taka a taka), naslende bude zverejneny na data.gov.sk a az potom moze byt oznaceny ako "Open Data".

11. Aktuálnosť údajov

=ciele sú nasledovné:

=vždy vedieť povedať, k akému okamihu (dátum/čas) sú údaje platné
=po aktualizácii dátového zdroja (alebo všeobecnejšie, pre dva rozdielne okamihy) vedieť efektívne zistiť, ktoré údaje boli zmenené (aktualizované, doplnené, vymazané)
=vedieť odhadnúť, kedy dôjde k ďalšej aktualizácii údajov, resp. či sú údaje online

= v časti "Spôsoby sprístupnia" popisujeme spôsoby, ktorými sa dajú údaje zverejňovať ako celok ("dump" = možnosť 1), po inkrementoch ("dump" pre určité časové intervaly - možnosť 2) alebo "individuálne" (po položke, cez API - možnosť 3). K nim platia nasledovné požiadavky o aktuálnosti:

  1. "dáta sprístupnené ako jeden celok ...": súčasťou metadát o datasete musí byž dátum poslednej aktualizácie, vítaným údajom je predpokladaný dátum a čas ďalšej aktualizácie alebo údaj o tom, ako dlho od poslednej aktualizácie možno údaje považovať za aktuálne
  2. "dáta obsahujúce prírastky ...": dátaum posledného inkrementu = dátum poslednej aktualizácie datasetu ako celku
  3. "prístup cez aplikačné rozhranie (API) ...": minimálne platí, že údaje získané cez API sú správne a platné k času, kedy bolo realizované volanie API, ideálne však je:
    1. k údajom vráteným z API pripojiť úaj o čase vzniku, voliteťne aj údaj o platnosti (obdobne ako HTTP cache hlavičky)
    2. v dokumentácii API uviesť, obdobne ako v bode 1, predpokladaný dátum a čas ďalšej aktualizácie alebo údaj o tom, ako dlho od poslednej aktualizácie možno údaje považovať za aktuálne

12. Licencia / právne aspekty používania údajov

Pre sprístupňované údaje musí byť vždy jednoznačný právny rámec určujúci, aké sú možnosti ďalšieho nakladania s údajmi a povinnosti s tým spojené.

V súčasnosti nie sme v situácii, kedy by sme vedeli predpísať konkrétne licencie pre všetky (OpenData) dátové zdroje, preto aspoň opisne stanovujeme minimálne požiadavky.

Pri sprístupnení údajov formou OpenData musia byť splnené minimálne nasledovné podmienky:

  • formálne právne aspekty prístupu k údajom a ich používania sú explicitne vysporiadané
    • Spôsob vysporiadania (napr. informácia, že databáza údajov nespadá pod ochranu autorským zákonom, alebo informácia o licenčných podmienkach) je uvedený v popise dátového zdroja, t.j. v metadátach
  • vzťahy potrebné na používanie údajov (napr. uzavretie licenčnej zmuvy) je možné vytvoriť pri anonymnom vzdialenom automatizovanom prístupe k údajom
  • všetci majú prístup k údajom umožnený za rovnakých podmienok
    • Týmto nie je vylúčená možnosť umožnenia prístupu k údajom iným - nie OpenData - spôsobom, v rámci ktorého môžu byť stanovené iné podmienky, napr. môže existovať špecifický prístup k údajom v rámci G2G vzťahov. V tejto oblasti sú stanovené pravidlá zákonom č.211/2000.
  • používateľ môže údaje použiť na nekomerčný alebo komerčný účel podľa vlastného rozhodnutia, vrátane ich ďalšieho zverejňovania,
  • používateľ môže údaje modifikovať podľa vlastného rozhodnutia, najmä kombinovať ich s inými údajmi, dopĺňať, opravovať alebo selektovať údaje,
  • využitie údajov vyššie uvedenými možnosťami je pre používateľa bezodplatné.

Poskytovateľ údajov najčastejšie stanovuje (podľa vlastného uváženia) pre používanie údajov podmienku identifikácie zdroja. Ak v takomto prípade používateľ údaje dátového zdroja kombinuje s inými údajmi (napr. "vlastnoručne" opravuje chyby v údajoch), musí vedieť zabezpečiť rozlíšenie pôvodných údajov dátového zdroja a ich označenie v súlade s požiadavkami.

  • No labels

1 Comment

  1. z diskusie v ramci FB grupy opendata.sk - "...ale posunul by som uvahu este kusok dalej. ja tam vidim vlastne takmer len cisto funkcne poziadavky (obmedzenia). myslim, ze by mal paralelne existovat dalsi dokument, ktory bude definovat nefunkcne (NFR) poziadavky a aktualnost dat by mala byt jednou z nich. taktiez klasicke NFRs ako availability, auditability, response time, testability (unit test coverage 80%), povinnost mat continuous integration, ..."