search

datagov-cz / otevrene-formalni-normy

V tomto repozitáři jsou otevřené formální normy pro otevřená data v ČR a sbíráme zde na ně další požadavky. Tento repozitář je udržován v rámci projektu OPZ č. CZ.03.4.74/0.0/0.0/15_025/0013983.
https://ofn.gov.cz
17 stars 13 forks source link

Feedback k OFN pro slovníky #439

Open psiotwo opened 8 months ago

psiotwo commented 8 months ago

pár hnidopišských, resp technických

věcné

jakubklimek commented 8 months ago

Ad Hnidopich 1) Jistě, ale Bikeshed to česky neumí. Tedy dokud nebude finál, tak to překládat nebudeme, pak asi udělam nějaký skript ala sed 2) Metodika nebude dřív než OFN, takže ne, až metodika bude, tak samozřejmě ano

Ad věcné 1) Ano, to je by design. Význam je, že autor udává, s jakou komplexitou má počítat konzument, ale povoluje to i ten potenciál nevyužít - i když to bude edge case 2) OFN ve sdílení dalších věcí nikoho neomezuje, ale cílem je aby byla co nejjednodušší. Tedy tohle je otázka nějakých dalších verzí - až několik poskytovatelů vyjádří potřebu dávat i examply, tak se do další verze examply mohou dostat. Ale pro začátek nechceme čtenáře zahltit možnostmi. 3) Ve smyslu že každá instance typu události je instence třídy, a instance Pojmu to ale dědičnost je. 4) To je dobrá otázka, záleží na tom, jak moc to chceme provazovat s RPP a agendami 5) Toto nevalidujeme. Nicméně do budoucna se počítá s možností slovníky harvestovat podobně jako lokální katalogy, takže tam to kdyžtak validovat půjde. Btw. tohle omezení jsem tam přidal na základě tvého feedbacku, že tam musí být :) 6) To je related k 4) 7) To jsou definice převzadé z C2V11 a jsou k diskuzi, nikoliv finální 8) Tady nevím, jaké kardinality myslíš

psiotwo commented 8 months ago

Díky.

Hnidopich

  1. OK, tušil jsem to.
  2. OK

Věcné

  1. Stále nerozumím, je-li to by design, co v takovém případě ty podtřídy přináší - za mě to jen zvyšuje potenciálně nekonzistentní data. Někdo klasifikuje něco jako Tezaurus, přesto v něm bude mít vztahy, ... nebo něco jako Model, přesto je v něm mít nebude.
  2. OK
  3. To vidím jinak. Např. ontologický vztah může být realizován jako třída, nebo jako asociace mezi třídama - ontologicky totéž, ale v modelovacím jazyku jsou to dva různé konstrukty.
  4. OK
  5. JJ, já svůj požadavek vidím, spíš mi šlo o to, kam psát (asi ne do specifikace struktury slovníku) to, jak to teda zvalidovat, nějaký impakt na architekturu řešení.
  6. OK
  7. OK
  8. já taky ne :-) jsem chtěl napsat obory (definiční, hodnot) ...

Jinak z mých 9 bulletů ses nevyjádřil k následujícímu, jestli jsem tvé odpovědi správně pochopil: "3.1.1. - proč description začíná "Datový slovník", zatímco kapitola se jmenuje "Slovník" ?"

jakubklimek commented 8 months ago

Ano, to je by design. Význam je, že autor udává, s jakou komplexitou má počítat konzument, ale povoluje to i ten potenciál nevyužít - i když to bude edge case

Stále nerozumím, je-li to by design, co v takovém případě ty podtřídy přináší - za mě to jen zvyšuje potenciálně nekonzistentní data. Někdo klasifikuje něco jako Tezaurus, přesto v něm bude mít vztahy, ... nebo něco jako Model, přesto je v něm mít nebude.

Jednak byl požadavek, aby autor explicitně řekl, na jakou úroveň míří. Zároveň je to ale i vhodné pro JSON-LD reprezentaci mapující tyto třídy na skos:ConceptScheme (Tezaurus) resp. owl:Ontology (Konceptuální model). Záměr tu nebyl (zatím) říkat, že když v Tezauru je jedna třída nebo v Konceptuálním modelu žádná není, že je to chyba.

To vidím jinak. Např. ontologický vztah může být realizován jako třída, nebo jako asociace mezi třídama - ontologicky totéž, ale v modelovacím jazyku jsou to dva různé konstrukty.

To souhlasím. Zároveň asociace je jednodušší, zatímco Typ vztahu je složitější. A cílem bylo na úrovni Konceptuálního modelu bez rozšíření mluvit jen o asociacích, s rozšířením pak i o Typech vztahů, což jsou právě třídy. Tedy já tady asi nevidim ten problém.

Že nemáme typ vlastnosti souhlasím. Můžeme přidat, abychom byli konzistentní.

JJ, já svůj požadavek vidím, spíš mi šlo o to, kam psát (asi ne do specifikace struktury slovníku) to, jak to teda zvalidovat, nějaký impakt na architekturu řešení.

Jo, tak to jo. Souhlas že ne do OFN - a tohle bych řešil, až bude na stole to harvestování a navázané funkcionality.

  1. jasně, tedy pokud jde o obory - tam to vyplývá z toho, že zatímco v RDFS máme domain a range, v UFO, aspoň jak jsme to s Martinem pochopili, má typ vztahu jen účastníky bez rozlišení (a proto v Z-SGoV je má účastníka 1 a 2). Tedy takto u typu vztahu obory rozlišíme pouze pokud je z něj odvozený vztah s domain a range.

"3.1.1. - proč description začíná "Datový slovník", zatímco kapitola se jmenuje "Slovník" ?"

Tohle souvisí s probíhajícími diskuzemi ohledně zákona o správě dat (politika) kde vykrystalizoval pojem "Datový slovník", tak je použit v textech, ale ještě není jasné, jestli se tak musí jmenovat i třída a kapitola. Tedy ano, teď je tady tahle nekonzistence, která by měla zmizet spolu s finalizací zákona o správě dat (teď snad odešel draft do připomínkování).

psiotwo commented 8 months ago

Stále nerozumím, je-li to by design, co v takovém případě ty podtřídy přináší - za mě to jen zvyšuje potenciálně nekonzistentní data. Někdo klasifikuje něco jako Tezaurus, přesto v něm bude mít vztahy, ... nebo něco jako Model, přesto je v něm mít nebude.

Jednak byl požadavek, aby autor explicitně řekl, na jakou úroveň míří. Zároveň je to ale i vhodné pro JSON-LD reprezentaci mapující tyto třídy na skos:ConceptScheme (Tezaurus) resp. owl:Ontology (Konceptuální model). Záměr tu nebyl (zatím) říkat, že když v Tezauru je jedna třída nebo v Konceptuálním modelu žádná není, že je to chyba.

Na druhou stranu Tezaurus, ktery namapujeme do skos:ConceptScheme a bude obsahovat pouze vztahy a tridy, moc velkou hodnotu mit nebude. Podle me se lehce stane to, ze budou vznikat slovniky splnujici OFN, ale ne(pre)pouzitelne - coz adopci celeho pristupu nepomuze. Za me by to mel byt jeden z cilu poskytnout datovy format, ktery omezi chyby. Ale jak pises je to o use-case - jestli to co pisu neni uloha OFN, pak premyslim, kdo a kde toto zaridi.

To vidím jinak. Např. ontologický vztah může být realizován jako třída, nebo jako asociace mezi třídama - ontologicky totéž, ale v modelovacím jazyku jsou to dva různé konstrukty.

To souhlasím. Zároveň asociace je jednodušší, zatímco Typ vztahu je složitější. A cílem bylo na úrovni Konceptuálního modelu bez rozšíření mluvit jen o asociacích, s rozšířením pak i o Typech vztahů, což jsou právě třídy. Tedy já tady asi nevidim ten problém.

Tak to asi bude fajn probrat.

  1. jasně, tedy pokud jde o obory - tam to vyplývá z toho, že zatímco v RDFS máme domain a range, v UFO, aspoň jak jsme to s Martinem pochopili, má typ vztahu jen účastníky bez rozlišení (a proto v Z-SGoV je má účastníka 1 a 2).

Ano toto je pravda, ale duvod je jinde - striktne vzato bys podle UFO mel mit jednotlive ucastniky rozlisene svymi rolemi a tedy zadny index nepotrebujes. Ale na toto jsme bohuzel zatim rezignovali, protoze nutit pro kazdy vztah modelovat k nemu i role jeho komponent by bylo slozite (dalo by se to i generovat na pozadi a udelat nejake "makro" nad OntoUML), ale tam jsme se tehdy nedostali.

Domain je prirozene ucastnik 1 a range ucastnik 2.

jakubklimek commented 8 months ago

Na druhou stranu Tezaurus, ktery namapujeme do skos:ConceptScheme a bude obsahovat pouze vztahy a tridy, moc velkou hodnotu mit nebude. Podle me se lehce stane to, ze budou vznikat slovniky splnujici OFN, ale ne(pre)pouzitelne - coz adopci celeho pristupu nepomuze. Za me by to mel byt jeden z cilu poskytnout datovy format, ktery omezi chyby. Ale jak pises je to o use-case - jestli to co pisu neni uloha OFN, pak premyslim, kdo a kde toto zaridi.

OFN ukazuje jak data strukturovat, a tady se speciálně vyhýbáme tomu, jak tu strukturu správně používat. To je úloha budoucí metodiky a návazných činností. Je to rozfázováno zejména z časových důvodů, a trochu také praktických - uvidíme, jak to první poskytovatelé budou používat, a na to pak můžeme reagovat. Stejně jako ve struktuře Turistického cíle dle OFN můžu popsat něco, co vůbec turistický cíl není, tak tady můžu vytvořit něco, co vůbec nedává smysl.

MichalMed commented 8 months ago

Mě se poslední dobou ukazuje, že právě tento design, kdy dělíme slovníky na konceptuální modely a tezaury nic pozitivního nepřináší a v praxi je to spíš důvod, proč se nedaří výrobní linku efektivněji propojit s jinými řešeními a celkově to omezuje i další vývoj výrobní linky.

MichalMed commented 8 months ago

Další kolo připomínek (částečně) vzhledem ke kompatibilitě s TermItem:

  1. OFN vypadá, že kombinuje věci, které byly definovány v ontologiích popis-dat a UFO (první dvě úrovně), ale zároveň s nimi není kompatibilní (Petrem zmiňované typ vlastnosti vs. vlastnost, tezaurus a konceptuální model jako podtřídy slovníku vs. glosář a model jako části slovníku).
  2. současná verze TermIta (i ta ve VL) používá dvě ontologie pro popis slovníků, jedná se o interní TermIt ontologii a právě zmiňovanou ontologii popis dat. Tím, že OFN není kompatibilní v podstatě úplně zbytečně komplikujeme kompatibilitu TermIta s touto OFN. Nechápu, jak je možné, že na to @psiotwo jako spoluautor této ontologie a duchovní otec TermIta nepomyslel.
  3. nedává mi moc smysl hierarchie "konceptuální model -> tezaurus -> slovník" a neodpovídá to ani tomu, jak jsme tyto pojmy vnímali v minulosti v dokumentech projektu KODI. Tezaurus (glosář) obsahuje oanotované pojmy, model obsahuje funkční vztahy mezi pojmy, slovník je kombinací obojího.
  4. proč slovník má životní cyklus a pojem ne?
  5. struktura OFN vychází z popisu jednotlivých tříd, neměla by (logicky) odpovídat spíše úrovním komplexity a být tak jakýmsi návodem pro implementaci?
  6. TermIt je v popisu a anotacích výrazně podrobnější. Nevidím důvod, proč by podrobnější nemohla být i tato OFN. @jakubklimek zmiňuje, že až nějací poskytovatelé vyjádří potřebu, tak se přidají. Potřeba takových poskytovatelů (IPR, ČAS) je vyjádřena v ontologii popis-dat a v současné standalone verzi TermIta.
psiotwo commented 8 months ago

@MichalMed k bodu 2:

OFN si klade za cíl maximálně podpořit sdílení jednoduchých slovníků vytvořených různými nástroji, proto je třeba mít jednoduchý výměnný formát založený co nejvíce na standardních stabilních slovnících, nezávislých na specifikách jakýchkoliv nástrojů (tedy ani výrobní linky, TermItu či Ontographeru). Každopádně díky tvaru OFN bude transformace do tvaru dle OFN mnohem jednodušší než pro další nástroje - řešitelné deklarativně, datově (možná pouze mapováním, možná SPARQLem, v nejhorším RML).

Druhou věcí je úroveň detailu OFN - ano je nízká - je tam mnoho směrů kterými lze tu OFN rozšiřovat, ale to bylo rozhodnuto nechat na další verze.