Compte-rendu de la séance n° 2

Segmentation et représentation des signes diacritiques des manuscrits : prendre en compte la mise en page du manuscrit, noter les insertions et les informations interlinéaires, représenter les corrections
Mardi 9 novembre — 16 h-18 h 

En présence de Vera Schwarz-Ricci, Jean-Baptiste Camps, Prunelle Deleville, Lucien Dugaz, Frédéric Duval, Simon Gabay, Lucence Ing, Vincent Jolivet, Marco Maulu, Mariotti Viola, Ariane Pinche, Anne Rochebouet, Aurélia Rostaing, Benedetta Salvati, Peter Stokes, Marguerite Vernet 

I-Présentation de l’ontologie Segmonto par J. B. Camps et S. Gabay

La présentation est disponible au lien suivant : https://hal.archives-ouvertes.fr/hal-03481089

1. Présentation du projet et de ses objectifs

La mise en place du vocabulaire contrôlé SegmOnto est un travail d’équipe mené par J. B. Camps et Simon Gabay1 qui a débuté en 2021 pour répondre à des problèmes pratiques qui se posent face à la nécessité de segmenter les documents pour l’HTR avant la phase de reconnaissance d’écriture manuscrite. Comment décrire les différentes zones des imprimés ou des manuscrits en utilisant des termes qui conviendraient aussi bien à des documents médiévaux qu’à des imprimés du 19siècle ? 

Différentes zones communes à un large nombre de documents ont été définies : corps du texte (1, 2, 3 colonnes), lettrines ou initiales ornées, décorations, numérotation des pages ou des folios, annotations marginales ou encore le titre courant. Le projet s’est inspiré des termes traditionnels de la codicologie (D. Muzerelle, Vocabulaire codicologiqueCodicologicade l’IRHT : http://codicologia.irht.cnrs.fr/accueil/vocabulaire) avec quelques adaptations pour permettre une compatibilité avec la recommandation SKOS2 et la mise en place d’un vocabulaire minimal permettant une approche générale et adaptable à une pluralité de cas. SegmOnto s’appuie essentiellement sur une analyse de la mise en page, plus qu’une analyse sémantique. 

La standardisation des pratiques est cruciale pour la numérisation massive des documents des prochaines années. L’analyse de la mise en page est donc une étape clef des futures chaînes de traitement, comme pour le projet Galli(corpor)a où ces informations permettront de proposer une chaîne de traitement automatique de l’image issue de Gallica jusqu’à une sortie en XML TEI ou en RDF3 où l’information sera structurée à partir de la segmentation. En effet, la reconnaissance des zones pourra être utilisée pour proposer un encodage XML TEI reprenant la structuration de l’information sur la page du document. La segmentation est donc l’élément clé de la pipeline, d’autant plus qu’une bonne segmentation favorise la mise en place de l’HTR, proprement dit.

Le segmenteur pour reconnaître les zones s’appuie sur l’organisation des éléments sur une page et repère les endroits réservés à certains types de zones. Le module des lettres, les variations des mains, la couleur permettent également leur identification. Toutefois, des limites techniques ont pu être observées, notamment la fusion de lignes ou de zones d’un même type quand ces dernières sont trop proches. Ces limitations, vouées à s’atténuer, voire disparaître au cours du temps, ne doivent pas avoir d’impact sur les définitions du vocabulaire contrôlé, mais des moyens à court terme pour aider le système à ne plus confondre les zones voisines sont envisagés. 

SegmOnto a un double objectif : 

  1. Permettre l’interopérabilité des données de segmentation pour pouvoir les mettre en commun et améliorer l’analyse de la mise en page ;
  2. Permettre le post-traitement automatique des données pour de la fouille de données et/ou pour mettre en place des exports dans différents formats (TEI, RDF).

2- Présentations des types de zones et de lignes de SegmOnto

A- Les zones

Les types de zones ont des définitions assez larges pour ne pas surcharger le vocabulaire en les multipliant.

Ci-dessous la liste des zones du projet et les questions qu’elles soulèvent. 

  • Damage : caractérise des zones avec des dégâts matériels. Leur texte est difficile à reconnaître automatique, mais leur présence a un effet sur la qualité de la prédiction.
  • Digitalisation artefact : objet externe au document source, par exemple les règles ou gammes de couleurs.
  • Décoration : tout type de décoration. Faudra-t-il à terme distinguer : ornementation et illustration ? La question est toujours en suspens.
  • DropCapital : lettrines et lettres ornées, tout type d’initiale occupant plus d’une ligne du corps de texte ou comportant des ornementations. Ces lettres sont distinctes des décorations, car elles mêlent décor et texte. Faut-il distinguer les lettrines de la ligne du texte principal ? Si on opte par une séparation, il sera compliqué de les rattacher au texte, mais pour un segmenteur les rattacher entraîne une fracture dans la ligne qui va affecter son masque et très certainement dégrader la prédiction de toute la ligne. 
  • Figure : zone consacrée, non pas au décor, mais à un schéma qui permet d’argumenter un propos comme on peut en trouver dans les imprimés scientifiques. Cette zone à une fonction différente de celles des décorations.
  • Main : zone de texte principale comportant une ou plusieurs colonnes. Dans le cadre d’une page de plusieurs colonnes, si ces dernières sont très proches les unes des autres, les différentes zones main ont tendance à fusionner. L’utilisation d’un type unique pose des problèmes pendant l’apprentissage. L’utilisation d’une zone Main est préférée à la multiplication des types de zones pour l’instant, quitte à faire des aménagements techniques en utilisant des spécifications comme main#1, main#2, etc.
  • Margin : caractérise toutes les zones de texte dans les marges (en haut, en bas, sur les côtés ou entre les colonnes) que ce soit des gloses, des additions, des corrections, des annotations, etc. En opposant main et margin, on fait une distinction matérielle de la mise en page, plutôt qu’une distinction sémantique en termes de contenu. Cette zone aura peut-être besoin de sous-types à terme, comme note ou apparat critique.
  • MusicNotation : portée, neumes. Cette zone est pensée pour être utile en combinant son usage à un outil de reconnaissance automatique de la musique. Il est toutefois difficile de gérer cette zone quand elle mêle musique et texte. Faut-il faire une autre zone dédiée au texte ?
  • Numbering : zone qui contient le numéro de page. Cette information est importante pour naviguer dans le corpus ou retrouver des problèmes de séquences dans le manuscrit. Toutefois, cette zone doit-elle constituer une zone à part ? Ou bien être regroupée avec les réclames, les titres courants et simplement être distinguée par des sous-types. 
  • RunningTitle : zone qui contient le titre courant. 
  • Seal : zone contenant un sceau. Les sceaux sont courants dans une variété de sources juridiques et quotidiennes (lettres, etc.). Ils sont généralement originaux et insérés par l’expéditeur du document. Faut-il réellement à terme distinguer les sceaux des tampons ?
  • Zone QuireMarks : réclame qui sert à marquer les cahiers pour faciliter l’assemblage. Cette zone doit-elle véritablement être distinguée de la zone Numbering ?
  • Stamp : zone qui contient les estampilles et/ou tampons. Ces éléments sont matériellement différents des sceaux, mais cela fait-il sens pour le segmenteur de les distinguer ?
  • Table : zone pour distinguer des zones de tableaux avec des chiffres et des noms
  • TitlePage : zone de titre principal qui se distingue du texte, notamment dans le cadre d’une page de garde.

B- Les lignes

  • Default : ligne standard où qu’elle soit et pour laquelle on a besoin d’une prédiction HTR.
  • DropCapitaleLine : ligne distincte pour les capitales ornée, car elle contient à la fois du texte et de l’image. Elles sont très rarement reconnues par le prédicteur. On peut se demander si la redondance avec la zone est problématique. Comment gérer le lien entre la capitale ornée et la ligne à laquelle elle appartient ? Insérer la lettre ornée dans la ligne de texte causerait une fracture dans cette dernière qui entrainerait un problème dans le calcul du masque de la ligne et viendrait très certainement affecter la qualité de la prédiction pour cette ligne.
  • Interlinear : caractérise les lignes non standards qui ont été ajoutées entre deux lignes pour signaler par exemple un oubli, une correction ou une glose. À terme, il faudra songer à réintégrer cette ligne au bon endroit dans le texte.
  • MusicLine : caractérise la ligne centrale d’une portée musicale. Faut-il ici caractériser la ligne ou bien se contenter d’une région ?
  • Rubric : texte écrit à l’encre rouge, parfois mêlé aux lignes par défaut. Ces lignes peuvent signaler le début d’un nouveau texte.

L’état du vocabulaire contrôlé présenté ici est un état qui demande encore à être enrichi et homogénéisé.

3- Mise en correspondance avec d’autres ontologies 

Comment exploiter ce vocabulaire ? 

On peut imaginer une correspondance avec un encodage TEI qui permettrait d’automatiser la chaîne d’acquisition du texte jusqu’à une mise à disposition d’un fichier XML TEI, voire d’une visualisation qui s’appuie sur l’encodage.

En TEI, il y a plusieurs manières de modéliser les données et plusieurs endroits pour ajouter les informations sur le lien texte/image des données issues de l’HTR :

  1. Dans l’élément <facsimile>
  2. Dans l’élément <sourceDoc>
  3. Dans le corps du document XML avec une mise en correspondance avec les zones de l’image source en standoff.

On peut créer de la redondance de données en mettant la prédiction liée aux images sources dans le <sourceDoc> et l’édition du texte dans l’élément <body> du document XML ou bien consigner toutes les informations au même endroit dans le corpus du texte en s’appuyant sur <facsimile>. C’est un débat en cours, la solution doit aussi dépendre à terme de l’usage que l’on veut faire du texte. Par exemple : comment gérer deux états du document dans une édition qui veut proposer une édition avec une transcription imitative et une normalisée ? Faut-il proposer un ou plusieurs formats TEI ?

La mise en place d’un mapping TEI permettra de produire des documents de bonne qualité les plus précis possible en automatisant au maximum leur production. Cette chaîne de traitement est déjà efficace pour les imprimés du 17et 18siècle et la reconnaissance des zones est déjà performante. Produire un balisage TEI avec une hiérarchisation sémantique des documents en paragraphes, par exemple, est toujours problématique, car ces subdivisions ne relèvent pas toujours de la mise en page de la source et parce qu’il n’est pas encore possible de gérer le chevauchement d’un paragraphe entre deux zones ou deux documents. 

Enfin, en plus du mapping XML Alto vers TEI, un mapping vers RDF est également en cours d’élaboration avec l’aide de Nicolas Carboni (université de Genève) pour faciliter l’interrogation des corpus.

Conclusion

SegmOnto est le travail de quelques mois, un peu moins d’une année. Il est possible que certains aspects des documents n’aient pas encore été pris en compte. Qu’a-t-on oublié ? Doit-on tout prévoir ? Par exemple pour les catalogues d’exposition et de ventes de manuscrits, des éléments supplémentaires sont nécessaires, comme ajouter une zone pour l’entrée d’un document. Une zone custom pour SegmOnto est envisagée à l’instar du XMLPage. En effet, pourquoi ne pas laisser une zone privée pour les spécificités des projets : paragraphes, vers, strophes ? On peut également envisager des sous-types de zones pour préciser les informations sans déroger au vocabulaire commun qui se doit d’être aussi général que possible.

L’avancée des modèles de segmentation, notamment sur les imprimées, permet d’espérer d’obtenir rapidement des modèles efficaces, quand il n’en existe pas déjà. Une spécification devrait être publiée dans l’année pour permettre à la communauté de comprendre SegmOnto, mais aussi de se l’approprier. Le projet étant jeune, cette spécification se heurtera encore nécessairement à la vérité de terrain d’autres utilisateurs.

Discussion autour de la présentation SegmOnto

– La superposition des zones pose-t-elle des problèmes d’apprentissage au modèle ?

D’après les entraînements faits sur les imprimés modernes, la superposition ne pose pas de problème. Pour les dropCapital, le problème viendrait davantage de la petitesse des zones qui ne sont pas encore assez distinctes, ainsi que du manque de données d’entraînement.

– Les lettrines et lettres ornées doivent-elles faire partie de la ligne ?

Cela nous ferait créer des lignes complètement fracturées et nous amènerait à une impasse technique. 

– Que faire des lettres d’attente pour les initiales, des mots d’attente pour les rubriques ?

Les signaler dans la catégorie concernée, elles peuvent être considérées comme un sous-type inachevé de la zone ou de la ligne.

– Dans SegmOnto, il y a des zones avec et sans texte, notamment avec des zones qui permettent de comprendre pourquoi il n’y a pas de texte. N’arrive-t-on pas à des cas limites qui sortent du cadre de l’HTR en faisant du computer vision ? Ne faudrait-il pas une catégorie par défaut pour une zone sans texte qui permettrait de simplifier le vocabulaire contrôlé ?

L’un des objectifs de SegmOnto est de se servir de l’analyse de la mise en page pour le préencodage TEI. Ainsi, les informations sur les zones sans texte permettent d’enrichir l’encodage. Ces ajouts informationnels sont déjà utiles pour les travaux sur l’Histoire de l’art de Béatrice Joyeux‑prunel (professeure ordinaire à l’université de Genève, sur la chaire des Humanités numériques). Connaître l’emplacement d’une image et avoir accès au texte à côté nous aide à interpréter le texte et l’image. On peut utiliser ces liens et les images pour reconnaître, par exemple, des imprimeurs, des scriptoriums, etc., à l’instar du projet Filigranes pour tous4.

– Est-il pertinent d’annoter les ajouts matériels hors sources dans le cadre de l’HTR ?

Cette annotation peut simplement être utilisée pour les exclure à terme comme du hors-document et éviter que ces éléments ne produisent du bruit.

– Le cas du document de Lyon, on observe une zone de texte dégradée. Ce type de dégradation est différent d’un trou, car on peut lire le texte. Ces cas-là ne devraient-ils pas donner lieu à la création de sous-types de la zone Damage ? Pour le trou, il doit être signalé, c’est un non-texte, mais pas un hors texte. Sa présence a un impact sur la prédiction. Pour le reste, la question est ouverte à débats.

– Quelle part reste-t-il à l’interprétation  dans ce vocabulaire ?

Il n’est pas toujours aisé de distinguer ce qui relève de Decoration ou de Figure ? Par exemple : les arbres généalogiques dans les manuscrits médiévaux peuvent relever des deux catégories. La question devra être tranchée en fonction des projets et de l’utilisation des illustrations. 

La zone Main relève de l’interprétation : on peut considérer que c’est le cadre complet contenant les colonnes ou l’unité colonne. Pour certains manuscrits, la glose qui est contenue dans les marges est en réalité le texte principal.

Pour des raisons techniques, il faut résonner « à plat » sans complexifier/hiérarchiser l’usage des zones et rester au niveau de la mise en page. Pour la question d’une zone main englobant toutes les colonnes, on arriverait à des limites techniques, à cause de l’enclavement des zones les unes dans les autres (problème des superpositions/du découpage des zones qui ne permet pas de distinguer des zones enclavées). 

– Est-il possible, grâce à SegmOnto de signaler/reconnaître les grattages dans les manuscrits ? De quel niveau cela relève-t-il ? Zone ? Ligne ? Modalité de transcription ? On pourrait envisager un type de ligne de Damage.

– Serait-il intéressant d’identifier les premières lignes des résultats de l’HTR qui posent souvent des problèmes dans les prédictions HTR ? On pourrait imaginer un type de ligne custom (dans une zone privée du vocabulaire contrôlé) pour les lettres cadelées5.

– Que faire si une ligne est complètement grattée, mais que le texte est lisible ?

C’est une information très riche qui relève d’un encodage TEI, et qui reste très délicate pour l’HTR. Il serait intéressant de les repérer avec des zones ou des lignes pour améliorer l’HTR des textes médiévaux. Pour les imprimés, la bonne qualité des documents et des numérisations permet vraiment d’enrichir grâce à la segmentation les documents pour mettre en place une pipeline vers TEI. Toutefois les dommages ne sont pas fréquents.

– Pour tous les documents, avant une prédiction HTR, faudra-t-il tout redessiner à chaque fois ? Pour l’instant les modèles de segmentation ne fonctionnent pas très bien sur les documents médiévaux. Toutefois, la situation est remédiable, il semble que c’est avant tout un problème de manque de données d’entraînement. Enfin, le segmenteur apprend par palier, il passe une longue phase avec des résultats médiocres, mais dès qu’il atteint son seuil critique, son apprentissage s’accélère rapidement. Simon Gabay rappelle qu’on peut toutefois espérer que les données soient interopérables avec des données modernes et qu’on pourra créer des modèles mixtes ou personnalisés dès que l’on aura plus de données médiévales. On peut également envisager de créer artificiellement des données pour augmenter rapidement leur nombre et mettre rapidement au point un modèle de base. Jean-Baptiste Camps émet quelques réserves sur un modèle uniquement basé sur des données artificielles. Elles sont un bon moyen d’augmenter d’un ou deux points l’efficacité d’un modèle, mais elles ne remplacent pas la variété d’un échantillon naturel. Alix Chagué rappelle que l’augmentation artificielle des échantillons est déjà prise en charge par Kraken avec l’option augment. Simon Gabay signale qu’aujourd’hui on peut créer des données artificielles plus poussées encore avec des jeux sur l’orientation des images, des jeux de dégradation, chiffonner les pages par exemple, pour créer du bruit. Il existe déjà des outils développés par le laboratoire LaBRI, comme DocCreator6 qui permet de faire tout cela. 

III-Comment signaler les corrections, les ajouts, les interventions du copiste et les signes auxiliaires présents dans le manuscrit ?

Nous essaierons ici de faire une liste des cas de corrections, ajouts, interventions du copiste et des signes auxiliaires que nous pouvons rencontrer dans les manuscrits. Nous chercherons par quel moyen nous pouvons les représenter : ajout d’un signe dans la transcription, indication sur la mise en page au niveau de la zone ou de la ligne à l’aide de l’ontologie SegmOnto.

1. Les corrections

Frédéric Duval souligne la difficulté de la tâche. Définir une norme pour représenter les signes de corrections ou les ajouts est encore difficile, car nous aurions besoin d’un projet avec un travail codicologique de fonds qui se concentre sur ces modalités dans les manuscrits médiévaux. Toutefois un tel projet aurait besoin de données, il faudra donc en attendant trouver un premier moyen d’en produire en mettant ici en commun nos expériences. Aurélia Rostaing rappelle que pour les notaires chacun a son système. Il s’agit donc de préconiser un système simple et généraliste qui puisse aider la plus large communauté scientifique possible.

Nous traiterons ici des corrections qui relèvent d’une intervention du copiste dans le corps du texte7. Les questions suivantes ont été soulevées : 

Comment indiquer les corrections quand le texte est barré, exponctué ou que l’encre a été modifiée ? Comment signaler un blanc en attente de correction ? Dans ces cas, peut-on identifier des zones ? Des lignes ? Comment signaler une lettre exponctuée et non pas un passage complet ? Le phénomène est souvent très limité dans le texte, le coût de création d’une nouvelle zone ou d’un nouveau type de ligne ne semble-t-il pas trop élevé ? Une solution plus légère serait préférable (à terme, un système d’annotations ou de mise en forme dans eScriptorium pourrait être une solution, mais cela pourrait rendre les données dépendantes d’une technologie). Pourquoi ne pas mettre des chevrons pour signaler une correction ? Attention, ces caractères peuvent poser des problèmes avec les documents modernes. Il faudrait trouver des caractères plus rares. Dans le cadre du projet Lectaurep, les ratures ont été signalées en faisant précéder la transcription du terme raturé par le signe € sans espace8. Pour signaler, par exemple, les corrections, Peter Stokes suggère que l’on choisisse un symbole Unicode avec une sémantique compatible. Il existe en UTF-8 un caractère delete (007F), également signalé dans MUFI9, mais il n’est pas visible dans le texte, ce qui semble le rendre difficile à utiliser. Nous favorisons l’usage d’un signe non imitatif pour signaler les zones de correction suivante : 

  • exponctuation
  • texte souligné
  • biffure/rature.

Pour tous les signes de corrections cités précédemment, après divers débats, dont la préconisation de l’ajout d’une annotation (à l’aide d’un balisage TEI) qui n’est malheureusement pas encore disponible sur eScriptorium, nous choisissons d’utiliser un signe standard aisément manipulable, quelque soit l’outil utilisé. L’enrichissement informationnel qui permettrait de les différencier nous semble davantage relever d’une annotation sémantique.

La proposition du signe : © (COPYRIGHT SIGN, 00A9) a été solution rejetée, car il semble plus pertinent d’utiliser un signe ouvrant et un signe fermant pour délimiter aisément le phénomène, notamment en cas de chevauchement d’une zone à une autre ou d’un document à un autre. Nous proposons de nous appuyer sur les signes sélectionnés par la convention de Leiden en choisissant : [[ (U+005B (deux fois), double crochets droits ouvrants) et ]] (U+005D (deux fois), double crochets droits fermants) qui viendront encadrer le texte corrigé de la manière suivante : [[ texte corrigé ]].

Quand la correction consiste en un blanc laissé en attente ou en un grattage qui rend le texte illisible, nous avions pensé au signe UTF-8 : « ¬ » (NOT SIGN, 00AC), mais ce dernier est utilisé notamment dans Transkribus pour noter les hyphenisations. Par souci d’homogénéité et pour réduire le nombre de signes différents, nous proposons d’utiliser les mêmes signes « [[ » et « ]] » que pour les corrections, mais cette fois sans texte à l’intérieur.

Dans le cas d’un grattage où le texte est lisible, nous proposons de le transcrire sans indication. Nous procéderons de même dans le cas de la transformation d’une lettre en une autre. Ces options sont également celles qui ont été retenues dans le cas du projet Lectaurep.

Dans le cas d’un palimpseste, seule la dernière strate de texte sera utilisée. D’un point de vue technique, il est fort peu probable que la couche en dessous soit traitée par la prédiction HTR, car elle sera considérée comme du bruit à éliminer. En effet, il semble impossible de faire la différence entre le texte en dessous et le texte de l’autre côté de la feuille qui pourrait apparaître par transparence.

2. Les ajouts : oublis, notes et commentaires

Pour les catégories suivantes : glose marginale, glose encadrante, marginalia, note, il nous semble qu’on peut les signaler grâce à la segmentation en utilisant par exemple la zone Margin de SegmOnto. Pour les gloses interlinéaires, elles peuvent être signalées par un type de ligne particulier comme le type Interlinear de SegmOnto. 

(les signes de renvois seront traités lors de la 3e séance)


Lexique

– Computer vision :  La vision par ordinateur est une branche de l’intelligence artificielle. Les tâches de vision par ordinateur permettent d’acquérir, traiter, analyser et « comprendre » des images pour en extraire des données sur le contenu de l’image. Une des utilisations les plus fréquentes de la vision par ordinateur est la reconnaissance faciale.

– RDF : Ressource Description Framework a été développé par les W3C. RDF est un modèle de graphes qui permet de lier sur le Web de données et des métadonnées grâce à un système d’URI qui relie des informations entre elles selon le schéma sujet-prédicat-objet (triplet RDF), <https://www.w3.org/RDF/>.

– SKOS : Simple Knowledge Organization System est une recommandation du W3C publiée en 2009 pour décrire les systèmes d’organisation : thésaurus documentaire, classifications. SKOS, en s’appuyant sur le modèle de données RDF. Elle permet la publication de vocabulaires structurés adaptés au Web sémantique, <https://www.w3.org/2004/02/skos/intro>. Il existe déjà un vocabulaire international de la codicologie – SKOS disponible à l’adresse suivante : <http://gams.uni-graz.at/archive/objects/o:voccod/methods/sdef:SKOS/get>

– TEI : La Text Encoding Initiative est un consortium qui développe et maintient un standard pour la représentation des textes sous forme numérique (XML), <https://tei-c.org>.

– XML Alto : ALTO (Analysed Layout and Text Object) est un standard XML permettant de rendre compte de la mise en page physique et de la structure logique d’un texte transcrit par OCR (optical character recognition) ou HTR. Il conserve toutes les coordonnées géométriques des contenus (textes, illustrations, graphiques) dans l’image et permet la superposition de l’image et du texte, <https://www.bnf.fr/fr/techniques-et-formats-de-conversion-en-mode-texte#bnf-le-format-alto>.

– XML Page : PAGE (Page Analysis and Ground truth Elements) est un standard XML pour l’encodage de documents numérisés. Comparable au format ALTO, il permet de rendre compte de l’organisation et de la structure d’une page et de ses contenus. Le format est développé par le Pattern Recognition & Image Analysis Lab (PRIMA), au sein de l’Université de Salford à Manchester.


1 Cette initiative est le fruit d’une collaboration entre les projets eScriptorium et Kraken (Benjamin Kiessling, Daniel Stoëckl, Peter Stokes), cremmaLab (projet ENC-INRIA), l’INRIA et l’université de Genève.

2 Simple Knowledge Organization System (SKOS) est une recommandation du W3C publiée en 2009 pour décrire les systèmes d’organisation : thésaurus documentaire, classifications. SKOS, en s’appuyant sur le modèle de données RDF, permet la publication de vocabulaires structurés adaptés au Web sémantique, <https://www.w3.org/2004/02/skos/intro>. Il existe déjà un Vocabulaire international de la codicologie – SKOSdisponible à l’adresse suivante : http://gams.uni-graz.at/archive/objects/o:voccod/methods/sdef:SKOS/get

3 Ressource Description Framework a été développé par les W3C. RDF est un modèle de graphes qui permet de lier sur le Web de données et des métadonnées grâce à un système d’URI qui relie des informations entre elles, selon le schéma sujet-prédicat-objet (triplet RDF),https://www.w3.org/RDF/.

4 « Le projet “Filigranes pour tous” prépare la réalisation d’une application de reconnaissance optique de formes destinée aux chercheurs, aux conservateurs et de manière générale à tous les publics intéressés à l’identification automatique des filigranes (antiquariat, amateurs, etc.) », <https://filigranes.hypotheses.org>.

5 « Cadelure, lettres cadelées : Traits de plume entrecroisés, à effet décoratif, qui forment certaines parties de la lettre ou qui en prolongent la haste », <http://codicologia.irht.cnrs.fr/theme/liste_theme/561#tr-5580>

6 JOURNET, Nicholas, VISANI, Muriel, MANSENCAL, Boris, [et al.], « DocCreator: A New Software for Creating Synthetic Ground-Truthed Document Images », Journal of Imaging, vol. 3 / 4, décembre 2017, [En ligne : https://hal.archives-ouvertes.fr/hal-01668915].

7 L’ensemble des termes utilisés pour indiquer les types de corrections sont issus du dictionnaire paléographique de D. Muzerelle, disponible en ligne : « http://codicologia.irht.cnrs.fr>

8 Certains projets ont pu utiliser des émojis pour signaler les corrections. 

9 MUFI: The Medieval Unicode Font Initiative, <https://mufi.info/m.php?p=mufi>.

Pour citer ce document : Ariane Pinche, Compte-rendu de la séance n°2 du séminaire : “Création de modèle(s) HTR pour les documents médiévaux en ancien français et moyen français entre le Xe-XIVe siècle”, École nationale des chartes; Centre Jean Mabillon, 2021.