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

[psekan]

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]

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

[stranak]

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]

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á

• některé výstupy ALTO rozdělení na odstavce nemají, respektive text jedné stránky tvoří jeden odstavec, jmenovitě element <TextBlock>
  • starší OCR (grafická předloha)
  • nejnovější z projektu PERO (grafická předloha)
• <TextBlock> slouží k rozdělení na nadpisy a sloupce (nikoli odstavce) (grafická přehloha)
• nenašel jsme výstup ALTO, který by identifikoval samostatné odstavce v našem pojetí (souvislý blok textu uddělený od okolí mezerou mezi řádky nebo odsazením/předsazením prvního řádku)

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:

• z každé stránky ve formátu ALTO získat elementy <ParagraphStyle> (odstavcový styl) a <TextStyle> (znakový styl)
• transformovat vlastnosti stylu na hodnoty CSS (např. @FONTFAMILY="Arial" na font-family: Arial;)
• jedinečné hodnoty atributu String/@STYLE převést na styly
• vytvořit pro stejné styly/formátování na zůzných stránkách téže publikace identické identifikátory v TEI (srov. např. definici stylů na dvou po sobě následujících stranách:
  • <TextStyle ID="font0" FONTFAMILY="Times New Roman" FONTSIZE="9"/> a
  • <TextStyle ID="font0" FONTFAMILY="Times New Roman" FONTSIZE="8"/> + <TextStyle ID="font1" FONTFAMILY="Times New Roman" FONTSIZE="9"/>
• budou se používáat identifikátory à la ALTO (tj. font# pro znakové styly a StyleId-GUID- pro styly odstavcové), nebo zavedeme vlastní pravidla pro vytváření názvů?
  • jsen pro druhou možnost, navrhuju následující schéma:
    • font-style-001, popř. fs-001
    • paragraph-style-001, popř. ps-001
• použít identifikátor stylu v TEI na odpovídající element v textu (tj. <p>, popř. <w>, <hi> ap.), je potřeba zkombinovat původní údaje z atributů @STYLEREFS a @STYLE.

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

• používat element <fw>
• pomocí atributu @type rozlišovat pouze
  • header (tj. <TopMargin> v ALTO)
  • footer (tj. <BottomMargin> v ALTO)

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

• strana pouze s obrázky, grafická přehloha
• strana s textem a obrázky, grafická přehloha

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]

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

• jaký software se používal pro OCR (resp. generování ALTO)? zatím jsem identifikoval tyto
  • ABBYY Recognition Server 4.0 (ABBYY); ALTO verze 2 (http://www.loc.gov/standards/alto/ns-v2#)
  • czech_old_printed 2021-01-26 (Project PERO); ALTO verze 2 (http://www.loc.gov/standards/alto/ns-v2#)
• proč software czech_old_printed (Project PERO) nepoužívá údaje o stylech (odstavce, písma)?
  • je to jenom chyba v parametrech generování výstupu, nebo tyto údaje czech_old_printed generovat neumí?

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

[hlageek]

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]

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

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

[daliboris]

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