search

LIBCAS / DL4DH-TEI-Converter

DL4DH TEI Converter
0 stars 0 forks source link

Tei converter - vydefinovanie používaných TEI elementov #2

Open psekan opened 3 years ago

psekan commented 3 years ago

Na základe dohody z online stretnutia zo 14. 5. prosíme o spísanie zoznamu TEI elementov, ktoré budú v projekte použité.

Na úvod, v priebehu týždňa prosíme o nástrel časti elementov, s ktorými môžeme pracovať a postupne dodávať ukážkový TEI výstup. Spísanie celého zoznamu by mal byť dodaný v polovici června.

Cieľom je mať spísané tagy, na základe ktorých sa vytvorí ODD pomocou nástroja https://romabeta.tei-c.org/, čím sa pre užívateľov systému a aj dodávateľa špecifikuje, užšia podčasť TEI formátu využívaného projektom.

Nástroj Roma umožnuje obmedziť aj Attribute a Model classes ako aj Datatypes. Ak ich viete @daliboris taktiež obmedziť, prosíme o spísanie, ktoré budú taktiež vylúčené.

daliboris commented 3 years ago

Klasifikace entit NameTag 2

Klasifikace rozpoznaný typů entit s ukázkami pro verzi NameTag 2 vznikla na základě materiálů, které jsou součástí dokumentace k Czech Named Entity Corpus 2.0; k dispozici ke stažení zde.

Doplněná verze převodní tabulky mezi NameTagem 2 a TEI. Stále ještě nejde o definitivní reperotát značek a atributů (můžou se měnit názvy elementů i atributů, popř. jejich hodnot).

Tabulka rozpoznávaných typů entit s odpovídajícími elementy podle TEI

Nadtyp/typ Popis Příklad TEI
a ČÍSLA JAKO SOUČÁSTI ADRES
ah číslo popisné ul. Šikmá <ah 356> <num><w>356</w></num>
at telefon, fax tel. <at 256 458 588> <num type="phone"><w>256</w><w>458</w><w>588</w></num>
az PSČ <az 180 00> Praha 8 <num type="zip"><w>180</w><w>00</w></num>
C Komplexní bibliografický údaj <ne type="C"> ... </ne> <bibl> (pokud jde o jediný prvek v rámci <s>)
C Komplexní bibliografický údaj <ne type="C"> ... </ne> <objectName type="bibliography" ana="#nametag-C"> (pokud nejde o jediný prvek v rámci <s>)
g GEOGRAFICKÉ NÁZVY
gc státní útvary <gc Česká republika>, <gc Svatá říše římská> <placeName><country><w>Česká</w><w>republika</w></country></placeName>
gh vodní útvary <gh Vltava>, <gh Balaton> <geogName type="water"><w>Vltava</w></geogName>
gl přírodní oblasti / útvary <gl Sibiř>, <gl Apeninský poloostrov>, <gl Polabí> <geogName type="area"><w>Apeninský</w><w>poloostrov</w></geogName>
gq části obcí, pomístní názvy <gq Smíchov> <placeName><settlement><w>Smíchov</w></settlement></placeName>
gr menší územní jednotky <gr Morava>, <gr Rychnovsko>, <gr Badensko-Württembersko> <placeName><region><w>Morava</w></region></placeName>
gs ulice, náměstí <gs ul. Šikmá>, <gs nám. Míru> <address><street><w>ul.</w><w>Šikmá</w></street></address>
gt kontinenty <gt Jižní Amerika> <geogName type="continent"><w>Jižní</w><w>Amerika</w></geogName>
gu obce, hrady a zámky <gu Praha>, <gu Opočno> <placeName><settlement><w>Praha</w></settlement></placeName>
g_ geografický název nespecifikovaného typu / nezařaditelný do ostatních typů Učkuduk v <g Mojunkumech> <placeName><w>Mojunkumech</w></placeName>
i NÁZVY INSTITUCÍ
ia přednášky, konference, soutěže,... <ia Stanley Cup> <objectName><w>Stanley</w><w>Cup</w></objectName>
ic kulturní, vzdělávací a vědecké instituce, sportovní kluby,... kino <ic Dlabačov>, hokejisté <ic Sparty> <orgName><w>Dlabačov</w></orgName>
if firmy, koncerny, hotely,... <if Unipetrol>, řetězec <if Edeka> <orgName><w>Unipetrol</w></orgName>
io státní a mezinárodní instituce, politické strany a hnutí, náboženské skupiny <io Evropská komise>, <io Policie>, <io ODS> <orgName><w>Policie</w></orgName>
i_ instituce nespecifikovaného typu / nezařaditelné do ostatních typů <i Studijní odd.> <orgName><w>Studijní</w><abbr><w>odd</w><pc>.</pc></abbr></orgName>
m NÁZVY MÉDIÍ
me e-mailové adresy <me john@seznam.cz> <email>john@seznam.cz</email>
mi internetové odkazy <mi www.cinestar.cz> <ref target="www.cinestar.cz">www.cinestar.cz</ref>
mn periodika, redakce, tiskové agentury agentura <mn Interfax> <orgName><w>Interfax</w></orgName>
ms rozhlasové a televizní stanice <mr Frekvence 1>, <mt ČT 2> <orgName><w>ČT</w><w>2</w></orgName>
n ČÍSLA SE SPECIFICKÝM VÝZNAMEM
na věk je mu <na 18> <num><w>18</w></num>
nc číslo s významem počtu s <nc 35miliardovým> deficitem, od <nc 8> do <nc 40> <num><w>35miliardovým</w></num>
nb číslo strany, kapitoly, oddílu, obrázku podle paragrafu <nb 187>, tab na s. <nb 13> <num><w>187</w></num>
no číslo s významem pořadí <no 154.> vydání, umění <no 20.> století <num type="ordinal"><w>20.</w></num>
ns sportovní skóre vyhráli <ns 5:0> <num>5</num><pc>:</pc><num>0</num>
ni itemizátor <ni 1)> DPH, <ni 2)> daň z příjmu <num><w>1</w><pc>)</pc></num>
n_ číslo se specifickým významem, jehož typ nebyl vyčleněn jako samostatný / nelze identifikovat autobusová linka <n 158> <num>158</num>
o NÁZVY VĚCÍ
oa kulturní artefakty (knihy, filmy stavby,...) Hugovi <oa Bídníci> <objectName type="artefact"><w>Bídníci</w></objectName>
oe měrné jednotky (zapsané zkratkou) 200 <om MHz> <unit><w>MHz</w></unit>
om měny (zapsané zkratkou, symbolem) 1000 <om Kč>, 30 <om $> <unit><w>Kč</w></unit>
op výrobky mikroprocesory <op Intel Pentium> <objectName type="product"><w>Intel</w><w>Intel</w></objectName>
or předpisy, normy,..., jejich sbírky ve <or Sbírce zákonů> <objectName type="rule"><w>Sbírce</w><w>zákonů</w></objectName>
o_ názvy nespecifikovaného typu / nezařaditelné do ostatních typů čeleď <o Rubiaceae>, <o HIV> <objectName><w>HIV</w></objectName>
p JMÉNA OSOB
pc obyvatelská jména <pc Afričan>, <pc Pražan> <name type="population"><w>Afričan</w></name>
pd titul (pouze zkratkou) <pd Mgr.> J. Pola <abbr><w>Mgr</w><pc>.</pc></abbr>
pf křestní jméno <pf David> Uhl, <pf J.> Drda <forename><w>David</w></forename>, <forename><w>J</w><pc>.</pc></forename>
pm druhé křestní jméno Georg <pm Friedrich> Händel <forename type="middle"><w>Friedrich</w></forename>
pp náboženské postavy, pohádkové a mytické postavy, personifikované vlastnosti <pp sv. Jakub>, <pp Prozřetelnost> <persName><w>sv</w><pc>.</pc><w>Jakub</w></persName>
ps příjmení <ps Nováková>, <ps van Dyk> <surname>Nováková</surname>
p_ jméno osoby nespecifikovaného typu / nezařaditelné do ostatních typů <p Slované> <name><w>Slované</w></name>
t ČASOVÉ ÚDAJE
td den <td 1.> října 2005 <date><w>1</w><pc>.</pc></date>
tf svátky a významné dny <tf Velikonoce> <date type="holiday"><w>Velikonoce</w></date>
th hodina v <th 17> hodin <time><w>17</w></time>
tm měsíc 1. <tm října> 2005 <date><w>října</w></date>
ty rok od roku <ty 1555> <date><w>1555</w></date>
daliboris commented 3 years ago

Návrh ODD pro potřeby DL4DH

První verze obsahuje minimum prvků v části pro samotný text (<text>) i hlavičku dokumentu (<teiHeader>). Elmenty, atributy, popř. jejich hodnoty bude potřeba ještě dále upřesňovat.

Přiložený zip obsahuje dokument ODD, schéma dokumentu ve formátu RNG a dokumentaci ve formátu HTML. Vše bylo vygenerováno nástrojem Roma - ODD Customization (Version 0.3.1).

Pokud by bylo potřeba definovat vlastní elementy nebo atributy, nanvrhuju jmenný prostor https://system-kramerius.cz/ns/dl4dh/1.0.

Aktualizovaná verze ODD a souvisejících souborů včetně ukázkového dokumentu XML s příklady z převodní tabulky. Provedené změny: doplněny elementy address, street a unit. ODD.zip

bukovskyIQ commented 3 years ago

Dobrý den, @daliboris,

děkujeme, kolega již zpracovává dodané tagy. Kompletní seznam elementů očekáváme v polovině června.

bukovskyIQ commented 3 years ago

Dobrý den, @daliboris,

na základě výše dodaných TEI elementů jsme připravili první prototyp a z něj vygenerovaný TEI soubor.

Zdroj (3 strana dokumentu):

Vygenerovaný TEI (doporučení podívat se na stranu 3):

bukovskyIQ commented 3 years ago

Dále bychom Vás rádi poprosili a vydefinování zbylých TEI elementů

stranak commented 3 years ago

Zdravím, přidávám sem diskusi s kolegy na konverze reprezentace pojmenovaných entit z NameTagu do TEITOKu. Nechám na vás, zda to stojí za nějakou úpravu.

Pavel Straňák 14:14 Can you have a look [at this issue], whether you see some problems, and of course, if it looks OK for possible later import into TEITOK?

Maarten Janssen 11:59 There is in principle nothing wrong with this - the only possible objection is the fact that it is both overly informative and underinformed; on the one hand, it does not keep the NameTag tag, and hence flattens all the numbers for instance; since those might be useful, it might make sense to keep the NameTag tag as either @ana or more explicitly @nertype, so that the information does not get lost 12:04 and on the other hand, it uses many different tags for names, which might make it more cumbersome to deal with them afterwards, since you would need to process each type of tag; and there are types of NER in NameTag that do not easily translate to tags - which is why Mattyas in ParCzech keeps a single tag for all NER ( if I am not mistaken); 12:05 The two things are related of course - if you keep an explicit @nertype, you can use that to collect all NER instead of the individual tags 12:06 And the conversion to TEITOK is (from the things listed here - there might be other things) trivial, it is only the typical conversion for <w> to <tok>, which the teitok-tools scripts already do 12:08 The converter of the Stefan institute is a different issue; I used it a lot in the past and even had it in the recommended TEITOK workflow; but it the end, it is often too literal for data processing, and I like the output of pandoc better, so that is what is used in http://quest.ms.mff.cuni.cz/teitok-dev/teitok/tools/index.php?action=convert 12:08 but the output of the Stefan institute is perfectly usable in TEITOK, as said, it has been used quite a bit in the past…

Matyáš Kopp 19:41 The current version of ParCzech 3.0 (I will release it tomorrow) basically distinguishes two types of name entities. Proper name are represented by <name> element and the rest have it's own element <num> ,<ref> ,<email> ,... Each type have CNEC category stored in @ana attribute. Furthermore, proper names have PER ,LOC ,ORG,MISC stored in @type attribute if they are not nested in other name entity. Proper names are usually targeted in search query and it make sense to add more features on them (normalized form, named entity linking, referencing them in text...). So we decide to store them in a common element <name> ...

daliboris commented 3 years ago

Reakce na ukázku:

Upravil jsem Tabulku rozpoznávaných typů entit s odpovídajícími elementy podle TEI

Připomínky k samotnému XML:

Následuje přehled doporučených změn. (Ukázka = značkování v první ukázce, NameTag = výstup z NameTagu, DL4DH = jak by to mělo vypadat.)

T

Ukázka

<group type="T">
    <date>
        <w lemma="16" msd="NumForm=Digit|NumType=Card" pos="NUM">16</w>
        <pc join="left">.</pc>
    </date>
    <date>
        <w lemma="duben" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos" pos="NOUN">dubna</w>
    </date>
    <date>
        <w lemma="1898" msd="NumForm=Digit|NumType=Card" pos="NUM">1898</w>
    </date>
</group>

DL4DH

<date when="1898-04-16">
    <w lemma="16" msd="NumForm=Digit|NumType=Card" pos="NUM">16</w>
    <pc join="left">.</pc>
    <w lemma="duben" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos" pos="NOUN">dubna</w>
    <w lemma="1898" msd="NumForm=Digit|NumType=Card" pos="NUM">1898</w>
</date>

P (Karel princ ze Schwarzenbergů)

NameTag

<sentence>
    <ne type="P">
        <ne type="pf">
            <token>Karel</token>
            <token>princ</token>
            <token>ze</token>
        </ne>
        <ne type="gu">
            <token>Schwarzenbergů</token>
        </ne>
    </ne>
</sentence>

Ukázka

<group type="P">
    <forename>
        <w lemma="Karel" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Giv|Number=Sing|Polarity=Pos" pos="PROPN">Karel</w>
    </forename>
    <w lemma="princ" msd="Animacy=Anim|Case=Nom|Gender=Masc|Number=Sing|Polarity=Pos" pos="NOUN">princ</w>
    <w lemma="z" msd="AdpType=Voc|Case=Gen" pos="ADP">ze</w>
    <placeName>
        <settlement>
            <w lemma="Schwarzenberg" msd="Animacy=Anim|Case=Gen|Gender=Masc|NameType=Sur|Number=Plur|Polarity=Pos" pos="PROPN">Schwarzenbergů</w>
        </settlement>
    </placeName>
</group>

TEI

<persName>
 <forename>Edward</forename>
 <forename>George</forename>
 <surname type="linked">Bulwer-Lytton</surname>, <roleName>Baron Lytton of
 <placeName>Knebworth</placeName>
 </roleName>
</persName>

DL4DH

<persName>
    <forename>
        <w lemma="Karel" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Giv|Number=Sing|Polarity=Pos" pos="PROPN">Karel</w>
        <w lemma="princ" msd="Animacy=Anim|Case=Nom|Gender=Masc|Number=Sing|Polarity=Pos" pos="NOUN">princ</w>
        <w lemma="z" msd="AdpType=Voc|Case=Gen" pos="ADP">ze</w>
    </forename>
    <placeName>
        <w lemma="Schwarzenberg" msd="Animacy=Anim|Case=Gen|Gender=Masc|NameType=Sur|Number=Plur|Polarity=Pos" pos="PROPN">Schwarzenbergů</w>
    </placeName>
</persName>

P (Thlg. Dr. Frant.)

Ukázka

<group type="P">
    <abbr>
        <w lemma="Thlg" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Thlg</w>
        <pc join="left">.</pc>
    </abbr>
    <abbr>
        <w lemma="doktor" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Dr</w>
        <pc join="left">.</pc>
    </abbr>
    <forename>
        <w lemma="Frant" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Sur|Number=Sing|Polarity=Pos" pos="PROPN">Frant</w>
        <pc join="left">.</pc>
    </forename>
</group>

DL4DH

<persName>
    <abbr>
        <w lemma="Thlg" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Thlg</w>
        <pc join="left">.</pc>
    </abbr>
    <abbr>
        <w lemma="doktor" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Dr</w>
        <pc join="left">.</pc>
    </abbr>
    <forename>
        <w lemma="Frant" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Sur|Number=Sing|Polarity=Pos" pos="PROPN">Frant</w>
        <pc join="left">.</pc>
    </forename>
</persName>

P (Dra. Michla)

NameTag

<NameTag>
    <sentence>
        <ne type="pd">
            <token>Dra</token>
            <token>.</token>
        </ne>
    </sentence>
    <sentence>
        <ne type="ps">
            <token>Michla</token>
        </ne>
    </sentence>
</NameTag>

Ukázka

<abbr>
    <w lemma="droktor" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Dra</w>
    <pc join="left">.</pc>
    <surname>
        <w lemma="Michla" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Sur|Number=Sing|Polarity=Pos" pos="PROPN">Michla</w>
    </surname>
</abbr>

DL4DH

<persName>
    <abbr>
        <w lemma="droktor" msd="Abbr=Yes|Animacy=Anim|Gender=Masc|Polarity=Pos" pos="NOUN">Dra</w>
        <pc join="left">.</pc>
    </abbr>
    </persName>
<persName>
    <surname>
        <w lemma="Michla" msd="Animacy=Anim|Case=Nom|Gender=Masc|NameType=Sur|Number=Sing|Polarity=Pos" pos="PROPN">Michla</w>
    </surname>
</persName>

P (Eminencí)

NameTag

<sentence>
   <ne type="p_">
        <token>Eminencí</token>
    </ne>
    <token>splnomocněn</token>
    <token>,</token>
</sentence>

Ukázka

<date type="holiday">
    <w lemma="eminence" msd="Case=Ins|Gender=Fem|Number=Sing|Polarity=Pos" pos="NOUN">Eminencí</w>
    <w lemma="splnomocněný" msd="Gender=Masc|Number=Sing|Polarity=Pos|Variant=Short|VerbForm=Part|Voice=Pass" pos="ADJ">splnomocněn</w>
</date>

DL4DH

<persName>
    <w lemma="eminence" msd="Case=Ins|Gender=Fem|Number=Sing|Polarity=Pos" pos="NOUN">Eminencí</w>
</persName>
<w lemma="splnomocněný" msd="Gender=Masc|Number=Sing|Polarity=Pos|Variant=Short|VerbForm=Part|Voice=Pass" pos="ADJ">splnomocněn</w>
daliboris commented 3 years ago

Zahrnutí odkazu na původní klasifikaci NameTagu je dobrý nápad. K tomu by mělo sloužit následující řešení:

<teiHeader>
  <profileDesc>
   <textClass>
    <classCode scheme="https://ufal.mff.cuni.cz/nametag/2/models">
     <interpGrp>
      <interp xml:id="nametag-ah">číslo popisné</interp>
      <interp xml:id="nametag-at">telefon, fax</interp>
     </interpGrp>
    </classCode>
   </textClass>
  </profileDesc>
 </teiHeader>

....

<text>
 <body>
   <p><num type="phone" ana="#nametag-at"><w>256</w><w>458</w><w>588</w></num></p>
  </body>
</text>
daliboris commented 3 years ago

Pro a proti k transpozici entit na elementy TEI

Na úvod základní premisy:

Nástroje pro rozpoznávání entit definují svou vlastní taxonomii jednotlivých druhů rozpoznávaných entit; repertoár se může měnit i u téhož nástroje, např. u NameTagu mezi verzemi 1.0 a 2.0.

Při práci s TEI je vhodnější využívat prostředky (elementy), které nabízí tento standard, a nesnažit se přizpůsobit TEI takovému pojetí, které má software pro rozpoznávání entit. (Zachování původní klasifikace je však možné – a nejspíš i žádoucí, viz předchozí komentář.)

Standard TEI používá vlastní taxonomii (v podobě repertoáru elementů) pro zachycení entit (např. <address>, <num>, <date>); tento repertoár se postupně specializuje: existují speciální značky pro jména osob, míst, organizací ap.; např. <objectName> se objevil teprve v lednu 2019).

Obsah specifických elementů (např. u <persName>) je obvykle identický s obecným elementem <name>, tj. repertoár zanořených elementů bývá stejný.

Výhoda specifičtějších elementů spočívá v tom, že je lze pomocí atributu @type blíže specifikovat, zatímco u obecnější elementu <name> se tento atribut využije pro základní rozlišení pojmenování. Srov. např.:

<name type="person"><name type="forename" subtype="abbreviated">J.</name></name>
<persName><forename type="abbreviated">J.</forename></persName>

TEI se snaží pro entity (jak je rozpoznávají používané aplikace) definovat samostatné elementy, např. <num>, <date>, <street> ap. Proto je potřeba při převodu z taxonomie programů pro rozpoznávání entit do standardu TEI vybírat nejvhodnější elementy: pokud používáme <num> pro čísla, proč nepoužít <orgName> pro názvy organizací?

Použití specifičtějších prvků má výhodu v tom, že jde o větší míru standardizace: zatímco názvy elementů se nemění, obsah atributu @type obvykle není pevně stanoven. Lze to sice omezit pomocí vlastní úpravy TEI (s využitím ODD), vždy to ale bude méně standardizované než v případě elementů (můžeme se rozhodnout např. pro hodnoty @type typu pers, org, nebo person, organisation; uživatel bude muset tuto konvenci znát).

Je velmi pravděpodobné, že pro označení křestního jména a příjmení budeme používat elementy <forename> a <surname>, nikoli <name type="forename"> a <name type="surname">. Viděl bych v tom hlavní princip naší transpozice: pokud v TEI existuje pro entitu specifický element, použijme ho, teprve pokud neexistuje, rozlišme entity pomocí hodnot atributů.

Příklady dotazů XPath s využitím obecnější a specifičtější transpozice:

Všechny názvy

//(name | foremane | surname) (: včetně zanořených :)

//(persName | placeName | geogName | objectName | orgName | foremane | surname)

Všechna pojmenování míst

//name[@type='place']

//placeName

Všechna pojmenování míst a geopolitických útvarů

//name[@type='place' or @type='geog']

//(placeName | geogName)

Pouze v případě dotazu na všechny názvy je první varianta kratší, v dalších případech bude varianta se specifičtější transpozicí úspornější.

Otázka pro badatele: budou se vyhledávat více všechny pojmenování (míst, osob ap.), nebo bude dotaz specifičtější (osoby a místa, nikoli věci)?

valekfrantisek commented 3 years ago

Soudím, že častěji se budou dotazy spíše specifické. Nebylo by ale relativně snadné mít nějaký separátní jednoslovný termín, který by byl zástupný pro všechny pojmenování (pouze proto, aby badatel nemusel jednotlivé kategorie vypisovat a náhodou na nějakou nezapomněl)?

Ještě vidím celkově zásadní problém u současného stavu OCR (jak bylo vidět i v ukázce a narážím na to neustále u vytvářeného usecase na biblické citace v prvorepublikovém tisku) - automatické rozpoznávání entit (a vše co z toho plyne) pak není dost dobře možné a tím pádem na to nebude spoleh a tedy se z toho nedají dělat skutečně relevantní statistické závěry... Myslím, že před konverzí do TEI je nutné OCR u většiny věcí zopakovat... je to vůbec v tomto objemu dat reálné, nebo se počítá spíše s postupným vylepšováním?

daliboris commented 3 years ago

Nebylo by ale relativně snadné mít nějaký separátní jednoslovný termín, který by byl zástupný pro všechny pojmenování (pouze proto, aby badatel nemusel jednotlivé kategorie vypisovat a náhodou na nějakou nezapomněl)?

Jenom pro jistotu: týká se to hledání ve Feederu, nebo v TEI? Hledání ve Feederu bude nezávislé na výsledné podobě TEI.

Taky myslím, že ještě není zřejmé, co budeme považovat za pojmenování: jde o jména osob/institucí/výrobků ap., nebo jde i o data, čísla, adresy - i to jsou rozpoznané entity.

valekfrantisek commented 3 years ago

Spíše Feederu - v podstatě jde o to, aby bylo hledání uživatelsky vstřícně nastavené (je nezávislé na výsledné podobě TEI, ale pracuje s ním, ne? Reagoval jsem jednoduše na "otázku pro badatele" - rád bych aby bylo snadné vyhledávat v obou "módech"). Pokud by badatelé chtěli pracovat přímo s dokumenty v TEI, pak se s jednotlivými entitami vypisovat musí (i tam mi ale přijde lepší varianta specifických entit).

S tím souvisí hned ten další bod, tedy kategorizace entit, která usnadní hledání (1. hledat všechny rozpoznané entity, 2. v rámci rozpoznaných entit hledat všechna pojmenování, hledat všechny časové údaje... 3. v rámci pojmenování hledat pouze jména osob, pouze geografická jména... 4. v rámci jmen osob hledat pouze křestní jména, příjmení, geografické tituly)

Tedy jsem pro použití specifických elementů (dle mého pohledu je to vstřícnější a přehlednější pro práci s TEI) a zároveň pro vytvoření kategorií pro Feeder, které jednotlivé elementy sdružují (což je např. v NameTag pouze částečně) - entity by pak mohly být zařazeny i do více kategorií (chtělo by to navíc i kategorizaci, která zohledňuje vnořování, jako např. u Schwarzenberga, kde je geografické pojmenování součástí jména osoby; to do toho ale možná vnáší až přílišnou variabilitu)

Případně též aby bylo snadné uživatelsky navolit jaké entity hledám (na základě seznamu rozpoznávaných entit), tedy vytvářet si vlastní kategorie (včetně možnosti vnořování - např. hledat pouze geografická pojmenování, která jsou součástí adres).

hlageek commented 3 years ago

Mě přijde, že se nad tím @daliboris pečlivě zamyslel. Bohužel TEI není moje doména a nemohu to kriticky posoudit. Ale líbí se mi to zaměření na to, aby zvolený zápis v TEI předpokládal větší flexibilutu NameTagu (navíc teoreticky můžeme zvolit i jiný tagovací nástroj, takže univerzálnější řešení jsou lepší). Beru to tak, že když nechci TEI, stáhnu si TSV/JSON s kategoriemi aktuální verze NameTagu. @valekfrantisek Já počítám s tím, že v TEI Feeder hledat nebude, to už si každý badatel bude muset zařídit sám u sebe. Ale rozumím těm poznámkám a myslím, že důležité bude mít TEI model dobře a uživatelsky přívětivě zdokumentovaný.

daliboris commented 3 years ago

První ukázka TEI

V příloze TEI.zip najdete ukázku převodu publikace Vznik a uznání Československého státu z repozitáře MZK.

Výsledek vznikl pomocí aplikace napsané v XProc 3.0, k jejímu spouštění používám volně dostupnou implementaci v Javě MorganaXProc-III.

Aplikace zatím umí následující:

Co zatím aplikace neumí:

Zjištěné problémy:

Je to podle mě dobrý základ pro to, abychom mohli stanovit, jaké elementy a atributy jsme schopni z dostupných dat získat a poskytnout uživatelům.

psekan commented 3 years ago

Druhý prototyp TEI generovaného z Kramerius+

Ďakujeme @daliboris za doplnenie ďalších elementov a ukážky, ako správne formátovať rozpoznané entity P a T z NameTagu. Na adrese https://drive.google.com/drive/u/0/folders/1z2KeWwoZrAvFcvVhGObsMJBJiIS7Y8I8 je dostupná druhá verzia transformovaného dokumentu https://dnnt.mzk.cz/view/uuid:bd3b89f0-1396-11eb-a4cf-005056827e52?page=uuid:189d4d39-8862-4bb8-9e51-b7d914a4087a

Zapracovali sme:

Chýba nám zapracovať (sú označené ako TODO):

Pokračujeme tak na zapracovaní týchto nedostatkov a budeme v blízkej dobe zasielať ďalšiu ukážku TEI. Máme ale jednu otázku k transformácií entity T: Ako transformovať bloky, ktoré nie sú správne rozpoznané ako napríklad tento:

    <group type="T" ana="#nametag-T">
        <date ana="#nametag-td">
            <w n="9" lemma="8" pos="NUM" msd="NumForm=Digit|NumType=Card">8</w>
        </date>
        <time ana="#nametag-th">
            <w n="10" lemma="—" pos="SYM" msd="ConjType=Oper">—</w>
        </time>
        <time ana="#nametag-th">
            <w n="11" lemma="38" pos="NUM" msd="NumForm=Digit|NumType=Card">38</w>
        </time>
    </group>

Ak v NameTag entite T nie je entita td, tm aj ty, tak nevieme previesť blok na format <date when="...">. Čím nahradiť tag group v takomto prípade? Pripadne, ako nestratiť informáciu o viacerých rozpoznaných entitách pri ich zlúčení do jedného tagu?

Doplňujúce informácie:

psekan commented 3 years ago

Tretí prototyp TEI generovaného z Kramerius+

Na adrese https://drive.google.com/drive/u/0/folders/1z2KeWwoZrAvFcvVhGObsMJBJiIS7Y8I8 je dostupná tretia verzia transformovaného dokumentu https://dnnt.mzk.cz/view/uuid:bd3b89f0-1396-11eb-a4cf-005056827e52?page=uuid:189d4d39-8862-4bb8-9e51-b7d914a4087a

Zapracovali sme:

Zostáva zapracovať:

Väčšina group tagov už bola odstránená, zostávajú iba tagy group z rozpoznaných entit P z NameTagu (zapracujeme podľa ukážok vyššie od @daliboris ), časť tagov z entity T, ktoré boli pravdepodobne zle rozpoznané ako časový údaj a časť tagov z entity C (tieto nevieme ako upraviť). Ukážky:

Entita T:

<group type="T" ana="#nametag-T">
    <date ana="#nametag-td">
        <w n="9" lemma="8" pos="NUM" msd="NumForm=Digit|NumType=Card">8</w>
    </date>
    <time ana="#nametag-th">
        <w n="10" lemma="—" pos="SYM" msd="ConjType=Oper">—</w>
    </time>
    <time ana="#nametag-th">
        <w n="11" lemma="38" pos="NUM" msd="NumForm=Digit|NumType=Card">38</w>
    </time>
</group>

Entita C

<group type="C" ana="#nametag-C">
    <orgName ana="#nametag-mn">
        <w n="10" lemma="Arcanum" pos="NOUN" msd="Case=Nom|Foreign=Yes|Gender=Neut|Number=Sing|Polarity=Pos">Arcanum</w>
    </orgName>
    <objectName type="artefact" ana="#nametag-oa">
        <w n="11" lemma="divinae" pos="ADJ" msd="Degree=Pos|Foreign=Yes|Polarity=Pos">divinae</w>
    </objectName>
</group>
daliboris commented 3 years ago

Komentář k 3. verzi

Obecně k chybám rozpoznání

Z ukázek je zřejmě, že např. NameTag nedokáže vždy správně rozpoznat záměr autora. Může to být chybou rozpoznání OCR, špatným rozčleněním textu na odstavce, stářím textu, tj. textem, na nějž nebyl NameTag natrénován.

Primárním cílem DL4DH není opravovat využívané nástroje, může jít o sekundární cíl, kterému poslouží vytvořená data.

Proto navrhuju ponechat chyby v rozpoznaných datech a pokusit se je převést do cílových formátů (TEI, CSV ap.), které by byl formálně validní, i když co do obsahu částečně chybové. Rozhodně by na to měl být upozorněn uživatel.

Víceúrovňové entity

Uvažoval jsem, že by se uváděla jenom nejvyšší rozpoznaná entita (např. <date> pro datum) a podřízené rozpoznané entity týkající se jednotlivých slov (elementů <w>; např. dne, měsíce a roku pro části data) by se zrušily a analytická informace (hodnoty atribut @nana přebírané z aplikace NameTag) se přesunula k podřízenému elementu <w>. Tím by se ale pořadová čísla (kde jde o kombinaci <w> a <pc>) řešila jinak než např. označení měsíce názvem. V rámci jednotnosti tedy doporučuju zachovat vnořené entity jako samostatné obalující elementy.

Odstavce

Myslím, že rozčlenění do odstavců (pomocí elementů <p>) nebude se současnými podklady (ALTO) možné, protože tam tato informace není obsažena. Ostatně když se v Krameriovu podíváte na textový přepis stránky (ikona T), text je slitý do jednoho odstavce.

Tady vidím dvě možnosti:

Elementy <extent>, <publicationStmt> a <sourceDesc>

Uvedené prvky mají být podřízené elementu <fileDesc>, nyní jsou přímým potomkem elementu <teiHeader>.

Hodnota atributu @when

Pravidla TEI pro hodnotu atributu @when říkají, že hodnoty pro měsíc a den musejí být dvoumístné, tj. v případě potřeby musejí být doplněny vodicí nulou, takže např.:

<date ana="#nametag-T" when="1897-04-1">
    <w n="6" lemma="1" pos="NUM" msd="NumForm=Digit|NumType=Card" ana="#nametag-td">1</w>
    <pc n="7" join="left" ana="#nametag-td">.</pc>
    <w n="8" lemma="duben" pos="NOUN" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos" ana="#nametag-tm">dubna</w>
    <w n="9" lemma="1897" pos="NUM" msd="NumForm=Digit|NumType=Card" ana="#nametag-ty">1897</w>
</date>

je potřeba upravit na

<date ana="#nametag-T" when="1897-04-01">

Pokud chybí rok, nahradí se pomlčkou, pokud chybí měsíc, údaj se vynechá, v obou případech se oddělovací pomlčky ponechají; zleva doprava se údaje vynechají včetně navazující pomlčky, takže např.

     <date when="1962-10-01">1st October of 1962</date>
     <date when="   --10-01">1st October</date>
     <date when="     ---01">1st day in month</date>
     <date when="   --10   ">October</date>
     <date when="1962-10">October of 1962</date>
     <date when="-0060">60 BC</date>

Příklad z ukázky:

<group type="T" ana="#nametag-T">
    <date ana="#nametag-tm">
    <w n="78" lemma="září" pos="NOUN" msd="Case=Gen|Gender=Neut|Number=Sing|Polarity=Pos">září</w>
    </date>
    <date ana="#nametag-ty">
    <w n="79" lemma="1892" pos="NUM" msd="NumForm=Digit|NumType=Card">1892</w>
    </date>
</group>

Je možné zachytit jako:

<date ana="#nametag-T" when="1892-09">
 <date ana="#nametag-tm" when="--09">
   <w n="78" lemma="září" pos="NOUN" msd="Case=Gen|Gender=Neut|Number=Sing|Polarity=Pos" ana="#nametag-tm">září</w>
 </date>
 <date ana="#nametag-ty" when="1892">
  <w n="79" lemma="1892" pos="NUM" msd="NumForm=Digit|NumType=Card" ana="#nametag-ty">1892</w>
 </date>
</date>

Odpověď na dotaz k nevalidnímu datu

NameTag chybě interpretuje zápis a v rámci nadřazené entity nebo jedné z podřazených entit není možné je převést na validní zápis v TEI.

V tomto případě doporučuju ponechat maximum možných údajů a nevalidní údaje neuvádět. Je možné ponechat textovou podobu (elementy <date>, popř. <time> a <w>) a vynechat atribut @when, který by nebyl validní.

Takže příklad

<group type="T" ana="#nametag-T">
    <date ana="#nametag-td">
        <w n="9" lemma="8" pos="NUM" msd="NumForm=Digit|NumType=Card">8</w>
    </date>
    <time ana="#nametag-th">
        <w n="10" lemma="—" pos="SYM" msd="ConjType=Oper">—</w>
    </time>
    <time ana="#nametag-th">
        <w n="11" lemma="38" pos="NUM" msd="NumForm=Digit|NumType=Card">38</w>
    </time>
</group>

by se zpracoval následovně:

<date ana="#nametag-T">
 <date ana="#nametag-td" when="---08">
  <w n="9" lemma="8" pos="NUM" msd="NumForm=Digit|NumType=Card">8</w>
 </date>
 <time ana="#nametag-th">
  <w n="10" lemma="—" pos="SYM" msd="ConjType=Oper">—</w>
 </time>
 <time ana="#nametag-th">
  <w n="11" lemma="38" pos="NUM" msd="NumForm=Digit|NumType=Card">38</w>
 </time>
</date>

Atributy u elementu <pc>

Atributy @lemma, @pos a @msd doporučuju u elementu <pc> ponechat, a to kvůli jednotnému zpracování, a tedy i předvídatelným výsledkům u statistických analýz. Pokud bude uživatel dělat statistiku lemmat v textu na základě atributu @lemma, interpunkce by se mu do přehledu nedostala.

Srov. např. dotaz XPath v případě, že @lemma u <pc> nebude:

distinct-values(//@lemma | //pc/.)

a když bude:

distinct-values(//@lemma)

Je také (spíš teoreticky) možné, že různá interpunkční znaménka budou mít stejné lemma, například znaky , (Comma) ， (Fullwidth Comma) a ﹐ (Small Comma).

Elementy <group type='C'>

Jde o jeden z případů chybného rozpoznání. Skupina C se používá pro bibliografické položky, čemuž v TEI odpovídá element <bibl>. V textu ukázkové publikace se jedná o názvy encyklik, takže to svým způsobem bibliografické citace jsou.

V tomto případě navrhuju použít element <objectName> s atributem @type="bibliography".

Nelze použít element <bibl>, protože nadřízeným prvkem je zde <s>, jehož nemůže být <bibl>.

<objectName type="bibliography" ana="#nametag-C">
 <orgName ana="#nametag-mn">
  <w n="10" lemma="Arcanum" pos="NOUN" msd="Case=Nom|Foreign=Yes|Gender=Neut|Number=Sing|Polarity=Pos">Arcanum</w>
 </orgName>
 <objectName type="artefact" ana="#nametag-oa">
  <w n="11" lemma="divinae" pos="ADJ" msd="Degree=Pos|Foreign=Yes|Polarity=Pos">divinae</w>
 </objectName>
</objectName>

Pokud by byl prvek <group type="C" ana="#nametag-C"> jediným elementem podřízeným prvkům <p><s>, pak bychom mohli hierarchii <p><s><group type="C" ana="#nametag-C"> převést na <p><bibl>. Tj.

<p>
 <bibl ana="#nametag-C">
  <orgName ana="#nametag-mn">
   <w n="1" lemma="Arcanum" pos="NOUN" msd="Case=Nom|Foreign=Yes|Gender=Neut|Number=Sing|Polarity=Pos">Arcanum</w>
  </orgName>
  <objectName type="artefact" ana="#nametag-oa">
   <w n="2" lemma="divinae" pos="ADJ" msd="Degree=Pos|Foreign=Yes|Polarity=Pos">divinae</w>
  </objectName>
 </bibl>
</p>

Víceúrovňové obalování tagu a umístění atributu @ana

O umístění atributu @ana rozhoduje to, jestli element TEI věcně koresponduje s druhem rozpoznané entity.

Např. entitě typu gu (obce, hrady a zámky) odpovídá TEI element <settlement> (contains the name of a settlement such as a city, town, or village identified as a single geo-political or administrative unit), zatímco <placeName> (contains an absolute or relative place name) je sémanticky o úroveň výš a může být dále rozděleno na menší části, které korespondují s rozpoznanými entitami.

V mé ukázce to bylo chybně, ve vaší je to v pořádku. Děkuju za opravu.

daliboris commented 3 years ago

Upravil jsem své procedury XProc, abych se ve zpracování dostal na vaši úroveň. Příklad s entitou typu C mi vyšel daleko strukturovanější, tj. už na straně rozpoznání v NameTagu se objevilo více úrovní a entit. Takto vypadá moje transformace na TEI:

<objectName type="bibliography" ana="#nametag-C">
 <orgName ana="#nametag-mn">
  <w n="10" lemma="Arcanum" pos="NOUN" msd="Case=Nom|Foreign=Yes|Gender=Neut|Number=Sing|Polarity=Pos">Arcanum</w>
 </orgName>
 <objectName type="artefact" ana="#nametag-oa">
  <w n="11" lemma="divinae" pos="ADJ" msd="Degree=Pos|Foreign=Yes|Polarity=Pos">divinae</w>
  <w n="12" lemma="z" pos="ADP" msd="AdpType=Voc|Case=Gen">ze</w>
  <w n="13" lemma="den" pos="NOUN" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos">dne</w>
 </objectName>
 <date ana="#nametag-T" when="--02-10">
  <date ana="#nametag-td" when="---10">
   <w n="14" lemma="10" pos="NUM" msd="NumForm=Digit|NumType=Card">10</w>
   <pc n="15" lemma="." pos="PUNCT" msd="_">.</pc>
  </date>
  <date ana="#nametag-tm" when="--02">
   <w n="16" lemma="únor" pos="NOUN" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos">února</w>
  </date>
 </date>
</objectName>
daliboris commented 3 years ago

Chtěl jsem se zeptat, odkud ve formátu TEI přebíráte údaj pro označení strany, tedy atribut @n, např. <pb n="[1b]"/>?

V dokumentu FOXML se mi ho nepodařilo najít.

daliboris commented 3 years ago

Upravil jsem ODD pro DL4DH, aby odpovídalo aktuální dohodnuté podobě TEI a bylo možné dokumenty validovat pomocí RNG nebo XSD. ODD_v02.zip

psekan commented 3 years ago

Na získavanie označenia strany využíva kolega API endpoint https://kramerius.mzk.cz/search/api/v5.0/item/uuid:08229f06-e6e3-4686-af5e-382b63d9d86f a pre získanie plaintextu zas API endpoint https://kramerius.mzk.cz/search/api/v5.0/item/uuid:08229f06-e6e3-4686-af5e-382b63d9d86f/streams/TEXT_OCR (pre porovnanie, prečo NameTag spustený nad Vami zadaný text vracia iný výsledok ako nám).

Pripomienky z komentára ku 3. verzií zapracovávame a zajtra sa budeme prezentovať ďalšie zapracované zmeny.

Zvláštne je, že u Vás obalil NameTag entitou C dlhší úsek ale kvôli tomu zdá sa, že oddelilo rok od entity T. Naša ukážka tej pasáže:

<group type="C" ana="#nametag-C">
    <orgName ana="#nametag-mn">
        <w n="10" lemma="Arcanum" pos="NOUN" msd="Case=Nom|Foreign=Yes|Gender=Neut|Number=Sing|Polarity=Pos">Arcanum</w>
    </orgName>
    <objectName type="artefact" ana="#nametag-oa">
        <w n="11" lemma="divinae" pos="ADJ" msd="Degree=Pos|Foreign=Yes|Polarity=Pos">divinae</w>
    </objectName>
</group>
<w n="12" lemma="z" pos="ADP" msd="AdpType=Voc|Case=Gen">ze</w>
<w n="13" lemma="den" pos="NOUN" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos">dne</w>
<date ana="#nametag-T" when="1880-02-10">
    <w n="14" lemma="10" pos="NUM" msd="NumForm=Digit|NumType=Card" ana="#nametag-td">10</w>
    <pc n="15" join="left" ana="#nametag-td">.</pc>
    <w n="16" lemma="únor" pos="NOUN" msd="Animacy=Inan|Case=Gen|Gender=Masc|Number=Sing|Polarity=Pos" ana="#nametag-tm">února</w>
    <w n="17" lemma="1880" pos="NUM" msd="NumForm=Digit|NumType=Card" ana="#nametag-ty">1880</w>
</date>
daliboris commented 3 years ago

Už vím, v čem je rozdíl: pokud přebíráte text z endpointu pro OCR, text je rozdělen do řádků, tj. konkrétně takto:

poměru manželského. Často к tomuto předmětu se vrací
a zvláštní encykliku Arcanum divinae ze dne 10. února 1880
mu věnuje. Rodina jest svazkem logicky i historicky dřívějším

Při svém zpracování převedu nejdříve ALTO na TEI a následně TEI na prostý text, čímž zmizí rozdělení na řádky (i na odstavce). Takže můj textový vstup pro NameTag a UDPipe vypadá následovně:

poměru manželského. Často к tomuto předmětu se vrací a zvláštní encykliku Arcanum divinae ze dne 10. února 1880 mu věnuje. Rodina jest svazkem logicky i historicky dřívějším

Takové odlišné rozdělení slov (mezerou versus odstavcem) má pak vliv na rozpoznávací schopnosti zmíněných aplikací.

stranak commented 3 years ago

Text je určitě třeba brát z ALTO, jak to dělá @daliboris už proto, že tam je ošetřeno dělení slov, jen na této straně je to 11 slov, která jsou v plaintextu z OCR špatně (rozdělená natvrdo). 

  <String CONTENT="Sa" HEIGHT="44" WIDTH="67" VPOS="741" HPOS="1834" SUBS_TYPE="HypPart1" SUBS_CONTENT="Sapientiae"/>
...
</TextLine>
<TextLine BASELINE="842" HEIGHT="56" WIDTH="1661" VPOS="799" HPOS="266">
  <String CONTENT="pientiae" HEIGHT="53" WIDTH="268" VPOS="799" HPOS="266" SUBS_TYPE="HypPart2" SUBS_CONTENT="Sapientiae"/>

tedy pokud je SUBS_TYPE="HypPart1" , pak forma = SUBS_CONTENT. Následně na dalším řádku 1. slovo, má mít SUBS_TYPE="HypPart2" a identickou hodnotu SUBS_CONTENT a pak toto slovo přeskočit.

Řeší TEI nejen semantiku textu, ale i formu? Tedy konce řádek, dělení slov...? Pokud ano, mělo by se to zachovat. Obzvláště pokud to souvisí, např. ty části sázené pro zdůraznění proloženě (s většími mezerami mezi znaky). Pokud ale TEI vzhled neřeší a chce jen semantiku, tak rozdělení zahodit (= formu slova brát z atributu: pokud je SUBS_TYPE="HypPart1" , pak forma = SUBS_CONTENT. Následně slovo, které má SUBS_TYPE="HypPart1" přeskočit ), ale nějak řešit třeba to proložení, něco jako <emph>. Pak ale bych uživateli poskytl volitelně vedle TEI i to ALTO.

  • novější nástroje pro OCR dokážou odstavce identifikovat a ve výstupu zachytit

Pokud by se měl použít novější nástroj, případně i jiný než Recognita Server užívaný dosud, musí se to rozhodnout nyní, protože výstup do ALTO se bude skoro určitě lišit ve více věcech.

  • na základě analýzy formátu ALTO bychom se o nějakou identifikaci odstavce pokusili my (až pokud bude čas)
    • na základě výrazně nízké hodnoty atributu TextLine\@WIDTH ve srovnání s předchozími elementy TextLine
    • na základě výrazně odlišné hodnoty atributu TextLine\@HPOS ve srovnání s předchozími elementy TextLine

Analýza layoutu na základě těch grafických informací (souřadnice, velikosti, atd.) ve výstupu z OCR je nepochybně velmi žádoucí a co jsem hledal, nemá to hotové asi nikdo. Daly by se takto identifikovat sloupce textu, spojovat články, přiřazovat nadpisy, obrázky a jejich popisy, atd. Podle mě je to ale rozsahem a obtížností na samostatný projekt.

bodnarIQ commented 3 years ago

Ako bolo zmienené na meetingu 28.07.2021, prikladám sem raw vstup z aplikácie Kramerius+ do sluzby NameTag spolu s odosielanými parametrami:

data=

poměru
manželského
.
Často
к
tomuto
předmětu
se
vrací
a
zvláštní
encykliku
Arcanum
divinae
ze
dne
10
.
února
1880
mu
věnuje
.
Rodina
jest
svazkem
logicky
i
historicky
dřívějším

output=conll; input=vertical;

psekan commented 2 years ago

Štvrtý prototyp TEI generovaného z Kramerius+

Na adrese https://drive.google.com/drive/u/0/folders/1z2KeWwoZrAvFcvVhGObsMJBJiIS7Y8I8 je dostupná štvrtá verzia transformovaného dokumentu https://dnnt.mzk.cz/view/uuid:bd3b89f0-1396-11eb-a4cf-005056827e52?page=uuid:189d4d39-8862-4bb8-9e51-b7d914a4087a

Zároveň sme vygenerovali TEI aj pre dokumenty https://dnnt.mzk.cz/view/uuid:84e676e0-a796-11e9-9209-005056827e51 a https://dnnt.mzk.cz/view/uuid:3c4c3540-3130-11ea-b0e3-005056827e52 pre kontrolu voči TEI, ktoré generovalo @daliboris a skúmanie špecifických prípadov na rozsiahlejšom diele.

Zapracovali sme:

Zostáva zapracovať:

psekan commented 2 years ago

Piaty prototyp TEI generovaného z Kramerius+

Na adrese https://drive.google.com/drive/u/0/folders/1z2KeWwoZrAvFcvVhGObsMJBJiIS7Y8I8 je dostupná piata verzia transformovaného dokumentu https://dnnt.mzk.cz/view/uuid:bd3b89f0-1396-11eb-a4cf-005056827e52

Zapracovali sme:

Konkrétne sme zapracovali prvé dve prípady pre entitu P z komentára https://github.com/LIBCAS/DL4DH-TEI-Converter/issues/2 podľa nasledujúceho pravidla: Ak rozpoznaná entita P obsahuje priamych potomkov iba elementy forename, placename, abbr, w a p, je jej odstránený atribút type a ana a zmenený tag z group na persName.

Zvyšné dva prípady sú spôsobené nástrojom NameTag, ktorý nám vratil iný výsledok ako Vám. Konkrétne sa jedná o prípad zo stránky https://dnnt.mzk.cz/view/uuid:bd3b89f0-1396-11eb-a4cf-005056827e52?page=uuid:189d4d39-8862-4bb8-9e51-b7d914a4087a ktorej OCR spracujeme cez nástroj UDPipe a výsledok (dostupný na https://drive.google.com/file/d/1oS2gTbG4D1pLINdNiY0kFndujqNPM1E9/view?usp=sharing pre možnosť replikácie výsledky) vkladáme do nástroja NameTag s nastavením inputu na Vertical. Slová Eminencí splnomocněn sú nespravné rozpoznané ako time expression a preto je v našom TEI element date namiesto persName. Toto je chyba nástroja NameTag (pre nás tretej strany) a nie chyba nášho konvertora.

daliboris commented 2 years ago

Srovnání rozpoznaných vět a entit pro vstup typu prostý text a vertikála

Identifikace vět

Identifikace vět na základě prostého textu v rámci UDPipe a NameTag: identická.

Identifikace entit

Rozdíly v rozpoznaných entitách (ve formátu XML). Nejdříve se vstupem v podobě prostého textu, pak vertikály. (Bohužel neumím dostat v Markdownu dostat XML do tabulky a výsledky zarovnat.)

Z uvedených 12 rozdílů vyplývá, že rozpoznání pomocí prostého textu dává o něco lepší výsledky (7 z 12). (Pro ukázkovou stranu bylo celkově rozdílů víc, snažil jsem se vybrat reprezentativní/odlišné případy.)

Srovnávané výstupy (prostý text × vertikála): NameTag-PlainText2Xml-1sentence.zip × NameTag-Vertical2Xml.zip

Je ale s podivem, že různé vstupní formáty můžou vrátit tak rozdílné výsledky.

prostý text 1 (lepší výsledek)

ps = příjmení

pf = křestní jméno

<ne type="oa">
 <token>Jeho</token>
 <token>Svatosti</token>
 <token>papeže</token>
 <ne type="P">
  <ne type="pf">
   <token>Lva</token>
  </ne>
  <ne type="ps">
   <token>XIIL</token>
  </ne>
 </ne>
</ne>

vertikála 1

pp = náboženské postavy, pohádkové a mytické postavy, personifikované vlastnosti

<ne type="oa">
 <token>Jeho</token>
 <token>Svatosti</token>
 <token>papeže</token>
 <ne type="pp">
  <token>Lva</token>
  <token>XIIL</token>
 </ne>
</ne>

prostý text 2

pm = druhé křestní jméno

io = státní a mezinárodní instituce, politické strany a hnutí, náboženské skupiny

<ne type="io">
 <token>Veličenstva</token>
 <token>císaře</token>
 <token>a</token>
 <token>krále</token>
 <ne type="P">
  <ne type="pf">
   <token>Františka</token>
  </ne>
 </ne>
</ne>
<ne type="P">
 <ne type="pm">
  <token>Josefa</token>
 </ne>
</ne>
<ne type="io">
 <ne type="P">
  <ne type="no">
   <token>I</token>
  </ne>
 </ne>
</ne>
<ne type="P">
 <ne type="no">
  <token>.</token>
 </ne>
</ne>

vertikála 2 (lepší výsledek)

pm = druhé křestní jméno

<token>Veličenstva</token>
<token>císaře</token>
<token>a</token>
<token>krále</token>
<ne type="P">
 <ne type="pf">
  <token>Františka</token>
 </ne>
 <ne type="pm">
  <token>Josefa</token>
 </ne>
 <ne type="no">
  <token>I</token>
  <token>.</token>
 </ne>
</ne>

prostý text 3 (lepší výsledek)

<ne type="p_">
 <token>Eminencí</token>
</ne>
<token>nejdùst</token>
<token>.</token>

vertikála 3

<ne type="p_">
 <token>Eminencí</token>
 <token>nejdùst</token>
 <token>.</token>
</ne>

prostý text 4 (lepší výsledek)

pm = druhé křestní jméno

<ne type="P">
 <ne type="pf">
  <token>Františka</token>
 </ne>
 <ne type="pm">
  <token>de</token>
 </ne>
 <ne type="pm">
  <token>Paula</token>
  <token>hraběte</token>
  <token>ze</token>
 </ne>
 <ne type="gu">
  <token>Schonbornů</token>
 </ne>
</ne>

vertikála 4

ps = příjmení

<ne type="P">
 <ne type="pf">
  <token>Františka</token>
 </ne>
 <ne type="ps">
  <token>de</token>
 </ne>
 <ne type="pm">
  <token>Paula</token>
 </ne>
 <ne type="ps">
  <token>hraběte</token>
  <token>ze</token>
 </ne>
 <ne type="gu">
  <token>Schonbornů</token>
 </ne>
</ne>

prostý text 5 (lepší výsledek)

<token>osvětlen</token>
<token>.</token>
<token>V</token>
<token>.</token>
<token>háji</token>

vertikála 5

  <token>osvětlen</token>
  <token>.</token>
  <ne type="pf">
   <token>V</token>
   <token>.</token>
  </ne>
  <token>háji</token>

prostý text 6 (částečně lepší výsledek)

p = jméno osoby nespecifikovaného typu / nezařaditelné do ostatních typů

<ne type="p_">
 <token>Veličenstva</token>
</ne>

vertikála 6

pp = náboženské postavy, pohádkové a mytické postavy, personifikované vlastnosti

<ne type="pp">
 <token>Veličenstva</token>
</ne>

prostý text 7

td = den

<ne type="td">
 <token>7</token>
 <token>.</token>
</ne>
<token>hodině</token>

vertikála 7 (lepší výsledek)

th = hodina

<ne type="th">
 <token>7</token>
</ne>
<token>.</token>
<token>hodině</token>

prostý text 8 (obojí špatně)

pf = křestní jméno

<token>Jeho</token>
<ne type="pf">
 <token>Jasnost</token>
</ne>

vertikála 8 (obojí špatně)

oa = kulturní artefakty (knihy, filmy stavby,...)

<token>Jeho</token>
<ne type="oa">
 <token>Jasnost</token>
</ne>

prostý text 9

<ne type="P">
 <ne type="pd">
  <token>Thlg</token>
  <token>.</token>
 </ne>
 <ne type="pd">
  <token>Dr</token>
  <token>.</token>
 </ne>
 <ne type="pd">
  <token>Frant</token>
  <token>.</token>
 </ne>
</ne>
<ne type="ps">
 <token>Hrádek</token>
</ne>

vertikála 9 (lepší výsledek)

<ne type="P">
 <ne type="pd">
  <token>Thlg</token>
  <token>.</token>
 </ne>
 <ne type="pd">
  <token>Dr</token>
  <token>.</token>
 </ne>
 <ne type="pf">
  <token>Frant</token>
  <token>.</token>
 </ne>
 <ne type="ps">
  <token>Hrádek</token>
 </ne>
</ne>

prostý text 10

gu = obce, hrady a zámky

<ne type="gu">
 <token>Králohradecko</token>
</ne>

vertikála 10 (lepší výsledek)

gr = menší územní jednotky

<ne type="gr">
 <token>Králohradecko</token>
</ne>

prostý text 11 (částečně lepší výsledek)

pp = náboženské postavy, pohádkové a mytické postavy, personifikované vlastnosti

<ne type="pp">
 <token>Eminencí</token>
</ne>
<token>splnomocněn</token>

vertikála 11 (zcela mimo kategorii)

tf = svátky a významné dny

<ne type="tf">
 <token>Eminencí</token>
 <token>splnomocněn</token>
</ne>

prostý text 12 (lepší výsledek)

no = číslo s významem pořadí

<token>Papež</token>
<ne type="P">
 <ne type="pf">
  <token>Lev</token>
 </ne>
 <ne type="no">
  <token>XIII</token>
  <token>.</token>
 </ne>
</ne>

vertikála 12

ps = příjmení

<token>Papež</token>
<ne type="P">
 <ne type="pf">
  <token>Lev</token>
 </ne>
 <ne type="ps">
  <token>XIII</token>
  <token>.</token>
 </ne>
</ne>
daliboris commented 2 years ago

Úpravy výstupního TEI

Připomínky na základě schůzky 22. 9. 2021.

<encodingDesc>
  <appInfo>
  <application xml:id="NameTag" ident="NameTag" version="2" from="2021-09-23T22:20:00" to="2021-09-23T22:21:00">
    <label>NameTag, model: czech-cnec2.0-200831</label>
  </application>
  </appInfo>
  <appInfo>
  <application xml:id="UDPipe" ident="UDPipe" version="2" from="2021-09-23T22:22:00" to="2021-09-23T22:23:00">
    <label>UDPipe, model: czech-pdt-ud-2.6-200830</label>
  </application>
  </appInfo>
  <appInfo>
  <application xml:id="TEIConvertor" ident="TEIConvertor" version="0.5.6" when="2021-10-01T15:30:00" />
  </appInfo>   
</encodingDesc>
psekan commented 2 years ago

Aktuálny stav TEI Convertora

@daliboris

Zapracovali sme (zatial do TEI Convertora, Kramerius+ bude niektore informacie Convertoru poskytovat neskor):

Potrebujeme upraviť ODD:

Očakávame:

Otvorené body:

daliboris commented 2 years ago

fix atributu s uuid (nemohli sme použiť iba uuid, nakoľko niekedy začína číslom a to nie je validný NCName v XML)

Podle dokumentace FOXML je atribut @PID jedinečný idnetifikátor. Digitální knihovna využívá textový řetězec ve formátu prefixu "uuid:" a jedinečného idntifikátoru typu GUID.

V dokumentu TEI se identifikátor odkazující na objekt FOXML objevuje jakožto obsah elementu <idno> (např. <idno type="mods:uuid">57f3ff20-9ee3-11e3-8b69-005056825209</idno>). Nepoužívá se nikde jako hodnota atributu @xml:id.

V metadatech typu MODS se GUID objevuje jako samostatná hodnota, tj. bez prefixu, např. <mods:identifier type="uuid">57f3ff20-9ee3-11e3-8b69-005056825209</mods:identifier>. Naproti tomu v metadatech typu Doublin Core se objevuje hodnota s prefixem, např. <dc:identifier>uuid:57f3ff20-9ee3-11e3-8b69-005056825209</dc:identifier>.

Navrhuju v rámci DL4DH považovat GUID za identifikátor pro abstraktní objekt (tj. bez konkrétní realizace/serializace) typu publikace/periodikum ap. V rámci jednotlivých realizací výše zmíněného abstraktního objektu, tj. v rámci objektů reprezentovaných dokumentem/souborem typu FOXML, TEI ap. bude mít identifikátor prefix, který bude typický pro objekt konkrétního typu, tj. např. "uuid:" pro FOXML, "tei:" pro TEI.

sekanIQ commented 1 year ago

@daliboris fix atributu s uuid súvisi s tagom pb, ktorému chceme uviesť aj uuid stránky, z ktorej vychádza. Uvádzali sme to v atribúte xml:id, ktorý ale nesmie obsahovať znak : ani nesmie začínať číslom, preto nie je možné v ňom uviesť uuid:57f3ff20-9ee3-11e3-8b69-005056825209 ani napríklad 57f3ff20-9ee3-11e3-8b69-005056825209. preto tam aktuálne uvádzame uuid-57f3ff20-9ee3-11e3-8b69-005056825209, čo ale nie je ideálne. Pokiaľ viete o inom lepšom riešení, dajte nám prosím vedieť. Ak by ste o inom riešení nevedeli, uzavrieme túto issue ako vyriešenú.

daliboris commented 1 year ago

Děkuju za upozornění na mou chybu v úsudku. Máte pravdu.

Podle definice z XSD musí @xml:id splňovat následující podmínky

Zachování identifikátorů původní strany považuju také za dobrý nápad. Proto navrhuju následující vzor:

<pb xml:id="pb.857f595f-f505-49d6-9c37-e81309a70c5b" corresp="uuid:857f595f-f505-49d6-9c37-e81309a70c5b" n="[1]"/>

Atribut @xml:id strany bude začínat zkratkou pb, následovat bude tečka . a 32místný GUID původního identifikátoru objektu strany, tj. údaj za původním prefixem uuid:.

Atribut @corresp strany bude obsahovat kompletní původní identifikátor objektu strany.

Aby bylo snazší udržet korespondenci mezi původní stranou (objektem dostupným např. z Krameria) měl by být v hlavičce <teiHeader> odkaz na původní zdroj, tj. minimálně, jestli to pochází z Krameria NKP, MZK ap.