URI a jeho dereferenciácia (z diskusie k PS Lepšie dáta)

@mtuchyna navrhujem, ty ako gestor :wink: z domény , sprav plís nové vlákno na štýl
URI entít životného prostredia (alebo Zelené URI :sunflower:) , 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?

1 Like

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

Zrejme viete aj o tomto: Google Chrome gets ready to mark all HTTP sites as 'bad'

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).”

2 Likes

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

V tomto dokumente odporúčajú pravidlá na URI v tomto duchu:

No ak keď sa pozrieme na naše navrhnuté štandardy otvorené a prístupné cca od 2013, tak tu môžete vidieť veeeľkú podobnosť

Takže tu by som moc nehovoril o zastaralom prístupe. :wink: 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;

  1. Potrebujeme si dohodnut nejaky sposob unikatnych identifikatorov a referencovania. Ci to bude uri, typ + id alebo nebodaj guid (neodporucam) je nepodstatne.
  2. Potrebujeme si dohodnut nejaky standard pre spolocne datove prvky = schema. Ci to bude json schema, ontologia alebo nebodaj len sql schema (neodporucam) je nepodstatne.
  3. 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:

  1. Rozne casy = rozne ico na zahriatie
  2. Rovnaky cas = rovnake/kolizia ico ako bonus.
  3. 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.

2 Likes

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

  1. 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.
  2. 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?
  3. 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 :

  1. Existovali by tak viacere URI firiem, ale nakolko su tie iste tak by boli spojene s mapovacim vztahom owl:sameAs

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

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

<xs:schema targetNamespace="http://data.gov.sk/id/eform/123456/{verzia}" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://data.gov.sk/id/eform/123456/{verzia}">
<xs:complexTypename=“Person">
    <xs:sequence>
        <xs:elementname=“name"type="xs:dateTime"/>
    </xs:sequence>
 </xs:complexType>

Príkladmapovania cez MetaIS:

<http://data.gov.sk/id/eform/123456/{verzia}/Person/name> owl:sameAs|rdfs:subClassOf <http://data.gov.sk/def/ontology/physicalperson/name>
<http://data.gov.sk/id/eform/123456/{verzia}/Person> owl:sameAs|rdfs:subClassOf <http://data.gov.sk/def/ontology/physicalperson/PhysicalPerson>`

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.

1 Like

+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ď.?

2 Likes

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.

1 Like

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

1 Like

Drahí priatelia,

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?” :wink:

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? :cry:

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?

tj. túto:
https://wiki.finance.gov.sk/pages/viewpage.action?pageId=16416838

z aktuálnej platnej tejto:
http://www.lewik.org/term/3328/standardy-pre-referencovatelny-identifikator-standardy-pre-is-verejnej-spravy/

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.

Mozno mimo misu, ale nestacilo by niekde v dokumentacii povedat ze URL dostaneme z URI transformaciou protokolu na https?

Čiže začiatok (rovnaký pre každý projekt) by mal byť takýto:

  1. v rámci riešenej domény sú určené dátové objekty
  • najmä tie, ktoré majú byť referenčné
  • majú vizuálnu reprezentáciu
  • majú strojovú reprezentáciu
  • v štandardizovanej štruktúre
  • majú jednoznačný referencovateľný identifikátor
  • z ktorého sa dá automatizovane generovať URL
  • na tomto URL je dostupná minimálne vizuálna reprezentácia

Kľúčový pre deref. je bod 7. Napr. taká “aplikačná služba Vydanie rozhodnutia o ročnom poplatku za malý zdroj znečisťovania ovzdušia” má v MetaIS teraz RefId http://data.gov.sk/id/egov/app-service/53807 , ale dostupná je na URL https://metais.finance.gov.sk/detail/AS/1acf61b6-6838-49b1-a928-6c0563c1b0a1
Stačilo by teda doriešiť aby fungovalo URL povedzme https://metais.finance.gov.sk/refid/id/egov/app-service/53807 ako redirect na terajšiu URL, a potom na data.gov.sk zaviesť redirect
http://data.gov.sk/id/egov/* → https://metais.finance.gov.sk/refid/id/egov/*

Ináč elektronické formuláre sú teraz registrované v “module elektronických formulárov” ÚPVS, viď. §10.8.
Povedzme taká “001.Žiadosť o odpustenie/zníženie poplatku za komunálny odpad a drobný stavebný odpad (FO)” má aktuálne RefId http://data.gov.sk/doc/eform/00321796.A0000224.000000002.ZiadostOdpustenieZnizeniepoplatkuZaKOaDSO_FO/1.4
vizuálna forma je dostupná na URL https://formulare.slovensko.sk/_layouts/eFLCM/DetailVzoruEFormulara.aspx?vid=00321796.A0000224.000000002.ZiadostOdpustenieZnizeniepoplatkuZaKOaDSO_FO&vh=1&vl=4
a strojová forma na URL
https://formulare.slovensko.sk/_layouts/eFLCM/GetEFormArtefact.aspx?ac=5&vid=00321796.A0000224.000000002.ZiadostOdpustenieZnizeniepoplatkuZaKOaDSO_FO&sid=&vh=1&vl=4

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 :

  1. 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.
  2. Povedzme ze RPO si zaregistruje v MetaIS pre svoje instancie namespace https://data.gov.sk/id/corporate-body/{id} . Redirect z data.gov.sk by mohol byt pausalny tj. https://data.gov.sk/id by bol vzdy redirectovany na https://metais.finance.gov.sk/refid/id/ .
  3. 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.

2 Likes

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.

2 Likes

Hi, apologies for the use of English in a non-English forum, but I had some dialogue with Jan Gondol about this, and he encouraged me to share my views here. Below is a slightly adapted version of an email I sent him about it.

For context, I work for the US government’s General Services Administration, and I help oversee the implementation of an HTTPS-only mandate for publicly accessible US government web services (details at https://https.cio.gov).


I strongly encourage you to move away from http:// for the use of URIs, even though they are not intended to be used as URLs.

While I understand that URIs are not URLs, the use of http:// for XML namespaces and DTD definitions, and the severe friction that has resulted in migrating open data services to use secure connections, has polarized me a bit on the subject.

For some context, see this discussion about proposing an exception to the US government’s HTTPS-only mandate for XML/DTD URIs:

I have read arguments by the linked data community – in particular Tim Berners-Lee – that mixing semantics around transport with URI namespacing is a mistake. I agree with that, but unfortunately this mixing is already present even when using http://. People seemed to choose http:// for URIs as a convenience rather than inventing something new, and I think that’s proving to be a mistake.

I have also seen arguments from the open data community – again most prominently by Tim Berners-Lee – that web browsers should drop mixed content protections to allow open data sources only available over http:// to be pulled into https:// websites. This is essentially saying that open data doesn’t need transport integrity or confidentiality at the protocol level, and seems to be partially motivated by the idea that pressure to change http:// URIs to https:// is too much work.

While you can argue for namespace purity without also arguing against the need for transport integrity, the fact that they’ve been both been argued together has entangled the issues more than they should be.

These entangled arguments, along with the pain I’ve observed around XML/DTD URIs, has led me to feel pretty strongly that if you’re going to use a URI that references a transport protocol – even if it’s not intended for dereferencing through a network connection – that URI should reference the secure version and not the deprecated version.

If URIs are meant to be fully independent, they should choose a scheme identifer other than http:// or https://. If they’re going to choose a scheme identifier that includes http, then it should be https://.

10 Likes

Zaujemci boli, len to nebolo v scope ani jedneho ani druheho. Alebo teda povedane inak, zaujemci prisli neskoro. :slight_smile:

Som za ucelenejsie riesenie zahrnajuce MetaIS2 (kedze uz existuje a je zhruba na tom spravnom mieste), za nejaku tu integraciu/delegovanie INSPIRE namespace na RPI (ak uz aj to je naslapnute) atd. A aj uprava na “forward looking” a “more secure” HTTPS by sa mi pacila (nerad by som opakoval chyby z USA, ktore nacrtol @EricMill). A urcite som aj za referencovatelnost (len, ako uz bolo spravne poznamenane, je na nu potrebna spolupraca dvoch systemov dvoch statnych organizacii, co je tiez vyzva, aj ked nie technicka).

A rad by som aj ASAP vypustil ontologie od @liska a @msurek aspon v odporucacom rezime, nech sa urychli ich pripadne pouzitie resp. nech sa aspon uz predchadza “divergenciam z neznalosti”. (O.i. mozno preto RPI nie je uplne “v sulade”, lebo komunikaciu o tych ontologiach nezachytili, kedze bola “interna” vramci standardizacie a nic alebo len malo “uniklo” von. Tak ako sme cca v 2014 vramci debat o Open Data velmi nevnimali INSPIRE.)

Ak sa teda najprv ujednotime tu, potom mozeme prist s jednym navrhom na Standardizacnu komisiu. Mame tak sancu, ze Luborom spominany polrok potrebny na novelu Vynosu bude realny.

Aby som to nekomplikoval, tak zatial uvediem otvorene body k red_id (nie ontologiam):

  1. referencovatelne URI: ano alebo nie? (v aktualnom Vynose mame “ano”, aj ked to data.gov.sk neimplementuje)
  2. ma byt v ref_id (URI) “http” alebo “https”? (v aktualnom Vynose je “http” pricom vdaka “centralizacii” temy na Vynos a data.gov.sk je sanca na najdenie dobreho riesenia, ak sa uzhodneme na zmenu na “https”, aj ked som mozno ignotrant a na nieco/niekoho som zabudol)
3 Likes