Komisia pre štandardy ISVS - PS1

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?

2 Likes

Budem rád ak vyskúšate našu aplikáciu

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:

Príklady úrovní interoperability
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=23986540

A.4.5.3 Pravidlá pre publikáciu katalógu, datasetu a distribúcie (DCAT/ADMS)
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=20022969

Ostatné body z tejto časti tj.
A.4.5.1 Úrovne interoperability otvorených údajov (tu sú napr. príklady formátov spomenuté)
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=23986522
a
A.4.5.2 Pravidlá pre úrovne interoperability verejných otvorených dát
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=23986518

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.

1 Like

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).

1 Like

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:

  1. 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ť.
  2. 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.
  3. Špeciálne fyzické osoby (vrátane cudzincov) majú univerzálny identifikátor, bezvýznamový, a používajú ho všetky OVM
  4. 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.)

Toto nie je pravda. Prosím buď presný, veď je to tu v topicu vedľa. Viď. ÚPVII Pracovná skupina K9.4 Lepšie dáta

(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ť.)

4 Likes

Pri ITMS nehovorime o datasetoch, ale o OpenAPI co je rozdiel, ktory ma trochu ine pravidla a mozno ze aj to vyvolava nepochopenie v niektorych pripadoch. Kazdopadne rovno popisem viziu maximalneho mozneho navrhovaneho scenaru pre API a vlastne celeho jeho zivotneho cyklu s 5 hviezdickami.

  1. Prva vec, je popisat sluzbu standardnymi metadatami, ktore predpisuje EU (Core Public Service Vocabulary 2.1). V principe je to velmi podobne ako pri datasetoch, kde je tiez nejaky standard pre metadata datasetov a tieto sa vzdy nachadzaju v samotnych datach. Toto je mozne povazovat za byrokraciu, ale nic extra strasne.

  2. Druha vec je, ze vsade kde sa pouzivaju teraz ciselne identifikatory, tak tie by boli nahradene referencnymi URI identifikatormi co je minimalna narocnost nakolko len ID z integer bude zrazu URI. Teda v pripade ze sa hovori o referencnych udajoch napriklad dodavetelId je asi referencny identifikator firmy (z nazvu ani popisu mi to nebolo zrejme).

Ukazka pre https://opendata.itms2014.sk/swagger/?url=/v2/swagger.json#!/subjekt/dodavatel_show

Vstupne parametre
dodavatelId : 50158635

Po novom :
dodavatelId: https://data.gov.sk/id/legal-subject/50158635

Vystupne parametre analogicky, pouzije URI identifikator namiesto ciselneho

  1. Treti a zaroven aj posledny krok je zaregistrovanie sluzby v MetaIS. To znamena, ze tu sa vlastne vyplnia metadata spominane v bode 1. Popisanie rozhrania cez OpenAPI specifikaciu (opensource nastupca Swaggera co teraz ITMS pouziva - v principe Swagger 3.0). Premapovanie vstupno/vystupneho rozhrania na datove prvky centralneho modelu cez jednoduche graficke rozhranie.
    Premapovanie je asi nasledovne :
    Takto vyzera skrateny vystup sluzby show_dodavatel
    {
    “createdAt”: “1994-10-17T22:22:30+01:00”,
    “ico”: “Eos voluptatem rerum voluptate et ipsum saepe.”,
    “id”: 7417765646913339000,
    “nazov”: “Totam id.”,
    “obec”: “Omnis ducimus consectetur voluptatibus.”,
    “psc”: “Beatae repellendus distinctio.”,
    “stat”: “Quis omnis quia minima.”,
    “ulica”: “Velit aperiam laborum est commodi.”,
    “ulicaCislo”: “Expedita est quia rerum sed.”,
    “updatedAt”: “2006-06-09T08:13:50+02:00”
    }
    v principe to bude formular na mapovanie v MetaIS kde sa povie (samozrejme s autocomplete, napovedou a podobnymi zlahcovakmi + supportom datovej kancelarie)
    createdAt = http://purl.org/dc/terms/created
    ico = https://data.gov.sk/def/ontology/legal-subject/legalIDCode
    nazov = https://data.gov.sk/def/ontology/legal-subject/name

Co tieto poziadavky riesia:

  1. zladenie so standardmi EU
  2. pekna strukturovana dokumentacia (tu uz ITMS ma, a su krasny priklad ze takto by sa to malo robit povinne pre vsetky sluzby)
  3. centralizacia do MetaIS - meta uz teraz registruje sluzby tak preto ona. Zaroven sa tak stane developerskym portalom s peknou dokumentaciou a nie len kopou balastu a kazdy bude vediet kde ma hladat bud OpenAPI alebo akekolvek API
  4. Pouzitie referencny URI identifikatorov jednoznacnych v celom SR
  5. Popisovanie rozhrania s Centralnym modelom tj. datove prvky reprezentovane cez jednoznacne URI:
  • stat ma prehlad o datovych tokoch v krajine
  • vie ktore systemy ake data pouzivaju a tak vie aj lepsie pomenovat ze ktory by mal byt zdrojovy, resp. ktory udaj by mozno mohol byt referencny, co by znamenalo ak by napriklad chceli zmenit “rodne cislo” na “bifo” lebo by vedeli kde vsade sa rodne cislo teraz pouziva a kde vsade to potom bude treba zmenit.
  • moznost robit centralizovanu validaciu - ked bude Centralne povedane ze meno ma 255 znakov, tak po takomto mapovani moze byt tento “constrain” automaticky aplikovany aj na dany atribut. Vsetci budu pouzivat rovnake obmedzenia a datove typy pre tie iste elementy.
  • jednoznacnost atributov a ich popisu (nazov = meno firmy, dodavatelID = referencny identifikator…) tj. kazdy vie ake data sa maju v atributoch posielat aj bez dodatocnej dokumentacie

Rad by som trosku blizsie hlavne rozviedol temu OpenAPI, pretoze do tohto konceptu v principe zapada aj dereferenciacia URI (https://wiki.finance.gov.sk/pages/viewpage.action?pageId=20023176) kde ak si zadam URI firmy do prehliadaca a do hlavicky podhodim Content-Type: application/json tak by som dostal vlastne JSON objekt o datach o firme. Podla mna by sa to v tom momentalne zacalo vsetko pekne zlievat. Po prestudovani toho navrhu (prosim citat az po koniec aj cast Dynamicka dereferencia) je mozne OpenAPI spojit aj tymto sposobom pre referencne URI.
V principe ak chcem dostat z RPO vsetko so Slovensko Digital tak zavolam sluzbu ako :
GET
https://data.gov.sk/id/legal-subject/50158635
Content-type: application/json

dostanem info ako OpenAPI v JSONe. V principe by vlastne OpenAPI a referencne identifikatory mohli byt pouzivane na volania. Co na ten koncept hovorite? @jsuchal @anton-somora @kyselat

1 Like

Ked budes mat cas, prosim pozri si ten link co som poslal @balgava v odpovedi o dynamicku dereferenciacii. Podla mna by tam mohol byt prekryv s OpenAPI resp. je to to iste len “endpointy” su vlastne referencne URI.

Uplne som nepochopil ten problem. Je to pomalost riesenia? Grafove databazy ako celok totiz su aj distribuovane a Neo4J alebo OrientDB podla mna su hodne konkurencne (zamerne nehovorim o triplestores, nakolko viem ze Neo4J si davno pouzival a kazdou novou verziou sa dostavaju o rad vyssie). Ak sa bavime ze ako vyriesili rychlost tak to je cez Cost based optimizery dopytov + tak ako pri kazdej DB cez indexy. Kazdopadne, znova sme upadli do debaty ze triplestores vsetci a povinne a to nie je pointa.

Tu ma napadlo, ze napriklad foaf.sk by podla mna SameAs mohlo byt celkom pekne.

Triplestores nie su povinne a nemaju byt povinne. Pre niekoho pri istych ulohach ano a pre niekoho nie resp. nechce v ziadnych ulohach. Podla mna je to OK a tak to ma byt.

Potrebujem vediet koncovy system, kam to chces integrovat aby som ti vedel poslat odpoved. Kazdopadne ak sa bavime specificky o streamovanom importe bez medzipamate tak to otvorene hovorim ze JSON-LD, su datasety, ktore tuto poziadavku nemusia mat resp. in-memory nie je problem. Ja sa nebranim ani definovaniu ze JSON-LD je recommended alebo required nakolko to riesi oba scenare a tym by sa niektore veci zjednodusili. Takze za mna +1.

EU tvori abstraktny model tj. nieco na urovni ze “Firma”, “Zivotna situacia”, … a z nich maju jednotlive krajiny “dedit” (ich nazov je Application profile) a rozsirovat si to sposobom specifickym pred danu krajinu - to je Centralny model udajov, ktory z nich dedi. Tieto modely sa volaju “Core Vocabularies”. Celkovo je ten koncept velmi podobny pridavanim referecnych udajov. Oni si zistia o ake atributy si vsetci rozsiruju svoj model a potom tie ktore su vsade daju do toho EU Core modelu.

Toto neviem posudit ci to povazovat za vzdusny zamok. Kazdopadne ked sa na to pozerame neIT pohladom, tak EU postupne harmonizuje vsetko tj. od legislativy, pracovneho trhu, hranice, momentalne sa hovori o daniach, uber ministerstvo financi a podobne co by si mozno pred par rokmi takisto nazval mission impossible.

Nie som si isty ze ci Talend je pre bezneho neIT uradnika a ci si pochopil cielovu skupinu. Tymto pohladom sa islo asi aj do unifiedViews, ze to taky clovek zvladne. Jednoduchy check pri takejto aplikacii je - “posad pred PC mamu s danou ulohou ze ci to zvladne”. Takto by som asi definoval ciel toho projektu a preto priklad Talendu mi pride usmevny :).

1 Like

S tym len mozem suhlasit. Hlavne je to neskutocne pomale.

Podla mna hovorime o EVS a nie ESO tak? Pokial sa bavime o tom istom projekte (je to na MVSR?), tak o tom relativne dost viem a ten je fazovany a momentalne bola priorita optimalizacia procesov a data prichadzaju na rad az nasledne. Preto schyluje sa k tomu, ale do konca roka sa podla mna nestihne predlozit urcite ani jeden navrh takze chvilu si urcite pockame kym to zacne nabiehat. Snad sa mylim alebo hovorim o inom projekte.

1 Like

Na to mozem povedat len : +1

1 Like

Otocim to, a ako to trivialne vyriesis v inej technologii? :slight_smile: Musime si rovno povedat, ze pri tomto type bordelu v datach nepomoze ziadna technologia, len si to poctivo konecne v tych registroch precistit. Nic take ako vseliek neexistuje. Chyby v datach su ale rozne, napriklad aj viac ID pre tu istu entitu a na to riesenie je.

1 Like

Ak jedno ICO dodnes mozu mat rozne subjekty, tak to dnes podla mna nemoze byt ich jednoznacny identifikator.

Uz fakt, ze v RPO dodnes chyba nemalo legal subject-ov aktualne evidovanych v ITMS, vyrazne znizuje motivaciu ich nan dnes mapovat. Ak navyse maju byt mapovane cez nejednoznacny identifikator, tak musim uznat ze mapovanim bordelu na iny bordel sa nic nezlepsi a straca to pre mna vyznam.

Ta datova kancelaria co sa tu spomina uz existuje? Ak ano, co robi pre zvysenie kvality tych dat? To sa mam uspokojit s tym, ze RPO je 5* aj ked je tam bordel?

1 Like

Ad príklad:

  1. No veď áno, OpenData API (toto je niečo iné ako OpenAPI) je to o čom celý čas hovorím že má zmysel. Tu siahodlho diskutujeme že bez ohľadu na API budú musieť existovať 5* datasety. Ako budú vyzerať?

  2. Popíš ten príklad s API poriadne prosím - takto narýchlo si to neviem poriadne predstaviť.

Popísanie služby metadátami - t.j. každú REST službu?

“Všade kde sa používajú číselné identifikátory, tak by boli nahradené referenčnými URI” - daj prosím konkrétny príklad, ako bude vyzerať výstup volania.
Napr. dajme takú troška zložitejšiu funkciu https://opendata.itms2014.sk/v2/zonfp/schvalene/5335
(Popis: https://opendata.itms2014.sk/swagger/?url=/v2/swagger.json#!/zonfp/schvalenaZonfp_show )
Výstup zostáva teda štandardný JSON? So všetkými zloženými objektami?
ID ŽONFP je teda referenčný? Rovnako aj ID pre “intenzitu”, “žiadosť o platbu”, “projektový ukazovateľ” atď. ďalších 30? Alebo toto ostávajú interné číselká? Pre ne je tiež “dereferenciácia”, alebo nie?

Prosím pre túto službu skús dať aj premapovanie na centrálny model.

Už dávnejšie som popísal ako by to malo fungovať a prezentoval aj v K9.4. Dôležité je, že ide o postupný proces.

Dám príklad pre “subjekt” 100004 z ITMS2014+ .

Krok 0:

  • Pre tie objekty, kde existuje, alebo má existovať ich referenčná reprezentácia (toto treba stanoviť asap, v pohode aj roky pred samotným zreferenčnením údajov), sa interne používa iba podmnožina ref. atribútov.
  • Ak treba niečo naviac, vytvorí sa nový objekt, ktorý však neduplikuje atribúty referenčného.
  • Napr. ak ITMS používa “polohu” subjektu (atribúty gpsLat, gpsLon), tak buď sú vyjadrené v štruktúre pre ref. register RPO (čo dnes zrejme nie sú, resp. hlúpo sa pre ref. údaje nedefinuje schéma, takže ťažko povedať), alebo si ITMS vytvorí novú entitu, napr. “polohaSubjektu”, kde je iba id subjektu a lat/lon.

Krok 1:
Vlastné ID sa prerobí na vlastné URI. To je stav ktorý de-facto ITMS2014+ už spravil. Čiže je to URI https://opendata.itms2014.sk/v2/subjekty/100004 Smerom von, t.j. G2G aj OpenData sa posiela výlučne URI, nie plain ID.
Pre G2G sa v rámci MÚK zavedie deref. pre https://opendata.itms2014.sk/v2/subjekty/100004 . Pre OpenData tak isto, samozrejme preferujeme priamo deref. na URI, ale môže byť aj centrálna služba napr. https:/ref.data.gov.sk/deref?https://opendata.itms2014.sk/v2/subjekty/100004 - zvážme čo bude lepší pomer cena/výkon.

Krok 2:

Tieto kroky 1 a 2 prebiehajú postupne pre ďalšie objekty. Výhoda je, že keďže štruktúra objektov v https://rpo.statistics.sk/data/ipo/ je nadmnožina https://opendata.itms2014.sk/v2/subjekty/ (viď. krok 0), konzumenti údajov nemenia svoje implementácie, ba ani nemusia o zmene vedieť (len si prepíšu URI id).

Krok 3: Keď už všetky objekty typu “subjekt” sú stotožnené (a nové pribúdajú samozrejme iba stotožnením), zruší sa služba https://opendata.itms2014.sk/v2/subjekty/

Ako vidíš, všetky podstatné časti - od dizajnu štruktúr, cez URI až po stotožňovanie - je toto potrebné riešiť vnútri IS / G2G, nie ako “prílepok” pre OpenData. Preto hovorím že reprezentovať dáta má zmysel v takej kvalite/štruktúre, ako sú interne. Samozrejme tlačme na to, aby v “nových” IS boli veci interne spravené tak ako treba.

2 Likes

Dobrý deň/ahojte

Ospravedlňujem sa, ale až teraz som sa dostal k tomu aby som napísal svoj príspevok. Pôjdem rovno k veci. Mňa zaujíma pridaná hodnota, ktorú vieme ktorým rozhodnutím dosiahnuť. To nás neomylne nasmeruje naspäť k štvor-bodovému zoznamu od @jsuchal - a hlavne k prechodu medzi 2. a 3. Pridaná hodnota je v tomto prechode obrovská a na tom tu panuje široký konsenzus. Pokojne na prepojenie využime unikátne identifikátory formou URI. Zostaňme nateraz len pri referenčných údajoch (dostatočne široký a hlavne kľúčový dopad). Z toho nám vypadne jednoduchý, ale praktický “centrálny model údajov” - entita, jej URI a linkovania, pričom atribúty sú predsa známe pri vyhlasovaní referenčného údaja. BTW reálne problémy naznačujú, že to, čo treba primárne riešiť pri atribútoch je vecný obsah, nie forma vyjadrenia dátového typu. Najmä pri “agregovaných” referenčných registroch typu RPO, kde síce vieme aké sú zdrojové registre, ale tie sa akosi niekedy nevedia do generického modelu centra “napasovať”, lebo nebol vyhlásený až tak…generický. Ďalej: osobne si nemyslím, že v prvej vlne potrebujeme štandardizovať aj typy atribútov viac, než má napr. OpenAPI. Publikačný formát nech je niečo štandardné a dobre spracovateľné (aby neboli problém streaming imports), ak zoberieme v kontexte OpenAPI - tak mne z toho vychádza json-ld (ale kľudne sa bavme aj o inom formáte). Zhrniem za mňa pre “centrálny katalóg”: Scope - referenčné dáta, URI - áno, triplety - nie. A modelovať v nejakej vizuálnej podobe, účelom akéhokoľvek (nie len dátového) dizajnéra je aj rozmýšľať, nie len katalogizovať. Snáď sa zhodneme, že sa rozmýšľa lepšie nad analytickou vizualizáciou (niečo na spôsob entitno-relačného diagramu) .

Všetko ostatné v tejto diskusii mi príde ako nadstavba (skôr forma ako obsah) s otáznou (prinajmenšom “niche”, teda v rámci konkrétnych scenárov) pridanou hodnotou. Pokiaľ ideme tvrdiť niečo iné, tak sa musíme poctivo vrátiť k téme subgraph isomorphism problem. Kto sa chce v rámci svojho projektu (či je to OVM alebo tretia strana) k nejakej niche pridanej hodnote dopracovať - nemá to ťažké, pretože základ od štátu dostane (vyčistené, prepojené a strojovo spracovateľné otvorené údaje). Predpokladám, že si mnohí potom tú “svoju” ontológiu “našijú” na svoj prístup, takže im to potom pobeží rýchlejšie a efektívnejšie, než keby využívali “centrálnu”. A keď sa časom ukáže, že nejaká forma centrálnej štátnej ontológie má jasnú pridanú hodnotu, tak nebude problém ju “prebrať”. Veď aj na to by komunita azda mala slúžiť: bude experimentovať s nadstavbami a tie, ktoré sa osvedčia “preberie” štát.

Pozrime sa na to ale trochu z pohľadu efektívnej alokácie zdrojov. Zaznel tu jeden argument, na ktorý mám trochu iný názor.:

Chcel by som upozorniť, že problém hrozí (a podľa mňa omnoho viac) aj z opačného prístupu. Ak nastavíme latku príliš vysoko s nejasnou pridanou hodnotou (otázna pridaná hodnota takmer vždy znamená, že to veľa ľudí nebude využívať), tak sa nám OVM a ich IT dodávatelia poďakujú za vytvorenie bezpečného priestoru, kde môžu “vymlátiť” podstatnú časť pridelených peňazí. To, že sa nikto netrhá, aby čistil a opravoval svoje údaje už predsa vieme z minulého obdobia (nie je to jednoduché, je to prácne, jedná sa o klasickú IT tému => nedá sa na tom - diplomaticky povedané - “optimalizovať efektivita”, ani nahnať zaujímavá/unikátna referencia). Stačí, že dostane k tomu ešte aj takúto “vzletnú” tému a môžeme skončiť tak, že budeme mať síce vo formáte sémantického webu (aj keď asi väčšina netuší, na čo to použije), katalogizovaný (a v rámci katalógu napojený na EÚ štandardy) a publikovaný veľmi podobný neutešený stav, ako máme teraz.

Argumentovať tlakom na posun latky vyššie len z princípu, že sú tu peniaze v OPII - nás privádza k otázke (stále sme pri efektívnej alokácii zdrojov) prečo chceme zvyšovať latku tu? Neoplatí sa posúvať ju naopak v inej oblasti? Čo keby sme v dátach urobili len to, čo má jasnú pridanú hodnotu a zvyšné peniaze použili aj na iné témy (napríklad nejakú dobrú službu zjednodušiť)? Aby som vám plasticky priblížil ako mi miestami niektorá argumentácia pripadá. Začnem vás teraz všetkých presviedčať, že okrem štruktúrovaných, je potrebné začať upratovať aj neštruktúrované dáta. Texty, obrázky, videá a pod. Zoberme ten text (viacerí sme sa tomu venovali). Cieľ je nespochybniteľne dobrý - v e-maile mnohých úradnikov je miestami “zamknutých” veľa užitočných informácií a veľakrát dotvára kontext napríklad prijatého rozhodnutia. Takže ideme riešiť “named entity recognition”, analyzovať sentiment (call centrá a zlepšenie komunikácie) a zlepšovať (pomocou NLP) vyhľadávanie/prehľadávanie/navigáciu a spol? Aj nejaký štandard k tomu máme (UIMA), aby sme vedeli aj v EÚ nadúrovni sa spájať a prepájať. Aj centrálne nástroje si vieme postaviť (keďže slovenčina je vysoko flexný jazyk, tak v MetaIS by sme mohli katalogizovať slovník a pravidlá skloňovania) atď. Myslím, že by malo byť jasné, kam s tým mierim.

P.S.

Dátová kancelária sa na ÚPPVII ešte len buduje, ale po schválení AP a iných dokumentov začne fungovať aspoň v nevyhnutnom režime (rozumejte do 30.10 sme takto do noci hore kvôli dokumentom, od 30.10. kvôli výstupom a činnostiam, ktoré z dokumentov vyplývajú). A áno - bude riešiť najmä kvalitu a prepájanie registrov. Čiže zatiaľ dominantne obsah, nie formu.

2 Likes

Nejde tu o žiadne nastavovanie latky príliš vysoko, ale pre nové projekty je to nastavenie presne akurát. Vo výstupných open datach sa musia používať schválené URI v MetaIS (referečné údaje). Ako som ukazoval vyššie, niekto sa na to može pozerať ako na XMLko (RDF/XML…), iný zas ako na GRAF. Toto nie je až také dôležité, podstatná je tam tá jednodnosť, ktorá je na realizáciu 1xdosť nevyhnutná.
Navyše, po dlhých diskusiách toto bolo odhlasované minulú stredu na UVPII zástupcami rôznych strán (5* - nové projekty s open datami s vysokym stupnom znovapouzitia). Takže plís, opusťme aj tento koncept, že tu niekto chce používať vysokú latku a zbytočne mínať prostriedky. Môžme sa sporiť čo je dôvodom že teraz nám ISVS škrípu, ale absencia toho prístupu asi určite.

Áno, ja len chcem upresniť že toto sa už stalo.
Centrálny model údajov VS už z referenčných údajov “vypadol”, rovnako vyšiel z KDP a bol schválený na PS1, opäť viacerými zástupcami rezortov a iných organizácií. Vytvoril a predkladal som ho ja ako zástupca ITAS a celý čas som ho publikovalna Slovensko.Digital
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=21169133

Navyše, je presne v súlade s vyhlásenými referenčnými údajmi MetaIS, tj. každý referenčý údaj má aj svoje URI (teraz ale netvrdím, že celkový proces vyhlasovania referečných údajov je OK, mr. @anton-somora , je to akiste na veľkú diskusiu, rád si vypočujem Tvoj názor).

To čo hovorí @jsuchal je pravda, tj. problém 2*-3*, čo nie je svet URI. Ale samozrejme treba riešiť aj toto, ale samozrejme systematicky, tak aby existovala jasná cesta od 1* do 5*, aby boli medzi tým vzťahy. Teraz si to dovolím otočiť a spýtať sa Vás, či máte na to pripravené nejaké ucelené riešenie/metodiku ako by to mohlo fungovať.

Čiže keď to zosumarizujem:

Pohli sme sa aspoň v tom, že by mohol existovať konsenzus takýto, že:
I.
aby sa neznížilo publikovanie otvorených, tak tá povinnosť použitia URI a Centrálneho modelu sa dotkne len referenčných údajov/registrov (čiže nebude to 5* platí pre open dáta s vysokým stupňom na znovapouzitie, ale 5* plati len pre nove open data v rozsahu referencnych udajov/registrov?)
II.
je nutné doriešiť metodiku aj ostatné open data ktore nie su referencne, a najst spolocny na to konsezus?

1 Like

Mozete mi prosim niekto vysvetlit ako suvisia open data (publikacia dat na verejnost) a 1x a dost (zdielajnie najma privatnych dat medzi uzavretymi systemami)?

No veď predsa, keď mám kľúčové/referenčné registre, ktoré môžu byť otvorené (RPO, RA, RDS), a tieto samozrejme používajú URI a Centrálny model, tak podľa mňa rovnaké identifikátory a rovnaký model sú použité aj v 1xdosť (kde sú použité aj ďalšie, uzavreté dáta). Napr. URI Štefanovičovej ulici v Bratislave

https://data.gov.sk/id/street/39124

bude jednak použité v rôznych open data (zoznam ulíc, zoznam križovatiek …), ale rovnako bude použitá aj v niektorej službe 1xdosť.

Ja priznávam že projekt ITMS2014+ moc nepoznám, zachytil som ho pár krát na opendata. Ale už dlhšie plánujem sa naň pozrieť, týmto idem na to. Až potom budem trošku viac v obraze aby som niečo počiatočne správne povedal.

Do konca roka chystáme vydať nový LOD, a myslím že prvé hlavné dáta projektu ITMS by som tam mohol stihnúť vložiť. Myslím tým ontológiu a príklady namapované na ostatné registre RPO, RA, … Na začiatok uvažujem o použití PROCC ( an Ontology for Transparency in Public Procurement), ale to asi nebude stačiť. Myslím, že to môže aj pomôcť ujasniť si veci.

Mozu lebo to zakon dovoluje alebo je to bordel? Podla mna skorej bordel a ten musi byt skor ci neskor vycisteny lebo inak sa to nikam nepohne. Tam podla mna nie je ziaden rozdiel vo vnimani.
Ak sa pouzije vlastny identifikator URI tj. nie https://data.gov.sk/… ale napr. https://opendata.itms2014.sk/… tak hovorime o 4 hviezdickach. Ten princip popisuje @Lubor v komente nizsie.
Dalsia dolezita vec je, ze tak ako sme sa bavili aj s @anton-somora tak pre kazde z tychto cielov bolo velmi narocne napisat spravnu vetnu definiciu tak aby to veci posuvalo no zaroven aby to malo hlavu a patu. Ak je v RPO bordel, ktory sa do 1.5 roka neopravi (projekt datova integracia bol prvy a pojde najskorej o rok von z obstaravania + kym sa nieco vyprodukuje tak 1.5 roka sa vlastne nic netyka daneho pravidla), tak bude to sice smutne ale kazdopadne definicia znie “maju vysoky potencial pre znovapouzitie”. Ked je to bordel tak tato veta moze znamenat ze RPO a jeho identifikatory zatial na to nie su pripravene aby spadali do chlievika “vysoky potencial pre znovupouzitie”.

Ako ma vyzerat 5 hviezdickovy dataset? Su to datasety, kde vacsina identifikatorov v nom je referencnych a pouziva Centralny model.

Ktoru cast mas na mysli? Tu s mapovanim a ze ako toma fungovat alebo tu kde namiesto ciselneho ID bude URI ako ID?

Kazdu integracnu REST alebo aj SOAP sluzbu - sluzba ktoru iny system/aplikacia vola a pouziva.

Vystup je stale ten isty JSON. V externom systeme (MetaIS) sa len cez JsonPath http://jsonpath.com/ (pri SOAP to bude XPath) napise mapovanie
JsonPath pre attribut1 = URI_referencny_identifikator

Priznam sa ze uplne neviem ci je ITMS pre niekoho dalsieho referencnym registrom alebo len prepouziva identifikatory a ciselniky od inych. Preto scenare mozu byt dva :

  1. Identifikatory, ktore spominas maju “potencial pre znovupouzitie” a preto by sa pouziadala Datova kancelaria aby ich zaviedla do Centralneho modelu + aby im bol prideleny nejaky namespace https://data.gov.sk/id/zonfp/{id}
  2. Bude odmietnuta datovkou ze takato vec nema zmysel aby mala referency URI identifikator a tym padom nebudu identifikatory v tvare https://data.gov.sk/id/zonfp/{id} tj nepatria ani do 5 hviezdiciek. V 4 hviezdickach sa meni v principe len to, ze namiesto https://data.gov.sk by bolo https://opendata.itms.sk/id/zonpf/{id}. Nie je to referencny identifikator, je to “len” ITMS identifikator. Pre tieto identifikatory nie je povinna dereferenciacia a je Optional : vid definicia na spodku tejto stranky 4 vs 5 : https://wiki.finance.gov.sk/pages/viewpage.action?pageId=16416799

Premapovanim na centralny model sa v samotnej sluzbe nic v principe nemeni, az teda na to ze entity, ktore maju referecne URI tak take sa aj ma pouzivat (v NUTS ciselniku bordel nie je tak ten moze byt automaticky https://data.gov.sk/…). Prepisovat sem celu sluzbu by bolo nadlho tak aspon koncepcne. V tom vystupnom JSONe je

,{“nuts3”:{“id”:10,“kodZdroj”:“SK021”,“nazov”:“Trnavský kraj”}.

a jedina zmena je ze by sa to zmenilo na

,{"nuts3":{"id":10,"kodZdroj":"https://data.gov.sk/id/nuts3/SK021","nazov":"Trnavský kraj"}

Samotny model JSONu by bol ale bez zmeny. V MetaIS by bolo napisane ze

$.miestaRealizacie[*].nuts3.kodZdroj = https://data.gov.sk/def/ontology/location/NUTS3

Co reprezentuje, ze na danom JSONPath sa nachadzaju URI individua typu NUTS3 a tak vlastne stat zisti, ze kde sa tento ciselnik vobec pouziva.

Tvoj navrh je ± taky ako si ho cely cas predstavujem aj ja. Rozdiel je ten ze tvoj interny identifikator, ktory ma URI som ja oznacoval ako 4 hviezdickove data a ked uz bude register precisteny tj. bez duplikatov a podobnych veci, tak vznikne centralny referencny identifikator URI a to je to co zacina https://data.gov.sk/… Som rad ze v principe veci vidime rovnako len sme ich inak nazyvalii a mozno aj z toho to nedorozumenie.
Co sa tyka prilepku k OpenData tak ono je to mierne inak. Vsade sa chceme aby to postupovalo tak ako si hore popisal a preto aj OpenData sa stale jednou z takych oblasti, ale urcite nie jedinou - preto hovorim, ze URI sa ma pouzivat na komunikaciu na rozhraniach a publikacia udajov. Urcite to nie je zamyslane LEN pre OpenData, ale aj pre OpenData.

1 Like

Nebolo mozne tam napisat ze sa to tyka LEN referecnych udajov a to aj preto co popisuje @balgava kde jedno ICO ma viac entit a to by tak samozrejme nemalo byt a je to kvoli bordelu. Preto sa tam napisala ta salamunska veta “vysoky potencial na znovupouzitie”, kde ked je aj bordel v referencnych data, tak dokym nebudu precistene tak sa im taky identifikator neda pridelit.

Ako som pisal, sluzba a dataset sa vnimaju aspon v navrhu odlisne. Preto JSON-LD by bol sice super ale tam zatial nie sme, a staci obycajny JSON/XML/… ale bude mat v MetaIS popisane mapovanie vstupneho aj vystupneho modelu sluzby na Centralny model vid ako som popisal v predchadzajucom prispevku.

Scope - v idealnom pripade referencne data a zakladne ciselniky ale az ked budu v bezchybnom stave co sa tyka identifikatorov. Takisto aj napriklad niektore udaje z DCOM a samospravy.
URI - som rad ze sa zhodneme
triplety - pre API suhlasim ze nie, datasety podla mna ale mozu mat odlisne kriteria nakolko maju aj odlisny usecase

Finalny model by mal byt zakresleny do nejakeho ERD aby sa kazdy lahko zorientoval. Pri tvorbe toho final modelu je nutne sa pozerat ale aj na “sub modely” a tam to nie je vzdy trivialne vyjadrit. Napriklad to co som ti spominal - tagovanie entit v zakonoch ale v principe to iste bude aj v sluzbach kde bude ta ista entita a atribut vystupovat v N roznych sluzbach.

S tym maximalne suhlasim, vzhladom na hore popisane a dovysvetlovane … myslis si ze tlak na zvysenu kvalitu zhltne vyznamnu cast rozpoctu/casu? Co sa tyka zlepsenia existujucej sluzby tak tam som urcite za, ved drviva vacsina sluzieb je extremne pouzivatelsky neprivetiva. V ramci deklaracie udrzatelnosti sa nesmu na tu istu vec, ktoru chceme len vylepsit tj. priklad sluzbu, pouzit prostriedky z EU po dobu minimalne 5 rokov po odovzdani tj. v takmer vsetko 31.12.2015 + 5 rokov, ale musi sa to spravit z vlastnych nakladov. Nakolko sa v DFS a akceptacnych protokol popisali aj myty a legendy o funkcionalitach tak to chce hodne kreativity aby vobec nejake peniaze na to boli a EU audit to neroztrhal. Papierovo sa totiz dodalo take nieco ze teraz uz vlastne ani neviem co vobec chceme zlepsovat :slight_smile:

PS:
S tym NLP by sa mi to ale pacilo :stuck_out_tongue: .