…ok, ale furt by sa aj tie viacere identifikatory mali sustredovat v RPO. A po utcitom case, kedy sa bud precistia data, alebo iba jednoducho to nadobudne uradnu vaznost (=vyhnije) sa moze prejst na jediny identifikator.
Metodológia data.gov.sk-semanticweb prezentovaná na Semantis2016!
Milí priatelia/kolegovia, takže opäť sa nám podarilo prezentovať projekt sémantizácie verejných údajov SK na medzinárodnej konferencii Semantics 2016 v Nemecku.
Abstrakt tu
http://2016.semantics.cc/miroslav-líška
Prezentoška tu
Fantastické bolo, že sme sa stretli s mr. Vassiliosom Peristerasom, ktorý pracuje pre EÚ komisiu v SEMICu, pričom, ehm, hoc musel odísť, zostal na našu prezentáciu 
. Jeho prezentácia bola z globálneho pohľadu na EGOV Linked Data pre EÚ, a my sme prezentovali ako sme to spravili pre SK.
Pár informácií o novinkách v metodike:
Medzi najdôležitejšie pridané veci do existujúcich sémantických štandardov bolo
-
zapracovanie ontológie ADMS, aby bolo lepšie pracovať s rôznymi GOV dátami ako sémantickými assetmi. Nižšie je príklad ilustrujúci sémantickú definíciu datasetov z metais ako sémantnické assety
-
každý dátový prvok definovaný v data.gov.sk ontológií má svoj identifikátor referovaný do MetaIS, pričom referuje aj kód metais, či KDP.
Nižšie je ilustrovaný príklad pre definíciu dátového prvku priezvisko
a registrácie identifikátora v metais
Tak, a už sme si povedali, dosť bolo neustáleho prerábania základných ontológií, a teda, hor sa na nový LOD Slovakia.
V pomerne starom príspevku ste spomímali, že sa budete venovať aj ďalším pripomienkam. Mňa by zaujímalo, že či sa treba snažiť vytvárať ontológie dopredu, alebo až keď ich treba.
Všimol som si tento thread až nedávno, zaujal ma a rád by som poznal názor ľudí, čo sa tomu venujú. Nechcem by som vyvolať konflikt dvoch táborov, ale zaujíma ma to a rád si vypočujem oba názory. Ďakujem
Dosti fylozofická otázka
Mne to tak vychádza, že “ontológie sa síce vytvárajú dopredu, ale keď ich treba, tak sa viac menej vždy opravujú (spresňujú) na danú potrebu.” Čiže je to taká stredná cesta.
Preto sa podľa mňa hodí štandardizácia, že sa aspoň primerane redukuje veľká prerábka.
Keď to tak trochu využijem, spojím to s porovnaním MDA (modelom riadená architektúra) vs. OOD (ontológiou riadený vývoj). Zatiaľ čo metamodel (mda) je preskriptívny (pravda je v modeli), tak ontologia je deskriptivna (pravda je vo svete, ontologia sa ju snazi len popisat).
Popis, teda aspoň OWL DL je formalny logicky system (podporuje strojové odvodzovanie), teda akiste je dobre mat vsetky fakty cim lepsie popisane, co je akiste pripad tvorby ontologie “dopredu”.
Ale tak či onak, keď sa niektorá z dopredu pripravených ontológií naozaj použije, aj tak sa viac menej opraví, doplní, spresní.
1 Like
Dovoľte mi sem preniesť ešte jednu debatu z PS1 fóra, a to je použitie URI identifikátorov pre súčasné XSD a spojené veci. Táto téma dlho tlela, totiž ako použiť URI v 1*…3* úrovni, aby bolo všetko konzistentné s 5*. Dovoľte mi preniesť i túto diskusiu sem.
Takým ústredným problémom je vzťah ontológií a xsd schém,pretože owl a xsd sú v niečom podobné, ale v niečom sú rozdielne. Obe definujú dátové prvky. Kým ontológia ich definuje pre význam (sémantiku), xsd ich definuje kvoli syntaxy.
Návrh
Kedže napr. ontológia Fyzickej osoby má URI
<http://data.gov.sk/def/ontology/physical-person>
rdf:type
owl:Ontology .
a napr. konkrétny dátový prvok z tejto ontológie má URI
<http://data.gov.sk/def/ontology/physical-person/birth>
rdf:type
owl:ObjectProperty .
tak pre fyzickú osobu môže existovať nasledovná schéma
<http://data.gov.sk/def/xsd/physical-person/>
rdf:type
res:XSDSchema .
týmto spôsobom môžem refereovať na konkrétne definovaný prvok v rámci xsd podobne ako v owl, tj. napr.
<http://data.gov.sk/def/xsd/physical-person/PhysicalPerson>
rdf:type
res:XSDElement .
Tento návrh rieši napr. súčasný problém obmedzenia počtu menných priestorov kvoli bezpečnosti pri podpisovaní. Z podpisovaným dokumentom by to bol vždy iba jedna referencia na xsd schému cez URI. Pre takúto sémantickú reprezentáciu XSD by existoval aj jeden mapovací súbor na jednotlivé ontológie. Toto samozrejme nie je optimálne, ale je to aspoň konzistentné.
Tu je zoznam URI pre zverejnené XSD
<http://data.gov.sk/def/xsd/physical-address/>
<http://data.gov.sk/def/xsd/conversion-record-summary/>
<http://data.gov.sk/def/xsd/physical-person/>
<http://data.gov.sk/def/xsd/data-container/>
<http://data.gov.sk/def/xsd/data-container-eform/>
<http://data.gov.sk/def/xsd/corporate-body/>
<http://data.gov.sk/def/xsd/physical-person>
<http://data.gov.sk/def/xsd/codelist/>
Dobrá vec je, že takéto URI sa bude dať dobre nahadzovať cez metais pričom dá sa použiť aj aktuálne GUI (cez pridanie novej ontológie, pričom namiesto …/ontology/… sa použije …/xsd/…).
Čiže suma sumárum, URI pre xsd schému vyzerá
http://data.gov.sk/def/xsd/[NAME]/{VERSION}]
Príklady URI uvedené Mirom Líškom by sa mali používať pre deklaráciu menného priestoru v koreňovom dátovom prvku v XML súboroch.
Príklad XML evidencie záznamov o vykonanej konverzii:
<ConversionRecordsSummary xmlns=“http://data.gov.sk/def/xsd/conversion-records-summary/1.0” …
Podľa uvedeného návrhu by v XSD pre evidenciu záznamov o vykonanej konverzii bola deklarácia menného priestoru riešená takto:
<?xml version="1.0" encoding="utf-8"?><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns=“http://data.gov.sk/def/xsd/conversion-records-summary/1.0” targetNamespace="http://data.gov.sk/def/xsd/conversion-records-summary/1.0"
Ukážka: https://goo.gl/YiOfxc
Otázky:
Môžem voľne meniť verzie na konci tohto URI? (Nedostanem sa tým do rozporu s navrhovanými sémantickými štandardami?)
Môžem zmeniť verziu na 1.1 aj v prípade, že sa iba zmení hash XSD súboru a nezmení sa nič v samotnej definícii koreňového dátového prvku ConversionRecordsSummary a ani v definícii podradených dátových prvkov?
1 Like
Ja vidím túto tému, tj. XSD & URI nie celkom triviálnu, pretože jednak nemám dostatok informácií k všetkým týmto veciam (XSD, hashovanie, podpisovanie) a stále mám obavu aby sa nepobili svety sémantiky (RDF, Ontológie, URI) a nesémantiky (XML, XSD bez sémantiky).
A) Tak napr. URI pre XSD FO podľa môže mať takéto URI
<http://data.gov.sk/def/xsd/physical-person/>
ale či to správne použiť v atribútoch xmlns, resp. targetNamespace, toto neviem posúdiť.
B) [quote=“stefan.szilva, post:27, topic:185”]
Môžem voľne meniť verzie na konci tohto URI?
Môžem zmeniť verziu na 1.1 aj v prípade, že sa iba zmení hash XSD súboru a nezmení sa nič v samotnej definícii koreňového dátového prvku ConversionRecordsSummary a ani v definícii podradených dátových prvkov?
[/quote]
Toto tiež neviem posúdiť, ide tu asi o metodiku verziovania XSD súboru, tj. ktoré podmienky zapríčinia novú verziu. Ehm, neviem prečo by sa mal meniť hash a nemeniť verzia XSD.
My napr. pri verziovaní číselníka (distribúcia datasetu typu číselník), napr. typy organizácii (a.s., s.r.o.) a podbne
http://data.gov.sk/set/codelist/organization-legal-form/2007-01-23.rdf
máme pravidlo, že distribúcia sa mení akoukoľvek zmenou jednotlivých položiek (pridanie, aktualizácia, vymazanie), Čiže ak by dnes povedzme vypadla a.s. so zoznamu, tak bude nová distribúcia
http://data.gov.sk/set/codelist/organization-legal-form/2016-10-14.rdf
Čiže tu treba spresniť tieto podmienky a potom to môžeme nahodiť do metodiky tvorby URI
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=16416826
kde pravdepodobne pridáme nový paragraf §B.2.5. URI pre XSD schémy.
C) Ďalšia kľúčová otázka je, že ako sa vysporiadať s tým, že vo všeobecnosti dáta o nejakej osobe môžu byť reprezentované buď na úrovni 3* alebo 5*. Tie zverejnené XSD schémy sú len pre 3*.
Napr. dátový prvok Fyzická osoba má definovanú schému XSD pre osobu, tj.
<http://data.gov.sk/def/ontology/physical-person/PhysicalPerson>
res:xsdScheme
<http://data.gov.sk/def/xsd/physical-person/> .
lenže v sémantickom svete zatiaľ so XSD schémamy neuvažujeme, pretože o tom, či sú dáta reprezentované “validne”, to definuje už ontológia. Lenže aj preto by sa dala urobiť XSD schéma, ktorá je ale iná než pre neRDF serializáciu. Otázka je teraz, ako sa z toho vymotať. Ak by sme mali byť úplne správny, asi by bolo dobre rozlíšiť aj to, čo by sa mohlo riešiť takto:
// schéma pre dátový prvok fyzická osoba pre neSémantické XML
<http://data.gov.sk/def/ontology/physical-person/PhysicalPerson>
res:xsdScheme
<http://data.gov.sk/def/xsd-non-semantics/physical-person/> .
// schéma pre dátový prvok fyzická osoba pre Sémantické RDF/XML
<http://data.gov.sk/def/ontology/physical-person/PhysicalPerson>
res:xsdScheme
<http://data.gov.sk/def/xsd-semantics/physical-person/> .
tie reťazce “xsd-non-semantics” a “xsd-semantics” by bolo asi vhodnejšie inak pomenovať, zatiaľ to berte plís len pracovne.
Dobre, takže s @msurek sme sa dohodli, že toto nebudeme nijako predpisovať do URI, aby sa stanovilo, o aký typ samotnej XSD ide. To sa bude riešiť cez jednotlivé ďalšie vlasnosti, ktoré dané URI môže mať. Čiže platí toto:
http://data.gov.sk/def/xsd/[NAME]/{VERSION}
Takže ak vieš zostaviť/definovať bližšie podmienky, napr. kedy sa mení verzia, kde sa čo uvádza, pridaj celé znenie plís sem, ja to pridam do celkového návrhu tvorby URI ako nový paragraf.
Čiže len pre upresenie, URI schémy publikovanej na metais pre fyzickú osobu je
<http://data.gov.sk/def/xsd/physical-person/>
pričom ak by sme my neskôr vytvorili inú XSD schému, ktorá by validovala fyzickú osobu z pohľadu RDF/XML, tak vytvoríme nové XSD, ktorá bude mať URI napr.
<http://data.gov.sk/def/xsd/physical-person-rdf/>
díkes
1 Like
Viď metodika tvorby XSD: https://wiki.finance.gov.sk/display/PS1/Metodika+tvorby+XSD#MetodikatvorbyXSD-VerzieXSDschém
a viď zápis PS1: https://wiki.finance.gov.sk/pages/viewpage.action?pageId=16023554#id-19.zasadnutiePS1-zápis-3.VerzionovanieXSDadeklaráciamennéhopriestoru
Ešte trochu upresňujúcich informácií:
Problematika použitia URIčok pre štandardizované XSD schémy je o dvoch odlišných veciach. Jedna vec je tvorba referencovateľného identifikátora pre dátový prvkok D.4.X.Y a súvisiace, druhá je ale ako to využijeme. Dotknem sa aj tretej veci, čo je časté, ako tvoriť identitu (čo “kódovať do URI”). A posledná švrtá vec je, ako to bude komplexne spracované a dostupné v najbližšiom LOD Slovakia (samozrejme keď to tu stabilizujeme ;).
Prvá vec je asi OK, tj. náš starší návrh (preklápanie KDP do owl) cez umiestnenie tohto a súvisiacich dátových prvkov do ontológie ikt, tj.
<http://data.gov.sk/def/ontology/ikt/XMLDataContainer>
rdf:type
owl:Class .
Pozn: toto URI bolo už zverejnené v poslednom LOD Slovakia (0.9.7) (časť ontológie/ikt)
Druhá vec je teda, ako a načo toto všetko použijeme.
Mali by sme to použiť korektne. Ak chceme vytvoriť URI pre XSD, tak musíme zohľadniť že XSD schéma je niečo iné, a niečo iné je jej element (akýužkoľvek), čiže to sú dve odlišné entity, tj. dve odlišné URI a nemožno to zamienať. XSD pri definícií má podstatné veci spoločné s ontológiou, hoc je to len o syntaxy. Preto vlastne pravidlo pre URI XSD schémy je
http://data.gov.sk/def/xsd/[SCHEMA-NAME]/{VERSION}
spresňujem to SCHEMA-NAME. Je to podobne ako URI ontológie, kde je to
http://data.gov.sk/def/ontology/[ONTOLOGY-NAME]/{VERSION}
Čiže nejaký prvok XSD schémy (rootovy, ale podradeny) a XSD schéma sú iné prvky, napr.
<http://data.gov.sk/def/xsd/physical-person/PhysicalPerson>
owl:differentFrom
<http://data.gov.sk/def/xsd/physical-person>
teda nie je správne stotožňovať URI schémy s URI XSD elementu vo vnútri.
Tretia vec je, že je dôležité vnímať URI ako reprezentáciu nejakej entity v grafe, a tá môže mať veľa spojení (vlastností). A až tie sú na “ukladanie” hodnôt vlasností. Účel samotného URI reťazca nie je zašifrovať všetky možné hodnoty entity priamo do URI, ide len o unikátnosť. Inými slovami, nejde o to - parsovať hodnoty z URI. Napr. kedy bolo URI vytvorené. Neparsujem z URI nejaký datetime reťazec, a to ani na určenom mieste. To je samostatná vlastnosť s možnými hodnotami.
<http://data.gov.sk/doc/standard/5455454424>
dct:created
"2016-01-01"^^xsd:date .
Štvrtá vec - Zaradenie do LOD Slovakia
XSD schémy publikované na
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=14712980
budú súčasťou Katalógu XSD schém, asi
<http://data.gov.sk/set/catalog/xsd>
rdf:type
adms:AssetRepository;
dcat:dataset
<http://data.gov.sk/def/xsd/physical-person>,
<http://data.gov.sk/def/xsd/corporate-body/>,
<http://data.gov.sk/def/xsd/physical-address/>,
<http://data.gov.sk/def/xsd/codelist/> ,
<http://data.gov.sk/def/xsd/xml-data-container/>,
<http://data.gov.sk/def/xsd/eform/> ,
<http://data.gov.sk/def/xsd/conversion-records-summary/>.
4 Likes
(trošku dlhší post)
Takže posielam tu aj opravenú metodiku použitia sémantiky v súvislosti s referenčnými údajmi. Zistili sme, že pôvodný návrh nebol ešte domyslený (odvodzovanie by prešírovalo vzťahy medzi referenčným registrom a referenčným údajom zo všeobecnejších na špeciálnejšie), pričom tak či onak by to nebolo riešením. Riešenie bolo jednoduchšie než by sa zdalo, a to použitie “referenčného kontextu” na strane sémantickej databázy. Tj. dáta vždy loadujem do kontextu zdroja, pričom množina referečných registrov tvorí referenčný kontext. A teda v prípade konfliktov (napr. rôzne hodnoty vlastností z rôznych zdrojov) sa bude vždy prefereovať vždy tá, ktorá je loadnutá v referenčnom kontexte.
Na nasledovnom prípade je graf reprezentujúci Andreja Kisku, pričom dáta sú (akože) loadnuté z RFO (do kontextu RFO) a taktisto z iného zdroja XY, kde je zámerne preklep v dátume narodenia. Keby som chcel potom pracovať s dátami, tak pri dopytoch (cez SPARQL) preferujem referenčný kontext.
Sémantika referenčné údajov podrobnejšie:
1) Zdrojové registre
Číselník CL010112 – Zdrojový register – tento obsahuje 1:1 zoznam podľa štatistického úradu
<http://data.gov.sk/set/codelist/stat-source-register>
rdf:type
adms:Asset;
dct:title
„Zdrojový register“@sk;
id:codelistCode
„CL010112“^^xsd:string …
Položka číselníka – Obchodný register
<http://data.gov.sk/id/stat-source-register/1>
rdf:type
egov:SourceRegister;
dct:title
„Obchodný register“@sk;
id:codelistItemCode
„1“^^xsd:string …
Číselník – Zdrojový register MetaIS
<http://data.gov.sk/set/codelist/source-register>
rdf:type
adms:Asset;
dct:title
„Zdrojový register“@sk ;
Položka číselníka – Zdrojový register
<http://data.gov.sk/id/egov/isvs/6117>
rdf:type
egov:SourceRegister;
dct:title
„Obchodný register“^^@sk ;
Mapovanie medzi číselníkom štatistického úradu a metais Zdrojových registrov
<http://data.gov.sk/id/egov/isvs/6117>
owl:sameAs
<http://data.gov.sk/id/stat-source-register/1>
2. Referenčné registre
Číselník referečných registrov v MetaIS
<http://data.gov.sk/set/codelist/reference-register>
rdf:type
adms:Asset;
Konkrétny referenčný register RPO
<http://data.gov.sk/id/egov/isvs/420>
rdf:type
res:ReferenceRegister;
Celková množina referenčných dát je reprezentovaná ako Katalóg referenčných registrov
<http://data.gov.sk/set/catalog/reference-data>
rdf:type
adms:AssetRepository;
dct:hasPart
<http://data.gov.sk/set/catalog/isvs/420>,
<http://data.gov.sk/set/catalog/isvs/191>,
<http://data.gov.sk/set/catalog/isvs/6113>,
<http://data.gov.sk/set/catalog/isvs/278>.
Kde napr. dáta RPOsú špecifikovaný nasledovne:
<http://data.gov.sk/set/catalog/isvs/420>
rdf:type
adms:AssetRepository;
res:dataSource
<http://data.gov.sk/id/egov/isvs/420>;
dcat:accessURL
<https://metais.finance.gov.sk/refregisters/list?page=1&count=100>;
dcat:dataset
<http://data.gov.sk/set/data/rpo-corporate-body>, // kompletné RPO
<http://data.gov.sk/set/data/6117-corporate-body>, // org. z OR
<http://data.gov.sk/set/data/226-corporate-body>, // združenia obcí
<http://data.gov.sk/set/data/224-corporate-body>, // register strán ...
Dataset referečného registra (RPO) bude reprezentovať nejaký dátový export z referenčného registra. Nasledovný triplet ukazuje napr. možný dataset z RPO – právnické osoby
<http://data.gov.sk/set/data/rpo-corporate-body>
rdf:type
adms:Asset .
Distribúcia k dnešnému dátumu (1.12.) datasetu referečného registra (RPO)
<http://data.gov.sk/set/data/rpo-corporate-body/2016-12-01.rdf>
rdf:type
adms:AssetDistribution .
Záznam v distribúcii (RPO)
<http://data.gov.sk/id/corporate-body/50158635>
rdf:type
org:CorporateBody;
org:businessID
<http://data.gov.sk/id/business-id/50158635>
org:name
„Slovensko.Digital“@sk;
id:rpoCode
„6562824“^^xsd:string;
<http://data.gov.sk/id/business-id/50158635>
rdf:type
org:BusinessID;
id:identifierType
<http://data.gov.sk/def/identifier-type/7>
id:businessIDCode
„50158635“^^xsd:string;
3. Referenčné údaje
Katalóg referenčných údajov
<http://data.gov.sk/set/catalog/reference-properties>
rdf:type
adms:AssetRepository;
dcat:dataset
<http://data.gov.sk/set/data/register-reference-data/420>,
<http://data.gov.sk/set/data/register-reference-data/191>,
<http://data.gov.sk/set/data/register-reference-data/6113>,
<http://data.gov.sk/set/data/register-reference-data/278>.
Distribúcia datasetu definície referečných údajov RPO k 1.12.
<http://data.gov.sk/set/data/register-reference-data/420/2016-12-01.rdf>
rdf:type
adms:AssetDistribution .
Príklad definície referenčného údaja – názov spoločnosti
<http://data.gov.sk/def/ontology/organization/name>
rdf:type
res:ReferenceProperty;
res:relatesTo
<http://data.gov.sk/def/ontology/organization/businessIDCode>;
res:referenceRegister
<http://data.gov.sk/id/egov/isvs/420>;
res:sourceRegister
<http://data.gov.sk/id/egov/isvs/219>,
<http://data.gov.sk/id/egov/isvs/6118>,
<http://data.gov.sk/id/egov/isvs/225>,
<http://data.gov.sk/id/egov/isvs/226>,
<http://data.gov.sk/id/egov/isvs/227>,
<http://data.gov.sk/id/egov/isvs/220>,
<http://data.gov.sk/id/egov/isvs/217>,
<http://data.gov.sk/id/egov/isvs/6117>,
<http://data.gov.sk/id/egov/isvs/215>,
<http://data.gov.sk/id/egov/isvs/218>,
<http://data.gov.sk/id/egov/isvs/224> .
Poznámka: pri práci s vlastnosťami referenčného údaja je možné pracovať len so stanovenými (explicitnými) tripletmi, nie odvodenými (implicitnými) z dôvodu, že medzi jednotlivými vlastnosťami ontológie sú hierarchické vzťahy, a odvodzovaním by sa prenášali tieto informácie z rodiča (superClass) na potomka.
X rdf:type rdfs:Property [CONTEXT explicit]
X res:resource Y [CONTEXT explicit]
2 Likes
A seriál o Milovaných referenčných údajoch má ešte jednu časť. 
Dobra vec je, ze naozaj netreba zbytocne referencne udaje specializovat, tj. ze ine URI ma referencny udaj Nazov tuzemskej organizacie a ine URI ma ref. udaj Nazov zahranicnej osoby. Staci len jeden, tj. nazov organizacie vo vseobecne, pricom ale je nutne pouzivat subjekt ku ktoremu sa to viaze, v referencnych prvkoch je to udaj skupina. Vsimol som si, ze toto je vyplnene len pri definicii ref. udajov pre RFO, pri RPO to chyba a treba to doplnit.
Z toho navyse vyplyva, ze netreba definovat samostatne referencne udaje pre cely objekt ako napr. Fyzicka osoba podnikatel, co je ref. udaj c. 22 v RPO, pretoze tento ma byt vyplneny ako som spominal v stlpci Skupina (domena referencneho udaja/vlasnosti).
Cize nazov spolocnosti (org:name) bude pre domacu spolocnost ako referencny udaj definovany takto:
a ten isty udaj je pre zahranicnu spolocnosti definovany zas takto:
čiže na grafe to vyzera zas takto:
Pri prezerani noveho EU Data Portalu je krasne vidiet ako su dane datove scheme prepojene na navrhovane SR datove standardy cim sa zabezpeci interoperbilita na EU urovni. Odporucam pozriet https://www.europeandataportal.eu kde je mozne data browsovat aj pomocou SPARQL tj. dopytovacieho jazyka nad semantickymi datami.
1 Like
Kde presne to krasne vidiet?
Ked si das Search SPARQL tak tam su aj nejake example dopytov. napr. na pocet datasetov je dopyt :
SELECT (count(*) AS ?count) WHERE { { ?s a dcat:Dataset } } LIMIT 100
Prepouzivanie dcat ontologii je navrhovany aj vramci EU a je zapracovany aj v narodnych standardoch kde dcat ontologia je primarna na zapis datasetu. Ostatne ontologie, ktore su tam popisovane su presne tie od ktorych dedia aj navrhovane narodne standardy takze budeme s EU v synchronizacii.
1 Like
Vedel by si vyskladat nejaku query kde by napriklad mi to vratilo kde vsade je firma IBM v roznych datasetoch?
Az tak dopodrobna nepoznam ako to riesi dany portal nakolko je novy. Co sa tyka nasich standardov tak to mame vymyslene v pripade pouzitia semantickych databaz. Kazdy dataset je loadnuty vzdy do subgrafu/contextu. Samotne query by vyzeralo cca nasledovne :
SELECT DISTINCT ?context WHERE {
GRAPH ?context {
{
<https://data.gov.sk/id/legal-subject/31337147> ?p ?o
}
UNION
{
?s ?p <https://data.gov.sk/id/legal-subject/31337147>
}
}
}
Samozrejme ze existuju aj riesenia “nenativne”, kde sa to da ale jednoducho poriesit napr. takto :
- Toolom, ktory by si vyziadal z MetaIS tie datasety, ktoreho hovoria o LegalSubject, postupne by si ich stahoval z data.gov.sk, a prechadzal s tym ze v nich hlada vyskyt daneho URI
- Vzdy pri nahravani do data.gov.sk spravil load do nejakej key-value DB kde by kluc bolo URI a values by boli distribucie a nad tym nejaka jednoducha sluzba
- Vytvorili by sa integracne sluzby na pozadi, ktore by si volal a oni to poriesia
Kazdopadne to co sa pytas je “offline” mode z existujucich datasetov/distribucii loadnutych na mieste X. Existuje aj decentralizovane riesenie pouzitim Federovanych dopytov aby sme sa vyhli centralizacii. Institucia, ktora vypublikovava datasety by mala prideleny svoj virtualny repozitar do ktorej by sa loadovali jej data. Samotny repozitar by bol informacne popisany v MetaIS tj. bolo by v nom zapisane ake typy entit sa nachadzaju v danych repozitaroch. Toto je samozrejme mozne aj automatizovat, ale to teraz nie je podstatne. Dolezite je to ze by sa takto dali spravit dopyt cross rozne databazy a nie je nutna jedna megadatabaza a takyto mechanizmus databaz by zabezpecil ze si viem z RPO vytiahnut hento a jednym query to hned prepojit na RFO a register adries a zrazu dostanem z jedneho query konsolidovany vysledok. Ber to ako highlevel princip, pretoze toto sa da nasobne presnejsie rozpracovat, ale na ilustraciu by to malo stacit.
No toto som vedel, moja otazka smerovala na ovela primitivnejsiu vec. Ked si nevieme roky data prepojit ani na Slovensku, tak by ma zaujimalo ci tam vobec su nejake datasety prepojene na medzinarodnej urovni. dcat ontologia je fajn, ale uprimne. Nie je to nic viac a nic menej ako “sme si dohodli spolocnu schemu na metadata o datasetoch”.
Ano, mas pravdu. Je to “iba” o spolocnej datovej scheme. Moja ale otazka je, a nie je to presne to co chceme? Ziadna raketova veda, len prepouzivanie schem a ich prepajanie s tym ze su vzdy unikatne a reprezentovane URI. Nic viac, nic menej.
Co sa tyka toho ze nevieme prepojit SR data, tak na tom sa prave pracuje aby to bolo co najlepsie popisane a vychytane. Dalsi krok je aby sa to preslo PS1 a vznikol standard a co hlavne, aby bol vynucovany tj. kto nepouziva za statne peniaze standard, nedostane zaplatene. Inak to proste nepojde. To si myslim uvedomujeme vsetci.
Datasety na medzinarodnej urovni by mali byt prepojitelne prave cez spolocne schemy. Link ti poslat neviem. Dolezite je ze vsetci chapeme pridanu hodnotu a mnozstvo penazi ktore by to v idealnom scenary vedelo usetrit. Neviem o inom plane B ako to podobnym sposobom zefektivnit. Ja osobne som otvoreny aj inym navrhom, ktore maju hlavu a patu.
1 Like
No prave ta pridana hodnota a gro problemu je v prepajani dat. A to sa deje podla mna na urovni referencnych registrov. To, ze budu identifikatory URI a schemy nejake standardne ontologie je podla mna ‘nice-to-have’, ale gro prace je uplne inde a tu za nas nikto nijakym sematickym kuzlom nespravi.