Spracovanie textu nástrojom UDPipe

[bodnarIQ]

Dobrý deň,

začal som implementovať spracovanie textov nástrojom UDPipe a narazil som na chovanie, ktorému trochu nerozumiem. Zakladám preto toto issue pre vyjasnovanie potrebných vecí počas implementácie spracovávania textov publikácií nástrojom UDPipe.

Ide konkrétne o spôsob tokenizácie. Z výstupu totižto ukladám pozíciu tokenu a narazil som na situáciu, že UDPipe pridal neexistujúci token do textu. Ide konkrétne o spracovanie vety Je potřeba jisté zralosti, řekl bych, jistého věku paternity, aby se člověk mohl stát zahradníkem amatérem., a podľa ďalších pokusov celkovo o vety obsahujúce slovo aby.

UDPipe slovo aby označil, že sa nachádza na pozícií 13-14 a neposkytol ziadne metadata okrem offsetov tokenu, na nasledujúcom riadku poskytol metadata o tokene aby (tu uz bez offsetov) a na dalsi riadok pridal slovo by spolu s metadatami (takisto bez offsetov).

Vedel by mi prosim niekto vysvetlit, preco sa toto deje, pripadne ci su aj ine slova, pri ktorych podobne spravanie mozme ocakavat a ako spracovat toto slovo? Predpokladam ze vkladat token by medzi obohatene metadata nie je ziaduce, udaje o offsetoch musim zobrat z prveho vyskytu slova a ostatne metadata z nasledujuceho riadku?

[daliboris]

Výraz aby funguje jako spojka, zároveň svým tvarem (abych, abys atp.) vyjadřuje slovesnou osobu a číslo. Proto UDPipe rozděluje tyto dvě funkce: řádek 13 (spojka) a 14 (součást slovesného tvaru).

Všimněte si, že TokenRange je pouze u řádku 13-14, na řádcích 13 a 14 již nejsou, takže tyto výrazy by se do výstupu dostat neměly.

Jiná otázka je, jak tuto dvojí informaci (spojka a slovesný tvar) zaznamenávat, pokud bychom chtěli mít pouze jednu textovou pozici (aby) a k němu obě informace. Například v Českém nádorním korpusu se tyto informace spojí do jedné a oddělí pomocí svislice.

[bodnarIQ]

Akym sposobom by sa teda tieto data mali prejavit v exportoch a TEI formate?

Zaroven som narazil na dalsiu vec s UDPipe. Pre urychlenie spracovavania by bolo dobre vyuzit davkove spracovanie a neposielat request na API UDPipe pre kazdu stranu samostatne, pretoze prave toto je uzkym hrdlom. Zaroven by ale bolo potrebne udrzat vo vystupe jednotlive strany oddelene.

Toto by bolo mozne za vyuzitia vstupneho formatu Conll, ktory podporuje posielanie komentarov, ktore sa zachovavaju vo vystupnom formate. Tym padom by sme mohli poslat celu publikaciu v jednej ziadosti, ale zaroven oddelit jednotlive strany v odpovedi napr. komentarom # newdoc. UDPipe ale pri snahe poslat data vo formate conll hlasi chybovu hlasku Cannot parse the input in 'conllu' format.

[daliboris]

Je potřeba se zeptat lingvistů, např. Radka Čecha z FF OU, jestli by jim vypadnuvší údaj chyběl.

[bodnarIQ]

Po diskusii na poslednom stretnutí znovu otváram túto tému, prikladám aktuálny stav:

Výstup z UDPip:

Spôsob ukladania v DB:

Ako to funguje:
V prípade, že sa v prvom stlpci (id) vo vystupe UDPipe nachadza viac nez jedno cislo, detekuje sa, ze ide o viactokenove slovo. V tom pripade sa z prveho riadku (28-29) extrahuje iba hodnota zo stlpca TokenRange, dalsie metadata sa zoberu z riadku 28 a riadok 29 sa preskoci.

(pozn. : TokenRange sa nezhoduje, pretoze ukazka v DB je po spracovani K+, kde vstup je extrahovany z ALTO formatu, zatial co pouzity vstup v prvom obrazku je OCR text)

[matyaskopp]

Zdravím, @stranak mě prosil o komentář k tomuto vláknu:

Na slovo aby se můžeme dívat dvěma způsoby:

1. to co vidíme v textu, tam je TokenRange definovaný, protože slovo v ortografickém zápise je
   
2. dvě slova která nesou význam a jsou každé zvlášť pověšená v syntaktickém stromečku, u nich TokenRange není, protože ta slova v ortografickém zápise nejsou
   

Akym sposobom by sa teda tieto data mali prejavit v exportoch a TEI formate?

Když jsme volili reprezentaci v TEI (v projektech ParCzech a ParlaMint), tak jsme se tento pohled snažili respektovat - tedy pokud spustím defaultní XSLT transformaci, která tiskne pouze textové uzly XML souboru, pak na výstupu dostanu pouze ortografická slova (žádná syntaktická slova se tam nepletou). Reprezentace je následovná:

<w>aby<w norm="aby" lemma="aby"/>
 <w norm="by" lemma="být"/>
</w>

a zdokumentována zde: A TEI Schema for Corpora of Parliamentary Proceedings > Normalised and syntactic words

Zaroven som narazil na dalsiu vec s UDPipe. Pre urychlenie spracovavania by bolo dobre vyuzit davkove spracovanie a neposielat request na API UDPipe pre kazdu stranu samostatne, pretoze prave toto je uzkym hrdlom. Zaroven by ale bolo potrebne udrzat vo vystupe jednotlive strany oddelene.

Pro rychlost a slušnost ke službě je určitě dobré posílat více textu najednou. Nevím přesně jaké texty zpracováváte, ale pokud budete mít větu přes zlom stránky, tak to jinak nepůjde, než posílat více stránek za sebou.
V TEI používám element <pb /> = page beginning, lze jej umístit doprostřed věty <s>. Navíc může uchovávat i další informace, například kterou stránku originálního dokumentu reprezentuje.

Toto by bolo mozne za vyuzitia vstupneho formatu Conll, ktory podporuje posielanie komentarov, ktore sa zachovavaju vo vystupnom formate. Tym padom by sme mohli poslat celu publikaciu v jednej ziadosti, ale zaroven oddelit jednotlive strany v odpovedi napr. komentarom # newdoc. UDPipe ale pri snahe poslat data vo formate conll hlasi chybovu hlasku Cannot parse the input in 'conllu' format.

Já posílám do UDPipe pouze text a pomocí TokenRange pak zpětně nahrávám data do TEI.

Poznámky k výstupům/chybám UDPipe:

• UDPipe občas nedodrží vloženou segmentaci na odstavce v plain text vstupu a špatně nasegmentuje věty: how to force new sentence ufal/udpipe#110
  Já to řeším tak, že ověřím, jestli uprostřed věty není dvojité odřádkování(= nový odstavec) a pokud ano, tak pošlu menší úsek textu, který končí problematickým místem (špatně rozseklou větou)
• relace root doprostřed stromu: Multiple root relations in sentence ufal/udpipe#144
  relaci root nahrazuji relací dep
• v kořeni stromu není relace root: Wrong deprel: punct instead of root  ufal/udpipe#145
• neexistující relace: czech-pdt-ud-2.6-200830: Crazy syntax relation <pad> ufal/udpipe#143
  nahrazuji relací dep