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 [1]. 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 [2] 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).
| <smal>
<TextStyle ID="Times New Roman_9._-4" FONTFAMILY="Times New Roman" FONTSIZE="9." FONTSPACING="-4" /></smal> |
<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).
| width=200px
<TextBlock ID="B3" HPOS="210" |
<block |
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" /> |
<line baseline="568" l="225" t="543" r="1224" b="576">
|
Voici un algorithme simplifié de la création d’un élément String :
|
Début si @wordstart = true alors finpour Fin
|
