Komisia pre štandardy ISVS - PS1

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

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

Nuž ako je to nakoniec naplánované si pozrite tu:

Bolo by fajn vedieť čo si o tomto dokumente myslia skutoční používatelia OpenData.

Dobrý deň, skúsim položiť doplňujúce otázky, aby som sa lepšie zorientoval.

Aby sme sa lepšie pochopili - skúsme sa vrátiť k 5stardata.info. Ospravedlňujem sa ak to tu už bolo vysvetlené, ale prečo za definíciou 4* vidíme automaticky “RDF/XML”?. Prečo úroveň 4* nemôže spĺňať obyčajný JSON (schema alebo export), kde sú použité URI ako “referencujúce” identifikátory? Keď sa pozriem na definíciu: “use URIs to denote things, so that people can point at your stuff” tak sa takýto výklad pod to zmestí nie? Kde presne je tam “automaticky” RDF?

Pozeral som model, a mám pocit, že keby bol zadefinovaný v úrovni 4* (tak ako si ju zatiaľ vykladám), tak sa výrazne jednoduchšie číta a chápe, zároveň je priamočiarejšie prepoužiteľný do OpenAPI (lebo napr. JSON schéma) a pod.

Skúmam, či si vieme zafixovať také členenie, ktoré bude postačujúce pre “referenčné údaje” (4* napríklad dereferencovanie by sme nemuseli mať automaticky) a zároveň nezavrie cestu pre zmysluplnú množinu otvorených údajov - tak aby boli na vyššej úrovni (5* a pobavme sa čo presne táto vyššia úroveň je, a čo prináša).

1 Like

Na danej stranke co je tu postovana je ako na obrazku, tak aj v samotnych popisoch co jednotlive stupne znamenaju ze 4* = RDF.

Kazdopadne samotne pouzitie je odlisne podla typu publikacie.

Treba rozlisovat dataset a API, pretoze pre jednu je potrebne aby vsetko malo URI (dataset) presne podla definicie a pre druhe je to obycajny JSON s tym, ze cez MetaIS je tam mapovanie.

Samotneho JSONu sa to dotkne iba tak ze ked sa v nom niekde hovori o identifikatore (kodKraja z predhadzajuceho prikladu, ktory som vypisoval ako to je presne na ITMS sluzbe) tak to ma byt URI. Samotny model je ale uplne standardny JSON a ziadne veci navyse. Zaroven aby sa ale vedelo co sa kde pouziva a posiela tak preto to mapovanie v MetaIS, lebo vlastne stat momentalne nevie robit analyticke dopyty nad tym ze v akej sluzbe sa ake data poskytuju a pouzivaju aby napriklad vedel aj lepsie vyhlasovat referencne udaje alebo robil presnejsie financne analyzy pri zmenach.

Ked sa bavime o datasetoch, tak “URI to denote things”, vyjadruje presne to co to hovori. Clovek vie ukazat presne aj na atribut a nie len na jeho hodnotu. Ja teda mozem hovorit o konkretnom atribute lebo aj ten ma URI a zaroven aj o jeho hodnote. Prakticky na kazdu vec v datach sa da ukazat. Preto az toto je mozne chapat ako realne RDF, lebo az vtedy je vlastne atribut URI a aj hodnota atributu bud URI alebo nejaky Literal (string, integer, …).

Ano, bavili sme sa o tom ze asi to je to preco tu vznika nepochopenie a momentalne sa robia standardne UML class diagramy (tam nie je problem to kreslit ako UMLka). Do standardu sa davala low level technicka specifikacia a tieto “big picture” obrazky tam chybaju a je pravda ze mali by tam byt prilepene o com sa porozpravame na najblizsom stretnuti a prihodia sa na confluence. Kazdopadne existujuce referencne registre(RFO, RPO, …), maju tieto udaje vo Worde v tabulke len sa to nepreklopilo aj do Confluence. Nastarosti to ma u Vas pani Niksova, kazdopadne aj UMLka budu coskoro dostupne.
Myslim si ze sa tu dost tocime a vraciame stale k tym istym veciam a preto idealne je sa k tomu stretnut a prejst si to. Tak ako je pisane v postoch vyssie, pre 4 hviezdicky sa dereferenciacia ani nevyzaduje (je to OPTIONAL) a to je tak aj v standardoch, kde link je hore uvedeny. Myslim si ze priestor na diskusiu je tu isto velky a definicie su dostatocne flexibilne aby naplnili ciel ale zbytocne nevytvarali nezmyselne bariery. Verim ze naozaj je mnohe sposobene nedostatocnym vysvetlovanim navrhu.

1 Like

Dobre, snáď iterujeme k potrebnej miere detailu. Ja som to pochopil z textovej definície inak (use URIs to denote things, so that people can point at your stuff) = trošku v užšej miere. Skúsme sa na stretnutí (privítam ho) pobaviť aj na tému, ktorú vopred avizujem: Čo ak nebudeme evidovať atribúty ako URI (iba hodnoty). O čo presne prídeme? Pretože prepájať datasety bude možné (URI v “hodnotách” nepustia). Čo presne získame evidovaním atribútov ako URI, resp. zostrojovaním niečoho takéhoto: Schema.org - Schema.org. Dataset v mojej (jednoduchej) predstave buď používa primitívne typy, alebo komplexné. Komplexné buď definované v rámci datasetu, alebo cez @ref v samostatnej - napríklad json schema - definícii (aha tu je URI tiež - ale nie konkrétneho atribútu, ale celého typu ktorý “vnáram”). Veľmi ale príklady pre zdieľané komplexné typy (medzi datasetmi) nevidím - možno sa na to pozerám zle - ale keď chcem publikovať dataset, alebo referenčný údaj - tak tam dávam prevažne atribúty ktoré sú unikátne pre mňa a čo môžem to linkujem na údaje z iných registrov (čiže len URI). Možno zistíme, že sa vieme zhodnúť na úrovni 3.5* (alebo 3*+) :wink: pre “bázu” a samozrejme určitú skupinu údajov potiahneme do 4*, resp. 5* (ale budeme vedieť čo od toho očakávame).

1 Like

Prideme o to, ze schema nie je unifikovana a tym padom aj tahsie prepojitelna lebo nemusi byt jednoznacna. Zaroven ako som napisal, narocnejsie je to aj z pohladu toho ze neviem ake presne data sa kde pouzivaju.

Rozdiel je cca asi takyto:
X si nazve atribut nazve “meno”
Y si nazve atribut ako “meno” a ma aj dalsi atribut “priezvisko”
Je mozne povedat ze X meno == meno z Y? alebo X meno == meno + priezvisko z Y?

Ak ten atribut bude https://data.gov.sk/def/ontology/physical-person/familyName tak je hned jasne ze nie je meno ako meno a raz je to meno a priezvisko dokopy a raz je to iba krstne meno (pri API len cez externe mapovanie v MetaIS).To je to co razi Google, Microsoft, EU a spol tym ze tvoria unifikovany model udajov, ktory oni nazyvaju schema.org resp Core Vocabulary pre EU a u nas Centralny model udajov od nich “dedi” a rozsiruje ho pre slovenske specifika.

Google vie taketo URIfikovane data na urovni schemy strukturovane indexovat, vyhladava ich podstatne lepsie a zaroven vie robit semanticke infoboxy (query do Google “Dunaj” alebo “Andrej Kiska”). Proste neindexuje ten obsah hlupo ale vie ze co je to tam popisane.
Tym ze je nejaky spolocny jazyk jednoznacnych identifikatorov a to nie len hodnot (long identifikatorov) ale aj modelu (atributy su tiez ako URI) tak sa nad nim daju robit strojove spracovania. Takze atribut “meno” pomoze Google len ako fulltext token, ak je to ale otagovane v JSON-LD ako familyName - Schema.org Property a je to vlozene ako metadata do HTML stranky tak si to zaraduje do svojho knowledge grafu a pracuje s tym ako so strukturovanou informaciou. : Intro to How Structured Data Markup Works | Google Search Central  |  Documentation  |  Google for Developers
Vsetky nase datasety tak mozu byt vyhladavatelne nasobne lepsie uz cez Google. Verim ze tento Google priklad ukazal, preco ma zmysle mat atributy URI a nie len texty. Kazdopadne znova len pripomeniem ze v navrhu je rozdiel medzi API a datasetom.

Presne, ale ked chce na ne niekto iny odkazat tak to vlastne nevie inak ako slovne. Proste ked chce niekto povedat ze v sluzbe XY atribut Z tak to musi takto napisat namiesto toho ze to vie vyjadrit jednoznacnym identifikatorov. Takisto ked chce povedat ze obe sluzby posielaju rodne cislo tak to vedia len tak ze pouziju URI identifikator na urovni modelu (znova problem ze ci je to personID, rodCislo, rodneCislo…)

Tak to je viac menej aj zapisane. Pretoze jedine 3 hviezdicky su na 100% a zvysne urovne maju nizsie percenta + aj tahsie podmienky ako “iba pre nove alebo inovovane” alebo len “z vysokym potencialom znovupouzitia”. Preto ak sa na to pozerame takto tak baza/minimum su stale 3 (ak sa dohodneme na minimum 3.5 tak o to lepsie). Proste len pokracujeme v nastolenom trende.
Vyhody su ako som povedal jednoznacna identifikacia toku dat v sluzbach a datach, strukturovane vyhladavanie na narodnej urovni (dopytovanie prirozdenym jazykom - mozem ukazat ukazku ale neoficialne :angel: ), dohladatelnost aj cez Google na vyssej urovni, unifikacia modelu nad ktorym sa daju robit unifikovane validacie( ked poviem ze meno = https://data.gov.sk/def/ontology/physical-person/familyName a vieme ze familyName ma constrain maxLength = 255 znakov, tak automaticky viem centralne poskytovat validacne constrainy a nebude to rozbite tak ako teraz. Datasety je taktiez mozne validovat nie len na zaklade syntaxe ale aj semantiky, zladenie s EU,semanticke mashupy a dopytovanie cez SPARQL endpointy,… nakonci dna by to mal byt hlavne poriadok a setrenie penazi.

Som za.

2 Likes

Ak sa má štandardizovať Centrálny model, nie je možné oddeliť vlastnosti od tried, to potom nie je štandardizácia. Toto nebolo ambicíou ani v historickom KDP, veď predsa musia sa definovať požiadavky na názov spoločnosti, resp. alternatívny názov, resp. formátované meno spoločnosti. To sú tri rôzne vlastnosti a vyjadrujú rôzne veci. A to je kľúčové aj pri výmene údajov medzi ISVS a aj pri publikácií datasetov. My musíme spoločne vedieť, akú vlastnosť mám na mysli, a preto je globálny identifikátor nutný. Tj. raz je to lsub:name, raz lsub:alternativeName a raz lsub:formattedName.

Navyše, URI pre vlastnosti sú dôležité aj pre identifikovanie referečných údajov, čo je už podporované aj v MetaIS. Napr. referenčný register pre lsub:name je RPO, ale pre pper:givenName je to už RFO.

Centrálny model je ľahko možné vizualizovať aj prostredníctvom UML, pretože podobne ako UML aj OWL používa triedy, relácie (dedenie) a podobne. Keď študujeme rôzne iné zahraničné ontológie, veľmi často používame ich UML podobu. Aby informácie o centrálnom modeli neboli príliš roztrúsené vo viacerých vláknach, vytvoril som preň domovské samostatné vlákno, kde môžeš spomenutú vizualizáciu vidieť:

Chápem. Iný pohľad je nasledovný - to meno z “physical-person” predsa používam len pri jednej entite (v ostatných len odkazujem identifikátorom na celú entitu (physical-person)). Keďže v tom jednom prípade bude jasne v dokumentácii typu povedané čo je to za atribút (či je tam meno alebo meno + priezvisko) - tak problém ktorý je tu uvedený vlastne nevzniká.

Iný pohľad je nasledovný - ak mám dobre zadefinované a zdokumentované typy v datasetoch, tak tento “strojovo spracovateľný meta-popis”, resp. napojenie na akúsi “globálnu” verziu - viem zostrojiť ako nadstavbovú vrstvu. Toto jasné členenie (základ a nadstavbová vrstva) mi umožní aplikovať “ontologický prístup” najprv len na vybranú podmnožinu údajov - následne vyhodnotiť prínosy voči prácnosti (či Google, Facebook, alebo EÚ sa pripojí a aké z toho budú efekty) a až potom rozširovať ďalej. Nazdávam sa, že toto je obojstranne výhodný princíp - najprv overiť a až postupne rozširovať - a pomôže k tvorbe širšieho konsenzu k tejto otázke.

Toto by som upresnil. V definíciach OpenAPI vieme presne povedať, ktorá služba má aké vstupy a aké výstupy (štruktúrovane). Adresácia celého API je pomocou URI, pričom je to už len o strojovom spracovaní formátu určeného na strojové spracovanie (= bez problémov). Takže tu nemusíme ísť do ontológie - stačí využiť štandard.

Otázka je ako to formálne dotiahneme v dokumente, ktorý je výstupom z PS. A o tom bude stretnutie - myslím si, že niektoré definície príliš striktne fixujú ontológiu a veci s ňou súvisiace (a náš názor zatiaľ je, že by nemuseli). Ale všetko je otvorené, závery budeme robiť až po stretnutí a diskusii.

1 Like

Ak sa bavime o dokumentacii, tak ta je vecinou slovna. Tu ide o strojovo citatelnu a jednoznacnu identifikaciu. A validacia centralna sa potom vlastne ako robi ked je to len v texte ze je to meno ale je to akekolvek meno? Ci bude sa to riesit ako doteraz ze validacia vlastne nie je?

Presli sme teda od API k datasetom? (je tu pomotany meta popis pre sluzby a jednoznacna schema tak neviem). Bavime sa o CSV? Kde sa tam definuje typ? Akoze textova dokumentacia? Ma CSV nieco take ako validaciu typov ako je XSD? Alebo predpiseme ze jediny mozny format je XML s XSD?

Ak sa bavime o API sluzbach, tym ze je to v MetaIS tak to moze byt chapane ako nadstavba a nie sucast.

EU to vyzaduje a viaze na to cerpanie eurofondov takze nie ze EU sa pripoji, ale my sa mame pripojit. Posielal som to sem uz viac krat, ale znova davam do pozornosti : https://www.europeandataportal.eu/sites/default/files/goldbook.pdf
Kde v kapitole 4.1.3 Preparing data: technical openness hovoria len o koncepte linkovanych datach a ako sa ma kazdy dataset donho transformovat a v kapitole 4.1.5 to popisuju ako potrebny check pred publikaciou. Nakolko Google a spol. to pouzivaju a my nie, tak znova si myslim ze to my sa pripajame na nich a nie oni na nas.

Zo dna na den to nebude mozne spravit takze rollout bude isto trvat a rozsirovanie bude postupne. Ked sa to tak vezme tak zatial len dva projekty sli na hearing a termin zaciatku je najskor koniec dalsieho roka. Myslim si ze rychly nastup nehrozi.

pokial viem tak viem definovat ze “meno” a viem povedat ze je to json. Ale to ze toto meno je to iste ako meno v inej sluzbe neviem kde sa prepaja v OpenAPI specifikacii. Ako teda viem povedat ze tato sluzba s meno je ta ista ako ina sluzba kde je taky atribut? a ze stat posiela v tu take data v tam zasa take a je to unifikovane?

Suhlasim, pobavme sa o tom.

1 Like