Harvestácia LKODu Registra priestorových informácií (LKOD-RPI)

[miroslavliska]

Uvedené otázky vytvoril: @MartinTuchyna

Pre integráciu na NKOD navrhujeme za RPI ísť cestou DC AP Dokumentov https://htmlpreview.github.io/?https://github.com/datova-kancelaria/dcat-ap-sk-2.0/blob/main/index.html#rozhranie-dcat-ap-dokumenty ktoré budeme generovat na báze dohodnutej spoločnej frekvencie harvestovania z Vašej strany. K tomuto riešeniu teda vytvoríme metadáta popisujúce katalóg RPI datasetov, ktoré by sa mali preniesť do NKOD (tu je potrebné prediskutovať aj niektoré veci priamo s providermi, lebo viacero organizácií registrovalo priestorové dáta na open Data portal ručne a mohlo by dochádzať k duplicitám. Za nás navrhujeme tieto prípady vyčistiť a provideri budú otvorené priestorové dáta popisovať metaújmi v RPI a tie sa pretransformujú potom aj pre potreby NKOD do DCAT štruktúry…). Z hľadiska implementácie spôsobu DCAT AP dokumentov, máme otázku k štruktúre samotného súboru. Bude možné mať na strane nášho súboru popisujúceho katalóg odkaz na jednotlivé datasety formou volania nášho API, ktoré vráti dáta v DCAT štruktúre, alebo budeme musieť reálne generovať nejaké statické súbory a zavesiť ich niekam na web server? Aby bolo jasné tak uvediem nejaký reálny priklad (sémantiku a správnosť DCAT kódovania nateraz neriešte - zaujíma nás technická realizácia…):

{

    "@context": [https://datova-kancelaria.github.io/dcat-ap-sk-2.0/kontexty/rozhranie-katalógu-otvorených-dát.jsonld](https://datova-kancelaria.github.io/dcat-ap-sk-2.0/kontexty/rozhranie-katal%C3%B3gu-otvoren%C3%BDch-d%C3%A1t.jsonld),

    "iri": https://data.gov.sk/set/lkod/rpi/katalog,
    "typ": "Katalóg",
    "názov": {
        "sk": "Katalóg otvorených dát RPI",
        "en": "Open Data Catalog of the Spatial data registry"
    },
    "popis": {
        "sk": "Otvorené dáta RPI. Obsahuje datasety o ......",
        "en": "Open data of the Spatial data registry. It contains datasets regarding ....."
    },
    "kontaktný_bod": {
        "typ": "Organizácia",
        "meno": {
          "sk": "Ministerstvo životného prostredia",
          "en": "Ministry of Enviroment
        },
        "e-mail": mailto:[email protected]
    },
    "domovská_stránka": https://www.mzp.sk/,
    "poskytovateľ": https://data.gov.sk/legal-subject/888888,
    "dataset": [
         https://rpi.gov.sk/api/collection_record/export?subject_upvs_id=1a898b93-6130-4b9e-ac56-0b560f6c51b8&unit_name=Slovensk%C3%A1%20agent%C3%BAra%20%C5%BEivotn%C3%A9ho%20prostredia&collection_record_id=2b5e8b14-1dad-4740-bbe6-cdc7556a14a1&export_format=geodcat,
         https://rpi.gov.sk/api/collection_record/export?subject_upvs_id=1a898b93-6130-4b9e-ac56-0b560f6c51b8&unit_name=Slovensk%C3%A1%20agent%C3%BAra%20%C5%BEivotn%C3%A9ho%20prostredia&collection_record_id=4a924106-9969-4fae-9d1a-afc7fa64cb99&export_format=geodcat,
         https://rpi.gov.sk/api/collection_record/export?subject_upvs_id=7fd57fac-2a2b-4e95-b8df-948972af89f6&unit_name=Ministerstvo%20%C5%BEivotn%C3%A9ho%20prostredia%20Slovenskej%20republiky&collection_record_id=6bc18781-2878-46a2-b2bf-fef3a65f95c0&export_format=geodcat
  ]
}

Ak sa podarí automatizovane naintegrovať metaúdaje do Open Data, viete tieto metaúdaje napárovať na konkrétne OVM (resp. ste schopní zabezpečiť harvesting distribuovaného katalógu), tak aby sa správne zobrazovali pod danými OVM?

Ak áno, na základe akého identifikátora bude na strane Open Data realizované párovanie metaúdajov na jednotlivé OVM?

[miroslavliska]

ad1.1) URI katalógu

Súbor s katalógom je v poriadku až na URI katalógu, ktoré musí aj URL, ktoré vráti metadáta katalógu. Tj. vo vašom prípade by to mohlo byť takto nejak:

https://rpi.gov.sk/api/lkod

pričom toto vráti ten JSON, ktorý si uviedol. A toto Vaše lokálne URI musí byť aj použité.

ad1.2) API vs. statické súbory

Samozrejme, môže byť použité API, dôležité je, aby vrátilo potrebné metadáta podľa DCAT-AP-SK-3.0.0 štandardu. Tu je jeho najnovšia verzia: file:///home/ubuntu/git/centralny-model-udajov/tbox/national/dcat-ap-sk/index.html

ad1.2) K príkladu metadát datasetu
Metadáta štandardu pre dataset (ktorý nie je typu HVD) sú dostupné tu:
file:///home/ubuntu/git/centralny-model-udajov/tbox/national/dcat-ap-sk/index.html#rozhranie-dcat-ap-dataset

Metadáta štandardu pre HVD dataset:
file:///home/ubuntu/git/centralny-model-udajov/tbox/national/dcat-ap-sk/index.html#rozhranie-dcat-ap-dataset-hvd

Dôležitá informácia je, že formát musí byť buď TTL alebo JSON-LD, tak ako je to v štandarde uvedené. Ostatné formáty, ako napr. RDF/XML nie sú podporované.

ad2+3) Poskytovatelia

Párovanie na poskytovateľov prebieha cez URI poskytovateľa. Tj. musí byť použité uri vo forme
https://data.gov.sk/id/legal-subject/{IČO}

Dôležitá informácia je, že datasety harvestovavné z LKODov sa zámerne nedajú editovať na strane NKODu. Prípadné zmeny, opravy chýb, atď, je potrebné vykonať na strane zdroja. Takže správne hovoríš, že najskôr ich bude potrebné vymazať z NKODu, ak sa tam už nahrali.

V rámco NKODu tu je zoznam poskytovateľov:
https://data.slovensko.sk/poskytovatelia

Čiže aby sa datasety na portáli zobrazili, je potrebné, aby bol ešte predtým pridaný takýto poskytovateľ do zoznamu. Ak budú mať poskytovatelia aj iné datasety, tak si ich budú môcť nahodiť cez portál. Preto budú musieť ale mať zriadený prístup, čo riešime my: stačí o to požiadať na adrese [email protected]. Každopádne, budeme potrebovať ich zoznam, aby sme ich vedeli pridať do NKODu. Ich názov, IČO, názov kontaktného miesta, email kontaktného miesta.

To isté bude patriť pre registráciu LKOD-RPI. Registrácia celého LKODu-RPI musí vykonať niekto za gestora RPI v NKODe (Nový lokálny katalóg). Predpokladám, že to asi budeš ty.

[radochudy]

@miroslavliska prosim dopln sem odkazy na NKOD v 3.0 a aj odkazy na tie validacne kriteria... Dakujem velmi pekne.

[miroslavliska]

@miroslavliska prosim dopln sem odkazy na NKOD v 3.0 a aj odkazy na tie validacne kriteria... Dakujem velmi pekne.
Ahoj, je to updatnuté.

[MartinTuchyna]

@miroslavliska

Seva Miro, kde presne nájdeme ten "Python" validator?
Vďaka, Martin

Cc: @radochudy

[radochudy]

@miroslavliska ako pristupit k mapovaniu, ked pre geodata mame GeoDcaT ale narodny profil pre NKOD pocita zatial len s DCAT? Vdaka.

[radochudy]

@miroslavliska aky je z vasej strany preferovany encoding? Turtle ci JSON LD? Ak JSON LD aky encoding poloziek pouzivat - sk ekvivalenty poloziek ako je uvedene tu https://htmlpreview.github.io/?https://github.com/slovak-egov/centralny-model-udajov/blob/develop/tbox/national/dcat-ap-sk/index.html#rozhranie-dcat-ap-dataset ? Preco sa vlastne robil vlastny preklad poloziek dcat do SK alternativ? https://datova-kancelaria.github.io/dcat-ap-sk-2.0/kontexty/rozhranie-katal%C3%B3gu-otvoren%C3%BDch-d%C3%A1t.jsonld Ja by som za RPI radsej ponechal EN nazvoslovie... Dakujem

[miroslavliska]

@miroslavliska aky je z vasej strany preferovany encoding? Turtle ci JSON LD? Ak JSON LD aky encoding poloziek pouzivat - sk ekvivalenty poloziek ako je uvedene tu https://htmlpreview.github.io/?https://github.com/slovak-egov/centralny-model-udajov/blob/develop/tbox/national/dcat-ap-sk/index.html#rozhranie-dcat-ap-dataset ? Preco sa vlastne robil vlastny preklad poloziek dcat do SK alternativ? https://datova-kancelaria.github.io/dcat-ap-sk-2.0/kontexty/rozhranie-katal%C3%B3gu-otvoren%C3%BDch-d%C3%A1t.jsonld Ja by som za RPI radsej ponechal EN nazvoslovie... Dakujem

Čo sa týka formátu, to je asi na Vás, ktorý vyberieš. Ja osobne by som si vybral TTL. Ak nechceš použiť tieto slovenské definície pre čitateľnosť JSON-LD:
https://datova-kancelaria.github.io/dcat-ap-sk-2.0/kontexty/rozhranie-katal%C3%B3gu-otvoren%C3%BDch-d%C3%A1t.jsonld

ktoré sme prebrali podľa odporúčaní ČR (čitateľnosť aj pre developerov čo nevedia čo je RDF), tak to ani nemusíš robiť, a môžeš vytvoriť rovno výsledné JSON-LD, kde použiješ správne URIčka ahotovo. Dôležité je, aby tam boli tie triplety a tým je to OK.

[miroslavliska]

@miroslavliska ako pristupit k mapovaniu, ked pre geodata mame GeoDcaT ale narodny profil pre NKOD pocita zatial len s DCAT? Vdaka.

Čo sa týka DCAT/GeoDCAT, toto je určite na diskusiu, pokúsim sa získať ďaľší názor ako sa s tým vysporiadať. Každopádne, národný portál tak či podporuje zatiaľ len DCAT-AP-3.0.0, pričom harvestovanie GeoDCAT nepredpokladám že bude implementované tak skoro, hoc pipelines na strane harvestra by nebolo až také ťažké updatnúť. Reálne to nevidím na rok 2024.

[miroslavliska]

@miroslavliska

Seva Miro, kde presne nájdeme ten "Python" validator? Vďaka, Martin

Cc: @radochudy

Ahoj, nájdete to tu:
https://github.com/lodslovakai/lkod-validator-py

Plánujem tu publishnut ešte viac zdrojových kódov v blízkej budúcnosti.

[radochudy]

LInk na dokument s mapovanim.... postupne ho doplnam.

https://docs.google.com/document/d/1lpO12YKGiWDb7KsyzvbElKScIA8JyH_PycH48_oqjU4/edit?usp=sharing

[radochudy]

Dobry den,
posielam zoznam otazok, ktore potrebujeme este potvrdit/ujasnit si:

• kodovanie: Ake je ocakavane kodovanie zo strany NKOD. Podla profilu je to JSON LD alebo Turtle. Je mozne vyuzit RDF XML kodovanie?
• prazdne povinne polozky: prosim o potrvrdenie dohody zo stretnutia, ze povinne polozky, ktore nevieme naplnit ponechame vo vyslednych suboroch zapisane ako prazdne

Polozka uzemny prvok z registra adries a Súvisiace geografické územie:
Položku nemáme priamo v mtd RPI. RPI eviduje len BBOX ale nie admin členenie evidované v RA. Bolo by mozne V zmysle GeoDCAT použiť dátový typ dct:Location a dcat:bbox. Je to akceptovatelne?

dct:spatial [ a dct:Location ; dcat:bbox "<gml:Envelope srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-31.285 27.642</gml:lowerCorner><gml:upperCorner>34.099 70.075</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral, "POLYGON((-31.285 70.075,34.099 70.075,34.099 27.642,-31.285 27.642,-31.285 70.075))"^^gsp:wktLiteral ] ;

Polozka Kontaktný bod – meno a email :
Polozku vieme naplnat po nasledovnej uprave Použitý typ kontaktu nebude vcard:Individual ale vcard:Organisation a následne bude naplnený obsah názvom organizácie a nie menom individuálnej osoby a emailom organizácie. Je to ok?

dataset: dcat:contactPoint kontakt: . kontakt: a vcard:Organisation ; vcard:fn "Ministersťvo životného prostredia"@sk ; vcard:hasEmail <mailto:[email protected]>

vdaka

[lk8w]

Dobrý deň:

• json ld alebo trutle, rdf - xml nie

• pošlite nám prosím zoznam všetkých metadát ktoré nemáte (alebo link), napr. pri accrualPeriodicity prosím vyplniť v prípade neznámej hodnoty hodnotu neznáme (UNKNOWN)

• toto tuším riešil p. Horník v e-mailovej komunikácii, tak on sa vám k tomu vyjadrí

• pre kontaktný bod použite (podľa príkladu v dokumentácii):

  dcat:contactPoint [
  a vcard2006:Organization ;
  vcard2006:fn "Ministerstvo dopravy, Odbor verejnej dopravy"@sk, "Ministry of Transport"@en ;
  vcard2006:hasEmail <mailto:[email protected]>
  ] ;

[hornik-informo]

Dobrý deň,
vyjadrím sa ku geogragrafickému územiu. Štandard DCAT-AP-SK 3.0 už vyžaduje prvok z registra adries NUTS/LAU. Existuje k tomu harmonizovaný číselník, kódy, aj prijateľné IRI (https://github.com/slovak-egov/centralny-model-udajov/blob/main/cbox/national/nuts2004.ttl).

Pre datasety, ktoré platia pre celú SR je to jednoduché, stačí uviesť: https://data.gov.sk/id/nuts1/SK0

Myslím, že bolo spomenuté, že z názvu obce alebo okresu viete odvodiť hranice. Viete to použiť aj naopak?