TEI formát

[bodnarIQ]

Zdroje, z ktorých vychádzam: DL4DH_pomocna_databaze_200323 Ukážkový súbor z Drive - TEI/Ukazka/P14/TEI Dokumentácia TEI

Formát jednotlivých ukážok sa nezhoduje, tak by som sa rád dotázal na objasnenie k niekoľkým veciam.

1. Naším cieľom pre formát TEI je hlavne pridanie atribútov pre jednotlivé tokeny. Predstavujem si to tak, ze každé slovo bude otagované v štýle <token persName="Karol IV." posX="124.5" posY="31">Karla IV.</token>. Vo Vami dodanej ukážke formátu TEI to takto ale nie je. Tam je každé slovo v body označené nejakým xml:ID, na ktoré sa potom predpokladám viažu atribúty pozície v tagoch <facsimile></facsimile>.
   
   
2. V súbore Pomocná databáza každý tag začína s predponou tei, napriklad <tei:persName>Karol IV.</tei:persName>, no v dokumentácii TEI to takto nie je.
   
   
3. V súbore Pomocná databáza je ukážka použitia tagov pre identifikáciu geografických lokácií nasledovným spôsobom: Zatiaľčo v dokumentácií je to takto: Bolo by ale dobré to zjednotiť v zmysle, že otagované slovo bude stále iba to, ktoré sa vyskytuje v texte(teda v tomto prípade by koordináty neboli medzi tagmi) a všetky metadáta, ktoré sa k danému tokenu viažu, by boli ako atribúty tokenu. T.j., napríklad: <token placeName="Brno" geoLat="42.1415" geoLon="16.1014">Brne</token> Bolo by toto použiteľné?
   
   
4. Ako správne otagovať prípad, kedy viacero tokenov zdieľa metadáta? Príklad: <token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso</token> - Po správnosti by sa rozoznaná menná entita mala otagovať tak, že každé slovo bude samostatný token, a každý token by mal obsahovať metadáta o tom, že ide o názov osoby, čiže by to vyzeralo tak, že každé jedno slovo z mena osoby by malo duplikované metadáta o celom mene osoby. <token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Pablo</token><token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">Diego</token><token persName="Pablo Diego José Francisco de Paula Juan Nepomuceno Cipriano de la Santísima Trinidad Ruiz Picasso" posX="124.5" posY="31">José</token>... Spojiť pod jeden token to nemôžeme, pretože na jednotlivé slová sa môžu vzťahovať ďaľšie metadáta, ktoré už nezdieľajú, napríklad lemma.

Ak by jednotlivé body potrebovali dôkladnejšie vysvetlenie/diskusiu, preferoval by som založenie samostatného issue pre jednotlivé body.

[motyc]

Ad 2 - je dobrým zvykem prefixy uvádět, zvlášť když se v rámci jednoho XML má uvádět více namespaces; jde samozřejmě stanovit výchozí namespace, ale toto je přehlednější a správnější řešení.

Ad 3 - Výhodou řešení s GML je, že jde standard, který je univerzální nejen pro bodové lokalizace, ale pro libovolné další typy geoprvků (linie, polygony...). Zároveň je v rámci syntaxe obsažen i užívaný souřadnicový systém (podle standardu EPSG), což naprostá nutnost pro správnou interpretaci souřadnic. Souřadnice v GML jsou navíc snadno zpracovatelné a převoditelné pro zobrazení v GIS.

[bodnarIQ]

Ad 3 - Ešte stále sme úplne nevyriešili, ako dokážeme transformovať textové reťazce rozoznaných entít typu geolokace na koordináty, a obávam sa že byť ešte presnejší a snažiť sa transformovať textové reťazce vyjadrujúce lokality na polygony, linie, a iné geoprvky(podľa toho, o akú konkrétne rozoznanú entity geolokace ide), bude ešte náročnejšie. Každopádne, (ak nachvíľu zabudneme na to, že je to zatiaľ nevyriešený problém) bolo by teda vhodné/nutné lokality zobrazovať práve touto syntaxou cez zanorené tagy, ktorý je akýsi štandard pre vyjadrovanie geolokalit? Pretože informace, ako použitý súradnicový systém, typ geoprvku, a pod. dokážeme obsiahnúť aj inou syntaxou, a bolo by jednoduchšie do budúcnosti, keď budeme programovať TEI Converter, ktorý sa práve o toto bude starať, mať jednotný formát pre metadáta tokenov, aby sa nemuseli v niektorých prípadoch vytvárať zanorené XML tagy, a v iných iba pridávať atribúty do <token> tagu.

Prikladám obrázok, ktorý ukazuje, ako by vyzeralo otagovanie rozoznanej entity "Abbey Dore". V prvom prípade je použité riešenie s GML podľa standardu, v druhom sú metadáta o rozpoznanej entite zahrnuté iba ako atribúty <token> XML tagu. V oboch prípadoch ide o rovnaký obsah metadát k danému tokenu.

[motyc]

Ad 3 - nejde o to, že bychom teď požadovali vkládat jiné typy geoprvků; šlo jen o příklad, v čem je problém a proč je standardní řešení mimo jiné lepší (je univerzální). Pokud to GML dovolí, lze zápis samozřejmě zjednodušit (definice zde: https://www.ogc.org/standards/gml). Pokud mají být ale data k něčemu a nechceme uživatele nutit výstupy nějak složitě před použitím transformovat, neměli bychom si vymýšlet vlastní řešení tam, kde standardní existují.

[stranak]

Záleží asi na tom, co je třeba vytahat z databáze (Wikidata, GeoNames ...) o dané entitě přímo do TEI. Mně přijde, že nejdůležitější je právě nějaký identifikátor, který tu entitu jednoznačně určuje, ideálně v některé z těchto velkých databází, kde je pak o entitě spousta dalších atributů. Abbey Dore

My zatím v experimentech s NE linkingem počítáme právě s linkováním na Wikidata.

[stranak]

Ten identifikátor je zásadní v případě nejednoznačnosti entity.

Vezměme si jako příklad takovou Prahu. Jedna je v okrese Lučenec na Slovensku, druhá ve středních Čechách. Ve specifikaci výše nevidím nic, čím bych je mohl rozlišit, vyjma porovnávání koordinátů, což mi přijde pro uživatele jako poměrně nešikovné (třeba ve vyhledávání).

[daliboris]

ad 1: cíl je definován správně (pridanie atribútov pre jednotlivé tokeny), pokud ale budeme generovat formát TEI, musíme využívat jenom ty elementy a atributy, které standard TEI definuje.

Element <token> standard TEI nezná. Odpovídá mu ale element <w>, takže výše uvedený příklad by v TEI měl vypadat spíše takto:

<placeName>
 <location>
  <geo>
   <gml:Point xmlns:gml="http://www.opengis.net/gml/3.2" >
    <gml:pos>-77.2 -10.0</gml:pos>
   </gml:Point>
  </geo>
 </location>
 <settlement>
  <w>Abbey</w>
  <w>Dore</w>
 </settlement>
</placeName>

Upozorňuju, že si nejsem jistý správným použitím elementu <Point> (zda jsou uvedeny všechny nezbytné atributy a elementy). Element <coordinates>, který se používá v našich ukázkách výše, má nyní ve standardu GML status deprecated.

Abychom mohli v TEI používat elementy ze jmenného prostoru http://www.opengis.net/gml/3.2, bude potřeba vytvořit vlastní specifikaci TEI, která tuto kombinaci elementů (<tei:geo> a <gml:Point>, popř. <gml:Polygon>) povolí. Nástroje pro to existují: Roma.

[daliboris]

ad 4: Pokud využijeme standard TEI, měly by se víceslovné entity zpracovat následovně: Jednodušší varianta:

<persName ref="https://cs.wikipedia.org/wiki/Pablo_Picasso">
 <w>Pablo</w>
 <w>Diego</w>
 <w>José</w>
 <w>Francisco</w>
 <w>de</w>
 <w>Paula</w>
 <w>Juan</w>
 <w>Nepomuceno</w>
 <w>Cipriano</w>
 <w>de</w>
 <w>la</w>
 <w>Santísima</w>
 <w>Trinidad</w>
 <w>Ruiz</w>
 <w>Picasso</w>
</persName>

Pokrčilejší varianta (pokud nástroj pro rozpoznání entit jednotlivé části jména identifikuje):

<persName ref="https://cs.wikipedia.org/wiki/Pablo_Picasso">
 <forename><w>Pablo</w></forename>
 <forename><w>Diego</w></forename>
 <forename><w>José</w></forename>
 <forename><w>Francisco</w></forename>
 <nameLink><w>de</w></nameLink>
 <surname><w>Paula</w></surname>
 <surname><w>Juan</w></surname>
 <surname><w>Nepomuceno</w></surname>
 <surname><w>Cipriano</w></surname>
 <nameLink>
  <w>de</w>
  <w>la</w>
 </nameLink>
 <surname><w>Santísima</w></surname>
 <surname><w>Trinidad</w></surname>
 <surname><w>Ruiz</w></surname>
 <surname><w>Picasso</w></surname>
</persName>

To, že token (<w>) tvoří součást jména, je dáno zanořením elementů. Vlastnosti, které se budou vztahovat k <persName>, budou platit i pro zanořené elementy.

[bodnarIQ]

@stranak

Ten identifikátor je zásadní v případě nejednoznačnosti entity.

Vezměme si jako příklad takovou Prahu. Jedna je v okrese Lučenec na Slovensku, druhá ve středních Čechách. Ve specifikaci výše nevidím nic, čím bych je mohl rozlišit, vyjma porovnávání koordinátů, což mi přijde pro uživatele jako poměrně nešikovné (třeba ve vyhledávání).

to je práve ten problém, že nedokážeme získať tento jednoznačný identifikátor z kontextu. Ak toto bude niekedy v budúcnosti možné a bude treba systém rozširiť o túto informáciu, je veľmi jednoduché pridať nový atribút pre daný uzol v strome metadát.

potom bude už na TEI Convertore, akým spôsobom sa táto informácia prejaví v TEI

@daliboris

ad 1: cíl je definován správně (pridanie atribútov pre jednotlivé tokeny), pokud ale budeme generovat formát TEI, musíme využívat jenom ty elementy a atributy, které standard TEI definuje.

mapovanie ukladaných uzlov a ich atribútov v strome na TEI formát bude tiež prebiehať v TEI Convertore, kde by sa uzly oznacene "token" mohli mapovat na tagy "word", podobne pri iných uzloch, bude treba došpecifikovať pri hlbšom rozbore TEI Converteru

Posledný komentár od @daliboris bol podnetom pre ukladanie metadát v stromovej štruktúre, práve preto aby sme neukladali duplicitne metadáta vzťahujúce sa k viacerým tokenom/slovám. Výstup z NameTagu definuje 2 úrovňové zanorenie typov rozpoznaných entít, a 8 podtypov rozpoznaných entít typu Personal Names - animal names, inhabitant names, (academis) titles, first names, second names, surnames, relif./myth persons, underspecified. Môžme sa rozhodnúť niektoré podtypy ingorovať v TEI formáte, no mali by sme zahrnúť všetko, čo NameTag definuje, do uloženého stromu metadát.

To, že token () tvoří součást jména, je dáno zanořením elementů. Vlastnosti, které se budou vztahovat k , budou platit i pro zanořené elementy.

tento vzťah zanorenia bude vyjadrený vzťahom parent - child v metadatovom strome

[bukovskyIQ]

Pokud nebude další diskuze, za inQool je tento issue připraven k zavření.

[stranak]

pokud jde o to, jak reprezentovat pojm. entity, pro srovnání zde diskuse v projektu parlamentních proceedings: ParlaMint. Velmi podrobná česká taxonomie entit se mapuje na běžnější hrubou, která existuje i pro jiné jazyky, a pak se reprezentuje v TEI. Je nějaký důvod tam zavedený přístup nepřebrat? https://github.com/clarin-eric/ParlaMint/issues/46

Zde kopíruji, co mi k tomu napsal kolega @matyaskopp, který to dělá, vč. kódu, který to TEI produkuje:

Matyáš Kopp: Já jsem ty parlamint entity zahrnul i k nám do ParCzech, tady je volání: https://github.com/ufal/ParCzech/blob/d7bd7805800271c19bb76077dc5e82e0ac0264b7/src/run_parczech.sh#L490-L495

parametr --conll2003 přidává do elementů type="PER|LOC|ORG|MISC" parametr --varied-tei-elements povolí mix tei elementů (nenacpe všechno do name), tady je mapování: https://github.com/ufal/ParCzech/blob/d7bd7805800271c19bb76077dc5e82e0ac0264b7/src/nametag2/nametag2.pl#L158-L166

jinak tady je obrázek toho, jak je to namapované: https://github.com/ufal/ParCzech/issues/95

mám issue na dopsání README k nametagu, ale je to v pořadí...

tady je TEI reprezentace taxonomie: https://github.com/ufal/ParCzech/blob/d7bd7805800271c19bb76077dc5e82e0ac0264b7/src/metadater/tei_parczech.xml#L706-L873

[stranak]

@stranak Ten identifikátor je zásadní v případě nejednoznačnosti entity. Vezměme si jako příklad takovou Prahu. Jedna je v okrese Lučenec na Slovensku, druhá ve středních Čechách. Ve specifikaci výše nevidím nic, čím bych je mohl rozlišit, vyjma porovnávání koordinátů, což mi přijde pro uživatele jako poměrně nešikovné (třeba ve vyhledávání).

to je práve ten problém, že nedokážeme získať tento jednoznačný identifikátor z kontextu.

Mluvil jsem o příkladu, kde je přesně identifikovaná entita popsaná GPS souřadnicemi. Když tedy už víme, o jakou entitu se jedná, tak bych preferoval ten její identifikátor / odkaz na ni před souřadnicemi. Asi je možné, že mám souřadnice a nemám odkaz na entitu do databáze, ale tady ten případ moc neočekávám.

[bodnarIQ]

pokud jde o to, jak reprezentovat pojm. entity, pro srovnání zde diskuse v projektu parlamentních proceedings: ParlaMint. Velmi podrobná česká taxonomie entit se mapuje na běžnější hrubou, která existuje i pro jiné jazyky, a pak se reprezentuje v TEI. Je nějaký důvod tam zavedený přístup nepřebrat? clarin-eric/ParlaMint#46

Problematika reprezentovania pojm. entít (v TEI) sa bude podrobnejšie riešiť až pri TEI Converteri, myslím si ale, že spomínaný spôsob ukladania metadát je dostatočne flexibilný, aby sa dalo pomerne jednoducho konvertovať ukladaný strom do TEI formátu s využitím mapovania v ParlaMint, na ktorý sa odkazujete.

Mluvil jsem o příkladu, kde je přesně identifikovaná entita popsaná GPS souřadnicemi. Když tedy už víme, o jakou entitu se jedná, tak bych preferoval ten její identifikátor / odkaz na ni před souřadnicemi. Asi je možné, že mám souřadnice a nemám odkaz na entitu do databáze, ale tady ten případ moc neočekávám.

Musíme myslieť na to, že súradnice nebudeme získavať z konkrétnej entity z nejakej externej databázy entít (pretože nemáme momentálne možnost EntityLinkingu) ale cez nejaký externý nástroj, ktorý nerozoznáva kontext, a preto pri transformácií textu "Praha" dostaneme stále tie isté súradnice (Praha v Česku, vo všeobecnosti prvý výsledok v nástroji, pravdepodobne radené podľa veľkosti, no závisí na internej implementácií nástroja, ktorý použijeme), nezávisle od kontextu. Tým pádom všetky spomínané "Prahy" v publikáciách budú odkazovať (podľa súradníc) na tú istú Prahu, takže nevidím význam zavedenie nejakého jednoznačného identifikátora a vytvárania entít(databázových entít) z rozoznaných entít (výsledky NameTagu, teda až PersonName - diskutované na meete 24.3., pre prípravu na LOD).