Na oficálnom obrázku je RDF, nie URI identifikátory. A to je veľký rozdiel. Môže dôsť k nesprávnej interpretácii. Keď si pozriem, do toho NASESáckeho dokumentu, ďalej je vysvetlené že:
Už som to písal vyššie, ale ďakujem že to môžem ešte inak vysvetliť. Všimni si, že zrazu už hovoríš o CSV, čo je formát pre úroveň 3★, a presne preto na oficiálnom obrázku je RDF.
A RDF je v podstate slovník na popisovanie zdrojov na internete, ale všetkých! RDF je aj na popis dátových prvkov (triedy, vlastnosti), aj popis číselníkov, datasetov, čo konktrétnych entít (organizácií, ulíc, atď). To je to “use URIs to denote things, so that people can point at your stuff”. Čiže nedá sa len jednoducho pridať stĺpec s URI. To by muselo byť URI všade. A toto je presne úloha RDF.
Pozrime sa na príklad úrovne 4★ priamo na oficiálnom webe:
krásne RDFko, tj. jednoduchý formát trojíc (tvoriacich graf), čo je v podstate veľmi jednoduché ale brutálne efektívne.
Súhlasím. Ale neohýbajme štandard preto, aby sa znížilo použitie RDFiek na Slovensku, skôr hľadajme presne ako si povedal: správny účel použitia. Ja nie som za totálne prejdenie na LinkedData všade okamžite (slovensko.sk má iné problémy ), OK, ale v prípade dát je to podľa mňa kľúčové. Centrálny model údajov a identifikátory entít potrebujeme tak či onak, na tom postaviť 1xdosť, a publikovať open data. A to sa samozrejme dohodlo, že to platí len pre nové publikované údaje, ktoré budú financované v rámci projektov. Označiť toto ako džihád s tým, že je to v agende aj Európskej komisie je myslím je dosť prehnané. Alebo všetko čo robíte Vy je tiež džihád? Asi nie.
Každopádne, ako si to predstavuješ, že “aby bol z toho úžitok”. Možno nakoniec zistíme, že sme úplne zjednotení.
Tak opat budem brzda a poviem nieco zase z praxe, hlavne teda k tomu co tu pise potencialny buduci byvaly hlavny datovy architekt SR.
@lubor nema pravdu, ze 4* neznamenaju RDF. RDF naozaj znamena pouzit format tripletov = cize nie CSV. (ak si odmyslime uplne haluzne publikovanie tripletov v CSV).
@lubor ma pravdu, ze toto vynucovat by bola chyba = linked data dzihad.
Teraz podrobnejsie:
Roky sa tu robia hodnotiace rebricky stavu open data na slovensku. Hlavna vytka vzdy bola, ze nie su dostupne klucove datasety a data ako take. Nasledne je problem neuplnost/chybovost dat. Neviem ako vy, ale ja som vobec nikde nikdy nezachytil, ze by sa niekto z praxe (napr. finstat, indexpodnikatela, …) stazoval na to, ze “jeeezis to by bolo super keby sme mali toto v tripletoch”. Poziadavka na RDF tu jednoducho v praxi neexistuje, ale pochadza zo slonovinovej veze.
RDF je extremne NEefektivny format. Pokial nechceme nanutit vsetkym pouzivanie triplestorov, (co dufam nechceme, lebo to sa osobne pojdem opasat bombami pred buducu kancelariu hlavneho datoveho architekta SR), tak toto skomplikuje zivot vsetkym. Konkretne - predstavme si ako tak vyzera import dat z triplestoru do nejake databazy (lebo nechceme vsetkym nanutit RDF, ze?) a ako by to vyzeralo zo suboru co obsahuje triplety. Pri CSV/JSON… natiahnem riadok/zaznam a ulozim do DB a hotovo (mam konzistentnu db), pri triplestore pokial nemam zarucene usporiadanie (co nemam), tak musim vsetko ulozit do pamate. Proste predstava, ze spravim nejaky efektivny - v case konzistentny streamovany import (uplne bezna a nutna vec) je iluzia.
Velmi sa bojim, ze tlacenie na 4* bude mat za nasledok zverejnovanie a vyuzivanie mensieho poctu otvorenych dat, lebo to jednoducho sposobuje netrivialne problemy nielen pre konzumentov ale aj producentov. Nezamienajme si tu prosim ciele a nastroje na dosiahnutie ciela. Cielom je mat co najviac dat, ktore sa budu vyuzivat co najviac a budu linkovane (prepojene medzi sebou). Mam za to, ze tlacit na triple formaty a RDF je cesta proti tomuto cielu.
Za ovela pragmatickejsi ciel povazujem nieco ako JSON-LD. JSON je praxou a miliardami APIciek overeny format. JSON-LD k nemu pridava standard ako odkazovat na ine zdroje. To co navrhuje @lubor je nieco ako “CSV-LD” a povazujem to za ovela jednoduchsie riesenie ako pre konzumentov tak pre producentov ako trvat na RDF. Kategorizaciu 5star data povazujem za fajn, ale prave v tomto bode za nedomyslenu, kedze JSON-LD sa tam nejako rozumne neda napasovat.
Preco tolko hate a navodzovania paniky ze nieco sa tu tlaci co nikto nechce. Tlaci na to EU a su na to W3C standardy v zaujme interoperability vramci EU to musime mat. A nakolko je EU aj sponzorom, myslim si ze jej treba vyjst v ustrety vo veciach co oni chcu. Mozeme na to ist aj systemom ze teraz to budeme robit v rozpore aby sme si potom mohli spravit dalsich N integracnych a zmenovych projektov. Svoj postoj preto adresuj aj ludom z W3C popripade ludom z EU, ISA, SEMIC a spol. a povedz im ze ich prirucka na otvorene udaje je zla a Slovensko.Digital sa nepaci : https://www.europeandataportal.eu/sites/default/files/goldbook.pdf alebo https://joinup.ec.europa.eu/sites/default/files/D4.3.2_Case_Study_Linked_Data_eGov.pdf alebo Data on the Web Best Practices.
Uprimne chcem aby to vyslo co najlepsie a nakonci budeme lidry v integracii a kvalite otvorenych udajov. Fakt nemame mat za tie peniaze skoro ziadne ciele? Je podla teba o tolko narocnejsie ked programator bude musiet vyplnat RDF/XML (JSON-LD), kde ma strukturu predpripravenu ako ked by si musel vymyslat vlastnu XML schemu? (ak je zaujem tak rad ukazem rozdiel v java kode)
Naozaj sa Vam bude viac pacit ked bude vznikat vela integracnych projektov po 2020 ked sa to uz v tomto moze spravit poriadne? Je to nejaky problem pre Vas ekosystem alebo biznis model? Chceme za ten giganticky balik penazi od IT firiem shit? Ja rozumiem skepsy z minulych obdobi, ale ked sa im da guideline tak to potom bude narocnejsie pokazit a ten uz existuje a neustale sa zdokonaluje predtym ako sa cokolvek spusti aby sa nezacala informatizacia ala divoky zapad, ale aby tie veci boli dopredu specifikovane a bol maly manevrovaci priestor pre spekulantov.
Vynucovanie triplestores - preco sirit dezinformacie o povinnosti triplestores? Kde je takato podmienka, ciel definovany ked uz siri ze sa ides priviazat o budovu s bombou? Na verejnosti je navodzovany dojem ako kebyze sa tu ide nieco zbytocne znasilnovat bez realneho zakladu. Ciel je komunikacia na rozhraniach a publikacia dat vo vysokej kvalite. Kazdy nech si to robi interne ako chce, ale vsetko co ide von musi mat nejaku stabnu kulturu. Myslim si ze tento postoj dobre poznas lebo uz niekolko krat sme sa o tom ci uz osobne alebo aj tu na fore, kde sa viac krat hovorilo ze vsade triplestore je hlupost a to nikto ani nespochybnuje a nechce. Ak to niekto bude v tom style tlacit, tak sa s tebou o tu budovu mozem priviazat ;).
Je to sice len tvoja domnienka ze ich bude potom menej a ja sa na to pozrem skorej z opacneho hladiska tj. je naozaj toto ta bariera a nie su problemy aj ine ako v tom ze programator dostane inu sablonu outputu do suboru?
Robime co sa da aby to nenastalo, tlacime aby ovela viac sa venovalo propagacii a chodenie po uradoch, skoleniach aby to publikovali a ked to uz budu robit tak nech to robia poriadne. Sam vediem timovy projekt na FIIT aby ta konverzia bola aj pre bezneho uradnika co najjednoduchsia a s minimalnym efortom dostaneme naozaj kvalitne data.
Tie ciele na publikaciu su len pre NOVE ALEBO INOVOVANE SYSTEMY platene z verejnych zdrojov a fondov a zaroven ide len o NOVE DATASETY a datasety “S VYSOKYM POTENCIALOM ZNOVUPOUZITIA”(referencne registre, referencne data a klucove centralne registre,…) o com bude rozhodovat datova kancelaria. Takze existuje mechanizmus, ktory to dokaze ustrazit v rozumnych medziach a verim ze je to mozne povazovat za systematicke zvysovanie kvality udajov co je podla mna taky doplnok k Vasmu zaberu na kvantitu a nie protipol.
S JSON-LD podla mna nikto nebude mat problem pretoze ako je presne aj v JSON-LD specifikacii pomenovany vztah JSON-LD vs RDF.
Ak ma byt preto svar len preto ze to nieje explicitne napisane v tej tabulke ako mozny output format, tak sa prvy hlasim nech sa to tam doplni. Celkovo si treba uvedomit ze je to len serializacny format. RDF ako taky je tiez serializovane do RDF/XML, TRIG, TRIX, TURTLE a n dalsich a JSON-LD moze byt kludne jeden z nich. Takze toto verim ze takisto nebude problem. Schemu a data ale treba popisovat jednoznacnymi identifikatormi a Centralnym modelom udajov. Nemoze sa predsa stat ze štát nebude vediet kde ma ake udaje na konci tohto obdobia a zhodneme sa ze jednoznacne identifikatory schemy (Centralny model udajov) tento problem riesia.
Ked lubor ukeca W3C na CSV-LD tak za take riesenie zdvihnem ruku dovtedy som zasadne proti. Vy sami ste najvacsi kritici ked nieco nejde podla standardov a ohybaju sa veci len pre SK verzie, tak ked je nieco vymyslene, nedovolme si ohybat veci tak ze to bude potom nekompatibilne s cely svetom.
cital som si diskusiu, aj ked sa tu pise o dzihade, panike a hate, mne sa to zda byt v ramci moznosti(a reality) diskusnych for celkom vecna diskusia. Dokonca by som povedal, ze konecne sa nejake odborne veci riesia aj takto otvorene (viac menej open source systemom, tam tiez su mailing listy a casto si nedavaju servitku pred usta, ale vo vacsine pripadov to funguje).
A teraz vecne:)
Podla mna je poziadavka, aby projekty financovane z EU v ramci OPII poskytovali data v vo vyssej kvalite celko opravnena. Ved lacne to nie je, takze ciele mozu byt aj vyssie. Tak isto komunikacia cez integracne rozhrania tak, aby tam vzdy bolo URI je podla mna na mieste, myslim si, ze z dlhodobeho hladiska to vela veci zjednodusi.
Z diskusie som pochopil ze nikto nebrani zverejnovaniu datasetov mensej kvality, ide len o to, ze ked je to OPII projekt, tak nech to spravi v lepsej kvalite.
A zase treba mat nejaku viziu, aby sme boli v niecom najlepsi, ked uz do toho ide tolko penazi, minimalne sa o nejake liderstvo treba pokusit. Mozno budeme raz prikladom ako estonci…
Co sa tyka tripletov, tu som sa trochu stratil (mozno preto si aj nerozumiete, lebo mam pocit ze sa tu tvrdi viac menej to iste, len inou recou). @jsuchal a @lubor hovoria, ze na triplety nie je objednavka. @msurek hovori, ze triplety standardy sa nevyzaduju (teda okrem OPII projektov), cize ste v sulade, ci sa mylim?
No a argument, ze na triplety nie je objednavka je sice relevantny, ale to iste sa da povedat aj o mnozstve open dat, pokial nie su, nikto ich nechce, ale ked uz su, tak sa vyuziju (skoro ako vajce a sliepka). A neviem kolko to je namahy navyse spravit taky triplet, ale verim ze nie vela. Ci?
Dokonca sa ani nemusí zaoberať, že 1., 2., 4., 5. vlastnosť je odvodená z toho že sa jedná o mestskú časť (čo je to skvelé pre analytiku/dopytovanie, resp. na vyhľadávanie). A dokonca, je to aj celkom čitateľné a univerzálne
2) Realista zas vidí HTML (obrázky su so zlinkovanej Slovakiany)
3) A iba kto chce, si pozrie dáta sémanticky. A následne sa môže vydať na tour de graf.
Vo formáte problém nevidím. Skôr challenge bude udržať jednodný dátový model a URI. Ale bez tohto budovať čokoľvek zmysluplné s verejnými dátami nemá význam. Používanie predpísaných URI, tj. 5* úroveň je zameraná na centrálne dáta (referenčné dáta, centrálne registre, DCOM, MetaIS), preto si myslím že je to dosiahnuteľne riešiteľné.
Myslím že je to zatiaľ najlepšia stratégia. To že to tlačí EÚ teraz ani neriešim (hoc čoskoro postnem pár tisíc riadkov EÚ štandardov).
Chcem ta opatovne ubezpecit, ze toto ziadny problem pre nijaky nas ekosystem ani biznis model nie je. Konspiracia pekna, ale ked uvidis nase prijmy z ekosystemu pochopis. A vlastne cele naopak, budem velmi rad, ked nebudem musiet cistit statne data, ale robit nad nimi len tie aplikacie s pridanou hodnotou.
Bavime sa vyhradne o open datach, ze? Ake integracne projekty tu spominas? Projekty ktore budu vyuzivat otvorene data budu najskor hradene zo sukromnych penazi, cize nerozumiem o com je rec. Plus teda ja mam za sebou nejake integracie pomerne velkych datasetov a skus uhadnut kde je zakopany pes:
data su nedostupne a treba ich zpristupnit (hocijako) - pridana hodnota nekonecno lebo z nuly mam nieco
data su dostupne ale je v nich bordel (duplicitne identifikatory smerom von na referecne data) - pridana hodnota velka aj ked si to vycistit musis sam. (toto je aktualny stav)
data su dostupne a su v nich nejake unikatne identifikatory na referencne data - pridana hodnota obrovska - viem prepojit dva datasety bez toho, aby som to rucne cistil (spoiler alert - toto niekto musi aspon trosku spravit aj tak, cize najskor gestor dat predtym ako to vyhlasia za ref. udaje)
data z roznych datasetov nie su jednotnom formate. - meh.
Prepac, ale cela tato saskaren ci to bude RDF, OWL, N3, Turtle alebo ine furtle riesi problem v praxi limitne sa bliziaci nula cela nic. A to ti hovorim ako clovek co sa semantickemu webu venoval na vyske, ked tam tvoj kolega - este o semantickom webe ani nesnival. A taktiez ako clovek co na open datach zacal svoju karieru aktivistu a mam za sebou zopar myslim celkom uspesnych open data projektov. To co tu prezentujete ako problem datovej integracie, tak na to som v zivote nenarazil a nikdy mi to nechybalo. Preto moja poznamka o slonovinovej vezi. Rad si vypocujem ake projekty napriklad v Datalane, za tie roky co sa tomu venujete ste s tymto urobili a kolko prinosov vam toto prinieslo. Lebo toto sa pytam snad uz milionty krat a nic. Problem neni medzi krokmi 3. a 4., to je implementacny detail. Kamen urazu je medzi 2. a 3. a to nijake rdf, owl, linked data nijakym sposobom neriesi. To dokonca neni ani ITckarsky problem.
K 4. vstupny/vystupny format a jeho konverzia/filtracia do niecoho co potrebujem je jednorazova vec, preto je dost nepodstatne co to je, hlavne nech to nerobi viac problemov ako uzitku. A to je presne ten moment kde zacinam mat pochybnosti.
Takze takto, na vstupe bude RDF, na vystupe RDF, odhlasovala sa povinnost robit pre nejake projekty 100% v 5* a tak sa teda opravnene pytam, ze co myslime pod tym RDF. Lebo zatial tu nepadlo ani slovo o tom, ze to moze byt aj to JSON-LD (teraz uz odrazu je to ok) a som zvedavy co povies na to, keby to ostali byt tie CSV a k tomu by sa len prilepila transformacia na RDF (mimochodom w3c odporucanie Generating RDF from Tabular Data on the Web) a kto chce nech si ju pouzije. Bude to 4* alebo 5* ? Ak ano tak s tym nemam ziadny problem. Ak nie, tak by som laskovo rad vedel aku pridanu hodnotu mi prinesie, ze to bude nejaky iny standardizovany format (prosim kreslenie grafov ktore si viem rozklikvat za pridanu hodnotu naozaj nepovazujem, bavme sa o realnych usecasoch z praxe). Ja pri takomto niecom paradoxne vidim vyhodu, az keby bol pod tym full SPARQL endpoint a mozem si odpalovat queries ake chcem, lenze toto predsa nechceme, ci?
Lebo mne z tohto celeho vychadza len to, ze vyhodu z toho maju len ti, co potrebuju velke mnozstva datasetov spracovavat = standard a z toho ti okamzite vylezie aj triplestore. A to sme predsa tiez nechceli, ci? Uz rozumies mojmu zdeseniu? Ked to kvaka ako triplestore, vyzera to ako triplestore, tak to najskor bude triplestore.
Toto je chvalihodna aktivita, ale rozmyslam co zlyhalo ked sme vlastne uz raz tento projekt nakupili za statne peniaze eDemokracia a dokonca - open data node - https://opendatanode.org/page/unifiedviews a nejako sa to neujalo.
Toto som nikde nerozporoval, takze s tym problem nemam. Skor by ma vsak zaujimalo ako riesite ten velmi prakticky problem s ktorym sa ja uplne bezne stretavam a nejako si sa v tvojej odpovedi mu vyhol - pripomeniem - streamovaci import ktori mi zaruci konzistenciu bez toho, aby som musel robit medziulozisko v pamati alebo disku.
No poviem to takto, trvalo nam 2 tyzdne kym NASES dokazal aktualizovat dataset schranok OVM v CSV, ktore by splnalo vynos - s korektnym kodovanim. (mezicasom tam bola pokazena verzia). Zvladli to tak, ze pomenili nazvy stlpcov. Predstava, ze teraz na nich nabehnes s tym, ze to odrazu musi byt v nejakom RDF/XML alebo nebodaj JSON-LD ma celkom pobavila a nasledne zdesila. Ano povazujem to za problem. Samozrejme, ze primarny problem tu je, ze to robia rucne (!!!).
Vieme teda zadefinovat nejaky set formatov ktory splna RDF koncepty a bude ich mozne (nutne?) podporovat na vystupe? Lebo RDF/XML asi urcite, chcelo by to nieco aj trosku pre ludi. Co to bude?
Ak sa nato pozriem prakticky, tak by som bol zato, aby sa hlavne otvorili DATA,
stale nam chybaju klucove veci ako napriklad kataster… nasledne nech sa riesi standard,
pretoze inak sa z takto definovanej poziadavky moze stat velmi vhodna vyhovorka, preco sa to neda zverejnit
@anton-somora Otvorenost dat je prioritou a o tom nie je ziaden spor tj. treba spravit minimalne bariery na publikaciu ale kto chce tak jasne ze si dovod najde ako tebou spominany kataster. Ten kto chodil na K9.4 tak postoj ich zastupcu pozna a podla mna to bude este na dlhsiu diskusiu.
Na ten zvysok by som rad priniesol druhy pohlad tj. nie ten skepticky (aj ked skusenostami mozno podlozeny).
Je vysoka pravdepodobnost, ze IT firmy si v najblizsom obdobi vytiahnu dost sta milionov z eurofondov. Teraz je otazka ze ci je spravne, ked si tam isto oni v rozboctoch rezervuju miesto na OpenAPI/Datasety budget, tak aby ho spravili ako pride mimo standardu a to aj v rozpore s odporucaniami a zadaniami od sponzora tohto celeho operacneho programu EU a jej ISA organizaciou, ktora riesi interoperabilitu na urovni EU. Osobne pochubujem ze potom na vlastne naklady to niekto bude harmonizovat aby aj oni boli spokojni.
Podme teda skorej diskutovat, ze co spravit aby to nikto nemohol ako barieru povazovat a ako maximalizovat kvalitu pri udrzani nejakej rozumnej miery. Napada ta nieco co presne je potrebne a doteraz to chyba a vyrazne by to pomohlo?
Neskor ukazem aj realny kodersky priklad o co je to z tohoto pohladu narocnejsie resp. ci vobec len to je na dlhsie.
Pokúsim sa konštruktívne posunúť celú túto debatu ešte ďalej, som rád že sme konečne uzavreli diskusiu čo je to 3*, 4*, 5* a diskutujeme viac k veci. Priznám sa, že sa ale trochu už strácam, kto má aké priority, celkové názory, či vôbec robiť nové projekty alebo ich všetky zastaviť kým nebude publikovaný posledný dataset; či má byť nejakým spôsobom štandardizovaný tento development s dohodnutými pravidlami, alebo na toto sa má riešiť až po dokončení projektov.
My sa zameriavame na to, aby začali softvérový dodávatelia robiť naozaj čo najviac v dátovej kvalite za verejné peniaze, ktoré získajú. A tu pokladáme interoperabilitu za úplne kľúčovú. Viac krát som započul názor (nešlo o linked data), že nejaký developeri sa hádajú ako sa má komunikovať, pretože im to robí rôzne problémy, atď. Že ale veci sú zadrótované, a podobne. Tejto téme sa venujeme už od roku 2013 a presadzujeme otvorene (aj tu na platforme), že riešením v tomto probléme je implementovať odporúčania EK pre interoperabilitu údajov. Lenže samozrejme, je nemožné urobiť revolúciu, ale postupnú evolúciu, ktorá bude zohľadňovať slovenské špecifiká. Preto sme presadzovali a získali sme podporu na K9.4, že všetky otvorené NOVÉ údaje za verejné zdroje (EU) by mali byť publikované v najvyššom stupni interoperability. Ono to možno znie tak honosne, najvyšší stupeň interoperability, ale v skutočnosti ide o používanie globálnych identikátorov na objekty ISVS a použitie Centrálneho modelu údajov, čo je podľa mňa úplne košér požiadavka.
Fylozoficky, mali by vôbec existovať jednotné “globálne” identifikátory objektov verejných dát, resp. dátových prvkov? (@anton-somora, @kyselat - tu ma obzvlášsť zaujíma Váš názor na projekt blížiacej dátovej integrácie 1xdosť) Alebo treba projekt zastaviť? Alebo neopužiť nič také ako URI, Centrálny model, ale urobiť to inak. Hoc to podporuje EKomisia a dokonca aj MetaIS?
Zdá sa vám že je nesprávne schválené (naformulované), že: všetky nové a inovované ISVS publikujúce open data za verejné zdroje musia byť v súlade s 5*, tj. používať URI a Centrálny model? Znamená to, že takto naformulované pravidlo zníži počet publikovaných datasetov? Veď ale potom sa im nič nepreplatí, takže tu nevidím priestor na zníženie počtu open data. Alebo by to malo byť ešte presnejšie usmernené, aby napr. to platilo len pre OPII projekty, kde je rozpočet pre projekt dosť veľký, aby to nezabilo maličké datasety, ktoré by chceli dodávať malé firmičky, resp. menšie projekty publikácie otvorených dát z existujúcich systémov ako kataster a podobne? Ak áno, navrhnite plis zmenu/doplnenie tej formulácie. Ak to bude systematické, tak si myslim že sa dá aj napriek už schválenému zneniu tieto pravidlá interoperability ešte upresniť. tu sa chcem zase obzvásť @jsuchal spýtať, či toto je ten najäčší problém čo vidí, alebo je to vo všeobecnosti o tom, že LinkedData nie, a my aj Európska komisia:ISA je čistý džihád? Rád by som sa posunul od takejto diskusie, pretože som presvedčený že nie je pre nikoho prínosná.
To sa naozaj nedá urobiť nejaké spoločné kompromisné riešenie, ktoré by sme “pretláčali” spoločne a spoločne by sme aj viac dosiahli? Ja verím že áno.
s tymto nemam problém, otázne je či všetkých objektov - entít, nateraz by stačilo pri referečných dátach, lebo potom treba robiť ont. model pre všetky možné enity
gestor, ktory by prebral zodpovednost za kvalitu zverejnovanych dat a ich mapovanie aspon na tie referencne data, ktore uz existuju, aby odberatelia dat nemuseli riesit taketo situacie: Metabase
Pre mna su open data aj akekolvek ciselniky, ktore sa v state pouzivaju a na ktore sa systemy integruju tj. zoznam zmluv je jeden typ dat a nie su uplne integracneho charakteru, druhy smer su prave vsetky ciselnikove typy udajov tj. zakladne ciselniky zo statistickeho uradu, zoznam miest v RFO (nakolko to ten ciselnik je iny ako ten zo statistickeho uradu) a kopa dalsich. Na PS1 sa aj dnes riesilo ako sa to momentalne musi ohybat a URI tam prave bolo riesenie. Preto som spominal integracne projekty.
Tento argument beriem len ciastocne nakolko su ludia co robili s Java 1.0 na skole a spravili si nazor, ale mozno ze sa nieco od tej verzie zmenilo. Otazka je ze ci su ochotni si pozriet kde to v sucasnosti je, kam sa vyvinuli technologie okolo toho a ci nahodou nie su tie problemy z minulosti vyriesene. Myslim ze aj kopa veci pre ktore si momentalne nevies predstavit ze by to mohlo jednoducho fungovat je mozno aj realne vyriesenych, len sa o nich musime porozpravat. Mozno aj niekedy pri pive
Prepac, tuto otazku tu od teba som asi nejako neumyselne prepocul. Nevadi, napravime. Veci co sa robilo su rozne. Peknym prikladom bola napr. medicina, kde to bolo celkom pekne. Lieky su publikovane na SUKL ale aj na ministerstve zdratovnictva (no tam su niektore data navyse oproti sukl a naopak), potom su na X miestach data o ucinnych latkach, klasifikacia chorob, interakciach, … Vsade sa pouzivali unikatne identifikatory a kazdy dataset pridaval dalsie a dalsie data o jednotlivych entitach v modely. Data mashup lahky ako facka a narocnost = dlzka loadingu dat do databazy. Toto je inak nasadene v nemocnicnych informacnych systemoch vramci SR. Dalsim peknym prikladom je anotacia nestrukturovaneho textu tj. hladanie entit roznych typov v texte zjednodusene povedane. Anotacie mali jednoznacne identifikatory a nad tym sa potom stavali rozne vylepsenia a aplikacie. Napriklad jednou z nich bol vyhladavac pre operatora. Priblizim jednoduchy priamociary usecase. V dokumente v systeme sa nachadzal “Samsung Galaxy S4”, ten mal unikatny URI identifikator. Ak je dopyt do vyhladavaca “telefon”, tak vyhladavac vrati aj ten dokument kde sa sice to slovo nenachadza, ale nachadza sa tam entita “Samsung Galaxy S4” a ta je smartphone a smartphone je telefon a preto sa to vyhladalo. Pri tej extrakcii z nestrukturovaneho textu je ale mnozstvo prikladov. Prave z tych skusenosti vychadzam ja a preto si myslim ze prinos to ma.
OT: uz tam nepracujem.
Myslim si ze to vidime uplne rovnako. Tiez povazujem ze 3 a 4 co je to kde sa zaciname bavit o linkovani je len implementacny detail a netreba sa ho extra bat. Problem medzi 2 a 3 tj. casti kde sa prideluju unikatne identifikatory. Myslim si ze aj tu sa mozeme zhodnut ze referencne identifikatory ma zmysel aby boli URI tj. ked sa uz prideluju tak nech su unikatne vramci krajiny. Narocnost tvorby takych identifikatorov je trivialna napr. referencny URI identifikator firmy je :
https://data.gov.sk/id/legal-subject/50158635
Ako vznikol? RPO si zaregistrovalo svoj URI prefix “MetaIS” ktory od toho momentu pouziva len on. Implementacne je to cca takto
String id = "https://data.gov.sk/id/legal-subject/" + ico
Co konkretne? Mozno ze sa daju vydiskutovat a ukaze sa ze ci su vazne alebo nie.
RDF je viac menej koncept a taky vystupny format neexistuje. Vystupny format tohto linkovaneho konceptu je napriklad RDF/XML alebo Turtle, alebo aj spominany JSON-LD. V dokumentoch sa pise RDF, tym padom argumentaciu ze zrazu je to OK nerozumiem, lebo nikdy to problem vlastne nebol. Znova opakujem ze ak je to treba explicitne do nejakej konkretnej tabulky napisat (aj ked to v principe nie je potrebne) tak verim ze to nebude problem lebo JSON-LD je len sposob serializacie pre RDF.
Z RDF do CSV je to trivialne, naopak ani zdaleka nemusi co podla mna sam dobre chapes a v principe je to niekedy nevykonatelne a to nehovorim o veciach ze CSV nevies validovat na typovu konzistentnost a podobne. Preto si myslim ze princip “IT firmy spravte viac a vieme to aj automatizovane downsizovat bez problemov” je jednoduchsi ako “odovzdajte cokolvek a snad sa nam z toho aspon nieco podari vytazit ved sme na to zvyknuti”. Celkovo si myslim ze downsizing by mohla byt jednoducha util featura na portaly ze kto to vyslovene nechce nech si to na dva kliky da do CSV/XML,… formatu. Znova len pripominam ze z RDF to do CSV je trivialne na max par klikov, v opacnom garde ak to vypublikuju ako pride sa o tom nebude dat ani uvazovat.
Ak by teda vobec bola konverzia daneho CSV mozna (ako to ale zabezpecit aby robili take CSV aby sa to isto dalo? mozno ze to vieme specifikovat a validovat ze ak sa to nebude dat tak sa to neda vypublikovat? mas namysli nejaku konkretnu definiciu?) tak definicia je stale rovnaka bezohladu nato ako sme sa dopracovali k cielu:
v pripade ze tam budu referencne URI a model bude ten Centralny tak 5
v pripade ze to bude nejaky custom model tak 4
To je dovod preco to chce EU… lebo si nad tym vie robit tie mashupy a kontrolovat, integrovat a pod jednoducho. Za mna znova opakujem, nech si to kazdy pouziva/transformuje/uklada vo svojich vnutornych systemoch ako chce. Ak to je v takom formate o takej moznosti sa da vobec uvazovat. Ak to bude “aby bol” vystup tak len zlahcujeme to IT firmam co za to dostanu slusne zaplatene a redukujeme co vobec s tymi datami robit. Zaver je teda taky ze cim vacsi tlak nie len na kvantitu ale aj na kvalitu, tym viac usecases je moznych.
Pri tom projekte som nebol a co sa vyfakturovalo a co sa realne dodalo je zasa ina tema + krasne poistena cez NDA pre zainteresovanych. Ked si pozries na UnifiedViews a to video na ich stranke, tak to je hodne vseobecny nastroj a padnem na rit ak to nejaky priemerny neinformatik uradnik zvladne bez dlhsieho skolenia. Takze podla mna ten nastroj minul svoju cielovu skupinu. To co robime tam, je prave o 2 urovne zjednodusenie oproti UV. Zakladom je specializovane rozhranie len na jednu ulohu, pouzitie jednotneho modelu na popis dat a trenovanie nejakeho odporucaca resp. natrenovaneho klasifikatora, ktory vie na zaklade popisu + samotnych dat povedat ze co je to za datovy prvok z centralneho modelu. Proste minimalizovanie toho co musi clovek spravit a v co najvacsej miere automatizacia a clovek v idealnom pripade len potvrduje.
Streamovaci import znamena ze data ti chodia “po riadkoch”? V takom pripade serializacia do JSON-LD a pouzitie array pre jednotlive elementy.
Cely problem tohto bol v napisani spravnej definicie aby sa to co ma zmysel spravilo kvalitne a to co nema az taku prioritu zjednodusilo. Tazko sa to definuje cenou a preto najschodnejsie prisla definicia “s vysokym potencialom znovupouzitia” takze tie centralneho data kde patria aj referencne registre, ale aj ine ako DCOM a podobne ktore nie su ale ma to pri nich zmysel. Mozno ze ta napadne lepsia alebo adresnejsia definicia, ktora tych co ma zasiahne a tych co nema odbremeni.
Suhlasim, ze urcite nie vsetky objekty maju mat statny referencny URI identifikator, ale znova len tie pre ktore to ma zmysel. Znova to je ale narocne povedat ze len pre referencne registre lebo napriklad kopa entit v DCOM by mala byt a mohla byt referencna ale bohvie kolko potrva a kedy sa vyhlasi aj taky obrovsky projekt ako DCOM a ako zdroj referencnych dat aj ked v principe to referencny register pre tie data je, ale status taky nema. Takisto ako MEF a kopa dalsich systemov. Ale ako tento subor roznych systemov a ich dat pomenovat tak aby sa tie dolezite data publikovali kvalitnejsie?
Ja URI nespochybnujem, to som pisal uz davnejsie. Sice povazujem napriklad dereferencovanie len ako nice-to-have feature, klucova pointa je standardizovany jednoznacny “ukazovatel” do inej databazy, pripadne do viacerych. URI sa na to ocividne pouzit da, nie som proti.
“Last time I checked” bol subgraph isomorphism stale NP-uplny problem a to aj bez toho, ze by boli triplety navyse rozhadzane este v distribuovanom prostredi. Preto SPARQL a federovane queries povazujem stale za utopiu a zaroven to jedine co na tom je zaujimave. A bez toho je to len hracka a RDF je len reinkarnacia entity-atribute-value modelu, ktory ma zname nedostatky. Verim, ze sa to pohlo dalej a nevidim vsetko, lebo to sledujem na pol oka, lenze mam s tym principialne problemy, nie nedoriesene detaily. Viem si vsak predstavit scenare kedy by som toto zvazoval a napriklad nativna podpora sameAs alebo nejake tranzitivnych uzaverov je pekna vec, ale len pre dost uzke scenare, ktore tu bohuzial nevidim.
Ano toto je klasicky query expansion trik a automaticka inferencia (tranzitivny uzaver) je pekna feature co to ulahci. Ci by som kvoli tomu siel do nejakej semantickej technologie… skor nie.
Toto som pisal este v case ked tu boli ako RDF spominane len triplety. To, ze za RDF subgraf tripletov sa da povazovat CSV + tranformacia, JSON-LD alebo N3 som zistil az potom. Ak by to boli triplety, tak je problem s tym streamovanym importom bez velkej medzipamate. Ak vsak mozu byt vseliake formaty, tak vznika nova otazka… ta slavna interoperabilita bude fungovat ako? Jeden system to pleskne ako N3, druhy ako JSON-LD a stvrty ako “CSV-LD”. Predpokladame, ze toto bude vediet integrovat nejako lahko hocikto? Veru neviem, neviem… preto sa pytam co bude standard pre serializaciu.
Tuto podla mna zacina trosku utopia. Ked sa len na SR piesocku tvarime, ze bez centralneho modelu sa nepohneme nikam, tak sa pytam: Mame centralny EU model? Ci bude sa vlastne nakoniec robit velky integracny projekt aby doslo k bajnej interoperabilite napriec EU? Tomu sme sa asi chceli vyhnut. Plus teda predstava, ze budem nejako vediet namapovat SK datovy model napr RPO na datovy model povedzme Spanielska je mi velmi smrdi vzdusnym zamkom specialne v pripade, ked uz len genericky model priamov RPO je este aj dnes (!!!) problem, kedze rozne zdroje pravnickych osob pouzivaju rozne datumy zalozenia PO v inom vyzname. To len pre ilustraciu.
Toto nie je to co robi Talend v CSRU na cistenie a prepajanie dat?
Urobili sme ju za tri mesiace (čistý vývoj) - traja: marek, ja a jeden náš študent, ešte v roku 2015pre prezentačné potreby. Prial by som si na nej robiť viac, kde by už bola. Našťastie o to ale teraz nejde. Poďme sa rozprávať o sémantike ako takej, z pohľadu dátovej integrácie.
Ako prvú dôležitú vec poviem, že my sme začaili robiť sémantiku v roku 2008 a až po 5 rokoch sme došli na to, že nám treba linked government data (lebo väčšina ciest skončila vždy tam), a tak som začal od roku 2013 roztáčať na štandardoch sémantický gramofón, kde som sa ako zástupca ITASu dostal. Čiže naše angažovanie vo verejných dátach nie je o tom, že sme si niečo prečítali a ideme pomôcť neefektívne minúť verejné zdroje. To len aby sme tiež už opustili diskusiu, že vaši používatelia to nechcú. Nech sa páči, ja si ale prajem EU interoperabilitu.
PharmaGuard - Open Linked Drug Data
V DB sú naloadované otvorené dáta o liekoch publikované na ŠUKLI (liekové dáta), dáta z MZ (ceny) a dáta o ATC (učinné látky) Interakciách z DrugBanku. Sú použité medzinárodné klasifikácie ATC v podobe ontológií a podobne. Príbalové letáky (pdka) sa parsujú do linked data, pričom z rozpoznaného obsahu o interakciách odvodzujú linky interakcie. Došlii sme k tomu, že týmto prístupom sa dajú skontrolovať, či niekde nechýba v texte výstraha o interakcii. (interakcia je založená na účinnných látkach, a niektoré lieky majú informáciu o prípadnej interakcii, a iné lieky s tou istou účinnou látkou to môžu mať zabudnuté uviesť). A prečo drugbank? Pretože z informácie o interakcii medzi kanadskymi liekmi sa dá odvodiť interakcia medzi slovenskými. Takáto architektúra v kombinácii s lahším sémantickým searchom na TIE TRI MESIACE sú ale fajn. Čo sa týka searchu, ak si zapneš v nastavenia “rozpoznávanie choroby”, tak môžeš dať vyhľadávať napr. “hypertenzia” a máš výsledok. atď…
Čo sa týka viacerých otázok tohto typu:
tieto zatiaľ odložím, aj príklady použitia sémantiky vo svete (BBC World Cup v roku 2010, v roku kedy vyslo AvP3). Mám 1MB argumentov pre použitie sémantiky v aplikáciách( to odvodzovanie je v triplestore je veľmi pekné (napr. spájanie odvodzovania rdfs, owl predikátov, obzvlášť sameAs)) ale naozaj teraz to ešte odložím, pretože Linked Government Data nie je o edgových vlastnostiach tej či onej architektúry, ide skôr či vie poskytnúť pre daný typ problému, vhodnú implementáciu. A teda používanie URI a Centrálneho modelu - je presne prípad LinkedData.
Dnes bola práve PS1, tj. predmet toho vlákna, a za Vás tam nikto nebol. Predpokladám že Lubor pozvánku dostal. A dnes bolo kolo RFComments, kde sa prezentovali okrem iných bodov dve témy spojené s linkeddatami:
sa neplánujú schvaľovať, pretože boli schválené na K9.4.
Ale, to je podľa mňa presne priestor, kde by sme mohli nájsť kompromis, a potom to spätna ešte dostať do SP Otvorené údaje, pretože ešte nie je schválená legislatívnou rady vlády, iba pracovnou skupinou.
Tak či onak, za tie roky vývoja sme vytvorili Centrálny model údajov VS (schválený cez PS1, ktorý prevzal rolu KDP), množstvo štandardov, ako aktivisti (niečo v práci, niečo doma, hlavne ale bez prestávky), vždy sme všetko publikovali tu. Spravili sme LOD Slovakia, ktorý obsahuje už modely základných registrov a vzájomných spojení, všetko ako opendata. Takže my sme tu neprišli riešiť LinkedData, lebo sme si niečo len prečítali a ideme neefektívne mínať verejné zdroje. Fakt je toho už dosť spraveného, aby sa na Core Data použilo LinkedData. A to sa už dostávam k mojej najoblúbenšej téme posledné roka, a tým sú EÚ štandardy, najmä ISA.
V tomto si nepochybne king a máš moje uznanie.
O to viac verím, že by sme mohli nájsť čo najširšie-spoločné riešenie informatizácie v rôznych oblastaich, ktoré budeme spoločne rozvíjať a strážiť.
ok, sme pri diskusii co je vlastne referecny udaj, pretoze dnes je to cele na hlavu postavene (toto vyhlasovanie).
cakam ze UPVII teraz po vsetkych dokumentoch a planoch vyhlasi dalsie referecne udaje (na Lepsich sluzbach sme sa dozvedeli, ze projekt ESO tieto identifkoval do urcitej miery) aj s casovym planom kedy budu dostupne cez sluzby (rozumej pripravi projekty). Aspon uvidme ako vazne sa to mysli s tym 1xdost.
OK, vieme sa posunut aj k sformulovaniu nejakeho konsenzu?
Ja som sa snazil nezapajat (lebo som pracoval na COMSODE, kde sme volili UnifiedViews a ten je primarne orientovany na Linked Data … cize sa citim zaujaty). Aj ked teda pre uplnost, high-level:
podobne ako @liska a @msurek by som rad trochu “postuchol latku vyssie”, napr. aj tymi 4* a 5* (aspon tam, kde by malo natiect vela OPII penazi)
ale od cias vyhlasenia 3* ako “minima” (cca 2013) stale nevidno nejaky zasadny progres (tot argument spomenuty IIRC @Lubor -om ci @jsuchal - om), takze ak by napr. dal Kataster, SHMU, … 3*, tak som na nejaky cas plne spokojny
Rad by som tieto protitlaky nejako zosuladil, nech teda mozem na tych PS zastupovat komunitu (a nie svoj sukromny nazor).
Ach jo, taká búrlivá diskusia a kvôli vecičke, ktorá je momentálne nepodstatná.
Som rád že sa tu do akademickej diskusie zapojili praktici. Všimnite si čo píše @jsuchal a @balgava - odpovedzte jej prosím ako by teda mala vyzerať “vzorová” implementácia OpenData pre ITMS2014+. (Mám hypotézu ako zareaguje, som zvedavý nakoľko sa mýlim.)
Za mňa, ako som hovoril, sústreďme sa na podstatné veci. Napr. tieto štyri ciele:
Kľúčových 40 registrov má na 95% čisté dáta (správne, aktuálne atď.), zvyšných 5% nečistých dát vieme presne identifikovať.
Pre najdôležitejších 20 entít sú stanované univerzálne identifikátory, registre z predošlého bodu tieto entity vždy majú interne reprezentované pomocou tohto identifikátora.
Špeciálne fyzické osoby (vrátane cudzincov) majú univerzálny identifikátor, bezvýznamový, a používajú ho všetky OVM
Celý* kataster bude dostupný minimálne v leveli 3*, alebo API. (*Celý = všetko čo legislatíva dovoľuje.)
Toto sú reálne podstatné veci pre interoperabilitu (no dobre, kataster som tam prihodil kvôli histórii čo s ním máme).
Keď budú vyriešené (to sme ešte zďaleka nesplnili ciele pre Mgmt. údajov a OpenData), môžeme sa začať baviť o jemných nuansách typu RDF. Kým to nebude, aj tie triplety budú nanič. Napr. momentálne množstvo entít je v registroch evidovaných hodnotou, nie identifikátorom. Evidencie medzi registrami nie celkom sedia, každý má preto vlastnú. Podstatné časti údajov sú nesprávne, neaktuálne, resp. spravidla sa ani nedá automatizovane zistiť, či určitý konkrétny údaj je valídny.
Zdrojov - najmä kapacity ľudí - je sakra málo. Nechcem aby hlavný dátový architekt mrhal svojím drahocenným časom, či nebodaj do toho zaťahoval aj ďalších. Konečne sa po rokoch poradilo na kľúčových rezortoch opustiť koncept “dáta sú tabuľka”, XML začína byť normálne používané. (Áno, pamätám si na to stretnutie PS1, kde sme s @gla v nemom úžase sledovali ako sa číselníky ŠÚ idú štandardizovať v tabulárnej papierovej forme s políčkami poznamka1, poznamka2 (ak sa nezmestilo do predošlého políčka) - nebolo to tak dávno.)
(Btw. som presvedčený, že ciele z dokumentov SP je absolútne vylúčené splniť do 2020, alebo hoci aj do 2030. Také ciele sú nanič. Bude s tým treba niečo spraviť.)
Nevšimol som si. Ja skutočne nechcem CSV!
A teraz mi povedz, ako triviálne vyriešiš URI pre subjekty, čo majú oba rovnaké IČO.
Pozvánku som nedostal a je to v poriadku - nie som členom. V PS pre štandardy zastupuje komunitu momentálne SOIT. Totiž málokto má čas, záujem a súčasne aj schopnosti len tak tráviť na týchto PS čas. (A zdá sa že Romana to už tiež prestáva baviť.)
Predstava, ze teraz na nich nabehnes s tym, ze to odrazu musi byt v nejakom RDF/XML alebo nebodaj JSON-LD ma celkom pobavila a nasledne zdesila. Ano povazujem to za problem. Samozrejme, ze primarny problem tu je, ze to robia rucne (!!!).
