search

LIBCAS / DL4DH-TEI-Converter

DL4DH TEI Converter
0 stars 0 forks source link

Extrakcia doplňujúcich informácií z ALTO formátu využíteľných v TEI #5

Open psekan opened 3 years ago

psekan commented 3 years ago

Podľa dohody z 28. 7. 2021 bude využívaný formát ALTO na extrakciu plaintextu (ktorý sa ďalej spracováva nástrojmi NameTag a UDPipe) namiesto služby https://kramerius.mzk.cz/search/api/v5.0/item/<uuid>/streams/TEXT_OCR. Hlavným dôvodom je možnosť vytiahnutia doplňujúcich informácií ku textu z ALTO formátu, ktoré sa využijú pri generovaní TEI dokumentu.

Prosíme o špecifikáciu, aké údaje je možné z ALTO vytiahnuť, ktoré je možné zahrnúť v TEI formáte (@stranak @daliboris ) a boli by pre projekt/bádateľov užitočné. Najväčší prínos bol spomenutý v spracovaní informácií o odstavci. Táto informácia sa ale v ALTO formáte nenachádza priamo a musela by sa spočítavať dodatočne. Výpočet bol označený za mierne komplikovaný, vhodný na samostatný projekt. Cieľom tohto issue je spísanie priamo dostupných informácií/ľahko spracovateľných z ALTO formátu prenositeľných do TEI formátu.

Zároveň prosíme p. @stranak o spísanie argumentov pre použitie ALTO formátu, ktoré zazneli z našej strany na stretnutí.

bukovskyIQ commented 3 years ago

Dobrý den, @daliboris a @stranak, prosíme o Vaše vyjádření.

stranak commented 3 years ago

Ohledně odstavců i toho, jak případně pouštět zpracování v TEI XML souboru jsem se vyjádřil v LIBCAS/DL4DH#9 a víc k tomu asi nemám.

Na schůzce jsem řekl nikoliv to, že najít odstavce by bylo příliš náročné. Naopak, to bychom myslím udělat měli, nebo aspoň vzít odstavce, co už našel ABBYY OCR server. Co by bylo zajímavé, ale je podle mě příliš náročné, je celkově analyzovat objekty na stránkách a spojovat je do logických celků, článků ve více sloupcích s nadpisem, obrázky, které mají popisky, pokračují na jiných stranách, na konci mají podpis, apod.

daliboris commented 3 years ago

Beta verze

Problematika je komplexní, postupně ji analyzuju, na základě konkrétních příkladů. Ukazuje se, že výstupy v ALTO jsou proměnlivé (např. identifikace sloupců). Berte zatím uváděné příklady jako nefinální (zejména pokud jde o grafiku), dokud to neotestuju na několika publikacích. Finální řešení budu ověřovat úpravami transformace v XProc.

Odstavce

Identifikace

Z mých zkušeností/analýz vyplývá

Zdá, že že v pojetí ALTO znamená <TextBlock> úsek se stejným formátováním (např. stejné mezery mezi odstavci, zarovnání odstavců na střed/do bloku ap.); dokumentace je v tomto ohledu dost skoupá: A page consists of margins and printspace, all of those are non-intersection rectangular areas within the page area. Each of these can contain any number of objects like lines, images or textblocks and more. A textblock is divided into textlines and those are divided furthermore in strings and spaces.

Z toho mi vyplývá, že budeme muset rekonstruovat rozdělení na odstavce na základě formátu ALTO, jak už jsem naznačil zde.

Styly

Důležité upozornění: výstupy z projektu PERO informace o stylech vůbec neobsahují.

Identifikace

ALTO definuje styly pro odstavce pomocí elementu <ParagraphStyle>, např. <ParagraphStyle ID="StyleId-75993BD8-EA13-42E4-8B79-EF538FA3E9D4-" ALIGN="Block" LEFT="0." RIGHT="0." FIRSTLINE="0." LINESPACE="8.159999847"/>.

Fonty (písmo, velikost) se definuje pomocí elementu <TextStyle>, např. <TextStyle ID="font0" FONTFAMILY="Times New Roman" FONTSIZE="9"/>.

Na tyto styly (jejich @ID) se odkazuje u elementu <TextBlock> pomocí atributu @STYLEREFS, např. <TextBlock ID="Page1_Block4" HEIGHT="2317" WIDTH="753" VPOS="249" HPOS="946" language="cs" STYLEREFS="StyleId-75993BD8-EA13-42E4-8B79-EF538FA3E9D4- font0">.

Další vlastnisti písma se identifikují pomocí atributu @STYLE elementu <String>. Jedná se o hodnoty oddělené mezerou, např. bold, italics, subscript, superscript, subscript italics.

Pravděpodobně znáte výstupy OCR do formátovaného textu, které jsou hodně podrobné (a chybné), např. několik velikostí písma (byť v orginálu jsou jenom dvě), prostrkání písmen (byť v originálu žádné není), chybné použití kurzívy ap. Tento nesoulad mezi originálem a výsledkem OCR mě vždycky iritoval, protože komplikoval převod na bezproblémovou digitální verzi, a doufám, že se tomu v DL4DH vyhneme. Ale samozřejmě chápu i druhý pohled: pokud budeme mít tato data, můžeme je analyzovat a navrhnout lepší řešení.

Napadá mě jedno řešení: když si uživatel bude vybírat, co vše bude v exportovaném TEI, měl by možnost ne/exportovat údaje o formátování.

Styly v TEI

Formát ALTO rozlišuje styly na úrovni odstavců a znaků. V TEI se pro to používají atributy @style (à la CSS), @rend (definice stylu v atributu), nebo @rendition (odkaz na styly definované v <teiHeader> / <encodingDesc> / <styleDefDecl> / <tagsDecl> / <rendition>).

Doporučuju použít poslední způsob, tj. v hlavičce definovat styly a v samotném textu používat atribut @rendition s odkazem na definovaný styl.

Při definici stylů (jejich vlastností) je možné vycházet z existujícíh standardů. Doporučuju využívat možností standardu CSS.

Implementace

Odhaduju, že pro převod stylů z ALTO do TEI bude potřeba:

Další grafické prvky

Sloupce

Ukázka textu rozděleného do více sloupců viz např. Ottův slovník naučný a odpovídající ALTO.

Jiná strana z téhož slovníku s odlišným výstupem v ALTO

ALTO

V jednom případě jsou sloupce naznačeny pomocí elementu <ComposedBlock>, který obsahuje dva elementy <TextBlock>.

V druhém případě element <ComposedBlock> přítomen není.

V obou případech se na samostatné sloupce dá usoudit z toho, že šířka obou elementů <TextBlock> je zhruba poloviční ve srovnání s šířkou elementu <PrintSpace>.

<PrintSpace HEIGHT="2408" WIDTH="1503" VPOS="158" HPOS="196">
<TextBlock ID="Page1_Block3" HEIGHT="2320" WIDTH="739" VPOS="245" HPOS="196">
<TextBlock ID="Page1_Block4" HEIGHT="2317" WIDTH="753" VPOS="249" HPOS="946">

TEI

Pro zachycení začátku sloupce se v TEI používá prázdný element <cb>.

Implementace

V případě použití elementu <ComposedBlock> každý podřízený <TextBlock> bude považovat za sloupec, takže se v TEI na začátek sloupce umístí element <cb>. První sloupec bude mít atribut @n="1", další sloupec @n="2" atd.

Pokud element <ComposedBlock> se v ALTO neobjeví, zkusíme sloupce určit na základě šířky elementů <TextBlock>: pokud se součet TextBlock/@WIDTH blíží hodnotě PrintSpace/@WIDTH a zároveň TextBlock[1]/@HPOS + TextBlock[1]/@WIDTH se blíží hodnotě TextBlock[2]/@HPOS, jedná se o dva sloupce.

Záhlaví a zápatí

ALTO

Text v záhlaví se uvádí v rámci elementu <TopMargin>, text v zápatí se uvádí v rámci elementu <BottomMargin>.

TEI

Pro zápatí a záhlaví se v TEI používá element <fw>, pro rozlišení umístění/účelu se používá atribut @type s doporučenými hodnotami header, footer, pageNum, lineNum, catch ap.

Implementace

Grafické prvky

ALTO

Ve standardu ALTO se používají elementy <Illustration> (pro obrázky) a <GraphicalElement> pro grafický prvek oddělující bloky textu (obvykle řádek nebo obdélník).

TEI

Pro obrázky (s popiskem) se používá element <figure>, jehož součástí jsou elementy <head> (pro popisek obrázku) a <graphic> s odkazem na samotný obrázek.

Implementace

Pro element <Illustration> se v TEI použije prvek <figure> a <graphic>.

Pro element <GraphicalElement> se v TEI použije prvek <graphic>.

daliboris commented 3 years ago

Z dosavadní analýzy mi vyplynulo několik otázek:

Mohli by mi prosím kolegové z knihoven odpovědět?

hlageek commented 3 years ago

Ještě jsem se díval na již několikrát zmiňovaný nástroj grobid. Podle dokumentace si PDF zpracovává sám (nástrojem pdfalto do ALTO a teprve tento podklad zpracovává dál. Takže by asi nebylo nemyslitelné si grobid přiohnout tak, aby místo PDF bral rovnou ALTO. Pak by nám grobid vyřešil úlohy jako rozpoznávání paratextu, odstavců, citací... Zejména, pokud by nám šlo hlavně o základní textové kategorie (odstavec, paratext, titul), mohl by i bez dalšího trénování poskytovat slušné výsledky. Asi nebude prostor něco takového implementovat nyní, ale v rámci příprav pajplan (#9 ) bych považoval za vhodné nechat tam prostor pro takovou intervenci.

psekan commented 3 years ago

@daliboris Prosíme o finalizáciu Vašej analýzy, ku ktorej by sme spravili schôdzu a mohli sa baviť o konkrétnych bodoch z nej, ktoré by Kramerius+ a TEI Converter podporovali. Následne by sme toto issue uzavreli, pokiaľ nepridá ďalšie požiadavky na rozšírenie TEI formátu o iné infromácie z ALTO formátu.

sekanIQ commented 1 year ago

@daliboris pripomíname sa so špecifikovaním, aké údaje z ALTO zakomponovať do akých TEI tagov/atribútov.

daliboris commented 1 year ago

Vyřešil jsem to zatím ukázkou konverze z ALTO do TEI. Připojuju rovněž XSLT transformaci, kterou jsem upravil z tohoto zdroje: https://github.com/INL/OpenConvert/blob/master/resources/xsl/alto2tei.xsl.

Alto+Tei.zip Xslt.zip