LTLOD: Knowledge Graph Lietuvai?

[Martynas Jusevičius]

Sveiki,

ryšium su rytojaus Digital Lithuania Meetup #2 renginiu, noriu įžiebti
diskusiją dėl RDF Knowledge Graph pritaikymo Lietuvos (atviriesiems)
duomenims, bei paraginti imtis darbų.

Mūsų 5+ metų senumo projektas LTLOD atgimė naujai, straipsnio
pavidalu: su įvadu į RDF bei argumentais, kaip ir kodėl integruojant
duomenis į Knowledge Graph sukuriama vertė:
https://github.com/AtomGraph/LTLOD

Iliustruota pavyzdžiais apie Petriuką, Vilniaus mokyklas, mokinius, jų
draugystės ryšius bei vidutinį amžių. Daugumą jų galite išbandyti
patys.

TL;DR: Knowledge Graph yra vienintelis standartizuotas metodas,
leidžiantis sujungti atskirus duomenų rinkinius į vientisą,
potencialiai beribį sluoksnį.

Jei turite klausimų, klauskit drąsiai. Laukiame atsiliepimų.


Martynas
atomgraph.com

[Mantas]

Kol kas dar niekur neskelbiau, bet rytoj pristatysiu Open Data Manifest idėją ir veikiantį prototipą. Prie šios idėjos dirbu jau kuris laikas, kažkur nuo 2018 rudens, bet buvo ir daugiau bandymu ir eksperimentu, tai galima sakyti, kad prie to dirbu jau kelis metus.

Iš esmės tai yra duomenų schema, kuri leidžia aprašyti iš kur ir kaip duomenis galima paimti, kas juos naudoja, naudojamas bendras laukų ir objektų arba esybių ir savybių žodynas, pokyčių versijavimas, yra galimybė susieti objektų klases ir savybes su Knowledge Graph, numatytas suderinamumas su DCAT, DataPackage, integracija su CKAN ir pan. Yra priemonės duomenų normalizavimui, susiejimui ir valymui. Palaikomas schemos normalizavimas ir denormalizavimas, ryšiai tarp objektų, objektų paveldimumas ir pan.

Visa tai leis automatiškai surinkti tvarkingus duomenis į vieną vietą, stebėti atvirų duomenų progresą, poveikį, nustatyti atveriamų duomenų prioritetus ir integruotis su įvairiais standartais.

Šiuo metu yra daugiau ar mažiau išbaigtas ir veikiantis duomenų modelis, pateiktų duomenų automatinis tikrinimas.

Esu aprašęs kelis duomenų rinkinius ir projektus naudojančius tuos duomenis. Išbandžiau vizualizuoti kelis rodiklius.

Tikiuosi tai valstybinėms įstaigoms suteiks daugiau aiškumo, kaip atverti duomenis ir tai bus aiškiai apibrėžtas komunikacijos protokolas, tarp duomenų tiekėjų ir naudotojų. Valstybinės įstaigos turės vieningą karkasą ir neturės spręsti duomenų atvėrimo kiekviena kaip išmano.

Ant viso to viršaus galima kurti pačius įvairiausius įrankius, tai yra fantazijos reikalas. Jei yra noras sukelti visus duomenis į vieną didelę TripleStore, visos galimybės tai padaryti yra. Jei yra kitų idėjų, galim diskutuoti kaip padaryti, kad tai veiktų.

Aš konkrečiai planuoju užsiimti tokiais įrankiais:

- Tobulinti duomenų aprašų automatinį tikrinimą, kad minimizuoti galimų žmogaus klaidų skaičių. Šiuo metu naudojama JSON Schema yra gan ribota šiuo atžvilgiu.

- Artimiausiu metu planuoju daryti tarpinę duomenų saugyklą ant PostgreSQL viršaus, kur bus surenkami visi duomenys ir pateikiami per draugišką API arba pasirinktą formatą, pavyzdžiui CSV, JSON, Turtle ar pan.

- Tada darysiu harvesterius automatizuotam duomenų surinkimui iš tiekėjų į tarpinę saugyklą. Tai reiškia, kad duomenų tiekėjams užteks pateikti duomenų aprašą ir duomenys jau atverti. Greičiausiai imsiuosi reliacinių duomenų bazių harvesterio, nes tokių duomenų yra daugiausiai.

- Darysiu interneto svetainę, kurioje bus vykdomas atvirų duomenų monitoringas, prioritetų sąrašas, įstaigų palyginimas, brandos lygio vertinimas ir pan.

Aišku, visa tai veiks tik tuo atveju, jei bus palaikymas tiek iš duomenų tiekėjų, tiek iš naudotojų. Šiuo metu lyg ir gavau palaiminimą iš Ekonomikos ir Inovacijų ministerijos, kuri atsakinga už atvirus duomenis. Duomenų naudotojai turėtų būti skatinami aprašyti ko jiems reikia, nes priešingu atveju, jei projektui reikalingų duomenų aprašo nėra, tai tokie duomenys nebus prioritetiniai atveriant. Reikia rasti keletą įstaigų kurios sutiktų bendradarbiauti aprašant savo duomenis. Tada reikės organizuoti keletą workshopų, kurių metu tiek tiekėjai, tiek naudotojai susės ir kartu aprašys ką turi ir ko reikia.

Bet viskas dar yra labai ankstyvoje stadijoje todėl bus matyt, kas iš to gausis.

Open Data Manifest: https://github.com/atviriduomenys/manifest

Rodiklių skaičiavimo pavyzdžiai: https://nbviewer.jupyter.org/github/atviriduomenys/manifest/blob/master/notebooks/metrics.ipynb

--

Mantas, http://t.me/sirexo

[Martynas Jusevičius]

Mantai,

dar kartą pasikartosiu, kad gerbiu tavo entuziazmą AD srityje.

Bet skaitant manifestą, apima jausmas, kad dviratis vėl išradinėjamas
iš naujo. Ypač krenta į akis nauji, nestandartiniai, "custom" YAML
formatai. Vietoj jų galima naudoti jau laiko patikrintas, įrankių
palaikomas, open data projektų naudojamas W3C specifikacijas:

# Vocabulary
Žodynams, ontologijoms, bei taksonomijoms aprašyti: RDFS [1], OWL [2]
bei SKOS [3].

# Constraints
SHACL [4] ir SPIN [5] duomenų kokybės tikrinimui.

# Virtual objects
CSV on the Web [6] CSV rinkinių aprašams bei R2RML [7] virtualiems
grafams virš reliacinių DB.

# Dataset
DCAT [8] ir VoiD [9] duomenų rinkinių aprašams.

# Versioning
PROV [10] versijų ir pakeitimų sekimui/registravimui.

Nepamirškime seno gero principo "standing on the shoulders of giants"
[11]. Išvertus būtų maždaug "atradimai remiasi ankstesniais
atradimais" -- priešingybė dviračio išradinėjimui. Taip palaipsniui
vyksta progresas.

Visas likusias idėjas, kaip Git flow naudojimą, automatizavimą,
machine-readability absoliučiai palaikau.

[1] https://www.w3.org/TR/rdf-schema/
[2] https://www.w3.org/TR/owl2-overview/
[3] https://www.w3.org/TR/2009/REC-skos-reference-20090818/
[4] https://www.w3.org/TR/shacl/
[5] https://www.w3.org/Submission/spin-modeling/
[6] https://www.w3.org/TR/tabular-data-primer/
[7] https://www.w3.org/TR/r2rml/
[8] https://www.w3.org/TR/vocab-dcat/
[9] https://www.w3.org/TR/void/
[10] https://www.w3.org/TR/prov-overview/
[11] https://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants

[Mantas]

Šiuo atveju pasirinkau pragmatinį kelią. Jei tiksliau, prie Open Data Manifest duomenų modelio priėjau per konkrečių problemų ir jų sprendimo prizmę, o ne per egzistuojančių antologijų analizės ir galimo jų taikymo prizmę.

Stengiausi padaryti kiek įmanoma paprastesnį ir kuo lengviau naudojamą, „one stop shop“ sprendimą. Noriu būti maksimaliai lankstus, kad prireikus būtų galima koreguoti duomenų modelį neapsiribojant griežtais pasirinktų standartų rėmais.

Jei yra noras susieti Open Data Manifest schemą su ontologijomis, tam jokių kliūčių nėra, reikia imti schemos failus [1] ir juos susieti su ontologijomis panaudojant JSON-LD [2]. Tačiau Open Data Manifest schema dar tikrai keisis ir bus tobulinama, todėl reikėtų palaukti nusistovėjusio ir laiko patikrinto varianto.

Šiuo metu, pati Open Data Manifest schema nėra susieta su jokiomis ontologijomis, tačiau aprašomus duomenis galima sieti su ontologijomis ir kaip tai daroma galima pamatyti `duomenys/rinkinys` duomenų apraše [3].

Konstruktyvi kritika yra labai laukiama!

[1] https://github.com/atviriduomenys/manifest/tree/master/schema

[2] https://json-ld.org/

[3] https://github.com/atviriduomenys/manifest/blob/master/vocabulary/duomenys/rinkinys.yml

-

--

Mantas, http://t.me/sirexo

[Martynas Jusevičius]

Mantai,

suprantu tavo sentimentus, bet negaliu sutikti dėl pragmatizmo.

Manau, daugiau padirbus su standartais, tavo požiūris apsiverstų.
Būtent W3C standartai, ir šiuo atveju ypač RDF, tave išlaisvina iš
rėmų ir leidžia būti maksimaliai lanksčiam.

Kodėl? Nes krūva organizacijų ir ekspertų įdėjo tūkstančius valandų
darbo tam, kad už tave viskas būtų pagalvota. Viska apimantis duomenų
modelis? Check. Schemos? Check. Formatai? Check. Užklausų kalba?
Check. Kokybės tikrinimas? Check.

Tau belieka susikoncentruoti į savo duomenų modelį ir jo tobulinimą.
Gali ieškoti RDF komponentų ir dėlioti juos į savo modelį ar pipeline
kaip dėlionės dalis.

O dabar vietoj to tau tenka skirti laiką savo specifikacijos kūrimui,
kuri kol kas pilnai suprantama vieno autoriaus visame pasaulyje, ir
turi vienintelę pasaulyje implementaciją. Būtent tai yra rėmai. Arba
vartai, kuriuos tu vienas stumdai :)

Manau abu suprantam, kad šis manifestas netaps globalia specifikacija
kaip tos, kurias išvardinau. Norėdamas prisidėti prie AD, turiu
paskirstyti resursus protingai. Kodėl turėčiau gilintis į manifestą,
jei vietoj to galėčiau įsigilinti į žymiai plačiau pritaikomą ir
palaikomą standartą? Ar toliau plėsti lietuvišką Knowledge Graph?

(Klausimas retorinis).

[Mantas]

Open Data Manifestas nėra naujas standartas, tai yra vidinis komunikacijos protokolas, kuris nebus niekur kitur naudojamas išskyrus github.com/atviriduomenys/manifest repozitorijos ribose. Visos implementacijos taip pat yra vidinio naudojimo reikmėms.

Galutinis rezultatas, t.y. atviri duomenys bus pateikiami kokiais tik nori formatais ir standartais, CSV, JSON, RDF, DCAT ir panašiai. Bet tai yra ko gero pati paprasčiausia dalis.

Manau mes tiesiog kalbame apie skirtingus dalykus. Tai ką pats siūlai LTLOD yra labai nedidelis Open Data Manifest poaibis iš esmės LTLOD yra vienas `link` atributas, kuris yra nuoroda į LOD terminą. Manifestas sprendžia žymiai platesnį spektrą problemų:

- Kaip automatizuoti duomenų ištraukimą iš įvairiausių duomenų šaltinių, ETL dalis.

- Kaip susieti skirtingus objektus, kai jie neturi vieningo identifikatoriaus.

- Kaip spręsti skirtingus duomenų modelių normalizacijos/denormalizacijos lygius.

- Kaip įvertinti duomenų poreikį ir prioritetus.

- Kaip įvertinti duomenų brandos lygį.

- Kaip daryti duomenų atvėrimą nedideliais žingsniais, pradžiai aprašant tik rinkinį (DCAT lygis), tada leidžiantis į detales ir aprašant objektus, savybes, toliau galima daryti duomenų modelio normalizavimą ir išvedimą į bendrai naudojamus generic modelius, dar vėliau galima daryti susiejimą su LOD ontologijomis ir pan.

Žodžiu manau tu labiau kalbi apie pyragus, o aš apie visą virtuvę, kur naudojant įvairius įrankius ir įrenginius sumaišomi įvairūs ingredientai, o pyragas yra tik galutinis viso proceso rezultatas.

Manifesto vidinė virtuvė yra daugiausiai aktuali valstybinėms įstaigoms, kurios turi du pasirinkimus arba rašo skriptus ir daro duomenų atvėrimą kaip kas išmano arba aprašo savo duomenis deklaratyviai YAML formatu ir nemokamai gauna duomenų atvėrimo ir nuasmeninimo skriptus.

Manifestas taip pat liečia ir duomenų naudotojus, bet jiems viskas labai paprasta, štai kaip atrodo projekto duomenų aprašas:

objects:

politika/seimas/kadencija:

properties:

pavadinimas:

nuo:

iki:

politika/seimas/seimo_narys:

properties:

vardas:

pavardė:

gimimo_data:

mirties_data:

gimimo_vieta:

      nuotrauka:

https://github.com/atviriduomenys/manifest/blob/master/projects/manoseimas.lt.yml

--

Mantas, http://t.me/sirexo