Eesti infoühiskonna aastaraamat 2011/2012. Karin Kastehein

Чтение книги онлайн.

Читать онлайн книгу Eesti infoühiskonna aastaraamat 2011/2012 - Karin Kastehein страница 6

Eesti infoühiskonna aastaraamat 2011/2012 - Karin Kastehein

Скачать книгу

endast kolme integreeritud süsteemi.

      • Uudiste, küsimuste, diskussioonide ja juhendite portaal, kus esitada juhendeid ja uudiseid, tõstatada küsimusi ja diskuteerida avaandmete teemal.

      • CKANi-põhine avaandmete linkide, kirjelduste ja oluliste metaandmete andmebaas (vt http://ckan.org), millele viib portaali ülariba menüüpunkt „Avatud andmed“. Sellest andmebaasist saab:

      1) otsida ja alla laadida avaandmeid ligipääsupiiranguteta,

      2) lisada uusi avaandmeid (selleks on vaja portaali registreeruda ja saada haldaja käest ligipääsõigus).

      • Andmehulkade hoidla, mis on üks võimalikest kohtadest, kuhu ametkond saab avaandmeid salvestada.

      Tehniliselt on loodud eeldused avaandmete infrastruktuuri väljakujundamiseks. Kuid tehnilistest eeldustest on vähe. On vaja mehitada ja välja õpetada meeskond, kes oleks võimeline haldama ja arendama infrastruktuuri, tegema järelevalvet ja haarama oma tegevusega nii avaliku sektori andmetootjad kui ka teenuseid loovad avaandmete kogukonnad.

      Avaandmete infrastruktuuri väljakujundamise eeldused on loodud.

      Kuidas avalikustada?

      Mis vormingus? Peamise põhimõttena arvestame, et palju parem on avaldada andmed ebamugavas kodeeringus kui jätta need esialgu avaldamata põhjusel, et millalgi on plaanis võtta ette kodeeringu täiustamine. Teiseks, avaldatud andmehulka saab edaspidi avaldada uues, paremas kodeeringus.

      Soovitame avaandmete süsteemi kontekstis lähtuda vormingute ja kodeeringute kasutajasõbralikkuse hindamisel Tim Berners-Lee viie tärni süsteemi19 põhimõtetest, mis on kirjeldatud eelmises artiklis. Andmehulga avaldamiseks sobivad eeskätt vormingud, mida on võimalik avada ja töödelda vabavaraliste rakendustega. Selliselt on töödeldavad näiteks odt-vormingus dokumendifailid, samuti struktuursete andmete levinuimad vormingud .csv, json, xml.

      Taaskasutamiseks sobivad vabavaraliste rakendustega avatavad ja töödeldavad vormingud.

      Ühetärni-vormingute kasutamist andmete avamiseks peaks vältima. Kuid teiselt poolt on nende publitseerimine siiski kindlasti parem kui sellest loobumine.

      Kahetärni-vorminguid kasutatakse eelkõige selliste andmete jaoks, kus kasutajale piisab juurdepääsust andmetele. Taaskasutamine tähendab eelkõige tutvumist andmetega ja nende kasutamist lõika-kleebi meetoditega. Teenuste loomise tagamiseks tuleks avaandmed esitada kas kolme-, nelja- või viietärni-vormingus.

      Loodud on avaandmete infrastruktuuri väljakujundamise eeldused.

      Kolmetärni-vormingud. Kolmetärni-andmed võiks olla ühel järgmistest vormingutest vastavalt sellele, mis on andmete avaldajale mugavam. Kasutaja seisukohast ei ole neil vormingutel väga olulist vahet, kuid kõige mugavam on tõenäoliselt kasutada json-vormingut.

      • csv-failid. Dokumentatsioonis peab olema öeldud tähestiku kodeering ja koma/semikooloni ning komaga arvu eraldaja (punkt/koma) kasutus. Soovitav on kasutada failides päiserida, kus väljade nimed on toodud • selles päisereas. Kindlasti tuleks lähtuda ametlikust20 csv-vormingust koos nüanssidega jutumärkide teemal jne.

      • json-vormingus failid, samad nõuded tähestiku kodeeringu kohta.

      • xml-vormingus failid.

      Neljatärni-vormingud. Põhimõtted on samad kui kolmetärni-andmetel, kuid peamise täiendusena kasutatakse objektide identifitseerimiseks globaalselt unikaalseid identifikaatoreid ehk URIsid. Globaalsete identifikaatorite kasutus muudab andmete ristkasutuse teistes süsteemides oluliselt mugavamaks.

      URIde kasutuselevõtuks tuleb andmete ekspordi ajal lisada igale objekti-identifikaatorile antud andmehulga prefiks, näiteks http://asutus.ee/andmehulganimi/objects/, kus siis terve URI oleks näiteks http://asutus.ee/andmehulganimi/objects/45321 ja 45321 on objekti algne ID andmehulgas. Kui IDd ei ole ka andmehulga enda lõikes unikaalsed (mis on kõige harilikum olukord), siis kõige lihtsam on esitada eksportimisel URId kujul, kuhu lisatakse objects-i asemel vastava tabeli nimi, näiteks http://asutus.ee/andmehulganimi/isikud/45321.

      Kui objekte on asutud esitama URIdena, siis on sobiv lisaks csv/json-i/xml-i kasutamisele esitada andmeid RDFi kujul objekt-omadus-väärtus kolmikutena21.

      Kuna RDFi kujul saab andmeid esitada eri süntaksitega, soovitame kasutada üht järgmistest kahest.

      • Microdata kujul22, mis on ette nähtud andmete kodeerimiseks inimloetava html-i sisse: info on korraga nii harilikul viisil inimloetav kui ka kergesti masintöödeldav.

      • RDFa23, mis on analoogiline ja samade eesmärkidega kui Microdata, kuid veidi keerukam.

      Microdatas esitatud andmed on alati triviaalselt konverteeritavad RDFaks. Järgmine küsimus peale Microdata/RDFa teemat on väljanimede ehk objekti omaduste nimede valik. Siin on kaks peamist lähenemist.

      • Kõige lihtsam on esitada algse andmehulga tabeli/väljanimede paarid URIdena, näiteks kujul http://www.asutus.ee/andmehulganimi/tabelinimi/väljanimi, kus näide võiks olla http://www.asutus.ee/loasaajad/fyysisikud/synniaeg.

      • Veidi keerulisem, kuid kohati kasulikum alternatiiv on kasutada algse süsteemi tabeli/väljanime asemel üldisemat ja laiemalt levinud omaduse nime, kui sellise leiab. Sobivaks kataloogiks nimede otsimisel on schema.org. Tasub tähele panna, et kui sobivat nime ei leita, on kasutajal hiljem siiski väga lihtne teisendada eksporditud nimesid endale sobivale kujule, eeldusel, et ta saab eksporditud väljanime tähendusest sisuliselt aru.

      Väljanimede esitamisest rääkides tasub puudutada ka ontoloogiate teemat. Neid võib vaadelda kui väljanimede teisendus-/klassifitseerimisreegleid, näiteks, kui soovime öelda, et meie URI kujul väljanimi http://www.asutus.ee/loasaajad/fyysisikud/synniaeg on täpselt sama asi kui schema.org-i Thing>Person>birthDate.

      Selliselt vaadates ei ole ontoloogiad andmete avalikustamisel otseselt oluline ega keeruline teema, pigem on tegu kasuliku töövahendiga rakenduste loojatele, kes kombineerivad eri allikatest saadud andmeid. Andmete eksportimiseks avalikustamisel tasubki ontoloogiaid soovi korral ise kirjutada kas siis oma väljanimede dokumenteerimiseks või alamhulga olemasolevate väljanimede konverteerimiseks schema.org-i nimedeks.

      Viietärni-vormingute selgitusi. Andmete URIde kaudu linkimise üks viise on kasutada andmebaasis rakendatava identifikaatori asemel võimaluse korral de facto universaalsemat globaalset identifikaatorit ehk URI. Oletame näiteks, et riigis lepitakse kokku (või asuvad näiteks rahvastikuregister ja äriregister kasutama) isikukoodide ja ettevõtete koodide jaoks vormingut kujul http://prefiks1.ee/prefiks2/isikukood ja http://prefiks3.ee/prefiks4/ettevõttekood. Sel juhul oleks isikukoodi ja ettevõtte koodi viietärni-esituseks taolisel kujul URId, kus prefiksid / URI kujud ei ole mitte antud asutuse enda, vaid üldisemalt kokkulepitud / laiemalt kasutusel kujud. Sama kehtib siis ka andmebaasiväljade ehk objektide omaduste nimede kohta.

      Kuidas andmehulka reaalselt avalikustada? Konkreetselt on andmete avalikustamiseks kolm peamist tehnoloogilist viisi.

      • Inimloetavate failide korral pakkida faile sisaldavad kataloogid kokku, lisada peakataloogi lühike sisuseletus ja laadida pakitud kataloog/kataloogid vabalt allatõmmatavana soovitatavalt asutuse veebisaiti http://<asutuse domeeninimi>.ee/avaandmed või opendata.riik.ee

Скачать книгу


<p>19</p>

http://lab.linkeddata.deri.ie/2010/star-scheme-by-example

<p>20</p>

http://en.wikipedia.org/wiki/Comma-separated_values

<p>21</p>

http://en.wikipedia.org/wiki/Resource_Description_Framework

<p>22</p>

http://en.wikipedia.org/wiki/Microdata_%28HTML%29

<p>23</p>

http://en.wikipedia.org/wiki/RDFa