CIDE (2007) Belaïd
Représentation des données en XML pour l’analyse d’images de documents
|
Sommaire
- Résumé
- Nous présentons dans cet article l'utilisation du standard XML à la fois pour représenter les modèles de documents ainsi que pour décrire les résultats des différentes étapes de reconnaissance. Notre choix s'est porté sur ALTO pour la structure physique issue des OCR, sur la TEI pour la représentation de la structure logique reconnue par un système dédié, et enfin sur METS pour coordonner les deux dernières. Ne voulant pas toucher aux représentations internes des outils existants, nous avons proposé des transformations type XSL pour dériver ces formats XML. Les expérimentations menées à la fois sur la reconnaissance de documents modernes au niveau macro-structurel et sur des documents anciens au niveau micro-structurel montrent comment ce choix d'association permet de conserver les données cohérentes tout au long du processus mais aussi de proposer un résultat de rétro-conversion accessible, standardisé et pérenne.
- Abstract
- This paper presents the use of XML format for document modelling and describing the results of document analysis and recognition steps. We have chosen ALTO for physical structure stemmed from OCR, TEI for logical structures and METS for the relationships between both. As the system tools representations are not homogeneous, we have proposed a series of XSL transforms for harmonization. The experiments performed on two kinds of documents: scientific with a macro-structure and historical with micro-structures show how this standard choice can maintain the coherence of data along all the processing chain.
Introduction
Cet article propose une solution au problème de la représentation des données par des standards dans l'analyse et la reconnaissance de documents (ARD). Les tâches principales des traitements à effectuer sont d'une part la reconnaissance de la structure physique (la forme) et d'autre part la reconnaissance de la structure logique (le fond) qui nécessitent toutes deux un format de représentation. De plus, comme la plupart des systèmes de reconnaissance manipulent en parallèle ces deux structures, les relations possibles entre physique et logique doivent aussi être représentées [7]. Cette dernière tâche est d'autant plus difficile que la correspondance entre structure physique et structure logique n'est jamais bijective ni unique et finalement dépend assez souvent de l'interprétation que l'utilisateur se donne du document.
Un certain nombre de formats ad hoc ont été développés pour réaliser cet objectif. Peu d'entre eux ont fait l'objet de publications ou n'ont été utilisés que dans le cadre d'une application très restreinte. Quelques travaux comme DAFS [3] existent et proposent un formalisme mais au final, aucun n'a été réellement adopté sur une période longue, laissant à penser que les solutions proposées n'étaient pas assez extensibles ou assez complètes pour résoudre un grand nombre de cas tout en respectant les besoins des utilisateurs.
Il existe pour ainsi dire autant de formats de représentation des données que de systèmes de stockage ou de reconnaissance de document. Cette grande diversité est un frein certain à l'échange des données d'un environnement à un autre, d'une plate-forme à une autre et rend souvent les sorties de certains systèmes utilisables uniquement par eux-mêmes. Le seul point commun entre les différents formats est sans doute l'adoption de plus en plus fréquente d'une représentation en XML des données. Son utilisation est déjà un grand pas vers la normalisation même s'il est rarement possible de l'utiliser directement pour échanger des données.
Afin de résoudre le problème d'interopérabilité des systèmes manipulant des documents numériques, nous avons étudié une représentation générique utilisant des formats reconnus et standardisés. La solution proposée utilise les formats XML TEI, ALTO et METS. Nous allons montrer dans cet article comment l'association de ces trois formats peut être utilisée pour représenter toutes les données provenant d'un système de reconnaissance de documents et ceci à n'importe quelle étape de l'analyse.
Structures de documents en ARD
La Figure montre les principaux composants d’un système ARD et les types des structure qui interviennent dans ces modules. Le modèle générique présente à l’entrée les deux structures physique et logique associées dans la description d’une classe de documents. De ce modèle, on génère des hypothèses de travail pour le système de reconnaissance : c’est-à-dire les objets physiques à localiser à chaque instant dans l’image en fonction du contexte connu à ce point de l’analyse et la nature du contenu associé. L’OCR quant à lui présente le résultat de la reconnaissance du moteur utilisé, généralement sous forme physique. Finalement, le document de vérité exhibe la structure attendue qui peut être comparée à celle reconnue par le système, dans un mode d’évaluation a posteriori.
Structurellement parlant, chacun de ces modules travaille sur un type de format propre dans lequel il exprime les particularités des structures employées.
- L’OCR limite sa sortie essentiellement à la production d'une structure physique même si quelques moteurs commencent à fournir maintenant quelques bribes de structure logique. Les éléments du XML propriétaire constitue une hiérarchie, décomposant des pages en blocs, des blocs en lignes et des lignes en caractères pour le texte, accompagnés d'attributs relatifs aux espacements et à la fonte.
- Le modèle générique met l'accent sur les constructeurs de structure (en ne se limitant pas qu'à la décomposition hiérarchique), et essentiellement sur les relations entre les contenants (éléments physiques) et les contenus (éléments logiques). La non bijection entre les deux structures conduit généralement à la mise en place de relation de correspondance plus ou moins complexes. Nous avons défini dans le système Graphein [8] un modèle physico-logique pour la description des structures pour la classe des articles scientifiques. Le modèle regroupe les deux structures pour des problèmes de visibilité. On distingue dans ce modèle :
- Des constructeurs de type séquence, agrégat, mosaïque et choix avec des orientations haut bas pour les deux premiers (TB : Top-Bottom), gauche-droite (LR : Left-Right), choix.
- Des séparateurs qui sont des blocs graphiques ou autres, horizontaux (HS : Horizontal Separator), verticaux (VS : Vertical Separator), etc.
- Des qualificatifs concernant les objets subordonnés, comme OPT (optionnel), REQ (obligatoire) ou OC (Optionnel Conditionnel). Cela veut dire que la présence de l'objet est tributaire d'un contexte ou d'une condition de manière générale. Ce qualificatif peut être exprimé par une fonction qui exprime la conditionnalité et permet de résoudre le problème de non bijection entre la représentation physique et le contenu logique de l'objet, comme par exemple la section courante est à cheval sur deux blocs successifs.
- Le format pivot est un schéma très simplifié qu'utilise le moteur de reconnaissance du système. Il est composé d'une hiérarchie de blocs dans des pages. Chaque bloc (texte ou image) est décrit par du texte (contenu ou description) et des catégories définissant des types de propriétés. Ces dernières sont données par des attributs. Ce format est d'abord initialisé au début par le résultat de l'OCR, puis complété au fur et à mesure par le moteur de reconnaissance.
- Le document de vérité est généralement un document écrit par l’expert et correspond à ce que l’on cherche à reconnaître dans le document. Il peut être une instance du modèle générique auquel on pourrait adjoindre le contenu. A l’heure actuelle, la littérature mentionne peu de ces cas pour les documents, dont le format reste très sommaire à cause de la complexité de la représentation de ce que l’on veut valider.
- Le modèle spécifique est une instance du modèle générique. On peut utiliser un seul modèle regroupant les deux structures ou deux modèles séparés suivant l’utilité affichée pour l’une ou l’autre des deux structures.
Idéalement, un seul format serait suffisant pour représenter tous ces modèles et faciliter le transfert des données entre les modules du système. Cependant, nous avons observé que chaque modèle utilise en général son propre format. Notre compréhension du potentiel offert par XML dans la représentation des structures documentaires nous a finalement conduit à laisser chaque modèle exprimé en XML avec sa propre structure, et à utiliser des transformations type XSL pour permettre les passages entre modèles, comme cela est montré dans la Figure 3.
Expressions des transformations
Nous allons voir dans la suite comment ces transformations s’expriment entre les formats propriétaires présentés ci-dessus. Nous n’aborderons pas dans cet article la transformation du modèle générique vers le format Pivot.
De l’OCR vers ALTO
Chaque moteur d’OCR propose en général son propre XML. Nous avons utilisé deux moteurs différents : FineReader et Omnipage. Nous allons montrer dans la suite le cas de la transformation de XML FineReader vers ALTO, en pensant que pour l’autre moteur les transformations seront globalement de même type. En général, très peu de différences existent et sont souvent au niveau du détail et non de la structure, ce qui permet de passer de l’un à l’autre sans beaucoup de difficulté. La Figure 4 montre les arbres de structures, à gauche pour FineReader, et à droite pour ALTO. On voit que ALTO a une structure orientée espace d’affichage avec une zone d’affichage.
- 1Création de l’élément Styles
L’élément Style est composé de plusieurs éléments TextStyle résumant tous les styles de texte présent dans le document (partie gauche du Tableau 1). Dans cet exemple l’ID correspond à la concaténation de chaque attribut. L’ensemble des informations permettant de créer cet élément et de valoriser ses attributs se trouve dans la balise formatting (partie droite du m).
<TextStyle
ID="Times New Roman_9._-4"
FONTFAMILY="Times New Roman"
FONTSIZE="9."
FONTSPACING="-4"
/>
|
<formatting
lang="EnglishUnitedStates"
ff="Times New Roman"
fs="9."
spacing="-4"
/>
|
On a donc: ff qui correspond à FONTMILY, fs qui correspond à FONTSIZE et spacing qui correspond à FONTSPACING. Pour réaliser cette transformation, il faut donc parcourir tous les nœuds formatting, concaténer les attributs nécessaires pour former l’ID et affecter aux attributs de TextSlyle, les attributs de formatting correspondant. Cependant plusieurs formatting peuvent posséder les mêmes attributs, il est donc préférable de n’effectuer cet algorithme que sur les formatting ne possédant de frère jumeau qui le précède dans l’arbre.
- 2Création des éléments TextBlock
L’élément Page du XML ALTO est constitué entre autre d’un élément PrintSpace qui est lui-même constitué d’un ou plusieurs éléments de type BlockType comme TextBlock (ex. partie gauche de Tableau 2). On peut trouver les informations nécessaires dans l’élément Block du XML de l’OCR (ex. partie droite du même tableau).
<TextBlock
::ID="B3"
HPOS="210"
WIDTH="1030"
VPOS="488"
HEIGHT="422“
>
|
<block
blockType="Text"
l="210"
t="488"
r="1240"
b="910 "
>
|
Nous valorisons les attributs de l’élément TextBlock de la manière suivante :
- L’ID est obtenu par concaténation de la lettre ‘B’et de la position du block dans la page. On peut donc l’obtenir de la manière suivante : concat('B',count(preceding-sibling::*)) ;
- HPOS correspond à l’attribut ‘l’ (position à gauche) ;
- VPOS correspond à l’attribut ‘t’ (position à droite) ;
- WIDTH correspond à la différence @r-@l (position à droite – position à gauche) ;
- HEIGHT correspond à la différence @b-@t (position du bas – position du haut)
Il est évident que l’on ne doit transformer un block en TextBlock, uniquement si @blockType = "text". Les autres valeurs de @blockType comme par exemple picture ou table peuvent être transformés en élément illustration. Ainsi, il est possible de transformer :
<block blockType="Table" l="400" t="226" r="664" b="492">
en :
<Illustration ID="B2" HPOS="400" WIDTH="264" VPOS="226" HEIGHT="266"/>
- 3 Création des éléments String
L’élément textLine du XML ALTO est constitué de un ou plusieurs éléments vides String (ex. partie gauche du Tableau 3). La structure du fichier issu de l’OCR est assez différente à ce niveau. En effet, le fichier XML issu de l’OCR (ex. partie droite du Tableau 3) ne représente pas directement les chaînes de caractères (mots). L’élément line est constitué de un ou plusieurs éléments formatting qui sont eux-mêmes constitués d’une suite d’éléments charParams. Il faut donc concaténer le contenu des éléments charParams contenu entre chaque espace. Ces derniers sont d’ailleurs aussi représentés par les éléments charParams.
<String
::CONTENT="Figure"
::HPOS="225"
::VPOS="543"
::WIDTH="97“
/>
|
<line baseline="568" l="225" t="543" r="1224" b="576">
<formatting lang="EnglishUnitedStates" ff="Times New Roman" fs="9." spacing="-1">
<charParams l="225" t="543" r="245" b="568" wordStart="true" wordFromDictionary="true" wordNormal="true" wordNumeric="false" <br/>wordIdentifier="false" charConfidence="52" serifProbability="100" wordPenalty="0" meanStrokeWidth="35">F</charParams>
<charParams l="246" t="543" r="256" b="568" wordStart="false" wordFromDictionary="true" wordNormal="true" wordNumeric="false" <br/>wordIdentifier="false" charConfidence="55" serifProbability="255" wordPenalty="0" meanStrokeWidth="35">I</charParams>…
|
Voici un algorithme simplifié de la création d’un élément String :
|
Début
finpour |
D'une structure logique vers la TEI
On part de l'hypothèse que l'information de structure logique est donnée soit manuellement comme par exemple lors de la création de documents de vérité soit par un système automatique pouvant sortir son propre XML propriétaire. On construit actuellement un XML spécifique qui est propre au système de reconnaissance. A terme, ce XML spécifique disparaîtra pour permettre l’utilisation directe de la TEI ou d’ALTO.
La Figure 5 montre à gauche une partie de la structure du XML spécifique (Pivot) correspondant à la description d’un bloc logique du document situé à droite.
La conversion en TEI est en général très simple car celle-ci couvre un large éventail de structures logiques. Dans les rares cas contraires, il est toujours possible d'assigner l'élément non directement transformable par un élément standard plus général ou encore de créer sa propre balise en respectant les indications TEI, ce qui permet d'avoir un fichier TEI adéquat tout en restant dans la norme.
La Figure 6 montre quatre types de bloc de XML pivot (à gauche) convertis en leur équivalent TEI (à droite).
A titre d’exemple, nous donnons ci-après le template permettant de créer un paragraphe TEI. On crée un élément <p> qui aura pour ID le numéro du paragraphe courant, pris dans le fichier pivot, dès qu’on est dans la « catégorie » structure_finale avec <propriete nom="paragraphe" valeur="1.0"/>.
<xsl:template name="creerParagraphe"><br/>
:<xsl:text>paragraphe</xsl:text><br/>
:<xsl:element name="p"><br/>
::<xsl:attribute name="xml:id"><xsl:value-of select=<br/>
::"count(preceding-sibling :: bloc / categorie<br/>
::@nom='structure_finale'] /propriete[@nom='paragraphe' and<br/>
::@valeur='1.0'])"/><br/>
::</xsl:attribute><br/>
::<xsl:value-of select="./texte"/><br/>
:</xsl:element><br/>
</xsl:template>
|
Transformation XML ALTO et TEI vers XML METS
Un fichier METS est structuré en sept sections, pouvant comprendre un ou plusieurs groupes de metadonnées.
Les deux sections principales sont obligatoires:
- FileSection: liste des fichiers composant l’objet (identifiant, format, url)
- Structural Map: carte de structure, description du plan du document (logique ou physique)
Les 5 autres sections sont facultatives et répétables:
- Header: informations sur le document METS
- Descriptive Metadata: métadonnées descriptives, externes avec des liens ou encapsulées dans le document
- Admisnistrative Metadata: métadonnées administratives, externes ou encapsulées
- Stuctural Links: liens entre les différents éléments de la carte de la structure
- Behavior: association d’exécutable (programme qui vont faire fonctionner l’objet)
METS utilise un système de pointeurs afin de mettre en relation des éléments de métadonnées et des fichiers entre eux. METS en propose plusieurs types:
- xlink : pour pointer vers un bloc à l’extérieur du document METS
- filepointer: interne au document METS et permet de pointer vers l’identifiant d’un fichier
- metspointer: externe au document METS et permet de lier plusieurs documents METS entre eux
- area: intégré dans la carte de structure et permet de pointer vers une partie de fichier
Un exemple de FileSection est donné ci-après :
<fileSec>
:<fileGrp ID="ALTO" USE="alto generated automatically via OCR">
:<file ID="ALTO_adams2" MIMETYPE="text/xml">
::<FLocat LOCTYPE="URL" xlink:href="adams-2.jpg_alto.xml"/>
:</file>
:</fileGrp>
:<fileGrp ID="TEI" USE="Documents de vérité en TEI ">
:<file ID="TEI_adams2" MIMETYPE="text/xml">
::<FLocat LOCTYPE="URL" xlink:href="adams-2tei.xml"/>
:</file>
:</fileGrp>
:<fileGrp ID="JPG" USE="Jpeg image">
:<file ID="JPG_adams2" MIMETYPE="image/jpeg">
::<FLocat LOCTYPE="URL" xlink:href="adams-2.jpg"/>
:</file>
:</fileGrp>
:</fileSec>
|
La partie la plus importante d'un fichier METS est donc la structMap. Dans notre cas c'est ici qu'est fait le lien entre l'image, la TEI et l'ALTO. Les étapes pour réaliser ce fichier sont les suivantes:
- xtraire la structure logique du document à partir du fichier TEI et la recréer grâce aux balises div.
- Créer les pointeurs vers le fichier ALTO
- Récupérer les coordonnés des lignes dans le XML ALTO, puis créer les pointeurs vers les zones de l’image correspondantes.
La connexion entre ALTO (structure physique) et TEI (structure logique) se fait par l'intermédiaire d'un fichier METS. A partir des résultats fournis par le système de reconnaissance, n'importe quel lien peut être établi entre tous les éléments. La génération d'un fichier METS est donc automatique et elle est un simple transcodage des liens trouvés par le système de reconnaissance dans un fichier XML mettant en correspondance les ID d'un fichier avec les ID d'un autre. L’exemple suivant montre un fichier METS reliant l’image Jpeg, ALTO et la TEI :
Expérimentations
La combinaison ALTO-TEI-METS a été testée sur deux tâches d'analyse de documents : la première sur des articles scientifiques récents et la seconde sur un dictionnaire ancien. Pour le premier cas, le système de reconnaissance est neuronal [5] et dans le second cas, la structure logique est extraite par un système de règles.
La Figure 8 montre un extrait de fichier ALTO, TEI et METS d’un article scientifique.
La Figure 9 montre un extrait de fichier ALTO à gauche et TEI à droite de l’article scientifique de la Figure 8
Pour des besoins expérimentaux concernant les dictionnaires, deux fichiers TEI sont formés: le premier est un document de vérité comportant un maximum d'informations en particulier tous les glyphes du texte. Le second est la transcription du document dans le schéma TEI spécialisé dans l'encodage des dictionnaires. Le système de reconnaissance par règles effectue les liaisons entre les lignes de texte avec leur équivalent en paragraphes TEI. Toutes ces interconnexions sont ensuite représentées en METS.
La Figure 10 montre un exemple des 4 fichiers XML pour une définition extraite du dictionnaire de Trévoux
Conclusion
Nous avons illustré à travers deux cas d'étude différents comment utiliser une composition des trois formats standards ALTO, TEI et METS pour la représentation des données lors d'un processus d'analyse et de reconnaissance d'images de documents. Le schéma XML ALTO sert à représenter la structure physique du document et le schéma TEI sa structure logique. L'interconnexion entre les deux structures est décrite par un schéma METS qui laisse une grande souplesse de liaison.
Contrairement à d'autres approches utilisant des modèles locaux ou des formats propriétaires et spécifiques, l'intérêt de la solution ALTO-TEI-METS réside dans le fait que chacun de ces formats possède déjà sa propre existence et sa communauté d'utilisateurs. Ils sont régulièrement révisés et sont toujours contrôlés par des groupes de normalisation veillant à la pérennité des trois formats. La solution proposée bénéficie donc des développements parallèles des trois formats et peut perdurer dans le temps grâce à la standardisation de ces formats. Les échanges sont ainsi grandement facilités sans pour autant nuire aux spécificités de la tâche à résoudre. Le format METS a aussi l'avantage de ne pas être réduit qu'à l'utilisation d'ALTO et TEI: il est possible d'utiliser d'autres schémas par exemple de manipulation de documents sonores ou vidéos sans pour autant changer le mécanisme de structuration de données ni perdre en généricité. Si besoin est, que ce soit pour la structure physique ou logique, il est possible d'introduire d'autres formats de représentation XML même s'il est toujours risqué de s'éloigner de standards comme la TEI ou ALTO dans notre cas.
Références bibliographiques
[1] ↑ "The Text Encoding Initiative, Guidelines, manuals, tutorials, tools for encoding text.http://www.tei-c.org.
[2] ↑ "Analyzed Layout and Text Object, References and technical details about the ALTO schema".http:// www.ccs-gmbh.com/alto/
[3] ↑ , "The Representation of Document Structure: A Generic ObjectProcess Analysis, in Handbook on Optical Character Recognition and Document Image Analysis, Eds, P. S. P. Wang and H Bunke, (1996) Chapter 17."
[4] ↑ "Metadata Encoding and Transmission Standard, [1]
[5] ↑ Rangoni Y et Belaïd A, " Document Logical Structure Analysis Based on Perceptive Cycles, 7th IAPR Workshop on Document Analysis Systems - DAS 2006, Springer Verlag (Ed.), (2006), 117—128
[6] ↑ Programme"Ingénierie des Langues et des Documents", http://ild.loria.fr
[7] ↑ G. Nagy, "Twenty Years of Document Image Analysis in PAMI, Pattern Analysis and Machine Intelligence", January, 1, 2000, 22, p38-62
[8] ↑ Chenevoy et A. Belaïd, " Hypothesis Management for Structured Document Recognition. International Conference on Document Analysis and Recognition, St-Malo, septembre 1991".
