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