Mno, nakoniec oveľa väčšie issue nakoniec vyzerá, že bude spojená s Registrom priestorových informácií, ktorý by mal teraz niekedy nabiehať na testovaciu prevádzku. Samozrejme že RPI je trošku historická vec pre mňa, až teraz som sa dozvedel že niečo také existuje, každopádne je to príklad toho, ako nechceme aby sa robili URI identifikátory, a to úplne samostatne, vo vlastnom systéme. Už vyššie som písal, že presadzujeme jediný metainformačný systém a to Centrálny metainformačný systém verejnej správy, ktorý jediný ma autoritu vydávať tzv. referenčné URI. Podporujeme, aby sa MetaIS stal referenčným registrom pre URI, podobne ako je to v prípade iných referenčných registrov. Toto som prezentoval na poslednom stretnutí K9.4, kde som mal pocit že sú s tým členovia OK, dokonca aj @Lubor (samozrejme nebavíme sa o URI fyzických osôb v RFO a podobne), rozprávame sa o URI priestorových entít aj ich dátových prvkov.
Čo ma trochu mrzí je, že sme už dávno dokonca do LODu zapracovali a voľne publikovali príklady priestorových dát z projektu data.sazp.sk, kde je všetko spravené jednotným spôsobom (jednotná metodika tvorby URI), jednotný prístup používania špecifických ontológií (INSPIRE v tomto prípade), tu je dokonca príklad:
všetko vyzeralo gúút. No a teraz keď sa pozerám na RPI, tak už to jednak ani nie je register priestorových informácií ale len register metadát priestorových informácií (modelu), ktorý požiadavky z uvedeného výnosu nerešpektuje, počíta sa tam s https://…
Čo s tým teraz?
ako som už spomenul, cieľom je dosiahnuť aby MetaIS bol referečný register URI, tj. aby bol len jeden metainformačný systém - čo je asi logické a správne riešenie. Tým pádom by ale musel RPI vyriešiť referenčné dáta mapovaním na referenčné údaje (napr. zverejneným datasetom medzi entitami MetaIS a RPI), čo by bola veľka škoda takto začať. Ponúkame im preto, že im zadarmo (zdôrazňujem) pomôžeme nahodiť do RPI prvky tak, že najskôr sa zaregistrujú v MetaIS a to sa použije v RPI. Nech sa v RPI vypne validácia URI, a bude to OOK. Keď začne metaIS poskytovať službu registrácie URI automatizovane, tak sa to do RPI môže dopracovať.
Aby som bol ešte presný, napr. opravil som formuláciu o cieľoch RPI, že RPI nebude vydávať URI, ale
kludne mozme preniest e-mail diskusiu aj sem, preto nizsie pripojim pre uplnost aj odpovede na relevantnu cast komunikacie, nech sa to neriesi na n miestach.
Na uvod by som chcel opatovne zdoraznit a pripomenut, ze okrem plnenia prioritnych povinnosti vymedzenych legislativou INSPIRE patri uzka integracia RPI s eGov a Open Data aktivitami medzi prioritne aktivity (vid aj bod 03 Akcneho planu implementacie INSPIRE v SR).
Viac v texte…
V prvom rade je potrebne uviest, ze INSPIRE legislativne poziadavky a suvisiace technicke usmernenia boli prijate podstatne skor ako legislativne poziadavky na narodnej urovni v oblasti eGov, comu zodpovedaju viacere nekonzistentnosti ale aj konceptualne rozdiely pri implementacii.
INSPIRE je navrhnuty nad URIs, preto aj implementacia Narodnej infrastruktury priestorovych informacii (INSPIRE v SR) ma ambiciu byt uzko napojena na funkcny a organizacne zabezpeceny narodny mechanizmus koordinacie spravy Mennych priestorov (namespace), ktore su klucovym predpokladom pre tvorbu URIs.
Aj ked RPI v sucasnosti poskytuje iba metainformacny system, vyssie uvedeny mechanizmus umoznuje zaujemcom pri dodrzani legislativnych poziadaviek a technickych odporucani zabezpecit pristup k samotnym zdrojom a ich jednotlivym castiam, ktore v kontexte INSPIRE mozu byt vo forme:
suborov priestorovych udajov
serie priestorovych udajov
sluzieb
Ano nasadenie RPI este moze priniest niektore vyzvy, ale dobra sprava je, ze pri dostatocnej koordinacii zo strany MZP SR+SAZP, podpory dodavatela a sucinnosti povinnych osob sa systemovo nastavi standardizovane dokumentovanie priestorovych zdrojov metaudajmi, ktore umoznia zaujemcom pristup az k popisovanym udajom a sluzbam.
Z uvedeneho dovodu iba vitame, ze je ambicia nastavit Centrálny metainformačný systém verejnej správy (MetaIS) ako koordinacnu autoritu, no myslim, ze koordinacia by mala prebiehat na urovni mennych priestorov pre jednotlivych poskytovatelov udajov. Poskytovatelia priestorovych udajov by mali na zaklade prideleneho menneho priestoru byt schopni alokovat URI a vypublikovat svoje udaje (Who allocates URIs?).
Na zaklade mne dostupnych informacii organizacne a procesne pridelovanie Mennych priestorov v sucasnosti nie je koordinovane a v zmysle legislativy INSPIRE tuto povinnost musime zabezpecit, (kedze SR ma ako aj ostatne clenske staty EU jasne zadefinovane terminy v INSPIRE roadmap), nateraz bol na zaklade najlepsieho stavu poznania poziadaviek Vynosu ISVS nastaveny system pridelovania mennych priestorov pre vyssie uvedene zdroje v RPI s tym, ze samotne URI je vytvorene ako kombinacia menneho priestoru a identifikatora, ktory prideli autor metazaznamu.
Viac informacii nizsie.
Opat pripominam, ze projekt data.sazp.sk je pilotnym riesenim zameranym na identifikaciu moznosti spristupnovania INSPIRE aj nie INSPIRE priestorovych udajov prostrednictvom semantickeho webu vo vazbe na aktivity Open Data. Sme velmi radi ze tieto udaje boli integrovane do LOD a ako sme uz neraz avizovali, velmi radi budeme pokracovat na aktivitach v tejto oblasti, no nakolko musime prioritne zabezpecovat legislativne poziadavky a kapacitne zdroje su vyrazne obmedzene musime prehodnocovat priority.
Ako si sam skonstatoval, jediny nesulad s URI, ktore momentalne RPI priraduje je ze namiesto “http://data.gov.sk/”
momentalne poskytuje “https://data.gov.sk/”. Po dnesnej konzultacii s dodavatelom by odstranenie “s” z protokolu nemal byt problem.
Ak ma byt sucastou URI aj samotny identifikator udajoveho zdroja, alebo jeho casti (atributu, triedy objektov), tak by bolo vhodnejsie nastavit MetaIS ako referencny register mennych priestorov. Vynimku mozu tvorit centralne spravovane ciselniky a registre. Kazdopadne by sprava identifikatorov jednotlivých inštancií konceptu mala zostat pod spravou autority, ktora udaje vytvara/spravuje (jeden zo zakladnych principov INSPIRE “Data should be collected only once and kept where it can be maintained most effectively.”).
Vobec nevidim ako problem sucasne nastaveny model, nakolko ihned ako sa v SR sprevadzkuje organizacne a procesne pridelovanie Mennych priestorov moze Ministerstvo zivotneho prostredia SR, pripadne SAZP poziadat danu autoritu o pridelenie menmeho priestoru: “MetaIS”.
Dolezite bude taktiez nastavenie “dereferencingu” cez uri pre zabezpecenie strojovo citatelneho pristupu az na najnizsiu dostupnu uroven. To ci uz budu samotne priestorove udaje, spristupnovane bud cez sluzby encodovane v rdf, json alebo gml je uz implementacny detail ako aj otazka preferencii ich konzumentov.
Ak sa da este dokument pripomienkovat, isto by som navrhovla upravit ten snapnuty text smerom:
“Jedným z dôležitých rysov RPI pre manažment údajov je zosúladenie sa s Centrálnym metainformačným systémom verejnej správy, od ktorého bude preberať pridelený menný priestor slúžiaci pre jednoznačné referencovateľne identifikatory pre priestorové údaje a súvisiace služby, čím sa dosiahne celková vzájomná interoperabilita údajov z RPI a ostatných referenčných registrov.”
Este k doterajsej komunikacii, nech to prediskutujeme na jednom mieste (reakcie su kurzivou):
na linkovaných dátach pracujeme spolu už dlhšie, škoda že tak neefektívne, pretože Ťa považujem za správneho človeka na správnom mieste.
Vdaka, nemyslim si, ze ide o neefektivnost, akurat som na tom s vynimkou podpory niektorych kolegov sam a kapacitne nestiham sledovat vsetko. Preto som rad, ze sa aj aktivitami ako je implementacia RPI a Dokument Lepsie data pomaly posuvame k praktickym dopadom niektorych navrhovanych rieseni (pricom viem, ze este o niektorych dosledkoch ani netusim ;o)
kde je jasne zadefinované URI, tj. v zmysle http://data.gov.sk/… , nie ako v RPI, kde URI začína prefixom https://data.gov.sk/…
Možno že je to len písmenko, ale ak chceme mať dobré Linkované dáta, tak aj to písmenko (mnapr. kvoli neskoršej derefernciácii) je potrebné dodržať.
Uz sa na tom pracuje. Ked to bude upravene, dam vediet.
mrzí ma to o to viac, že sme už v marci milého roku spracovali vaše dáta zo http://data.sazp.sk a zahrnuli sme ich do LOD Slovakia (aby boli voľne prístupné pre všetkých),
publikovali sme to napr. na slovensko.digital aby to každý videl LOD Slovakia (Linked Open Data Cloud) - #2 by liska
Som presvedceny, ze aj tieto udaje bude mozne upravit. Uz od minuleho roku ziadame posilnenie kapacit, pricom sme aj podali aj nejake projektove navrhy. Ak by daco vyslo, snad na to bude priestor. Bohuzial momentalne musime riesit riesit prioritnejsie ulohy.
navyše, teraz v rámci K9.4 navrhujeme, aby vydávanie URI bolo v kompetencii jediného metainformačného systému verejnej správy a to Centrálneho metainformačného systému, a myslím že v tomto je aj logicky podpora, aby skrátka boli aj dáta, aj metadáta sémanticky interoperabilné s ostatnými referecnými registrami, aj s ontológiami INSPIRE Len pre uplnost. Tie INSPIRE ontologie, vo ci ktorym su natransformovane udaje na https://data.sazp.sk/dataset taktiez nie su jedine a zavazne, aj ked vidiet, ze sa Europska komisia snazi aj o vyvoj nastrojov v tejto oblasti (LD proxi).
, aj s ontológiami ISA2 napr. atď … čiže obzvlášť rád tu by som sa chcel vyhnúť potrebe,aby ste museli publikovať aj mapovacie datasety na referenčné URI. Bližšia informácia o zmenách v dokumente K9.4 je napr. tu: MIRRI Pracovná skupina K9.4 Lepšie dáta - #63
čo s tým teraz?
Ponúkam, že im zadarmo (zdôrazňujem) pomôžem nahodiť do RPI prvky tak (spracujeme krátku kuchárku na URI), že sa zaregistrujú do MetaIS, a súčasne i do RPI. Nech sa v RPI vypne validácia URI (lebo to nepĺňa bod 1), a bude to OOK. Keď začne metaIS poskytovať službu registrácie URI automatizovane, tak sa to do RPI môže dopracovať.
Super, velmi radi vyuzijeme tuto ponuku a za seba pomozem, kde to bude mozne. Zriadis tu na SD platforme nejaky priestor, alebo to mam urobit ja, alebo niekde inde, aj ked tu je vyssia sanca na prispevok z komunity?
Vdaka, m.
miro
Od: Martin Tuchyna [martin.tuchyna@sazp.sk]
Odoslané: 17. februára 2017 8:53
Do: Líška Miroslav; Martin Koska; Peter Mozolik (SAZP); Radoslav Chudý; Peter Hanecak; Ján Tóbik
Predmet: Ad identifikator a URI v RPI vs Meta is
Zdravim vospolok
koncom minuleho tyzdna ma Miro Liska upozornil, ze struktura identifikatorov a suvisiacich URIs nezodpoveda legislativnym poziadavkam Vynosu ISVS.
V zmysle uvedeneho by som Ta chcel Miro poprosit, aby si nam upresnil, kde presne RPI nie je v tejto oblasti v sulade s Vynosom, pripadne inou legislativou.
Pre jednoznacnost niekolko klucovych “URI related” informacii:
RPI v sucasnosti poskytuje moznost/povinnost vytvorit jedinecne identifikatory na baze URI pre nasledovne koncepty:
súbor priestorových údajov (dataset)
série priestorových údajov (súbor datasetov)
služby (aplikačná služba v zmysle MetaIS)
metaúdaje popisujúce vyššie uvedené koncepty
Tieto identifikatory sa vytvaraju v nastroji s nazvom MetauDajovy Editor (MDE) .
Ten ma dve instancie:
MDE - dostupný cez verejnu cast - bez potreby registracie a prihlasenia
MDE - dostupny cez cast prispievatelov - tu je potrebna registracia a prihlasenie
V 1.MDE je mozne identifikatory volne upravovat, nakolko ucelom tohto nastroja je umoznit zaujemcom vytvorit metaudaje, ktore si nasledne uloza pre svoje potreby (tieto metaudaje sa neukladaju do RPI a preto nie su v rezime kontorly IDs a URIs)
V 2.MDE je vyssia kontrola , kde je prva cast URI pod spravou RPI (pre zachovanie jedinecnosti mennych priestorov) a jediny editovatelny priestor je pre samotne identifikatory, ktore musia pridelit tvorcovia metaudajov, nakolko oni su vlastnici/spravcovia popisovanych zdrojov.
Spominal si https, strukturu uri ako aj skutocnost, ze URIs by mal generovat MetaIS.
Mozes nam prosim upresnit, co je z toho uz legislastivne zavazne a procesne nastavene a co je vo faze pripravy?
Ako som Ti spominal, je nasim zaujmom zabezpecit sulad nie len s legislativou ale aj s poziadavkami praxe, predovsetkym v ramci vyuzitia metaudajov a v buducnosti aj samotnych udajov a sluzieb nielen pre potreby INSPIRE, ale aj eGov a Open Data. Kde to bude mozne samozrejme radi podporime spristupnenie udajov aj prostrednictvom technologiii semantickeho webu, ale tiez mame urcite priority a kapacitne a financne limity.
@mtuchyna navrhujem, ty ako gestor z domény , sprav plís nové vlákno na štýl URI entít životného prostredia (alebo Zelené URI ) , alebo SK Environment Linked Data, alebo niečo podobné.
tam môžeme sústrediť diskusiu o RPI & MetaIS & ISA2 & INSPIRE & SK GOV LINKED DATA
začal by som s tým, že to čo je v LODe, cca. 9 enviro-datasetov, tak tie poďme nahodiť do RPI. Do MetaIS je to pripravené, dátové prvky sú sústredené do Ontológie entít životného prostredia.
mr. @jsuchal , prosím o premenovanie vlákna
URI aj jeho dereferenciácia
na
Jednotné URI subjektov RPO
je to presne ten problém, bude to ešte na dlhšie, je to viac zapeklité ako by sa zdalo. prečo majú niektorý podnikatelia IČO a nie sú organizácia, ani právnická osoba ??? je štátna organizácia právnická osoba?
Ahojte, v čom presne je problém? Prečo chcete ísť z https na http? Nie je možné radšej updatnúť staré normy, ktoré spomínajú http, ako sa vracať na starú, nezabezpečenú, legacy technológiu?
Viete, kedysi sa masovo používal telnet, ale nebudeme sa hádam vracať z dnešného SSH-čka nazad len kvôli tomu, že kedysi proste staré normy nemohli reflektovať stav internetu v roku 2017?
Prosím nerobte takéto zmeny. Ja keď získam dáta z data.gov.sk, chcem vedieť, že 1) niekto nebude po ceste sniffovať môj traffic, 2) niekto ho za jazdy nezmení a 3) data.gov.sk je naozaj data.gov.sk (aspoň podľa tvrdenia certifikačnej autority).
Pre info: The HTTPS-Only Standard - Migrating APIs to HTTPS – “All new APIs should use and require HTTPS. Rather than issue a redirect when visited over HTTP (redirects within APIs are problematic, as outlined below), the API should likely return an error message (such as the HTTP status code 403 Forbidden).”
Problem je v tom, ze kopa lamerov si nevie nastavit klientov tak aby im vedeli citat ssl… ale to asi bokom. Optimalne by podla mna bolo mat moznost potiahnut si info zo systemov aj cez http aj cez https.
Nikto z nás nechce ísť na žiadne staré normy, alebo čo Naopak, ide nám o tech na plech.
Pri návrhu štandardov pre tvorbu URI sme samozrejme vychádzali z odporúčaní EÚ, konkrétne sa jedná o dokument 10 rules for persistent URIs.
Budeme veľmi radi keď si podrobne pozriete ten dokument. Tu je z neho prvý obrázok:
Takže tu by som moc nehovoril o zastaralom prístupe. URI nie je to isté ako URL. V rámci grafovej databázy je to vnútorný identifikátor ako každý iný, ktorý je analyticky abstraktný od spôsobu implemtácie (protokolu prístupu). Tu by som možno poprosil @msurek aby sa tiež vyjadril, či sa to takto dá interpretovať.
Tak či onak, dôležité pre informatizáciu aj je, aby sa štandardy neignorovali, a keďže ako som uviedol, naše návrhy nie sú vycucané z prstu, dávno sme ich vypublikovali, chvalabohu sa prijali hoc zatiaľ len prvotné idei, som si istý že sme na správnej ceste.
Budem trochu za spiatocnika teraz. Naozaj nevidim velku pridanu hodnotu v tom, ze pouzijeme nejake RDF, ontologie alebo linked data. Skusim spravit krok spat a najst pointu ako ju vidim ja;
Potrebujeme si dohodnut nejaky sposob unikatnych identifikatorov a referencovania. Ci to bude uri, typ + id alebo nebodaj guid (neodporucam) je nepodstatne.
Potrebujeme si dohodnut nejaky standard pre spolocne datove prvky = schema. Ci to bude json schema, ontologia alebo nebodaj len sql schema (neodporucam) je nepodstatne.
Potrebujeme si dohodnut nejaky standard ako z tohto idecka budem vediet ziskat samotny datovy prvok. ci za tym bude RDF/xml/json je nepodstatne.
Mne sa zive URI ako identifikator datovych prvkov, ktore riesi viacero tychto problemov velmi paci. Samotne linkovanie/prepojene data nie je podla mna nic nove. Mame tu referencne registre a to su de facto a de jure linkovane data platne uz dnes. Do neceleho roka by mali vsetci nabehnut na pouzivanie referencovania RFO, RPO a dalsich vyhlasenych ref. registrov. URI ako identifikator vidim len ako celkom fajn sposob na implementaciu tohto ciela.
Zase vsak ci za tym bude nejaky RDF inference engine, SPARQL, federovane queries by som nateraz nechal tak. Disclaimer: Tomuto som sa chvilu venoval pocas mojej davnej akademickej kariery a veruze odvtedy som realnych pouziti vela nevidel. Viem presne co to vie, ale vnimam to ako velmi uzky scenar a malu pridanu hodnotu pre problemy egovu dnes ci v 2020.
Cela debata o tom ci ma ta URI pre RPO byt taka ci onaka mi pride dost uletena mimo a velmi marginalna. Pre nove subjekty nie je problem uri vo formate https://corporate-body…/ico123 - kedze po novom by to mal SU vydavat cez RPO uz unikatne bez kolizii. Netusim ako su na tom so znovupouzivanim starych ICO.
Vedeli by ste @liska a @msurek ukazat konkretne riesenie pre nejake subjekty, ktore maju toto:
Rozne casy = rozne ico na zahriatie
Rovnaky cas = rovnake/kolizia ico ako bonus.
Subjekty co nemaju ICO = ano aj takych je v RPO dost.
A ked to vymyslite, tak mam otazku ci tento novy identifikator ma nejaku oporu v zakone o egov?
Fun fact: ICO je autoincrement tiez, len posledna cifra je checksum.
@liska Co sa tyka toho http vs https tak to ma dve roviny. Ako pises URI nie je URL. Na druhej strane je v zamere prave vyuzit URI a dereferencovat ho na zaklade integracie s data.gov.sk. Tym padom zacina mat https realny zmysel. Nakolko teraz standard vznika, je najvhodnejsi cas sa zamysliet ze ci stare http nezatratit a radsej neprisposobit standard modernej dobe
@jsuchal
Po technologickej stranke s tebou uplne suhlasim i ked to nebude take uplne ciernobiele.
Suhlas, kazdopadne je fajn mat aspon nejaku metodiku aby z toho nebol uplne bordel. Technologicky to v principe je jedno, ale pre potreby registracie URI, datasetov, cohokolvek je vhodne mat nejaky pattern aby si niekto vedel registrovat namepace a mal tak garantovanu unikatnost.
Ano, serializacia je znova v principe jedno. Otazka skor znie, ked sa vsetci zhodneme ze URI, nie je vhodne na datove prvky pouzit taky sposob, ktory s URI nativne pracuje + graf ako strukturaje hodne volna?
Ano, dereferencia a jej content type je jedno. Momentalne navrhujeme aby bol MetaIS integrovany s data.gov.sk a ked clovek zada URI datoveho prkvu do browsera, tak bude redirectovany do MetaIS, kde bude jeho kompletny popis. Ak mas nejaky iny napad, co lepsie by sa dalo tak navrhni.
Ja si osobne nemyslim ze by ani bolo vhodne aby sa nejako masovo prechadzalo na triplestory. Pointa je v tom pouzivat jednotny popisny jazyk na danu vec urceny ktory je mozne pouzit v principe v akomkolvek db engine. Zhotovitel nech sa sam rozhodne ze v com sa mu najlepsie robi a co je pre dany usecase najvhodnejsie. Vyhoda je v tom, ze z grafu, ktory je linkovany cez URI a standardne datove prvky vies velmi jednoducho spravit transformaciu dat ci uz do relacnych db, dokumentovych, key-value, alebo inych db storage. Preto suhlasim ze datovy standard nesmie predpisovat finalne implementacne riesenie a musi pouzivat taku schemu aby sa to dalo lahko “vyexportovat” do pozadovaneho uloziska.
Co sa tyka tych danych cases a sposobov na riesenie :
Existovali by tak viacere URI firiem, ale nakolko su tie iste tak by boli spojene s mapovacim vztahom owl:sameAs
Z toho co som sa bavil so statistickym uradom, tak tieto pripady by mali byt docasne s tym ze kazdy jeden sa individualne riesi tak aby sa register precistil. Tu je hlavne dolezite povedat, ze “URI template/namespace” by si registroval v MetaIS samotny RPO a on je zodpovedny za korektnost a unikatnost dat. Takze na tejto urovni to musi vyriesit samotne RPO a nasledne aj vsetci integracny partnery, ze maju bordel v DB. Ak by to nebol ale referencny register tak by to bolo tak ze http://orsr.sk/123456 a potom http://zrsr.sk/123456 maju rovnake ICO, ale rozdielne URI. Zaroven ma kazdy z nich na sebe zaveseny adms:identifier ktory reprezentuje identifikator ICO co by bolo vlastne rovnake no zaroven by bolo v mapovacom datasete napisane ze http://orsr.sk/123456 owl:differentFrom http://zrsr.sk/123456 aby sa to nedalo zlucit. Kazdopadne, RPO v case vypublikovania je povinne mat konsolidovanu a upratanu DB. Inak slovo REFERENCNY bude nasmiech.
. Takto toto radsej ani nebudem komentovat, ze ako toto vobec mohlo nastat. Kazdopadne neviem co presne je to za problem tak sa neviem vyjadrit. Ide o to ze ani nemali pridelene ICO ale mali mat a tak sa im dodatocne pridelia? Na toto by som sa rad spytal stastistickeho uradu ze co s tym robia pri cisteni dat a podla toho by sa zvolil postup.
V sucasnosti nema taku poziciu v zakone, a preto sa snazime pocas standardizacie co najviac problemov vychytat a spisat aby sme si boli isti ze sme v stave pre ktory je toto riesenie odladene. Nie je podla mna vhodne hura systemom nieco tlacit do zakona ak sa nepreukaze ze dane riesenie je dobre. @liska sa ich sem snazi aj vzdy postnut aby sa k nim mohol vzdy ktokolvek vyjadrit a pripomienkovat.
Rad by som si k tomu mozno aj sadol a cele to presiel osobne. Vela navrhov totiz stoji na transformacnych mechanizmoch aby sa “zivot vyvojara” zlepsil a chceli to pouzivat. Napr. mapovanie XSD schem na datove prvky vyjadrene cez URI a popisane cez ontologie a tak budu moct zbiehat validatory vyznamu nad samotnymi XSD schemami popripade navrh standardizovat dokumentaciu rozhrani napr. cez XSD, Swagger, … no vzdy bude musiet premapovat tie prvky na datove prvky cez “owl:sameAs/rdfs:subPropertyOf/rdfs:subClassof”. Jednoduchy priklad pre pochopenie. Bolo by zavedene ze MetaIS by bol primarny registrator eformularov s tym, ze by registroval formular, vytvoril URI a to poskytol MEFu a on by s nim pracoval tak ako dnes. Priklad schemy
Ako je vidiet, tak mapovanie pri prebiehalo cez URI prvkov v scheme s datovymi prvkami definovanymi cez ontologie, takze developer si pomenovava prvky ako chce, nakonci dna ale musi spravit premapovanie na datove prvky a tak kazdy vie o com formular je a zaroven je mozne potom tieto prelinkovania veci pouzit pri vyhladavani napr. na tragickom slovensko.sk. Existuje viacero navrhov, napr. ze mapovanie by bolo sucastou XSD schemy, alebo externe sposobom ako som hore ukazal. Este taka drobnost, naschval som napisal do schemy ze name je xsd:dateTime, tym ze by ale existovalo mapovanie s datovym prvkom tak by mohol existovat validator, ktory by odhalil ze formular je zly.
Moj osobny ciel je pomoct priniest poriadok do verejnych dat a uprimne verim, ze URI idea a grafova reprezentacia spolu s velmi prisnou ale flexibilnou standardizaciou a dohladom ma potencial veci pohnut spravnym smerom.
+100. Presne tak. IMHO by bola škoda nevyužiť príležitosť dať tam https. Inak aj ten dokument EÚ, ktorý spomína @liska ako referenčný / best practice, spomína (ak to nečítam zle), že napr. takí Estónci používajú pre URI pri novších systémoch https (pri niektorých je URI s http). Ak sa robia nové štandardy, tak poďme ich písať ako v roku 2017 a použiť jednotné URI/URL s https.
Anekdota o URL: Keď sa robil redizajn data.gov.sk a navrhol som v pripomienkach, aby všetky dáta išli len cez https, bola voči tomu silná opozícia. Že vraj na čo, že to zbytočne spomaľuje a že sú to otvorené dáta, tak načo ich vlastne šifrovať (vlastne je jedno, či mi ich posiela štát alebo útočník a čo by sa mal štát trápiť, že mi niekto môže sniffovať traffic a prečo by sa mal štát trápiť tým, že bude enforcovať nejaké základné bezpečnostné štandardy). To sme riešili transport dát, takže to neboli nejaké akademické diskusie o URI.
Teraz máme príležitosť povedať si, že URI aj URL budú jednotné, s https protokolom. K tomu otázka: Aký je reálny benefit toho, že by sme dali http pri systéme, ktorý vzniká “from scratch”? Čo tým pokazíme, rozbijeme, nesprávne implementujeme, atď.?
Mne sa navrhovany sposob URI a referencovania velmi pozdava, dokazalo by to vyriesit viacero problemov naraz a mam pocit, ze by to nebolo ani take narocne.
Ako jeden z najvacsich prinosov ziveho URI vidim, ze by na jednoznacnom mieste mohla byt ulozena vsetky zdroje a dokumentacia (alebo aspon referencia na nu) k prislusnym prvkom/sluzbam/atd.
No a ontologie, je pravda, ze to je na svete pomerne dlho a zatial sa to vyrazne nepresadilo, ale na druhu stranu od referencovatelnych URI nie je uz k linked data daleko. Na Slovensku bola vzdy v dokumentoch vizia dobehnut (ak nie predbehnut) v informatizacii lidrov, lenze asi nikdy to nebolo realne. Ale uz len keby sa zacalo poriadne pouzivat URI, tak myslim ze veci by sa pohli dopredu a vytvorilo by to potencial na zjednodusenie integracie a vyvoja novych sluzieb.
Linked data by stalo za to vyskusat to, mam taky pocit, ze z hladiska ceny/prinosov to je ovela menej rizikove ako niektore grand projekty navrhovane v sucasnych strategickych prioritach…
K diskusii o http/https, ak to dobre chapem tak problem je iba v tom, ze vo vynose je napisane http, ale asi by bolo vhodne zmenit to na https, kedze aj data.gov.sk aj metais.finance.gov.sk funguju na https?
Cize za seba vyjadrujem zavedeniu URI velku podporu. A dalsie veci (linked data) su very nice to have.
V otázke ako bude vyzerať identifikátor je mi jedno či tam je na začiatku o písmenko “s” menej, alebo viac. Prosím zvážte, že _ne_tvoríme úplne nový štandard, http je vo výnose o štandardoch už 3 roky - jednak treba zmeniť výnos, to je realisticky splniteľné tak o pol roka, dvak už sú implementácie kde sa používa http.
Pokiaľ ide o dostupnosť údajov, za dôležité považujem aby boli dostupné http aj https, v zmysle že po zadaní URL sa mi nezobrazí chyba (čiže napr. automatický redirect je v pohode).
Bezpečnosť prístupu k údajom, je to v pohode riešiteľné z hocakými URL, resp. bez poriadneho riešenia bezpečnosti samotné URL veci nezachráni, viď. HSTS
Pokiaľ ide o automatické dereferencovanie URI, pri nákladoch ktoré doteraz v štátnych projektoch na tieto veci boli kalkulované, som proti tomu aby sa robil nový veľký projekt len na túto vec.
Podstatné zlepšenie môže používanie dobrých identifikátorov priniesť najmä do G2G zdieľania údajov. Viď. aj návrhy čo som písal tu vo vlákne v novembri. Sústreďme sa na túto vec, nie je to ľahká úloha, za posledné roky sme sa v nej prakticky skoro nepohli (videl niekto z vás nejaké URI v CSRÚ, či integračných rozhraniach?).
To, ze je tu je 3 roky neznamena ze je vseobecne rozsireny a zadratovany. Samotny navrh hovori, ze URI by sa stalo referencnym az po zaregistrovani a odsuhlaseni v MetaIS. Dovtedy je to “iba” URI, ktore nepodlieha novej metodike, ktora sa medzicasom vypracovala a vyladila. Zatial ziadny prvok/URI nesplna dany navrh a preto si myslim ze je stale este priestor to upravit. Ako sam vravis, planuje sa novela a je mozne to zapracovat.
Ano, automaticky redirect je v pohode. Zaroven ako pisem, stale je podla mna priestor to zmenit bez vyraznych problemov a tak nebude potrebne vobec ziaden redirect riesit.
Neviem kto tu hovori o velkom projekte na dereferenciaciu, a ja som ani ziadnu kalkulaciu nevidel.Ak o niecom vies tak to sem postni. Podla mna je skor velky svojim prinosom ako cenou. Pre mna osobne je klucove aby boli v prvom kole dereferencovane IBA URI ktore su/maju byt registrovane v MetaIS tj. datove prvky, sluzby, formulare. Uz aj toto by bol obrovsky uspech dosiahnut. Podla mna dana integracia MetaIS vs data.gov.sk nemoze stat giganticke peniaze, ved pojde iba o sluzby na strane MetaIS, ktora bude len blbou key-value mapou kde ak sa nachadza dany kluc tak posli na data.gov.sk, kam sa ma redirectovat, inak posli 404. Si ani neviem predstavit ze by za take nieco chceli 5m. - teda to predpokladam ze povazujes za velky projekt.
To ze v CSRU nie je si myslim ze treba tiez riesit a pretlacit to tam ale z toho co o tom viem si myslim ze to nie je ani zdaleka jediny problem ktory maju. Takisto aj integracne rozhrania, ale v prvom kole to musi byt akceptovany a vynutitelny standard a MetaIS na to musi byt pripravene aby zvladalo svoju ulohu. Neviem preco ale tolko pesimizmu, sam si za tieto veci, sam si uvedomujes ich prinos a vsetci si uvedomujeme ze sme na zaciatku a treba s tym zacat. Urcite treba ale nie hura systemom, ale systematicky vybudovanim zakladnych pilierov a to uz ako v zakone tak aj na SW casti s centralnym riadenim a standardizaciou tj. integracia na data.gov.sk vs MetaIS, MetaIS vs MEF, MetaIS a CSRU, MetaIS a referencne registre ako RPO, RFO… Ano, zo dna na den to nepojde. Ale urcite nepodporujem zivelne pouzivanie URI kde si kazdy registruje URI ake chce a je v tom bordel hned nazaciatku.
skutočne mám rád, keď sa veci hýbu, keď sa zlepšujú. Veď to poznáte “Chceli by ste radšej krásne červené audi, alebo 1000 riadkov dobrého kódu?”
Tie štandardy tu zverejňuje už veľmi dlho, milión človeko/hodín som strávil ich nahadzovaním do MetaIS (hoc iba ako návrhy), 500xsom ich prerábal, snažil sa konzultovať. A keď už všetko vyzeralo fajn, tak mi, drahí veriaci, nabúrate metodiku. Že https…
Lenže život je niekedy bitch, že?
OOK teda, chápem že kvoli dereferenciácii URI má zmysel asi uvažovať o https. Naše ontológie, či celý LOD Slovakia updatnem bez väčšej námahy, ale ten milovaný MetaIS, to bude teda effort. Skúsim to vyriešiť, či by sa to nedalo “updatnúť” cez backend, uvidíme.
Priatelia, @jsuchal, @Lubor, @panda, @jangondol, kedže ste videli, že sme ti tie URI naozaj nevymysleli len tak, že sme sa to snažili robiť tansparentne ako sa len dalo, že sa naše dáta veľmi budú podobať na trendy v EÚ (proti ktorej snáď moc nemáte), viete si predstaviť, že by ste metodike tvorby data.gov.sk URI, ktorú updatneme vlastne o https:// aspoň dali šancu pozrieť si ju? Vysvetliť si ju?
Kľudne k Vám dobehneme, za pár dní tu publikujeme LOD Slovakia 0.9.8 (kde budú ontológie, referenčné dáta, atď …) aj s vyhľadávačom (hoci iba light).
Teraz je šéfom PSx @stefan.szilva a myslím že on taktiež chce, aby sa štandardy prijímali po širokom konsenze, pretože inak to to nebude fungovať. Myslím že Štefan tým že nás historicky pozná ako za LinkedData bojujeme, vie nás podporiť, hoc nie na 100%, viď problém s URI pre subjekt RPO. To bude ešte len zaujímavé, takže šup sa do príslušného vlákna.
Aj pre toto sa dá spraviť regex transformácia RefId → URL.
V tomto príklade vidno, že MetaIS je na deref. dokonca horšie pripravený ako MEF ÚPVS… (prečo?)
Vyššie uvedené som sem dal aj ako príklady vecí kde už to nejako zadrátované je. Napr. formuláre, ktoré už boli podpísané/podané sa nedajú spätne zmeniť. Vzory formulárov sa dajú iba aktualizovať na novšie verzie (kde by bolo iné RefId), staré musia zostať tak ako sú.
Keď už sme pri tých anekdotách, pri el. formulároch som osobne sledoval tzv. bodkovo-lomítkovú vojnu, kde sa riešilo “iba” či sa komponenty podtriedy RefID odďeľujú pomocou “.” alebo pomocou “/”. Každá strana to mala implementované inak a tvrdili že prerobenie je extrémne náročné. Jedna strana konkrétne deklarovala, že zmena u nich “bude vyžadovať 100 MD práce”.
Písal som “zvážte že…” a tak som to aj myslel.
Kďeže pesimizmus. Iba by som rád upriamil pozornosť na kľúčové veci.
Ano, ale nakolko sa dereferenciacia aj URI nezacali masivne pouzivat. Je mozne to teraz podla mna este zmenit na https a neriesit redirecty hned nazaciatku.
Ano, aj toto riesenie je v equivalentne. Predpoklada ze sa prerobi komplet routovanie na MetaIs, ktore nanestiastie hentak nie je. Ak to chceme rozvinut ako by neskor mohla vyhladovo fungovat dereferenciacia, tak znova najjednoduchsie riesenie by fungovalo nasledovne :
Kazdy by mal povinnost registrovat URI tj. ci datovy prvok, sluzby, formular, alebo namespace na MetaIS. Toto je mozne dosiahnut vyhlasenim MetaIS ako referencneho registra pre URI.
Pouzivatel by hodil do browsera https://data.gov.sk/id/corporate-body/123456 . Nakolko MetaIS pozna https://data.gov.sk/id/corporate-body/{id} namespace mohol by nastat takyto scenar:
Pri registracii namespace by bola moznost registrovat ja redirect URL tj. RPO by si definovalo ze napr. toto je ich redirect pattern http://rpo.sk/prezentovatelne-view-rpo-entity?uri={uri} a MetaIs by sluzil len to len redirectlo.
Kazdopadne toto myslim ze zatial nie je na “pořadu dne”, ale je pekne vediet ze dereferenciacia moze prebiehat postupne, nenasilne a nemusi byt z toho ziaden jeden mega projekt ale vzdy len mozne rozsirenie nejakeho projektu ak sa ukaze ze pri nom ma dereferenciacia fungovat lebo ma zmysel.
Ak by pouzivatel zadal iba https://data.gov.sk/id/corporate-body/ tak sa zobrazi na stranke MetaIS kto je registratorom daneho namespace atd
data.gov.sk by spravil len redirect na MetaIS.
Na strane MetaIS by sa spravil jednotny sposob redirectingu co nemoze byt az take narocne a urcite tato funkcionalita nemoze stat milony.
Co sa tyka tych formularov, ktore ako jedine asi realne zacali pouzivat URI. Metodika by bola jasna
URI sa stava referencne a referencovatelne az po zaregistrovani namespace v MetaIS a jeho schvaleni
elektronicke formulare sa musia prioritne registrovat v MetaIS, ktore vygeneruje URI a to dalej pouziva MEF ako identifikator fomularu.
existovala by povinnost kazdeho subjektu poskytnut na poziadanie mapovaci set na referencne URI
Neviem najst konkretne formular, ktory si poslal na MetaIS, ale v principe napr. formular http://data.gov.sk/doc/eform/37861298.ZiadostOPoskytnutieDotacieNaPodporuCestovnehoRuchuPO.sk
na metais url: https://metais.finance.gov.sk/detail/Formular/bb94d0c7-6302-4b49-ac3f-3d05cd0a4d33/cimaster?tab=basicForm
je vidiet ze aj MetaIS mu pridelilo kod “formular_879”. Tym padom pri registracii formularu by MEF zavolal integracnu sluzbu MetaIS a ten by mu vratil http://data.gov.sk/doc/eform/879 a s tym by robil MEF dalej interne. Odbural by sa tak problem tych haluznych URI a sporov a bodky a ciarky, kazdy si tam dava take sialene nazvy ze az a podobne blbosti a mohla by aj nabehnut derefenciacia a aj validaci (vid vyssie prepojenie XSD a URI). Proste vsetko zacne spolu hrat. Co sa tyka prechodneho obdobia, tak tam tiez nie je problem lebo je mozne jednoducho vygenerovat mapovaci dataset na nove URI ktory by fungoval pocas prechodneho odbobia kym by sa postupne formulare nenabiehali na tento zjednoduseny sposob.
Pripravenost MetaIS na URI. Existuju mechanizmy na schvalovanie a standardizaciu URI co je podla mna klucove. Momentalne treba spravit N mensich adresnych zmien aby to cele zacalo fungovat globalne nakolko sa nasli oblasti kde je jednoznacne ze MetaIS nie je este kompletny pre tuto oblast. Na tvoju otazku preco odpoviem asi nasledovne. O inych ludoch povedat neviem. Nebol som tam ked sa o tychto veciach rozhodovalo a za inych povedat neviem. O MetaIS som sa dozvedel ked uz finishovala jeho implementacia a podarilo sa tam dostat na poslednu chvilu standardizacia URI co vzhladom na to v akej faze projekt uz bol povazujem za velky uspech. V tej dobe (koniec 2015) uz OPIS finishoval a NIKTO sa do ziadnych systematickych a radikalnych zmien nechcel pustat.
Momentalne sa OPII zacina a je tu moznost zacat veci robit systematickejsie s tym ze jednoznacne treba mat aj plan na prechodne obdobia. To ale nastava vsade pri referencnych registroch, kde je povinnost ich zacat pouzivat. Treba podotknut ze pri MetaIS uz nehovorime o novom registry, ale o doladeni tak aby mohol vystupovat ako referencny a nemohlo tu nastat znova taky bezpravny stav. Vela veci sme pri navrhu zvazovali a navrhujeme docasne riesenia, ktore pomozu preklenut obdobie prechodu.
Velmi rad si prejdem konkretne opatrenia aj osobne. Kludne ich mozeme prekonzultovat a najst riesenia, ktore budu systematicke, nebude nutny ziaden mega projekt.
Len potom by mohol niekto pre tú istú entitu začať používať URI s http:// a iný z https:// a to by bol totálny záhul na reasoner po stotožnení. To radšej jedno, alebo druhé.
V tomto príklade vidno, že MetaIS je na deref. dokonca horšie pripravený ako MEF ÚPVS… (prečo?)
Podla mna preto, ze nebol nikto na strane zakaznika (MFSR) ani druheho stakeholdera (data.gov.sk-NASES) kto by o to prejavil zaujem…
A zase mapovanie URL nemoze byt tazke spravit, ved to ma kazde dobre CMSsko, nebol by to ani velky budget.
Inak prave na taketo male veci/vylepsenia, ktore sa nedaju/nerobia v ramci prevadzky (napr. do 100k), a ktore by dokazali niekedy pomerne zasadnym sposobom zlepsit existujuce projekty, tu chyba budget.
z domény , sprav plís nové vlákno na štýl
) , alebo SK Environment Linked Data, alebo niečo podobné.
. Takto toto radsej ani nebudem komentovat, ze ako toto vobec mohlo nastat. Kazdopadne neviem co presne je to za problem tak sa neviem vyjadrit. Ide o to ze ani nemali pridelene ICO ale mali mat a tak sa im dodatocne pridelia? Na toto by som sa rad spytal stastistickeho uradu ze co s tym robia pri cisteni dat a podla toho by sa zvolil postup.