Vlastnosti distribúcií dcat:downloadUrl (a dcat:accessUrl) nie sú permanentné URL

[MarkySim]

URL dát v jednotlivých formátoch (napr. CSV) nie sú permanentné. Jedná sa napr. o dataset https://data.slovensko.sk/datasety/81764225-893b-4e6a-a6a1-3fbbe56fcb69. Táto URL by mala byť permanentná. Avšak pre tých, ktorý pravidelne sťahujú aktualizácie dát je dôležité, aby boli nemenné aj URL pre jednotlivé formáty, napr. pre tento dataset vo formáte CSV URL https://data.slovensko.sk/download?id=6881224e-6ec4-4e83-ae73-f1dfa3125d82 nie je permanentná, zdá sa, že sa mení s každým updateom. Bežný prípad použitia je: Každý týždeň si chcem stiahnuť tento dataset v CSV formáte. A k tomu potrebujem permanentnú URL na dataset v CSV.

[miroslavliska]

P. @hornik-informo , ak tomu správne chápem,

Jedná sa napr. o dataset https://data.slovensko.sk/datasety/81764225-893b-4e6a-a6a1-3fbbe56fcb69. Táto URL by mala byť permanentná.

URL datasetu je vždy permanentné, aj samozrejme jeho URI (hoc nie sú totožné). Však?

Avšak pre tých, ktorý pravidelne sťahujú aktualizácie dát je dôležité, aby boli nemenné aj URL pre jednotlivé formáty, napr. pre tento dataset vo formáte CSV URL https://data.slovensko.sk/download?id=6881224e-6ec4-4e83-ae73-f1dfa3125d82 nie je permanentná, zdá sa, že sa mení s každým updateom.

Ale linky na stiahnutie distribúcií sa menia, ak to správne chápem. Čiže vlastne toto nerieši SPARQL endpoint, pretože i keď sa to samozrejme dá dynamicky zistiť, cez dotaz podľa permanentného URI datasetu, tak súvisiace distribúcie budú mať vždy rozličné dcat:downloadUrl, však? Tým pádom by som podľa permantentnej linky dcat:downloadUrl sa nevedel dostať k URI datasetu cez SPARQL Endpoint, však?

Myslím že sme sa o tom už inicálne rozprávalali, a ja som bol tiež za to, aby aj dcat:downloadUrl bolo stále nemenné. Všinol som si to, keď som videl, že hodnota dcat:downloadUrl je robená cez get parameter, ale v starom portáli to bola reálna cesta k súboru. Toto je ale asi jedno, či je to volané cez parameter alebo nie, ale ak je pravda čo som hore uviedol, tak som aj ja za permanentné URL pre dcat:downloadUrl, či dcat:accessUrl, pričom predpokladám že URI aj URL datasetu, aj URI distribúcií sú nemenné. Je to prosím tak?

[hornik-informo]

SPARQL endpoint to rieši, pretože ak poznám URI datasetu, tak si viem zistiť jeho distribúcie a z nich downloadUrl. Zabezpečiť rovnaké downloadUrl sa teoreticky dá, ale bude závislé aj od postupu jeho vkladania. Ak vymažem distribúciu a vložím novú, tak nie je šanca, že sa zachová. Navyše pre LKODy to tiež nie je záväzné.

[miroslavliska]

SPARQL endpoint to rieši, pretože ak poznám URI datasetu, tak si viem zistiť jeho distribúcie a z nich downloadUrl. Zabezpečiť rovnaké downloadUrl sa teoreticky dá, ale bude závislé aj od postupu jeho vkladania. Ak vymažem distribúciu a vložím novú, tak nie je šanca, že sa zachová. Navyše pre LKODy to tiež nie je záväzné.

Ano to je pravda ze sa to da cez SPARQL endpoint vzdy ziskat, avsak pridana hodnota permanentneho linku moze byt v tom, ze ak viem ze sa zmenila, tak doslo k zmene distribucie, napr. kvoli oprave chyby, co moze byt uzitocne. Skusim ziskat nazor Jakuba z CR, aky ma na to pohlad, hoc rozmyslam, ze tym, ze maju ich NKODe len LKODy, toto asi moc neriesia. Mne by to ale s permanentnymi dcat:downloadUrl toto davalo velky zmysel, lebo by som si vedel odkontrolovat, ze toto som uz stiahol.

[hornik-informo]

Tento podnet je presne o tom, že URL súboru na stiahnutie sa mení v prípade zmeny obsahu súboru (nahratie novej verize, pridanie novej distribúcoe a pod.). Bez zmeny obsahu distribúcie zostáva URL nezmenené by default (inak to ani nemôže byť).

Všeobecne je dobrá prax, že súbory s odlišným obsahom majú rozdielne URL, práve aby bolo jasné, že je to iný súbor/iný obsah.

[luciajanikova]

Ako autorka požiadavky by som ešte doplnila. Nemusí to byť nevyhnutne permanetná URL pre súbor (ak Vám takéto riešenie nepasuje), povedzme aj nejaká forma /latest endpointu pre daný formát datasetu alebo podobné riešenie by vyriešilo tento problém.

Scenár je "Každý týždeň chcem automatizovane stiahnúť tento dataset v CSV formáte." Je to bežný scenár nie len pre nás, ale aj napr. pre väčšinu subjektov integrovaných na ÚPVS. Hľadáme iba odpoveď ako prítvetivo sa to dá zrealizovať.

[miroslavliska]

Ako autorka požiadavky by som ešte doplnila. Nemusí to byť nevyhnutne permanetná URL pre súbor (ak Vám takéto riešenie nepasuje), povedzme aj nejaká forma /latest endpointu pre daný formát datasetu alebo podobné riešenie by vyriešilo tento problém.

Scenár je "Každý týždeň chcem automatizovane stiahnúť tento dataset v CSV formáte." Je to bežný scenár nie len pre nás, ale aj napr. pre väčšinu subjektov integrovaných na ÚPVS. Hľadáme iba odpoveď ako prítvetivo sa to dá zrealizovať.

Ako píšete, toto je bežný scenár nie len pre Vás, ale aj pre väčšinu subjektov naintegrovaných na ÚPVS. Keď to zovšeobecním, tak toto je úplne celosvetový scenár, že hľadám najnovšiu verziu nejakého datasetu. Toto sa presne krásne a prívetivo rieši cez SPARQL Endpoint, že si vypýtate takýto dotaz:

Pre nejaký konkrétny dataset, ktorý je dátovou sériou
    vrát mi všetky datasety, ktoré túto sériu tvoria
    a zoraď mi ich od najnovších po najstaršie

Samozrejme predpokladá to, že musia byť správne skatalogizované opendáta. Čiže toto prejdem s poskytovateľom a dám vedieť, či sa to podarí urobiť takto úplne správne. A dovoláím si povedať prívetivo.

edit: prešiel som si to s kolegami z NASESu a vysvetlili sme si koncept správnej katalogizácie. Prosím preto chvíľu o strpenie, kým takto upravia dané opendata a na tom základe budete potom vedieť správne vyberať si vždy najnovšiu, resp. akúkoľvek časovú verziu datasetu.

[lk8w]

Pre nie celkom technicky zdatných používateľov (a funkčnosť ich dátových prepojení) by bolo fajn ak by bolo možné mať dataset napr. www.data.slovensko.sk/dataset123.csv, potom ho akualizovať tak, že URL zostane rovnaká. Dá sa to riešiť aj tak, že OVM bude mať dataset na svojom serveri a downladURL zostane rovnaká.

Neviem či to správne chápem, ale aj ak by to bolo www.data.slovensko.sk/dataset123.csv/latest tak to by bolo tiež vyhovujúce.

[miroslavliska]

Pre nie celkom technicky zdatných používateľov (a funkčnosť ich dátových prepojení) by bolo fajn ak by bolo možné mať dataset napr. www.data.slovensko.sk/dataset123.csv, potom ho akualizovať tak, že URL zostane rovnaká. Dá sa to riešiť aj tak, že OVM bude mať dataset na svojom serveri a downladURL zostane rovnaká.

Neviem či to správne chápem, ale aj ak by to bolo www.data.slovensko.sk/dataset123.csv/latest tak to by bolo tiež vyhovujúce.

Pre netechnických používateľov je k dispozácii portál (frontend). Pre automatizované strojové spracovanie je na prvom mieste systémové riešenie, a to je správne použitie metadát otvorených údajov.

[lk8w]

Myslel som používateľov (napr. študentov, analytikov), ktorí si vedia stiahnuť dataset/y, urobiť nad ním/nimi nejakú vizualizáciu v Exceli, PowerBI, ... a vedia si nastaviť aby sa im dáta aktualizovali z URL. Títo nebudú vedieť programovať a nebudú riešiť nejaký komplikovaný systém aktualizácie dát cez SPARQL. :)

[miroslavliska]

Myslel som používateľov (napr. študentov, analytikov), ktorí si vedia stiahnuť dataset/y, urobiť nad ním/nimi nejakú vizualizáciu v Exceli, PowerBI, ... a vedia si nastaviť aby sa im dáta aktualizovali z URL. Títo nebudú vedieť programovať a nebudú riešiť nejaký komplikovaný systém aktualizácie dát cez SPARQL. :)

Už asi trochu miešame viac vecí dokopy. Či sa už jedná o úplne netechnického, polotechnického alebo technického používateľa, v prvom rade potrebuješ mať správne metadáta otvorených údajov - tj. dátum vytvorenia, dátum aktualizácie, dátum časového pokrytia od, dátum časového pokrytia do a ostatné všetky metádata podľa profilu DCAT-AP-SK2.0. .

Pre štandardných technických používateľov, ktorí sa potrebujujú na portál naintegrovať potrebuješ systémové riešenie, a to je nájdenie najnovšej verzii datasetu podľa jeho skutočných metadát, nie podľa nejakej finty. :)
Pre polotechnických používateľov poďme hľadať riešenia, som úplne za to. Ale metadáta musia byť správne nech sa deje čo sa deje. :) A to nielen pre naitegrovanie, ale aj vo všeobecnosti pre rôzne štatistiky, napr. vyhodnotenia či máš všetky dáta za všetky obdobia, a podobne.

[miroslavliska]

@lk8w ešte predsa len dodám, že viem si predstaviť, že ten enpoint typu /latest by mohol byť implementovaný tak, že on v skutočnosti i tak zavolá SPARQL Enpoint, ktorý vykoná dotaz - vráť mi najnovší dataset zo série. Môžme sa o tom do budúcna rozprávať, ale zatiaľ máme všetko čo na treba na naintegrovanie sa na portál. Dôležité teraz je, aby sa dali metadáta do poriadku na strane poskytovateľa, v tomto prípade je to NASES. Verím že sme sa po dnešnom stretnutí posunulli a že to bude čoskoro v poriadku.

Asi možno medzi riadkami čítaš, že sa snažím dotlačiť technických používateľov, aby to robili štandardne cez SPARQL endpoint. Áno, presne to robím, pretože SPARQL Endpoint poskytuje dotazovaciu voľnosť na ľubovoľne-požadované dáta. Určite je potrebné toto viac zdokumentovať, možno pridať tento typ dotazu aj to príkladov pre dotazovanie a podobne. To určite áno.

A nezabudni tiež, že cez štandardný SPARQL Endpoint vieľ dotazovať aj iné opendatové portály, napr. https://data.gov.cz/sparql https://datos.gob.es/en/sparql https://data.europa.eu/sparql https://www.govdata.de/web/guest/sparql-assistent ...

[lk8w]

Jasné, nehovorím ze robme niečo mimo SPARQL, no v skratke som to myslel takto podľa priorít:

1. URL je rovnaké po aktualizácii.
2. Jednoduchý spôsob ako sa cez SPARQL dostať k URL aktuálnej verzie súboru. (pochopiteľný pre polotechnika) :)

[miroslavliska]

Jasné, nehovorím ze robme niečo mimo SPARQL, no v skratke som to myslel takto podľa priorít:

1. URL je rovnaké po aktualizácii.
2. Jednoduchý spôsob ako sa cez SPARQL dostať k URL aktuálnej verzie súboru. (pochopiteľný pre polotechnika) :)

Mno, začal som toto diskutovať s Jakubom Klimekom z ČR a vyzerá to tak, že v niečom som pravdu mal, ale nie úplne vo všetkom. Pokúsim sa predsa len dotiahnuť, aby jeho názor postol tu. Ak to správne chápem, sedí to s tými metadátami, že je potrebné mať správne metadáta, tj. všetky dátumové vlastnosti, tj. administratívne - vytvorené, modifikované, alebo obsahované - dátum pokrytia od, dátum pokrytia do, atď, a potom že najnovší dataset zo série sa zisťuje cez SPARQL Endpoint podľa metadát.

Avšak zmena URL distribúcie na stiahnutie - dcat:downloadUrl (dcat:accessUrl), pri zmene súboru neplatí absolútne. Ak to som to dobre pochopil: ak sa nemenia kľúčové metadáta (napr. časové, alebo územné pokrytie) , napr. kvoli oprave chyby v súbore, tak by sa link na stiahnutie meniť nemal. Ak sa však jedná o nový dataset v rámci série (nové časové obdobie alebo územie), tak by sa hodnota dcat:downloadURl meniť mal.

Takže zatiaľ plís berte stále riešenie tohto problému ako otvorené, aby sme spoločne stanovili pravidlá.

[jakubklimek]

Zdravím. Ten problém má několik rovin, tak pojďme postupně. Co se týče metadat - vždy je třeba mít správně metadata v katalogu. Tím lze vždy (přes SPARQL endpoint) najít URL souboru ke stažení, nezávisle na tom, zda se mění, nebo se nemění po aktualizaci. O tom asi není třeba diskuze.

Pokud se URL souboru s daty po aktualizaci změní - je třeba myslet na to, že je třeba ve stejnou chvíli změnit i URL v katalogu, jinak se to v tu chvíli až do aktualizace katalogu rozbije. Tohle funguje dobře, pokud data nahrávám přímo do katalogu, a stejnou akcí měním i metadata. Předpokládá to ale, že data se nahrávají tam, kde vznikají metadata, a to není vždy a všude, a navíc že se poměrně rychle dostanou do NKOD, což také nebude vždy platit.

U nás v Česku NKOD (národní katalog) již neumožňuje nahrávat data přímo do něj. MV ČR a teď DIA nechtěli brát za poskytovatele odpovědnost za hostování jejich dat. Zároveň se NKOD CZ plní výhradně pomocí harvestace metadatových záznamů, která probíhá jednou denně. To pro naprostou většinu use casů stačí, ale znamená to, že pokud se změní URL nějakého souboru ke stažení, tak i když se třeba v lokálním katalogu poskytovatele metadata změní hned (a u řady poskytovatelů to jeden systém není), v NKOD změna bude stejně až další den. Do data.europa.eu pak harvestace NKOD CZ probíhá 1x týdně.

Z výše uvedených důvodů v ČR nedoporučujeme, aby se při aktualizaci souboru měnilo jeho URL. Má to i další důvody

1. Řada uživatelů pracuje stylem "data najdu jednou v NKOD, zjistím si jejich URL a dále do NKOD nechodím a přistupuji k tomu URL". Je pro ně obtíž chodit pro aktualizace do NKOD.
2. I když by NKOD využili, a chtěli to dělat automaticky, je tu jeden detail, který to může zesložiťovat. Mějme dataset, ten má své IRI, a má distribuce. Ty distribuce budou třeba 2x CSV, 1x JSON, 2x XML. Pokud najdu URL souboru ke stažení, a je to jeden z CSV nebo XML souborů, kterých je více, tak pokud není metadatový záznam dostatečně bohatý na to, aby distribuce ve stejném formátu rozlišil něčím jiným než downloadURL (například linkem na rozdílné specifikace), tak po aktualizacích jejich URL, i s přístupem k NKOD, nepoznám, kterou z těch distribucí jsem to minule našel.
3. Pokud mi jde o to zjišťovat, zda se soubor na daném URL změnil či ne, tak k tomu si vystačím se správně implementovaným HTTP serverem, který v HTTP hlavičkách poskytuje eTag, případně Last Modified. To funguje, pokud se URL s aktualizací nemění.
4. Pro High Value Datasets je vyžadováno, aby i downloadURL bylo permanentní, tj. aby se nikdy nezměnilo. Zde je prováděcí nařízení trochu vágní, explicitně zmiňuje perzistentní IRI datasetu a endpointu API, nicméně v komunitě se to interpretuje i jako perzistentní URL souboru ke stažení.

Když přemýšlím, jaká může být výhoda toho, že se mi po změně obsahu souboru změní jeho URL (tj. staré zmizí, objeví se nové), tak mě vlastně nic nenapadá, krom jistého malého ulehčení implementace úložiště, které mi pro každý upload vrátí jiné URL, možná založené na hashi obsahu souboru, a pak není třeba dál nic řešit. Ale to je výhoda maximálně pro vývojáře takového systému, nikoliv pro jeho uživatele.

[hornik-informo]

Dobrý deň, za vývojárov data.slovensko.sk rozhodne nemám problém súhlasiť s tým, aby boli URL rovnaké aj po zmene. Na rozhodnutie je však potrebné zvážiť všetky pre a proti. Z toho dôvodu dopĺňam tieto informácie:

1. NKOD hostuje len cca polovicu súborov na stiahnutie, ostatné si poskytovatelia hostujú sami. Zadefinované pravidlo „URL sa nikdy v budúcnosti nezmení“ bude mať len obmedzenú platnosť a nemalo by sa preto komunikovať verejne. Z tohto dôvodu zostane katalóg potencionálne nekonzistentný aj naďalej.
2. Aktualizácia URL má zmysel aj koncových používateľov, pretože tak môžu pasívne zistiť, ktoré súbory sa zmenili a ktoré nie. Napríklad, ak bude existovať aplikácia načítavajúca stovky datasetov, tak bude musieť každý deň po jednom zisťovať, či sa náhodou nezmenili. Asi je jasné, že to skončí tak, že sa bude všetko sťahovať zakaždým, čo je zlé pre obe strany.
3. Rovnaké URL súboru distribúcie môže byť splnené len za predpokladu, že pri aktualizácii nedôjde k zmazaniu distribúcie a pridaniu novej, čim by sa väzba stratila. Predpokladajme, že sa to nebude stávať. Potom sa dá súbor stiahnutie nájsť vždy cez SPARQL pomocou IRI distribúcie, netreba hľadať podľa formátu.
4. Ak sú nové dáta publikované ako nové datasety v sérii, tak sa nové informácie vždy zverejnia pod novým URL. Napr. nasledujúci mesiac vznikne nový dataset, s novou distribúciou a tá bude mať súbor s novým URL. Riešenie je podľa mňa v tom, aby sa upozornili konzumenti dát, ako vznikajú aktualizácie a ako si zabezpečiť aktuálnosť (napr. odkazom na support článok portálu).
5. Vlastnosť pevných URL na pôvodnom opendata portáli nás v skutočnosti pekne potrápila v čase migrácie práve preto, lebo sa na ňu nedalo pripraviť vopred a neodkázali sme spoľahlivo zistiť, ktoré súbory sa zmenili a ktoré nie.
6. Nič nebráni tomu, aby poskytovateľ zmenil spôsob publikovania, tak že prestane publikovať súbory v rámci data.slovensko.sk a bude používať vlastný hosting súborov. V prípade, ak si konzument vždy načíta URL zo SPARQL, tak ho takáto zmena neovplyvní.

Ešte dodám, že z hľadiska vývoja sa na tejto vlastnosti neušetrilo nič.

[hornik-informo]

Skúsim ešte navrhnúť niečo medzi dvoma riešeniami: URL súborov na stiahnutie sa budú meniť po zmene ako doteraz, bude však dostupné permanentné URL distribúcie, ktoré bude viazané na ID distribúcie. Čiže po výmene súboru tej istej distribúcie sa toto URL nezmení. Zobrazovať by sa mohlo na detaile datasetu po rozkliknutí detailov (kde sa dnes zobrazujú licencie). V budúcnosti by tam mohol pribudnúť odkaz na wiki článok, ktorý by vysvetľoval výhody získania metadát cez SPARQL a prečo nie je výhodné závisieť na tomto. Ten, kto používa SPARQL si vie načítať downloadUrl – ten to nepotrebuje.

[jakubklimek]

Aktualizácia URL má zmysel aj koncových používateľov, pretože tak môžu pasívne zistiť, ktoré súbory sa zmenili a ktoré nie. Napríklad, ak bude existovať aplikácia načítavajúca stovky datasetov, tak bude musieť každý deň po jednom zisťovať, či sa náhodou nezmenili. Asi je jasné, že to skončí tak, že sa bude všetko sťahovať zakaždým, čo je zlé pre obe strany.

Tomuto uplně nerozumím. Jak často se datová sada mění, tj. jak často má smysl kontrolovat, zda se nezměnila, je dáno metadatem frekvence aktualizace na datové sadě. Tedy pokud se datová sada mění jednou za týden, vím, že častěji nemá smysl kontrolovat, zda je novější. Dále pokud je HTTP server nakonfigurovaný správně, tak eTag, případně Last-Modified mi řekne na HTTP HEAD, tj. metodu, která vrací jen HTTP hlavičky a je nenáročná. Tedy i kdybych měl 100 datových sad potenciálně aktualizovaných denně, tak, pokud mě to opravdu bude zajímat, pošlu 100 HTTP HEAD požadavků na zjištění, zda se něco změnilo, pokud mám stabilní URL.

Pokud stabilní URL nemám a musím přes NKOD kde budu hledat datum modifikace distribuce, tak to zjistím SPARQLem, pokud mě bude zajímat 100 datových sad, tak buď SPARQL bude složitější, nebo jich bude 100 malých, každopádně to zřejmě výpočetně bude náročnější, než 100 HTTP HEAD požadavků na statické soubory.

Skúsim ešte navrhnúť niečo medzi dvoma riešeniami: URL súborov na stiahnutie sa budú meniť po zmene ako doteraz, bude však dostupné permanentné URL distribúcie, ktoré bude viazané na ID distribúcie. Čiže po výmene súboru tej istej distribúcie sa toto URL nezmení. Zobrazovať by sa mohlo na detaile datasetu po rozkliknutí detailov (kde sa dnes zobrazujú licencie). V budúcnosti by tam mohol pribudnúť odkaz na wiki článok, ktorý by vysvetľoval výhody získania metadát cez SPARQL a prečo nie je výhodné závisieť na tomto. Ten, kto používa SPARQL si vie načítať downloadUrl – ten to nepotrebuje.

Tedy bude třeba vysvětlit, že si má uživatel pamatovat IRI distribuce a používat SPARQL na zjištění aktuálního download URL. Je to dost podobné případu výše. Stále ale nevidím tu uživatelskou výhodu v tom, že se mi po každé aktualizaci změní URL souboru - proč když chci aktualizovat distribuci datové sady, musím změnit URL souboru ke stažení?

Dám příklad - máme konkrétní CSV soubor https://www.coi.cz/userdata/files/dokumenty-ke-stazeni/open-data/kontroly.csv - ten má toto URL již cca 10 let. Pokud toto URL mám v nějakém datovém procesu, v čem je pro mě jako uživatele výhoda v tom, že by se to URL třeba každý týden měnilo a já se na něj musel navíc doptávat do NKOD?

[hornik-informo]

Zdá sa mi, že už zachádzame mimo rozsah tejto diskusie.

1. Ak sa dáta menia raz za týždeň, tak samozrejme neviem, kedy to bude a keď mi záleží na aktuálnosti, tak musím zisťovať častejšie a pravidelne. Možno máte iné skúsenosti, ale kľudne 20% “vývojárov” to bude načítavať pri každej potrebe, hoc aj každú sekundu. To, že obsah URL nie je stabilný to len umocňuje.
2. Dátum modifikácie distribúcie v metadátach neexistuje a aj keby existoval, tak to nie je berný údaj, keďže dáta sa menia mimo NKOD (ako som písal, polovica dát je hostovaná inde). Závisieť na hlavičkách - ja by som toto ako konzulment nepoužil, kým nemám garantované, že tie informácie sú 1:1 s realitou.
3. V mnou navrhnutom riešení SPARQL používať netreba.
4. Výhoda je v tom, že mám URL súborov, ktorých aktuálnosť viem zistiť hromadne jedným malým SPARQL dotazom.
5. URL distribúcií aktualizovať netreba, deje sa to automaticky pri uploade.

Prosím teda o potvrdenie, že ideme cestou permanentných URL distribúcií. Nebude to však globálne garantovaná vlastnosť, ako som popísal vyššie.

[jakubklimek]

Mně naopak přijde, že se dostáváme k jádru diskuze - tj. co jsou přesně očekávání a výhody zvoleného řešení.

1. takové chování pak ale nesouvisí s tím, co je v metadatech, ani s tím, zda se URL mění či nemění. Zkrátka ano, existují uživatelé, kteří nezávisle na čemkoli mohou chtít data stahovat často.
2. to samozřejmě záleží na potřebách uživatelů. Kdyby potřeba byla, metadatový záznam lze rozšířit. A pokud data nejsou hostována přímo v NKOD, to ještě neznamená, že se metadata neaktualizují v LKOD poskytovatele, který takto data poskytuje, a tedy se projeví při další harvestaci NKOD. I frekvence harvestace NKOD záleží na potřebách uživatelů. To že teď je nastavena na denní je jedna věc. Pokud se najde relevantní skupina uživatelů kteří by to potřebovali častěji, tak se to dá změnit dle potřeby.
3. Tak to jsem to řešení nepochopil. Píšete, že bude "permanentné URL distribúcie, ktoré bude viazané na ID distribúcie.". Pod URL distribuce si představuji DCAT distribuci v metadatech. To když bude pevné, stále potřebuji získat aktuální downloadURL.
   • Pokud tím URL distribúcie myslíte URL, které bude pevné, a vždy mě přesměruje na poslední známé URL kde se soubor skutečně vyskytuje, tak to je pak něco jiného. Pak by ale bylo žádoucí, aby toto pevné URL bylo v ono downloadURL v metadatech a fakt, že dochází k přesměrování, by pak zůstal interní záležitostí implemetnace NKOD a jeho datového úložiště. Pokud by tomu tak nebylo, došlo by ke zmatení - nebylo by jasné, jaký je vztah mezi downloadURL v metadatech NKOD, pevným URL, které je ale dostupné jen přes UI NKOD, a tedy nepoužitelné pro strojové zpracování tam, kde o ta stále nová downloadURL třeba nestojím.
4. Pokud nemáme datum aktualizace distribuce v metadatech, jak tedy jedním SPARQL dotazem zjistím, které soubory se změnily? Předpokládáte zde, že si uživatel bude pro každý dataset pamatovat jeho "poslední viděné downloadURL" a porovnávat to s aktuálním, a z toho, že nesedí, bude usuzovat, že došlo ke změně?
5. Zde nerozumím, o jaké URL tedy jde (viz bod 3), a kde a proč by se mělo či nemělo aktualizovat

[hornik-informo]

1. Ak sa mení obsah bez zmeny URL, tak to umocňuje pocit, že ho treba načítať často/vždy, lebo nevieme, či sa zmenilo. Unikátne URL sa dá kešovať bez výhrad a bez dodatočnej kontroly.
2. Nehovorím o LKODoch, ale o distribúciách, ktoré sú metadátovo primárne v NKOD, ale fyzicky inde. Pri registrácii distribúcie vo formulári môžem zadať ľubovolné URL a neuploadujem súbor do NKOD. Takýchto distribúcií je cca polovica zo všetkých.
3. Lepšie bude to nazvať "Permanentné URL súboru na stiahnutie tejto distribúcie", nie je to jej URI/IRI. Podľa môjho návrhu by to existovalo ako fallback pre tých, ktorí chcú zachovať doterajší stav a berú ohľad na všetky okolnosti a riziká. Napr. ak nenačítavam metadáta, tak sa nedozviem, že mohlo dôjsť k zmene licencií danej distribúcie. Možno sa to zdá len mne, ale vidím ako niečo, čo ide proti zámeru projektu NKOD. Súčasťou môjho návrhu mala byť aj verejná informácia o tom, prečo takéto URL existuje a prečo to nie je najsuper riešenie ho používať.
4. Zistím aktuálne URL distribúcií a hneď viem, ktoré sú zmenené.
5. To bolo ako reakcia na potrebu zmeniť URL súboru, ked chcem zmeniť distribúciu. To nie je vyžadované od poskytovateľov dát, ale deje sa automaticky, keď uploadnu nový subor tej danej distribúcie.

Mojim cieľom nie je presadiť nejaké svoje riešenie, len popísať, že ak sa to zmení, tak to automaticky neznamená garancie pre všetkých a vo všetkých situáciách. Často sa nám totiž stáva, že sa rozšíri informácia typu "URL sú garantovane stabilné naveky vekov" a chápe sa to doslovne.

[jakubklimek]

OK, za mě jsou nyní pro a proti měnících se a permanentních URL celkem jasně popsané. Tedy teď je to na rozhodnutí, zda jsou upřednostňovaná měnící se, permanentní, nebo se to nechá otevřené, případně volitelné pro poskytovatele.

Jedinou nedořešenou věc vidím to, že by stálo za to nějak informovat uživatele o zvolené politice, aby bylo jasné, co očekávat. A to i strojově čitelně, nejen v UI NKOD.

[miroslavliska]

Ahojte,

pokúsim sa zhnúť tento task a čoskoro ho uzavriem. Riešili sme tu, či má byť linka na stiahnutie súboru perzistentná (nemenná) alebo nie. Táto problematika sa netýka len samotného centrálneho portálu data.slovensko.sk ale aj lokálych katalógov, ktoré sa do portálu denne harvestujú. Na tomto základe som vykonal analýzu lokálnych katalógov, tu je zverejnená: https://platforma.slovensko.digital/t/lokalne-katalogy-otvorenych-dat-lkod/9196/2

na základe čoho je výsledok taký, že je to rôzne, napr. niektoré používajú tú istú linku na stiahnutie, a to dokonca permanentne, tj. nech sa aj mení časové pokrytie datasetu, niekde je perzistentná len v rámci časového pokrytia, tj. pre dané obdobie. Nech je to tak či onak, faktom je, že toto nie je nemožné kontrolovať, iba usmerňovať.

Ďaľším faktom je, že v minulosti neexistovali metadáta pre časové pokrytie datasetu, a jediné časové údaje boli adminitratívne metadáta, tj. dátum vytvorenia, či dátum modifikácie. Ak došlo k nejakej oprave staršieho súboru, došlo k automaticky k nesprávnemu usporiadaniu datasetov, ak sa používal ako referenčný dátum modifkácie (starší sa stal najnovší).

Nový portál, resp. lokálne katalógy majú novú pridanú hodnotu, a tým je časové pokrytie datasetu (platnosť od - do), čo je najdôležitejší údaj. Ak sú tieto údaje spravne evidované, tak potom nevadí, či dôjde aj k oprave staršieho datasetu, a pokiaľ sa sortujú datasety podľa časového pokrytia, tak sa s datasetmi pracuje časovo korektne. Tento fakt teda hovorí, že nie je nutné viazať sa na permantnú linku, ale vždy je možné získať správne časové verzie podľa metadát. Navyše, je možné využiť i dodatočný fakt, že ak sa zmení obsah, aspoň teda na centrálnom portáli, tak to môže signalizovať zmena URL linky, čo je dodatočná informácia.

Pre celkovú správnu prácu s Národným katalógom je kľúčové, aby boli datasety a distribúcie katalogizované správne. Jedným z problémov minulého riešenia bolo, že sa distribúcie katalogizovali nesprávne, tj. nebolo často splnené pravidlo, že všetky distribúcie datasetu musia byť obsahovo totožné, rozdielne môžu byť jedine vo formáte.

Preto na horeuvedom základe sme sa rozhodli, že linka downloadUrl na centrálnom portáli zostáva implementovaná vo forme, ako je to teraz, tj. nemení sa s výhradou, že sa zmení súbor. Najnovšie verzie datasetov sa nebudú zisťovať cez downloadUrl, resp. administratívnymi metadátami dátum vytvorenia, alebo dátum modifikácie, ale na základe skutočných metadát časového pokrytia datasetu. Zmena downloadUrl bude indikovať dodatočnú informáciu, že došlo k zmene obsahu súboru, avšak časová platnosť bude vždy daná správnymi metadátami časového pokrytia.

Tu je potrebné dodať, že nejaký čas potrvá, kým poskytovatelia "si dajú do poriadku" metadáta svojich publikovaných otvorených údajov. Pre potrebnú dôležitú kvalitu celého národného katalógu, je to však nevyhnutné. V tejto súvislosti bude dátová kancelária usmerňovať poskytovateľov, konkrétnymi usmerneniami.

Príkladom môže byť Usmernenie pre katalogizáciu zoznamu schránok na doručovanie

kde je spravená analýza: Súčasná nesprávna katalogizácia zoznamu schránok na doručovanie (2024-04-04)

spolu s odporučením, ako je to potrebné správne spraviť: Odporučená správna katalogizácia zoznamu schránok na doručovanie (2024-04-04)

spolu s usmernením pre konzumentov, Usmernenie pre získanie najnovšieho zoznamu schránok na doručovanie

V prípade potreby vydania usmernení pre iných poskytovateľov, je nás potrebné kontaktovať na opendata@mirri.gov.sk. Takže ešte raz, implementácia sa nemení, za deň/dna tento task uzavriem. Ak sú k tomu ešte nejaké otazky, nech sa páči.

[jsuchal]

Popisalo sa tu vela, priznam sa, ze som sa v detaile stratil, ale zaver beriem tak, ze sa nateraz nebude implementovat/menit na portali nic.

Cim sa teda oblukom dostavame naspat k povodnej otazke: "Ako ziskam linku na najaktualnejsie data?"

Ked si pozrieme napriklad taky github a tam https://github.com/slovensko-digital/autogram/releases/latest - (schvalne si kliknite, ze to teraz spravi redirect na https://github.com/slovensko-digital/autogram/releases/tag/v2.1.5)

Tu citam, ze treba na ziskanie url pre distribuciu SPARQL endpoint. Skusme teraz uplne konkretne, ze ako to bude vyzerat implementacne. Co kde ako mam zavolat? Doteraz sme volali nieco ako "curl " a hotovo. Po novom to bude co?

[miroslavliska]

Tu citam, ze treba na ziskanie url pre distribuciu SPARQL endpoint. Skusme teraz uplne konkretne, ze ako to bude vyzerat implementacne. Co kde ako mam zavolat? Doteraz sme volali nieco ako "curl " a hotovo. Po novom to bude co?

Po novom to bude poslanie lubovolneho sparql select dotazu na sparql endpoint, ktory je dostupny

https://data.slovensko.sk/api/sparql?query=URL-ENCODED-SPARQL-QUERY

Napr. príklad dotazu 100 datasetov a ich poskytovateľov z https://data.slovensko.sk/sparql

PREFIX dcat: http://www.w3.org/ns/dcat# PREFIX dct: http://purl.org/dc/terms/ PREFIX foaf: http://xmlns.com/foaf/0.1/

SELECT DISTINCT ?dataset ?názov ?poskytovateľ WHERE { GRAPH ?g { ?dataset a dcat:Dataset; dct:title ?názov; dct:publisher/foaf:name ?poskytovateľ. FILTER(langMatches(LANG(?názov), "sk")) FILTER(langMatches(LANG(?poskytovateľ), "sk")) } } ORDER BY ?názov LIMIT 100

Po url encodnuti sa da zavolat dotaz cez https: https://data.slovensko.sk/api/sparql?query=PREFIX%20dcat%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2Fns%2Fdcat%23%3E%0APREFIX%20dct%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0APREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0A%0ASELECT%20DISTINCT%20%3Fdataset%20%3Fn%C3%A1zov%20%3Fposkytovate%C4%BE%20WHERE%20%7B%0A%20%20GRAPH%20%3Fg%20%7B%0A%20%20%20%20%3Fdataset%20a%20dcat%3ADataset%3B%0A%20%20%20%20%20%20dct%3Atitle%20%3Fn%C3%A1zov%3B%0A%20%20%20%20%20%20dct%3Apublisher%2Ffoaf%3Aname%20%3Fposkytovate%C4%BE.%0A%20%20%20%20%20%20FILTER%28langMatches%28LANG%28%3Fn%C3%A1zov%29%2C%20%22sk%22%29%29%0A%20%20%20%20%20%20FILTER%28langMatches%28LANG%28%3Fposkytovate%C4%BE%29%2C%20%22sk%22%29%29%0A%20%20%7D%0A%7D%0AORDER%20BY%20%3Fn%C3%A1zov%0ALIMIT%20100%0A

a tiež sa dá použiť aj curl forma curl --location 'https://data.slovensko.sk/api/sparql?query=PREFIX%20dcat%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2Fns%2Fdcat%23%3E%0APREFIX%20dct%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0APREFIX%20foaf%3A%20%3Chttp%3A%2F%2Fxmlns.com%2Ffoaf%2F0.1%2F%3E%0A%0ASELECT%20DISTINCT%20%3Fdataset%20%3Fn%C3%A1zov%20%3Fposkytovate%C4%BE%20WHERE%20%7B%0A%20%20GRAPH%20%3Fg%20%7B%0A%20%20%20%20%3Fdataset%20a%20dcat%3ADataset%3B%0A%20%20%20%20%20%20dct%3Atitle%20%3Fn%C3%A1zov%3B%0A%20%20%20%20%20%20dct%3Apublisher%2Ffoaf%3Aname%20%3Fposkytovate%C4%BE.%0A%20%20%20%20%20%20FILTER%28langMatches%28LANG%28%3Fn%C3%A1zov%29%2C%20%22sk%22%29%29%0A%20%20%20%20%20%20FILTER%28langMatches%28LANG%28%3Fposkytovate%C4%BE%29%2C%20%22sk%22%29%29%0A%20%20%7D%0A%7D%0AORDER%20BY%20%3Fn%C3%A1zov%0ALIMIT%20100%0A'

Samozrejme, na strane poskytovateľa sa musia metadáta doplniť tak, aby fungovali query. Najčastejšie treba dotiahnuť skutočné časové pokrytie na dataset. Na viacerých opravách sa pracuje.

Tu je doplnená dokumentácia: Ako zistím najnovšiu verziu nejakého datasetu cez SPARQL Endpoint?

[miroslavliska]

Ked si pozrieme napriklad taky github a tam https://github.com/slovensko-digital/autogram/releases/latest - (schvalne si kliknite, ze to teraz spravi redirect na https://github.com/slovensko-digital/autogram/releases/tag/v2.1.5)

Takéto niečo by sme vedeli spraviť /latest ,nevylučujem to do v budúcnosti.

Zatial mame tieto dokoncovania ako prioritne veci https://github.com/slovak-egov/nkod-portal/milestone/8

A toto sa neda dosiahnut alternativne, tak ako sa da zistit najnovsi dataset cez SPARQL Endpoint. Otazka ale znie, ci vobec nejake api robit, ked je univerzalny endpoint a existuje mnozstvo veci, ktore sa daju radsej namiesto urobit. To je na debatu.

[jsuchal]

Univerzalny endpoint je sice fajn ale pre konzumentov ktori doteraz niekde "pleskli" url do stahovacieho skriptu to odrazu znamena

0. najst tuto diskusiu alebo metais (nemozne)
1. naucit sa ako pouzivat sparql
2. spravit dobry request a rozparsovat ho.
3. najst tam co treba
4. nastavit si monitoring, ze ked ten sparql endpoint je dole, tak co sa ma diat. (je to zavislost na novom API)

[miroslavliska]

0. najst tuto diskusiu alebo metais (nemozne)

Určite sa dá robiť v dokumentácii viac. Updatol som stránky podpory pre data.slovensko.sk Téma: Strojové získavanie otvorených údajov

My sme už robili aj všeobecné školenie na túto tému: Školenie: Dotazovanie metadát otvorených údajov cez SPARQL Endpoint

A v najbližšiom čase chystáme 2 súvisiace školenia: Úvod do dátovej interoperability Školenie 2024-04-DD: Dotazovanie otvorených údajov data.slovensko.sk cez SPARQL Endpoint