Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

Articles

Publication d’un modèle de transcription et de la vérité de terrain !

Afin de rendre visible le travail colossale d’annotation réalisé par les équipes des Archives nationales, les transcriptions susceptibles de servir de données d’entraînement sont désormais publiées au sein du projet HTR-United, dans 3 répertoires Github distincts. Leur publication permet désormais à d’autres utilisateurs et utilisatrices de l’HTR de les réemployer pour leur propres expérimentations.

Il s’agit des répertoires suivants :

LECTAUREP Repertoires : qui contient les pages de répertoires, transcrites et validées (de nombreuses nouvelles pages sont en cours de relecture).

LECTAUREP Bronod : qui contient les minutes rédigées par Maître Bronod, dont le format diffère du corpus de répertoires car elles datent de 1742.

LECTAUREP Mariages et Divorces : qui contient les registres des Mariages et Divorces, pour le début du XXe siècle principalement.

Illustration des 3 types de documents issus de chaque corpus
Illustration des 3 types de documents issus de chaque corpus (de gauche à droite : Bronod, Repertoires, Mariage et Divorce)

Un modèle générique v1

Un nouveau modèle générique intitulé lectaurep_base a été entraîné à partir de ces données. Il est publié sur deux plateformes :

– sur Zenodo, ce qui le rend interrogeable depuis Kraken et permet de lui attribuer un DOI : https://zenodo.org/record/6542744

– sur Github afin de correctement documenter ses conditions de création : https://github.com/lectaurep/lectaurep_base_model

Les deux espaces de publication sont synchronisés et ont l’avantage de permettre de versionner les dépôts. Cela signifie que lorsque de nouvelles données seront publiées, nous pourrons entraîner un nouveau modèle et le publier dans les mêmes répertoires comme des v2, 3, etc.

Il est toujours possible d’accéder aux autres modèles entraînés au cours du projet LECTAUREP, notamment Generic_lectaurep_26, en se rendant ici : https://gitlab.inria.fr/dh-projects/kraken-models.

9,8% de CER

Le modèle générique produit encore beaucoup d’erreurs car son CER (Character Error Rate) reste au-dessus de 5%. Ce taux d’erreur augmente sur des données hors-domaine, c’est-à-dire des variations d’écritures inconnues pour le modèle.

Si on l’applique à un poème autographe d’Apollinaire par exemple, il fait 5 erreurs sur le titre :

Lettres à lire Lettres lue
L l
ont ais
b l
Aperçu de la transcription produite par lectaurep_base, comparé à la transcription attendue (manual) et à celle produite par generic_lectaurep_26
Aperçu de la transcription produite par lectaurep_base sur une écriture inconnue, comparée à la transcription attendue (manual) et à celle produite par generic_lectaurep_26

Le modèle lit donc “le Pais Miraleau” au lieu de “Le Pont Mirabeau”. Il est toutefois intéressant de noter deux choses :

– sur ce même segment, le modèle lectaurep_base fait moins d’erreurs que le modèle generic_lectaurep_26 (même si une partie d’entre elles sont identiques)

– les erreurs propres à lectaurep_base ont plus de sens que celles de generic_lectaurep_26 : si on regarde le tracé des lettres, on comprend l’origine de ces inversions.

L’ajout de nouvelles données d’entraînement pourra peut-être permettre d’abaisser le taux d’erreur théorique, mais cela permettra surtout d’augmenter la robustesse face à des écritures inconnues. Par ailleurs, le but d’un tel modèle n’est pas forcément d’être utilisé comme tel, mais plus de servir de base (comme son nom l’indique) pour affiner de nouveaux modèles de transcription, spécialisés sur une période ou une famille d’écritures.

Publication avec Kraken

Le dépôt Zenodo à été généré à partir de l’utilitaire de publication proposé par Kraken. Il me paraît intéressant d’expliquer ici la marche suivie.

Après avoir installé Kraken (dans un environnement virtuel), la commande “ketos publish” permet de lancer l’utilitaire de publication. La commande complète la plus basique ressemble à ceci :

ketos publish -a $ACCESS_TOKEN chemin/vers/le/model.mlmodel

Cette commande déclenche l’utilitaire en mode interactif. L’utilisateur ou l’utilisatrice est alors amené(e) à renseigner, entre autres, le nom des auteurs et autrices du modèle, leur affiliation, la licence associée au modèle, ainsi qu’une description plus ou moins longue.

La valeur ACCESS_TOKEN doit être obtenue prélablement à partir de Zenodo. Pour cela, il faut créer un compte Zenodo et s’y connecter, puis aller sur Paramètres, puis Applications (ou cliquer ici). C’est depuis cette page que l’on peut créer un jeton d’authentification (access token) qu’il faut prendre soin de copier avant qu’il ne devienne invisible. Le jeton est une (longue) liste de caractères, par exemple “xTjfTjffMh3Ch0CSfwT1tpC”. Avec une telle valeur, la commande ressemble donc à ceci :

ketos publish -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel

Comme il peut sembler risqué d’utiliser la ligne de commande pour fournir les métadonnées qui seront ensuite publiées avec le modèle, il est possible d’utiliser un fichier JSON reprenant la structure suivante :

{"authors": [{"name": "", "affiliation": ""}], "summary": "", "description": "", "accuracy": 00.00, "license": "", "script": [], "name": "", "graphemes": []}

C’est l’option “-i” qui permet de passer le fichier de métadonnées à Ketos. Le mode interactif ne se déclenche pas si on utilise cette option. Admettons que le fichier soit nommé “metadata.json”, la commande ressemblerait à ceci :

ketos publish -i chemin/vers/metadata.json -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel

Lorsque la publication vers Zenodo est terminée, Kraken affiche l’identifiant du nouveau dépôt. Il est alors possible d’éditer les métadonnées depuis Zenodo de manière à corriger des erreurs, mieux structurer la description longue, ou encore ajouter d’autres contributeurs et contributrices.

En publiant à l’aide de Kraken, le modèle est automatiquement associé à la communauté “OCR/HTR model repository“. Cela lui donne plus de visibilité, ce qui n’est pas un luxe dans l’océan de dépôts qu’est Zenodo !

Création de modèles de transcription pour le projet LECTAUREP #2

Dans le précédent billet, nous vous expliquions quelles avaient été nos premières pistes pour la création de modèles de transcription applicables aux données du projet LECTAUREP. En essayant d’entraîner un modèle pour chaque famille d’écriture identifiée, nous nous retrouvions à devoir effectuer beaucoup de saisie pour des modèles finalement peu efficaces. Lorsque nous fusionnions toutes ces données, nous obtenions des performances similaires mais qui nous laissaient entrevoir la possibilité d’une plus grande robustesse face à des écritures nouvelles. Au lieu de silos de données assignées à tel ou tel modèle, nous pouvions envisager un pot commun pour tous les documents du projet et gagner ainsi un temps précieux.

Le présent billet vise à rendre compte de la stratégie mise en place afin d’élaborer un modèle générique pour les pages des répertoires de notaires.

Des données variées et imparfaites

Un premier lot de données de vérité de terrain a été constitué par les équipes du Département du Minutier Central des Archives nationales à partir de plusieurs extraits de répertoires. En plus des données mentionnées dans le billet précédent, ce lot rassemblait des pages issues des notaires Rigault, Legay, Boissel et Cahouet. Il était composé d’un total de 480 fichiers XML, correspondant chacun à une page de répertoire. Chaque page avait été pré-segmentée automatiquement1, reprise manuellement (parfois entièrement) puis transcrite par différent(e)s annotateurs et annotatrices.

Notons : comme pour une partie des données testées précédemment, aucune de ces transcriptions n’avait été relue en totalité. Cette vérité de terrain comportait donc non seulement des erreurs de transcription, mais également des omissions non résolues, généralement marquées par une suite de “X” ou de “?”.

Exemple de notation d'omission
Exemple d’omission : au lieu de “rue des Remises”, la transcription propose “rue des xxxx”.

Notre objectif général était de tester si l’augmentation du corpus de vérité de terrain, opérée grâce à la mise en commun de transcriptions associées à des types d’écritures différents, permettait de gagner quelques points d’exactitude (accuracy) de manière à atteindre un score d’au moins 80%. Ce modèle aurait ensuite été affiné (finetuné) pour permettre de réaliser une première transcription que les annotateurs et annotatrices auraient ensuite seulement à corriger. Même si l’usage est de viser une vérité de terrain la plus correcte possible, ici nous jugions que le rapport entre gain de performance et temps investi pour la correction ne justifiait pas que l’on relise chacune des 480 pages pour débusquer les erreurs et que cela pouvait venir dans un deuxième temps. Pour cette raison, on peut considérer que la qualification d’un tel lot en “vérité de terrain” constitue une erreur. Cependant, lorsque l’on mène un projet de cette envergure, avoir suffisamment de temps ou de personnes chargées d’annoter n’est pas évident. Laisser ce lot de données en l’état permettrait de prendre en compte cette réalité dans la chaîne de production de la vérité de terrain.

Optimisation du temps de calcul

Étant donné la quantité de données rassemblées, nous avons d’abord dû optimiser le temps de calcul afin de pouvoir effectuer différentes expériences dans des temps raisonnables.

Nous avons ainsi configuré Kraken, notamment en ce qui concerne le réglage des threads, aussi appelé fils d’exécution des CPUs. Ce paramètre a un impact important sur la vitesse des entraînements car il spécifie avec quel moyen (et donc à quelle vitesse) la machine charge en mémoire les données pour ensuite réaliser ses calculs à l’aide des GPUs.

Sur des machines de type laptop comme ceux qui équipent une partie des membres de l’équipe ALMAnaCH, on trouve des processeurs Intel Core i7 ou i9, comportant entre 4 et 8 cœurs, soit respectivement 8 ou 16 threads. Le serveur Traces6 possède, lui, 2 processeurs à 16 cœurs, soit un total de 64 threads. Pour l’entraînement de modèles de transcription, Kraken est paramétré par défaut pour n’utiliser qu’un seul thread2. Conserver ce paramétrage par défaut sur une machine possédant 2 GPUs RTX 6000, 125 Go de RAM et 64 CPUs, c’est vraiment ne pas donner les moyens aux GPUs de se rendre utile : on passerait beaucoup plus de temps à charger les données qu’à effectuer les calculs .

Les premiers entraînements réalisés permettaient ainsi de passer de près de 4 heures pour 30 époques3 d’apprentissage, à environ 2h30. C’était mieux mais toujours lent ; depuis, les modalités de chargement des images par Kraken ont été revues dans le code source, de manière à effectuer plusieurs chargements en parallèle4.

Des résultats décevants

Les entraînements sont lancés en ligne de commande et non depuis eScriptorium, ce qui pour le moment permet de mieux surveiller ce qu’il se passe durant l’entraînement tout en pouvant intervenir sur les paramètres par défaut. Les premiers résultats obtenus se sont avérés décevants :  en ayant quasiment doublé le lot d’entraînement, au lieu des 80% espérés, ou des 70% acquis avec les modèles à une seule main, nous plafonnions à 67 % d’exactitude au bout de 23 époques.  Nous en avions initialement tiré deux conclusions :

– l’augmentation de la taille du lot de données ne compensait pas l’augmentation de la variation dans les images ;

–  et/ou il restait trop d’erreurs dans la vérité de terrain.

Il fallait donc d’abord relire les transcriptions, ou bien en produire de nouvelles, puis retenter l’expérience.

Avec ce premier modèle générique à 67%, nous avons tout de même tenté une campagne d’affinage avec les données du notaire Riant, en ajoutant 50 pages qui avaient été laissées de côté. Cette fois encore, le modèle obtenu peinait à dépasser les 75% d’exactitude.

Un problème d’architecture

Nous en étions restés là de nos expérimentations lorsqu’une discussion avec les membres de l’équipe SCRIPTA nous a donné de nouvelles pistes. S’étonnant que nous ne parvenions pas à dépasser la barrière des 80% avec la quantité de données rassemblée, Daniel Stoekl5  nous a encouragé à modifier quelques paramètres supplémentaires, notamment le learning rate (ou vitesse d’apprentissage) et l’architecture des réseaux de neurones employée (exprimée en spécifications VGSL).

L’architecture correspond à l’enchaînement de couches de neurones, c’est-à-dire à l’enchaînement des transformations appliquées aux données afin d’en tirer la sortie souhaitée. La vitesse d’apprentissage correspond à l’amplitude de l’espace de probabilité exploré par le modèle à chaque itération. En somme, c’est comme, marchant dans le noir et cherchant une sortie, choisir de faire des grands pas autour de soi pour arriver plus vite vers une porte, ou bien faire de petits pas qui nous amènent plus lentement mais plus sûrement vers la bonne porte.

Entre-temps nous avions ajouté de nouvelles données6 à notre lot d’entraînement. Pour comparer l’impact de ces paramètres sur la réussite de l’apprentissage, nous avons réalisé un entraînement sans ces paramètres. Comme précédemment, celui-ci restait bloqué autour de 73% d’exactitude après 19 époques.

Courbe montrant en miroir l'évolution du CER et celle du taux d'exactitude pour un entraînement avec les paramètres par défaut de Kraken. Le CER reste au-dessus de 26%.
Performance du modèle entraîné avec les paramètres par défaut, exprimée en CER et en exactitude. Le CER reste au-dessus de 25%.

En revanche, les résultats étaient bien meilleurs en ajoutant à la commande d’entraînement les deux éléments suivants7 :

-s ‘[1,120,0,1 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 S1(1×0)1,3 Lbx200 Do0.1,2 Lbx200 Do.1,2 Lbx200 Do]’
r 0.0001

C’est-à-dire en ralentissant les pas d’apprentissage de Kraken (0,0001 au lieu de 0,001) et en revoyant l’enchaînement des couches de transformation (l’architecture par défaut de kraken est la suivante : ‘[1,48,0,1 Cr4,2,32,4,2 Gn32 Cr4,2,64,1,1 Gn32 Mp4,2,4,2 Cr3,3,128,1,1 Gn32 Mp1,2,1,2 S1(1×0)1,3 Lbx256 Do0.5 Lbx256 Do0.5 Lbx256 Do0.5]’8. On passait soudainement à 91% d’exactitude en 26 époques.

Performance de l'entraînement en modifiant les paramètres de Kraken, la courbe du CER passe en-dessous de la barre des 10%.
Performance de l’entraînement en modifiant les paramètres de Kraken, la courbe du CER passe en-dessous des 10% !

Comme on a plus d’images et que le learning rate est plus petit, le modèle a besoin de plus de époques d’entraînement, ce qui ralentit l’ensemble du processus . Pour obtenir notre modèle à 91%, il nous a ainsi fallu compter 16h pour l’apprentissage. Une majeure partie de ce temps reste toutefois dédiée au chargement des images en mémoire et non au calcul.

Cette attente est un moindre mal dans la mesure où non seulement le modèle générique peut être utilisé tel quel pour pré-annoter des manuscrits similaires9 , mais en plus on peut l’utiliser comme base pour affiner de nouveaux modèles qui peuvent très largement dépasser les 95% d’exactitude avec relativement peu de données. Ce fut le cas pour les répertoires du notaire Bronod. Mais nous en parlerons dans un prochain billet !

Finalement, ce billet est l’occasion de rappeler que posséder des connaissances en apprentissage machine reste encore crucial pour profiter à fond des outils de reconnaissance automatique des écritures : la production de la vérité de terrain ne fait pas tout. Cela nous permet aussi d’insister sur l’intérêt de mettre à disposition de la communauté des modèles déjà en partie capables de traiter des données variées. Ce premier modèle générique entraîné dans le cadre du projet LECTAUREP, nommé generic_lectau26, a ainsi été plusieurs fois partagé avec d’autres projets souhaitant travailler sur des écritures françaises des XIXe et XXe siècles.

  1. A l’aide du modèle de segmentation lectau1_8 []
  2. Voir Kraken/ketos.py []
  3. Une époque correspond à une itération sur l’ensemble des données du set d’entraînement, à la fin de laquelle l’état des connaissances du modèle est évalué sur un lot de données qui n’étaient pas contenue dans le set d’entraînement – elles constituent le set de test. []
  4. Voir Issue kraken/#242 []
  5. Daniel Stoekl supervise le développement de la plateforme eScriptorium dans le cadre du projet SCRIPTA []
  6. Avec les données issues du projet TIME US, le lot comptabilisait 502 pages. []
  7. Notez, la commande complète était : ketos train -o generic_lectau -f page -t allxmls.xmllist –device cuda:1 –augment –threads 64 -u NFD -s ‘[1,120,0,1 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 S1(1×0)1,3 Lbx200 Do0.1,2 Lbx200 Do.1,2 Lbx200 Do]’ -r 0.0001 []
  8. Source : https://github.com/mittagessen/kraken/blob/ffb35d101166e35fad7930d468138e216e48991a/kraken/lib/default_specs.py#L21) []
  9. Nous reviendrons dans un autre billet sur les tests réalisés pour confirmer les performances effectives du modèle sur des données “hors domaine”. []

Création de modèles de transcription pour le projet LECTAUREP #1

Quand on se lance dans une campagne de transcription reposant sur la reconnaissance d’écritures manuscrites, on passe généralement par une série de questions qui sont les mêmes d’un projet à l’autre. Parmi ces questions, il y a celle des modèles de transcription et de leur rapport à la variation des écritures. Doit-on entraîner un modèle pour chaque type d’écriture présent dans un corpus de documents ? Au contraire, peut-on se contenter d’entraîner un seul modèle tout terrain (qu’on appellera mixte ou générique) ?

On se pose rarement ces questions si l’on a recours à l’OCR car généralement ces outils ont déjà atteint le stade du tout en un, mais c’est loin d’être le cas pour les textes manuscrits. S’il faut mener une campagne de transcription manuelle pour créer la vérité de terrain nécessaire à l’entraînement des modèles, il est normal de chercher à déterminer en tout premier lieu si une seule suffit, ou s’il faut en fait en mener autant qu’il y a de familles d’écritures. Le problème devient encore plus tentaculaire si la répartition de ces écritures n’est pas prévisible et qu’on commence à se demander comment déterminer et repérer ces variations d’écriture dans les documents : on frissonne à l’idée de devoir dépouiller chaque page du corpus et gérer des dizaines de modèles alors qu’on pensait régler le problème de la transcription en deux claquements de doigts sur un clavier.

Le projet LECTAUREP n’échappe pas à ce cas de figure : avec nos centaines de mains d’écriture dans les répertoires de notaires, dont certaines n’apparaissent que sur très peu de documents, la perspective de créer une vérité de terrain pour chaque main ne manque pas de provoquer des grimaces. Très tôt, nous avons envisagé des solutions pour éviter d’avoir à entraîner plusieurs centaines de modèles différents.

La piste des modèles multiples

Nous ne nous sommes pas directement engagés sur la piste d’un modèle générique. Au contraire, nous avons d’abord imaginé restreindre nos efforts pour ne traiter que quelques notaires lisibles et dont les scribes sont restés constants. L’idée était notamment de simplifier la tâche de transcription manuelle car chaque changement d’écriture requiert un temps d’adaptation et un effort supplémentaire pour la personne chargée de l’annotation.

Une première campagne de transcription avait pris place durant la phase 1 du projet LECTAUREP et s’était concentrée sur 50 pages du notaire Marotte. Nous avons transposé cette transcription dans eScriptorium et annoté 100 pages tirées des répertoires de deux autres notaires : Dufour et Riant. Notons que le texte est beaucoup plus dense dans les pages de Marotte.

En septembre 2020, nous avons évalué l’efficacité des entraînements menés avec ces données à l’aide de Kraken. Le graphique ci-dessous résume l’essentiel des points pris en compte, à savoir :

  • le plus grand score de précision atteint avec les données (Best accuracy), basé sur une évaluation du taux d’erreur par caractère tel que fourni par Kraken à la fin de chaque cycle d’entraînement1 ;
  • le nombre de cycles d’entraînement (epoch) maximum opérés avec ces données avec les réglages par défaut de Kraken ;
  • le nombre de pages et le nombre de caractères contenus dans le set d’entraînement.

graphique entrainements des modèles Marotte Dufour et Riant

Nous nous sommes aperçus, sans surprise, que la densité du texte a un impact sur la quantité de pages qu’il faut transcrire pour obtenir de bons résultats : 49 pages de Marotte contiennent plus de données textuelles que 98 pages de Riant. Avec un tel écart, il faut plus d’itérations (epochs) sur les données Riant pour obtenir un modèle qui reste de toute façon largement en-dessous du modèle Marotte : 69,51 % de précision contre 89,17 %.

Grâce à cette expérience, nous avons conclu que pour passer le cap des 10 % d’erreurs par caractère pour le modèle Marotte, il nous fallait produire plus de données, et que nous étions encore loin du compte pour les modèles Dufour et Riant. En effet, il semblait nécessaire de prévoir de transcrire manuellement 200 pages (ou plus) pour certains notaires avant de parvenir à un modèle à peu près efficace. Cette perspective nous a légèrement échaudé et nous avons décidé de nous intéresser de plus près à la question des modèles mixtes ou génériques, entraînés simultanément sur plusieurs écritures.

Affinage et robustesse

Sans chercher à créer d’emblée un modèle mixte prêt à l’usage, nous avons envisagé d’en acquérir un dont la précision serait au moins supérieur à 80 %, puis d’utiliser nos sets Marotte, Riant et Dufour pour affiner des modèles et finir de gagner les points de précisions restants.

On s'approche du centre de la cible grâce au modèle mixte et on finit de resserrer sur le coeur de cible en affinant sur une écriture particulière

Avec les sets Marotte, Dufour et Riant, nous possédions près de 250 pages de vérité de terrain (pour un total d’environ 42 500 caractères) regroupant au moins 3 types d’écriture. Pour vérifier la faisabilité d’un modèle mixte, et en attendant de constituer un nouveau set de données pour notre modèle générique de base, nous avons décidé de réaliser un entraînement à partir de ces 250 pages.

Graphique montrant la courbe d'apprentissage du premier modèle mixte entraîné

Le graphique ci-dessus représente la courbe d’apprentissage du modèle mixte : en 25 cycles d’apprentissage, le modèle parvient à une précision maximale de 82,89 %. C’est moins que Marotte, mais mieux que Dufour et Riant seuls.

Au-delà du score de précision fourni par Kraken à la fin des cycles d’entraînement, nous nous interrogions sur la capacité du modèle à généraliser son apprentissage à d’autres écritures. La question était alors de savoir si un modèle mixte est plus robuste qu’un modèle unique face à des données légèrement différentes. Derrière la notion de robustesse, nous entendons la capacité d’un modèle à maintenir une transcription correcte malgré l’apparition d’écritures qui n’étaient pas présentes dans le set d’entraînement. Ce sont ces éléments inconnus du modèle que l’on appelle les données hors-domaine.

Illustration du concept de données hors-domaine

Si, appliqué à de nouvelles données, le modèle de transcription maintient une performance élevée malgré la variation des écritures, alors on peut considérer le modèle mixte robuste face à la variation des écritures.

Nous avions désormais deux questions liées : pouvons-nous, pour une écriture donnée, entraîner un modèle plus rapidement et avec moins de données en nous appuyant sur l’affinage d’un modèle mixte ? Le modèle obtenu en bout de course gagne-t-il en plus en robustesse face aux variations imprévues dans le lot traité ?

Le prochain billet s’attachera donc à la description des modalités de création du modèle mixte, mais aussi aux réglages qu’il nous a fallu opérer sur Kraken pour dépasser le plafond des scores à 80 %.

  1. Pour cette expérience, on prend la valeur maximale tout cycle confondu et pas le taux d’exactitude du modèle considéré comme le meilleur. Cf. Surapprentissage []

Un exemple d’exploitation des données produites grâce à la reconnaissance d’écriture manuscrite : la reconnaissance d’entités nommées

De la création des données à leur exploitation

Grâce à l’instance eScriptorium mise en place sur le serveur Traces6 et la création de modèles de reconnaissance d’écriture manuscrite (REM), il est maintenant possible d’automatiser la transcription automatique des documents du projet LECTAUREP à grande échelle. On peut exporter les données produites depuis eScriptorium dans trois formats différents : du texte brut, XML PAGE, et XML ALTO. Ce contenu textuel peut ensuite faire l’objet de premières recherches plein texte, de corrections automatiques, ou encore servir à la création d’une nouvelle couche d’annotations. Celles-ci permettraient de repérer et d’organiser plus finement les informations essentielles.

En décidant de traiter le texte obtenu par la REM, on entre dans l’étape de post-traitement. Celle-ci est importante et nécessite des prises de décisions : que faire du bruit généré par la REM ? Faut-il nécessairement le corriger ? Souhaitons-nous livrer le texte en l’état, ou du texte enrichi ? Autant de questions qui impacteront l’expérience de l’exploitation de ces documents.

La reconnaissance d’entités nommées

Une des tâches les plus communes du traitement automatique des langues (TAL) dans le champ de l’extraction d’informations est la reconnaissance d’entités nommées (REN). Ce processus propose de repérer automatiquement dans un texte les noms propres, les localisations, les informations de date, etc. Ce faisant, un nouvel accès au texte est créé, basé non plus sur la lecture directe mais sur une lecture ciblée. L’important ici est de souligner que cette tâche est bien documentée et réalisable à l’aide de la plupart des librairies de TAL.

La REN peut s’appuyer sur plusieurs méthodes. Dans le domaine de l’apprentissage machine (machine learning), il existe des approches supervisées et non supervisées. Dans le premier cas, on cherche à entraîner un modèle reconnaissant des structures similaires grâce à une phase d’apprentissage effectuée à partir de données annotées manuellement. Dans le second cas, on laisse le programme détecter automatiquement des structures et les classifier. L’apprentissage profond (deep learning) possède également aujourd’hui une part importante dans la REN.1

Ces architectures permettent de détecter une entité et de lui attribuer un label. Notons que ces deux tâches sont distinctes : il est possible de détecter une entité mais de mal l’identifier (catégoriser une somme monétaire comme une date, par exemple), et la première est la condition de la deuxième. Sans détection, impossible de donner un label. 

On retrouve enfin des approches par systèmes de règles, où on cherche par exemple à faire correspondre les mots analysés à des référentiels extérieurs afin de générer des étiquettes, ou à retrouver des structures morpho-syntaxiques spécifiques. 

La REN doit également faire face aux limitations techniques des modèles génériques de reconnaissance qui sont mis à disposition. Si l’on prend l’exemple de la chaîne de traitement la plus complète en langue française de la librairie de TAL spaCy, on observe qu’avec les “réglages d’usine”, on ne peut détecter que les types d’entités suivants2 :

  • LOC – Localisation
  • ORG – Organisation
  • PER – Personne
  • MISC – Miscellaneous3

Quatre types d’entités donc, dont une difficilement exploitable en tant que telle (MISC), contre dix-huit pour la chaîne de traitement en langue anglaise. En plus des entités déjà présentes pour le modèle français, on retrouve par exemple les entités de date, de quantité, de temps, monétaires, etc.

L’entraînement d’un modèle de REN permet de répondre à des besoins spécifiques de détection.4  On peut alors déterminer les entités que l’on souhaite récupérer tout en choisissant leur étiquette. Il serait alors possible d’envisager d’entraîner un modèle de REN pour détecter par exemple les mentions d’œuvres d’art et littéraires dans un roman.

La REN et LECTAUREP

Dans les documents du projet LECTAUREP, nous cherchons à appliquer un traitement de REN au texte de la colonne centrale.5 Regardons de plus près un exemple tiré d’une ligne issue de la colonne centrale d’une page datée du mois de février 1901 dans un registre de notaire.

Extrait d'un enregistrement de la colonne centrale d'un registre de notaire datant du mois de février 1901
Dans cet extrait, on lit “Gauthier (par Marie Alexandrine) à Paris, rue St Ferdinand 2, à ses père et mère”

Il serait intéressant de récupérer automatiquement, dans les données de cette colonne, les noms propres et les localisations, par exemple.

Observons dans un premier temps une extraction réalisée avec spaCy à partir d’une transcription manuelle de la page6 :

Visualisation avec la librairie python displaCy de la reconnaissance d'entités nommées. [Gauthier, PER] (par [Marie Alexandrine, PER]) à [Paris, LOC], [rue St Ferdinand 2, LOC], à ses père et mère

Le résultat est satisfaisant : les noms de personnes ont bien été détectés, les localisations également. La segmentation des entités est également efficace : “Marie Alexandrine” a été reconnue comme une seule et même personne, et l’adresse – type de voie, nom de la voie et numéro – a correctement été extraite si l’on met de côté le nom de la ville. L’adresse complète peut facilement être reconstituée par concaténation, ou par l’entraînement d’un modèle sachant identifier ce format. Gardons cependant en mémoire que la structure de cette unité sémantique est simple et les termes non ambigus. Plus on ajoute de difficultés, plus on risque d’avoir des erreurs : des entités mal définies et/ou mal catégorisées.

Dans un deuxième temps, observons une extraction réalisée à partir d’une transcription  bruitée. Par bruit, on entend l’ensemble des erreurs de transcription ayant un impact sur l’intégrité des mots : des caractères absents ou en trop, des espaces mal placés, etc. Un modèle de REM générique entraîné à partir des documents de LECTAUREP nous a permis d’obtenir cette prédiction :

Visualisation avec la librairie python displaCy de la reconnaissance d'entités nommées sur une transcription automatique. [Gauther, LOC] (par [Marie Cexandinte, PER]) à [Paris, LOC], [rue St Ferdinandt, LOC], à sespère et [mère, PER]

La REM livre ici une transcription compréhensible et proche du texte original.7  L’extraction des entités sur ce texte bruité est globalement satisfaisante : sur les quatre entités reconnues à partir de la transcription manuelle, on en retrouve trois correctement identifiées dans la transcription automatique. Cependant, remarquons que “Gauthier” en début de ligne, devient “Gauther” et est maintenant labellisé comme une localisation.

Des stratégies à établir

Le bruit généré par la REM, lorsqu’il demeure en quantité acceptable,8 pourrait finalement n’être considéré que comme une gêne mineure, d’autant plus qu’il n’empêche pas la recherche plein texte dans le cadre d’un moteur de recherches floues. Bien que cette solution ait l’avantage de proposer de la souplesse à l’utilisateur.ice, l’enrichissement des données textuelles par des annotations permet une nouvelle approche du texte. Grâce à la REN on peut par exemple mettre en place une recherche à facettes. Réussir à récupérer tous les noms propres permettrait alors de choisir ces entités comme point d’accès au texte. 

En conclusion, la finalité d’un projet et les données sur lesquelles il est élaboré sont déterminants pour la mise en place d’une stratégie d’identification et d’annotation des entités nommées. Dans le cas du projet LECTAUREP, par exemple, on n’a pas besoin d’utiliser des outils de TAL pour toutes les colonnes : le nombre de valeurs possibles étant limités dans les colonnes “nature et espèce des actes”, on peut se contenter de mettre en place un script basé sur des règles pour comparer la prédiction de la transcription avec une liste des entrées acceptées. Lorsqu’une procuration est enregistrée par un notaire, seul le mot “procuration” est indiqué : pas besoin du TAL pour interpréter le sens de cette indication. En revanche, nous avons besoin de reconstituer le sens des informations contenues dans la colonne centrale afin de trier ce qui relève de telle ou telle catégorie d’information. 

La nature du texte à analyser n’est pas le seul facteur à prendre en compte : il est aussi nécessaire d’observer la quantité de bruit dans les données transcrites automatiquement, et d’en estimer l’impact sur l’analyse du texte. 

Enfin, s’agissant d’une couche d’analyse, la REN doit faire l’objet d’une réflexion scientifique visant à modéliser les informations contenues dans les documents et la manière dont il convient de les catégoriser. Parmi les questions à aborder : quels types d’entités souhaite-t-on collecter ? Dans quel(s) but(s) ? Avec quel niveau de granularité ? Peut-on/Doit-on normaliser et/ou désambiguïser les entités identifiées ?

Des questions se posent également sur l’après. Récupérer automatiquement des entités spécifiques avec un haut taux de réussite est une victoire, mais il est nécessaire de réfléchir à comment les stocker pour préparer leur exploitation.

  1. Pour un guide plus détaillé des différentes approches existantes concernant la REN, voir https://nanonets.com/blog/named-entity-recognition-2020-guide/ []
  2. Ses spécificités sont accessibles ici, dans la rubrique Label Scheme, à la ligne NER []
  3. Ce type d’entité indique de manière générale que le mot détecté en tant que MISC est une entité nommée, sans en déterminer la catégorie. Une entité nommée en devenir, en somme. []
  4. Voir par exemple, la documentation pour entraîner un modèle de REN à partir du modèle de langue française CamemBERT, sur huggingface. []
  5. La colonne centrale, rappelons le, concerne les “noms, prénoms et domiciles des parties – indications, situations et prix des biens” []
  6. La visualisation des entités nommées est réalisée à l’aide de la librairie python displaCy. Voir https://spacy.io/usage/visualizers []
  7. Entre la transcription manuelle et la transcription automatique, le taux d’erreur au niveau du caractère (CER pour character error rate) est de 20% et la distance de Levenshtein est de 16. Au niveau du mot, le taux d’erreur (WER pour word error rate) s’élève à 60%. Ces mesures ont été effectuées grâce à la librairie Python KaMI, utilisée ici pour comparer deux chaînes de caractères. []
  8. Avec un CER au-delà de 80%, on estime que le texte est illisible et inexploitable par un humain. []

Traces6 : notre serveur principal

Depuis le mois d’août 2020, l’équipe ALMAnaCH s’est dotée d’un nouveau serveur de calcul, nommé Traces6. Ce serveur est  mieux dimensionné pour le déploiement de l’application de transcription automatique eScriptorium. Il remplace le serveur “Lectaurep”,  un serveur initial matérialisé par une machine virtuelle ouverte dans le cadre de l’offre de services informatiques d’Inria et qui était dédié comme son nom l’indique au projet LECTAUREP.

motherboard, electronics, computer hardware, electronic engineering, electronic component, technology, electrical network, circuit component, electronic device, transistor, passive circuit component, computer component, circuit prototyping, microcontroller, capacitor, audio equipment, personal computer hardware, cpu, Free Images In PxHere
Zoom sur le hardware !

Alors que le serveur Lectaurep ne disposait pas de carte graphique (GPU), l’architecture du serveur Traces6 a été conçue autour de ce composant essentiel pour une utilisation optimale de la plateforme. En effet, les GPUs accélèrent les calculs nécessaires aux technologies de machine learning en prenant en charge leur parallélisation. En quelques mots : un entraînement dont les calculs prendraient plusieurs heures sur CPU peut ne prendre que quelques minutes à peine lorsqu’ils sont effectués sur un GPU.

Ce gain de vitesse suppose de s’appuyer sur un processeur capable de suivre la charge pour éviter les effets de goulot (bottle neck), où le chargement en mémoire des données prend plus de temps que le calcul lui-même. Il ne suffit donc pas d’ajouter simplement des cartes graphiques à une machine : cela suppose de mener une réflexion complète sur la configuration de la machine. Cette configuration est donc élaborée dans le cadre d’échanges avec le service informatique du centre Inria qui a ensuite réceptionné, monté et maintenant héberge la machine, en en assurant le bon fonctionnement matériel.

Server room
La machine est installée dans la salle des serveurs du centre, dans des étagères qui ressemblent à celles-ci.

Le serveur Lectaurep avait été mis en place dans le cadre du projet LECTAUREP pour le déploiement d’une instance d’eScriptorium principalement dédiée au projet. Ce n’est pas le cas du serveur Traces6 qui a été financé par l’enveloppe du DAHN (Dispositif de soutien à l’Archivistique et aux Humanités Numériques). Ainsi si c’est encore une fois une instance d’eScriptorium qui est déployée sur Traces6, le serveur accueille désormais davantage d’utilisateurs. Cela explique le gonflement considérable de la capacité de stockage : nous sommes ainsi passé d’un peu moins de 100 Go de disque dur à un peu plus de 23,5 To, couplant HDD et SSD (plus rapide à l’écriture). Même gonflement du côté de la mémoire : le serveur Lectaurep ne disposait que de 8 Go de RAM pour faire tourner l’application et ses tâches d’arrière-plan, tandis que le serveur Traces6 dispose désormais d’une confortable mémoire vive de 128 Go.

Dans la mesure où eScriptorium n’utilise pas les GPUs à chaque instant, ce serveur est aussi utilisé en ligne de commande (via un accès en SSH réservé) pour certains calculs réalisés hors application. C’est en particulier le cas lorsque nous comparons les entraînements menés à l’aide du logiciel Kraken seul par rapport à ceux effectués par l’intermédiaire d’eScriptorium.

Le serveur Lectaurep n’est pour autant pas tombé en désuétude : il nous permet de disposer d’un bac à sable où tester certaines features sur lesquelles nous travaillons avant de les intégrer dans le code source du projet SCRIPTA, ou bien de vérifier le fonctionnement d’une nouvelle version de l’application avant de l’installer sur le serveur Traces6. Le serveur Lectaurep est donc devenu notre serveur de test avant la mise en production sur Traces6.

A l’heure actuelle, Traces6 accueille un peu plus de 100 utilisateurs et utilisatrices, dont 30 participent au projet LECTAUREP. Parmi les projets de recherche bénéficiant d’un accès à eScriptorium par le biais du serveur Traces6, que ce soit pour un usage avancé ou simplement pour expérimenter l’outil, on compte les projet suivants :

Ce sont autant de projets qui, à l’occasion d’échanges au sujet de l’application, font émerger des questions et des cas d’usage, alimentant ainsi une partie des réflexions menées conjointement avec l’équipe SCRIPTA et ses partenaires pour améliorer la plateforme. Le projet LECTAUREP contribue en effet directement au projet SCRIPTA en mettant à contribution la force de travail de son développeur, Yves Tadjo. Le but est alors de généraliser autant que possible les scénarios utilisateurs identifiés par le projet LECTAUREP pour participer à l’accélération du développement de l’application.

Dans les mois à venir l’architecture de Traces6 est amenée à évoluer dans le cadre du financement du projet d’équipement CREMMA par le DIM MAP, dont l’un des objectifs est de continuer à construire un environnement équilibré et robuste pour le déploiement de l’application eScriptorium et sa mise à disposition pour la communauté des humanités numériques. Traces6 constituera alors l’un des serveurs sur lesquels s’appuiera l’architecture CREMMA.

Résolution de bug : Something went wrong during the segmentation

Lorsque l’on suit la procédure pour transférer des données de Transkribus vers eScriptorium, il arrive que durant l’exécution de l’étape 3 (le re-calcul des maques) le message “Something went wrong during the segmentation” s’affiche plusieurs fois, tandis que sur autant de cartes-images, l’icône “segmentation” s’affiche désormais en rouge.

Ce qui suit est une proposition de résolution pour ce problème.

Comment rendre mes pages compatibles avec le calcul des masques ?

Si vous cliquez sur l’une des cartes-images problématiques et affichez le volet de segmentation, en activant le mode “line mask”, vous vous rendez rapidement compte quand dans les pages où la segmentation n’a pas marché, il existe des lignes pour lesquels un masque existe sans baseline.

Affichage des baselines et des masques dans eScriptorium: la dernière ligne n'a pas de baseline
La dernière ligne n’a pas de baseline !

Un procédé relativement simple consiste à :

  • copier la transcription de la ligne fautive et l’enregistrer temporairement ailleurs ;
  • en gardant le mode “line mask” activé,  sélectionner le masque sans baseline puis le supprimer ;
  • dessiner une nouvelle baseline (automatiquement associée à un masque) puis lui assigner à la transcription initiale.

Une fois qu’il ne reste plus de masques sans baseline sur l’image, il est alors possible de relancer la segmentation de tous les masques pour cette page.

La segmentation s'effectue maintenant sans problème
La segmentation s’effectue désormais sans problème !

Comment faire si toutes les lignes de la page sont concernées ?

Il n'y a que des masques sans baseline correspondantes
Il n’y a aucune baseline, que des masques !

Afin de traiter l’ensemble de la page en une seule fois, il est possible d’utiliser le volet “Text” pour copier/coller la totalité de la transcription au lieu de procéder ligne par ligne :

  • activer le volet “Text” et copier la transcription ;
  • sélectionner la totalité des masques et les supprimer ;
  • tracer une par une les baselines en suivant l’ordre de lecture ;
  • vérifier l’ordre des lignes puis coller la transcription initiale.

Pourquoi ne pas ignorer ces messages ?

Lorsque vous transférer vos données de Transkribus vers eScriptorium, il est possible que vous souhaitiez comparer les performances des deux logiciels. Si vous ne faites rien pour résoudre ce problème, vous risquez de fragiliser les bases de votre expérimentation. En effet, ces pages non segmentées contiennent des données qui ne seront pas utilisables par Kraken lors de l’entrainement d’un modèle.

Cela signifie aussi que l’intégrité de vos donnée n’est pas garantie pour la suite de vos expérimentations sur eScriptorium.

D’où vient le problème ?

Il est possible de prévenir ces problèmes de segmentation en inspectant les fichiers XML PAGE générés par Transkribus. En effet, on se rend alors compte que les lignes qui posent problèmes correspondent à des noeuds TextLine où l’élément Baseline est absent. Dans l’image ci-dessous, on peut voir :

  • de la ligne 40 à 45, un noeud TextLine incorrect, sans élément Baseline ;
  • de la ligne 46 à 52 un noeud TextLine correct.
Extrait d'un fichier XML PAGE ayant généré une mauvaise segmentation
L’élément TextLine de la lingne 40 à 45 n’a pas d’élément Baseline.

 

Switching from Transkribus to eScriptorium with Aspyre

Warning: the pipeline described below is no longer necessary to transfer data from Transkribus to eScriptorium. It is indeed preferrable to use PAGE XML, which is immediately compatible with eScriptorium. See our tutorial.

 

 

eScriptorium is a transcription platform currently being developed by SCRIPTA PSL. It provides Kraken with a GUI and an API, increasing the accessibility of this OCR software and broadening its functionalities1. Both eScriptorium and Kraken are free and open source, and so are the models created with them. This is important because it means that when using eScriptorium and/or Kraken you can save your model as a file and share it with whoever you want, however you want. This makes the effort put into creating the ground-truth all the more worthwhile2!

Additionally, Kraken produces two types of models:

  1. Segmenters which detect lines of text on an image; and
  2. Recognizers which transcribe these lines. 

Both types of models can be trained with your own data on the eScriptorium platform. Therefore, if your documents’ layout is too specific to be properly handled by a generic model, you can create one from scratch or finetune the default generic model in order for it to fit your own needs and objectives. In other words, compared to a platform like Transkribus, eScriptorium gives you more flexibility and more freedom to build your own models for the detection of the layout and the transcription of your documents. 

If you have started your project using Transkribus and wish to transfer your data to eScriptorium, it is possible. To address the complexities encountered and bridge the gap between these two platforms, we developed Aspyre, an easy-to-use solution leveraging ALTO XML as a hub.

This article is not a tutorial on how to use eScriptorium or Transkribus: rather, it is intended to be extended documentation on what to expect from and how to use Aspyre.

LectAuRep, a case example

Back in 2018, during an exploratory phase of the LectAuRep project which aimed at determining whether it was possible to automatically transcribe our documents3, we evaluated the performance of several transcription tools, including Transkribus and Kraken. 

A major issue we encountered was that of detecting the text on the documents and reproducing the table-like layout. We soon realized that the quality of segmentation weighs a lot in the quality of transcription. We were successful at training an acceptable transcription model in Transkribus4, but would spend too much time manually rendering the layout on this platform. 

It became necessary to find another solution to automatically detect the segments and Kraken and eScriptorium offered promising perspectives. 

As a result, we switched to Kraken while in the meantime leaving the data produced during phase 1 on Transkribus. Recently, we decided to retrieve the transcriptions created with Transkribus and transfer them to eScriptorium. Our intentions were to compare, given an identical dataset, the transcription performances of Kraken and Transkribus. Ideally, we also wanted to add the ground truth created during phase 1 to the rest of the data generated with eScriptorium.

Transferring the data from Transkribus to eScriptorium turned out to be more complicated than just exporting data from Transkribus and importing them to eScriptorium. A few changes needed to be made in the documents exported from Transkribus: we developed Aspyre to execute these modifications.

Okay, so what about Aspyre?

Aspyre is a Python library that will help import into eScriptorium data you exported from Transkribus. Because you may want to use Aspyre quickly without having to worry about a local installation, we also provide Aspyre as a service online (GUI) on a demo server5. We even created a ready-to-use script to run Aspyre as a CLI.

Aspyre uses ALTO XML because this standard is processed by both Transkribus and eScriptorium. However, by default the files produced by the former slightly differ from the files expected by the latter6. The three main issues are:

  1. Transkribus’ exports follow the ALTO 2 schema specifications, while eScriptorium is based on ALTO 4;
  2. Transkribus does not refer to the image associated with a transcription whereas eScriptorium relies on it to dynamically pair a transcription and the corresponding image;
  3. Transkribus exports only refer to a baseline coordinate from the y axis (“At which height on the image do we find the baseline?”) whereas eScriptorium will produce a baseline based on at least two x-y coordinates. 

To summarize Aspyre’s actions: it takes an archive exported from Transkribus and re-composes the information needed by eScriptorium. It injects the reference to the source image matched by the transcription and transforms the ALTO XML tree to conform to the correct schema specifications on top of fixing how baselines are specified. 

Using Aspyre: a walkthrough

The steps to run your data through Aspyre are fairly simple.

  1. Export your data in the “Transkribus Document” format, checking the “Export ALTO” and “Export Image” options (see screenshot below). You will now have a ZIP file.
  2. If you use Aspyre as a GUI, you need to keep your ZIP file under 500 MB. Conveniently, Aspyre does not need the images to run7 so you can eliminate them from the archive following your preferred method8
  3. Run Aspyre on your data from the CLI or upload the archive on Aspyre GUI following the documentation provided with each tool. You will obtain a new ZIP file containing modified ALTO XML files.
  4. After uploading your images on eScriptorium, import the transcriptions using the “Import Transcription” option and select the new ZIP file.
Minimal configuration of the exports on Transkribus: check "Transkribus Document" and then "Export ALTO" and "Export Image".
Minimal configuration of the exports on Transkribus.

Dissecting Aspyre

Aspyre was developed as a library (aspyrelib), so you can add it to your own pipeline and call its main function (aspyrelib.main()). 

To run properly, Aspyre will take a directory with an architecture similar to the ones you can extract from Transkribus: at minimum, it shall contain a file named “mets.xml” and a directory named “alto/” containing ALTO XML files. The file “mets.xml” must contain a node such as “<ns3:fileGrp ID=”IMG”>” referring to image files, and a node such as “<ns3:fileGrp ID=”ALTO”>” referring to the ALTO XML files.

The ALTO XML file has a new schema declaration and includes a reference to the corresponding image after being processed by Aspyre.
The ALTO XML file has a new schema declaration and includes a reference to the corresponding image after being processed by Aspyre.

After Aspyre has listed the image files referred to in “mets.xml” and the XML files in the alto directory, each ALTO XML file is mapped with its corresponding source image. This is rendered by the creation of a “sourceImageInformation” node in the “Description” section of the ALTO XML file. 

The schema specifications are updated to ALTO 4 (currently an eScriptorium-flavored version9 ) and non-ALTO 4 elements are modified. Mainly, this results in “composedBlock” elements being removed, although their content is kept in the tree.

Additional modifications are made on the segment level. First, since complete baseline coordinates are key information for eScriptorium, Aspyre makes sure that they are properly expressed: it takes the unique value stored in the @BASELINE attributes  and extrapolates the correct coordinates based on the values associated with the corresponding @HPOS, @VPOS and @WIDTH attributes. @BASELINE attributes are then populated with the right coordinates. At the end of the process baseline coordinates are expressed as “xA yA xB yB” instead of “yA”. Unfortunately, for images where the text is crooked or tilted, this extrapolation may result in unsatisfying segments, forcing the user to later manually correct the imported segments. This aspect of the transformation will be improved in future developments.

After Aspyre is ran, BASELINE attributes refer to 4 x and y coordinates, calculated from the values in the original BASELINE, HPOS, VPOS and WIDTH.
After Aspyre is ran, BASELINE attributes refer to 4 x and y coordinates, calculated from the values in the original BASELINE, HPOS, VPOS and WIDTH.

Finally, since the ALTO 4 specifications used by eScriptorium currently differ slightly from the official schema, we want to point out that coordinates associated with the @BASELINE and @POINTS attributes must be expressed without any comma. The coordinates “xA,yA xB,yB” will thus become “xA yA xB yB”. This modification is handled by Aspyre as well and is easily reversed.

Commas are removed from the values of POINTS attributes, following eScriptorium's ALTO schema specifications.
Commas are removed from the values of POINTS attributes, following eScriptorium’s ALTO schema specifications.

Contribute!

The transformation scenario followed by Aspyre was tested against data produced in various contexts. However, your data and your practices may differ from ours. This can cause Aspyre to not exactly fit your needs or to somehow not be compatible with your data. Please, let us know if Aspyre has failed you! 

Aspyre is a work in progress and we would be happy to make updates so it is compatible with your data. Even if you have no idea why it didn’t work, we ask that you report the error by creating an issue on our development platform

Of course, you can also dig into the code yourself and find out what is causing the issue. In such cases, please, shoot us a pull request!

  1. For more information on eScriptorium and its functionalities, see https://escripta.hypotheses.org/ []
  2. For example, you can share your ground-truth via the HTR-United initiative:  https://htr-united.github.io/ []
  3. Digitized notary registers from Minutier Central’s collection at the Archives nationales. For more information on this collection, see http://www.archives-nationales.culture.gouv.fr/fr/web/guest/archives-des-notaires-de-paris  []
  4.  For more information on this phase, see Marie-Laurence Bonhomme. Répertoire des Notaires parisiens Segmentation automatique et reconnaissance d’écriture : Rapport exploratoire. Inria. 2018, pp.1-10. ⟨hal-01949198v2⟩. []
  5. Since this is a demo server, there is a limitation on the size of the files you can upload: 500 MB max! []
  6. Compare documents exported from each platform : https://github.com/alix-tz/aspyre-gt/tree/master/data/altos  []
  7. It only needs the mets.xml file to refer to them, this is the reason why you have to check “Export Image” in Transkribus. []
  8. You can use a software like 7-Zip or run this step from the command line. In any case, to remove the image from the archive, unzip it and rezip it keeping only the “alto” directory and the “mets.xml” file. []
  9. We believe this divergence from the official schema is only temporary and closely linked to future improvements in the ALTO 4 specifications.  []

Le saviez-vous ? Les répertoires de notaires ne sont pas seulement des images numérisées !

Par Lucas Terriel
Étudiant de l’École nationale des chartes

Master « Technologies numériques appliquées à l’histoire »
Stage chez Inria


En 2020, le projet Lectaurep a franchi un cap. Il marque une concrétisation importante des objectifs de départ et des efforts menés jusqu’à maintenant dans le déploiement et l’utilisation importante de la plateforme « couteau suisse » eScriptiorium1 : la segmentation et la transcription automatique des images de répertoires de notaires devient réalisable dans un environnement autonome. Cependant, le projet est aussi rentré dans sa phase la plus « expérimentale ». Comme dans de nombreux projets menés en mode agile2 , un des principes phares, de ce concept de management de projets numériques consiste à toujours remettre en question et ouvrir des discussions sur les moyens de devenir plus efficace dans les buts que l’on s’est fixés au départ. Parmi ces réflexions, l’une d’entre elles s’est ouverte sur la garantie de l’accès aux métadonnées aussi bien pour les usagers que pour les administrateurs du projet. Qu’il s’agisse de la récupération ou d’assurer l’enrichissement de ces métadonnées; en somme la question n’est pas si simple, d’autant que ces dernières sont très nombreuses !


Une galaxie de métadonnées

Commençons par le matériau brut, je veux parler des métadonnées. Imaginez que vous disposiez de vos dernières photographies de vacances : vous aimeriez peut-être vous souvenir de la date et du lieu des prises de vues, des personnes ou des monuments qui y sont présents. Peut-être encore souhaiteriez-vous pouvoir les classer en fonction des couleurs dans le cadre d’un projet ? En résumé, vous voudriez disposer des informations ou des références liées à vos images à tout instant. Une définition simple des métadonnées consisterait à dire qu’il s’agit « d’une donnée servant à définir ou décrire une autre donnée quel que soit son support (papier, audio, vidéo ou électronique) ».

Cette définition de la métadonnée comme une « donnée sur la donnée » est pourtant loin d’être suffisante dans le cadre d’un projet numérique comme Lectaurep. En effet, les métadonnées répondent à un besoin d’intégrité dans le temps (elles ne doivent pas être altérées), à un besoin de persistance (stockage et pérennisation des métadonnées), et répondent éventuellement à des modèles d’interopérabilité avec le web sémantique ou des modules de visualisations qui correspondent à des standards comme IIIF (International Image Interoperability Framework). Il faut aussi penser à leurs usages futurs et aux droits d’accès que l’on laisse associer à certaines métadonnées : peut-on garantir le même degré d’accès à l’ensemble des informations entre un chercheur en sciences humaines qui réalise des analyses computationnelles sur les répertoires et les opérateurs des Archives nationales ? Enfin les métadonnées doivent être enrichies au fil du temps selon les traitements effectués dans la plateforme eScriptorium pour conserver une trace des opérations.

Le schéma ci-dessous donne une idée de l’ensemble des métadonnées qui gravitent autour d’un répertoire de notaire et auquel un «super-utilisateur» hypothétique devrait avoir accès dans le cadre du projet Lectaurep.

Modélisation des métadonnées associées aux répertoires de notaires dans le cadre du projet Lectaurep
Figure 1 : Modélisation des métadonnées associées aux répertoires de notaires dans le cadre du projet Lectaurep

Plusieurs observations sur les métadonnées propres au projet Lectaurep découlent de ce schéma :

  • 1) Il existe des métadonnées « sources » ou inhérentes aux répertoires de notaires (c’est-à-dire celles qui se rattachent à l’archive papier ou à sa copie numérique conservée aux Archives nationales) et des métadonnées « en puissance » (qui seront attachées aux documents pendant ou après leurs utilisations à différents stades de traitements) ;
  • 2) Les métadonnées ne proviennent pas du même silo d’informations (Système d’information des Archives nationales ou base de données SQL3 ) ;
  • 3) Les formats de ces métadonnées suivent des schémas très différents, ce qui rend leur interopérabilité difficile car cela suppose d’en passer par un alignement des différents référentiels ;
  • 4) Toutes les métadonnées ne sont pas forcément consultables, cela dépend des droits attachés à un profil utilisateur.

Des métadonnées liées aux objets physiques

Une première classe4 de métadonnées correspond aux métadonnées administratives et de gestion (identification des archives, provenance et contexte de production de ces archives, intégrité, droits, etc.) et aux métadonnées descriptives (nom et prénom du notaire, numéro de l’étude, adresse, type de répertoires…). Ce sont généralement des métadonnées qui sont liées à l’objet physique lui-même, c’est-à-dire l’archive papier ou aux copies numériques. Les répertoires de notaires sont associés à des instruments de recherche (abrégé IR)5 généralement encodés en XML6 EAD 7 (Encoded Archival Description) et en XML EAC-CPF8 (Encoded Archival Context – Corporate Bodies, Persons and Families), rédigés et maintenus par le minutier central des Archives nationales.

On compte deux IR EAD associés à chaque répertoire de notaires : le premier relatif aux images du (ou des) répertoire(s) d’un notaire qui se présente sous la forme d’un inventaire spécifique pour des images numériques du répertoire de tel ou tel notaire et un deuxième relatif aux « Minutes et répertoires d’un notaire » qui constitue un inventaire des actes accompagnés de descriptions minutieuses de chacune des minutes de notaires et des répertoires eux-mêmes. Pour un notaire, nous disposons donc de trois fichiers XML en tout (deux XML EAD et un XML EAC-CPF), contenant des balises XML similaires mais des structurations d’arborescence différentes et parfois des informations redondantes.

Au total le minutier central a recensé plus de 2000 registres de répertoires laissés par le notariat parisien sur la période allant de 1803 à 1944, je laisse donc au lecteur la liberté de mesurer la quantité de fichiers XML associés aux répertoires . Pour avoir un aperçu de ces instruments de recherche vous pouvez vous rendre sur la Salle des inventaires virtuels et télécharger l’inventaire .xml pour le visualiser dans un éditeur XML.

Des métadonnées techniques liées aux numérisations

La numérisation des répertoires de notaires est associée à une seconde classe de métadonnées : les métadonnées techniques. Parmi celles-ci les métadonnées EXIF (Exchangeable image file format)9 qui fournissent un ensemble de renseignements sur l’image numérisée : les réglages et la marque de l’appareil, les dimensions de l’image, la date et l’heure de la numérisation, ou encore des informations sur les droits d’auteur. Ces métadonnées peuvent être structurées sous la forme d’un fichier XML en respectant l’espace de nom et ne sont accessibles que par l’intermédiaire d’un logiciel de traitement photographique (XnView, GIMP ou ExifTool) ou en passant par des scripts. Avec le langage Python, on peut utiliser les bibliothèques Pillow ou PyExifTool, par exemple.

Un exemple de métadonnées EXIF extraites à l’aide d’un script utilisant PyExifTool :

EXIF:ImageDescription => 74 - Main frame
EXIF:Make => i2S, Corp.
EXIF:Model => SupraScanII [SN: 283910] - Cam7600RGB [SN: 283910]
EXIF:Orientation => 1
EXIF:XResolution => 300
EXIF:YResolution => 300
EXIF:ResolutionUnit => 2
EXIF:ModifyDate => 2015:09:07 09:45:39
EXIF:YCbCrPositioning => 1
EXIF:ExifVersion => 0230
EXIF:CreateDate => 2015:09:07 09:45:39
EXIF:ComponentsConfiguration => 1 2 3 0
EXIF:FlashpixVersion => 0100
EXIF:ColorSpace => 65535

Des métadonnées sur les traitements réalisés avec eScriptorium

Pour finir, la plateforme eScriptorium permet un certain nombre d’opérations comme la binarisation, l’entrainement de modèles, la segmentation, ou la transcription à partir des images de répertoires. Toutes les opérations génèrent autant de métadonnées de traitement propres au projet Lectaurep. Celles-ci impliquent que l’image est modifiée par un opérateur et/ou un relecteur (qui dispose d’un compte utilisateur stocké dans une base de données SQL, qui conserve l’historique des révisions effectuées sur les documents, eux-mêmes conservés en base).

Dans eScriptorium, il possible pour un utilisateur de réaliser des exports au format XML ALTO ou PAGE10 pour récupérer des informations relatives à la mise en page physique et à la structure logique d’un texte transcrit par reconnaissance optique de caractères (OCR) comprenant les coordonnées des segments, le taux de confiance en la reconnaissance ou encore des éléments de mise en forme (polices ou graphies).

Extrait d’un export XML ALTO après segmentation et transcription réalisée dans eScriptorium :

<TextLine ID="eSc_line_31857" BASELINE="1349 1186 1944 1186 2503 1197" HPOS="1349" VPOS="1096" WIDTH="1154" HEIGHT="134">
            <Shape>
              <Polygon POINTS="1349 1186 1360 1150 1406 1132 1453 1147 1526 1132 1544 1150 1565 1132 1728 1154 1807 1143 1829 1161 1919 1136 1937 1154 2002 1147 2063 1103 2114 1096 2243 1114 2492 1107 2503 1197 2485 1230 2409 1212 2240 1215 2160 1194 2124 1208 1926 1201 1912 1215 1619 1201 1569 1219 1547 1201 1518 1222 1504 1208 1378 1212 1352 1186"/>
            </Shape>
        <String CONTENT="Murel (après décès de Gabrielle Jeanne Coste Ve de François Samuel Louis)" HPOS="1349" VPOS="1096" WIDTH="1154" HEIGHT="134"></String>
</TextLine>

Conclusion

Cet état des lieux des métadonnées brosse le tableau d’un paysage désorganisé d’informations, certes hétérogènes, mais essentielles pour les utilisateurs finaux du projet. Un point commun, peut-être, entre toutes ces métadonnées : le format XML. Les prochaines étapes consisteront donc à opérer des choix dans ces métadonnées et trouver le moyen d’agréger celles-ci au sein d’un format pivot pour les rendre facilement interrogeables.

« Un format pour les gouverner toutes. Un format pour les trouver. Un format pour les amener toutes et dans eScriptorium les lier», avis aux cinéphiles. Pour finir, un spoil sur le prochain billet : on parlera de format pivot et de TEI (Text Encoding Initiative).

  1. Pour en savoir plus sur la plateforme eScriptorium. []
  2. La méthode agile est un ensemble de pratiques pour la gestion de projets numériques qui reposent sur le prototypage rapide et des itérations courtes pour en savoir plus. []
  3. Le langage SQL (Structured Query Language) est utilisé pour exploiter les bases de données relationnelles. []
  4. Je parle de classes de métadonnées afin de ne pas sous-entendre une hiérarchie par niveaux, ce qui laisserait supposer que certaines métadonnées ont une importance supérieure à d’autres dans le projet. []
  5. « Un instrument de recherche est un outil papier ou informatisé énumérant ou décrivant un ensemble de documents d’archives de manière à les faire connaitre aux lecteurs. » Définition extraite de Abrégé d’archivistique, principes et pratiques du métier d’archiviste, Association des archivistes français, Paris, 2012, 3e édition revue et augmentée []
  6. Extensible Markup Language (« langage de balisage extensible »). XML est un langage qui permet d’encoder des informations. Il est largement utilisé pour l’encodage de ressources textuelles de par son système de balise. Un paragraphe peut être noté <p>Texte</p>, définition extraite de Clérice, T., « Les outils CapiTainS, l’édition numérique et l’exploitation des textes », Médiévales [En ligne], 73 | automne 2017, mis en ligne le 28 février 2019, consulté le 01 juin 2020. URL : http://journals.openedition.org/medievales/8211 ; DOI : https://doi.org/10.4000/medievales.8211 []
  7. « EAD ou Encoded Archival Description est un modèle pour la production en XML d’instruments de recherche archivistiques conforme à la norme internationale ISAD(G) », op.cit. []
  8. « EAC ou Encoded Archival Context – Corporate Bodies, Persons and Families est un modèle de production en XML de notices d’autorité de personnes physiques , de familles ou de personnes morales conformes à la norme internationale ISAAR(CPF) », op.cit. []
  9. EXIF ou Exchangeable image file format est une spécification de format de fichier pour les images utilisées par les appareils photographiques numériques. Cette spécification repose sur des formats existants tels que le JPEG, JPG, TIFF (mais pas le JPEG 2000 ni le PNG). Elles sont généralement conservées automatiquement avec chaque photographie. Des logiciels de traitement d’images permettent aisément de consulter ces métadonnées. []
  10. Les formats XML ALTO et PAGE XML sont adaptés à la conservation à long terme des données issues de la conversion comme l’optical character recognition (OCR) []