Feedback k OFN pro slovníky

[psiotwo]

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

• ta OFN má něco česky, něco anglicky - působí to divně. Když se to bude dávat ven, chtělo by to mít česky celé
  
• nechtělo by to do Abstract odkaz na tu metodiku dát (bude-li veřejná)? Protože ta OFN obsahuje spoustu pojmů (slovník, tezaurus, konceptuální model, ...) - i technici implementující publikaci či konzumaci slovníků by měli mít možnost získat kontext toho, co vlastně zpracovávají IMO.

věcné

• Podle diagramu to vypadá, že "konceptuální model" je jen "blíže neurčený" tag toho tezauru. Tedy nic nebrání tomu sdílet instanci třídy "konceptuální model" a přesto v ní nemít jediný vztah/třídu,vlastnost. Z tohoto pohledu mi to přijde pro sdílení klasifikace nedává smysl. Řešení vidím dvě:
  1. buď přidat do sdíleného schematu tato omezení a specifikovat, že každý pojem konceptuálního modelu musí být typován jako vztah/třída/vlastnost/datový typ ..., nebo
  2. zrušit "konceptuální model" a "tezaurus", nechat jen "slovník" a vytvořit pravidla za kterých se slovník klasifikuje jako tezaurus/konceptuální model (tedy např. tezaurus = slovník, ve kterém jsou pouze instance třídy "pojem", nikoliv jeho podtříd, atp.). Tahle varianta je flexibilnější.
• v anotacích pojmu bych byl klidně otevřenější - čím více toho budou sdílet, tím lépe pro pochopení (tedy např. i skos:example - příklad použití, synonyma)
• chápu to tak, že "třída", "vztah", "vlastnost" jsou tady nějak vložené obecné "technické modelovací" konstrukty, které nemají nic společného s ontologiemi, takže specializaci "Typ ..." od "Třída" nerozumím. Vidím to jako dvě části modelu které nejsou ve stejné specializační hierarchii:
  • strukturní - "ala-UML" - třída, vlastnost, vztah - prvky "jednoduchého grafického modelovacího" jazyka.
  • sémantická (ala https://data.gov.cz/kodi/v%C3%BDstupy/C5V2.pdf)
    • "typ objektu", "typ události" - stereotypy tříd
    • "typ vztahu" - stereotyp asociační třídy
    • chybí mi tam "typ vlastnosti"
• Existují jiné instance třídy než subjekty nebo objekty práva? Pokud ne, může být "Typ události" objektem práva?
• "Název slovníku. Je unikátní v rámci názvů všech slovníků." - jak tu unikátnost zajistit? Takže tento požadavek předpokládá existenci nějaké centralizovaná služby, která to umí zvalidovat.
• 3.1.1. - proč description začíná "Datový slovník", zatímco kapitola se jmenuje "Slovník" ?
• 4.1.2. - "Pojem, reprezentuje typy subjektu a objektu práva, vlastnost nebo vztah" - definice není aligned s diagramem. Co instance "třídy" bez speciálního typu?
• 6.1.1. - "Pro danou agendu relevantní událost" - v diagramu se o agendách nemluví - takže nelze modelovat událost mimo agendu? Pokud ne, není třeba, aby diagram agendu obsahoval taky?
• 6.1.5 - z příkladu a definice to vypadá, že spíš "Typ vztahu" by měl mít kardinality, než vztah samotný ...

[jakubklimek]

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]

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]

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.

8. 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]

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.

8. 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]

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]

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]

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]

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