Textes et savoirs numériques

Encoder un texte en XML-TEI : principes de base pour éditer un corpus littéraire

Pourquoi encoder un texte littéraire en XML-TEI ?

Éditer un corpus littéraire ne consiste pas seulement à numériser des pages ou à recopier leur contenu dans un fichier texte. Une édition numérique doit aussi rendre explicites les informations utiles à la lecture, à la comparaison et à l’analyse. Il faut pouvoir distinguer un titre, un paragraphe, un personnage, une note, une correction éditoriale, une page du document source ou encore une variante entre plusieurs témoins.

Le XML-TEI répond à ce besoin. XML, pour Extensible Markup Language, est un langage de balisage qui décrit la structure et le sens des données. TEI, pour Text Encoding Initiative, désigne un ensemble de recommandations destinées à représenter des textes, en particulier dans les sciences humaines et sociales. Les recommandations TEI sont maintenues et documentées par le TEI Consortium, notamment dans les TEI Guidelines.

L’intérêt principal n’est donc pas de produire un fichier plus sophistiqué qu’un document bureautique. Il est de séparer plusieurs niveaux souvent confondus :

Cette séparation rend le corpus interrogeable, transformable et réutilisable. Le même fichier XML-TEI peut servir à produire une lecture en ligne, une version imprimable, un export pour une base de données ou un jeu de données destiné à une analyse textuelle. La TEI ne garantit cependant pas, à elle seule, la qualité d’une édition. La cohérence des décisions éditoriales et leur documentation restent essentielles.

Comprendre la logique du balisage sémantique

Un balisage sémantique ne se limite pas à indiquer l’apparence d’un passage. Dans un traitement de texte, on peut mettre un mot en italique parce qu’il apparaît ainsi sur la page. En TEI, la balise hi peut signaler une mise en évidence, avec un attribut précisant éventuellement son rendu ou sa fonction. Si l’italique indique plutôt un titre d’œuvre, une expression étrangère ou une pensée rapportée, des balises plus précises peuvent être préférables.

La question à se poser est donc : que représente ce passage dans le document ou dans l’édition ? Cette question évite de multiplier les balises choisies uniquement pour leur apparence. Une balise comme p décrit un paragraphe. Une balise comme div décrit une division textuelle, par exemple un chapitre ou une partie. Une balise comme persName identifie une mention de personne. Une balise comme placeName identifie une mention de lieu.

Le balisage doit aussi respecter une hiérarchie. Un chapitre peut contenir un titre et plusieurs paragraphes. Une pièce de théâtre peut contenir des actes, des scènes, des répliques et des indications scéniques. Un poème peut contenir des strophes, représentées par lg, et des vers, représentés par l. Cette structure forme un arbre : chaque élément est contenu dans un autre, sauf l’élément racine.

Il faut distinguer deux notions souvent mélangées :

Une édition peut ainsi représenter un paragraphe qui commence au milieu d’une page, tout en conservant le début et la fin de cette page au moyen de balises adaptées. Cette distinction est importante pour les corpus qui s’appuient sur des éditions anciennes, des manuscrits ou des fac-similés.

La structure minimale d’un fichier TEI

Un fichier TEI comporte généralement un élément racine TEI. Celui-ci contient deux grandes parties : teiHeader, qui décrit le document, et text, qui contient le texte édité. Une structure minimale peut être résumée ainsi :

<TEI xmlns="http://www.tei-c.org/ns/1.0">
  <teiHeader>... métadonnées ...</teiHeader>
  <text>
    <body>... texte ...</body>
  </text>
</TEI>

L’attribut xmlns indique l’espace de noms TEI. Il permet aux logiciels de reconnaître la grammaire utilisée. Son absence peut compliquer la validation ou les transformations, surtout dans des environnements qui manipulent plusieurs vocabulaires XML.

Dans text, l’élément front peut accueillir les éléments liminaires, comme une préface, une dédicace ou une table des matières. L’élément body contient le corps principal de l’œuvre. L’élément back peut accueillir une postface, des annexes ou un glossaire. Ces parties sont facultatives selon le type de document.

Un extrait de roman pourrait être structuré de la manière suivante :

<text>
  <body>
    <div type="chapter" n="1">
      <head>Titre du chapitre</head>
      <p>Premier paragraphe du texte.</p>
      <p>Deuxième paragraphe du texte.</p>
    </div>
  </body>
</text>

L’attribut type précise ici la nature de la division, tandis que n fournit un numéro ou un repère. Un attribut n’est pas une balise supplémentaire : il donne une propriété à l’élément auquel il est attaché. Il faut éviter d’utiliser des attributs de manière improvisée, car un corpus cohérent repose sur des choix stables et documentés.

Renseigner le teiHeader : l’édition commence par ses métadonnées

Le teiHeader est souvent considéré comme une partie administrative du fichier. Il joue pourtant un rôle scientifique central : il indique ce qui a été encodé, à partir de quelle source et selon quelles règles. Un lecteur doit pouvoir comprendre l’origine du texte et les interventions de l’éditeur.

Le composant fileDesc est généralement obligatoire. Il peut contenir :

Dans sourceDesc, on peut distinguer une édition imprimée, un manuscrit, une transcription antérieure ou plusieurs témoins. Cette information est particulièrement importante lorsque le texte numérique n’est pas une simple reproduction d’une édition unique.

Le composant encodingDesc décrit les principes d’encodage. Il peut préciser les choix de normalisation, les conventions utilisées pour les abréviations, la représentation des corrections ou la manière dont les personnes et les lieux sont identifiés. Le composant profileDesc peut décrire la langue, la situation de communication ou certains paramètres du texte. Le composant revisionDesc conserve l’historique des modifications.

Une documentation utile répond notamment aux questions suivantes :

La présence de ces informations permet de distinguer le texte source, la transcription et les interventions éditoriales. Elle facilite aussi le travail d’une personne qui devra vérifier ou prolonger le corpus.

Choisir entre transcription diplomatique et édition de lecture

Avant de baliser, il faut définir le type d’édition recherché. Une transcription diplomatique cherche à conserver au plus près les caractéristiques observables du document : graphie, ponctuation, abréviations, retours à la ligne ou disposition. Une édition de lecture peut normaliser certains éléments afin de faciliter la compréhension, tout en signalant les interventions importantes.

Ces deux orientations ne sont pas interchangeables. Si une graphie ancienne est modernisée sans être signalée, le fichier ne permet plus de distinguer la forme présente dans le document de la forme proposée par l’éditeur. À l’inverse, une transcription diplomatique très détaillée peut être moins adaptée à une lecture courante ou à certaines analyses linguistiques.

La TEI offre plusieurs mécanismes pour rendre ces choix visibles. L’élément orig peut conserver une forme originale, tandis que reg peut fournir une forme régularisée. L’élément choice permet de regrouper plusieurs possibilités éditoriales. Pour une correction, sic peut signaler une forme conservée malgré son caractère inhabituel, et corr une forme corrigée.

Un exemple conceptuel pourrait être représenté ainsi :

<choice><orig>forme présente dans la source</orig><reg>forme régularisée</reg></choice>

Ce dispositif ne signifie pas que la forme régularisée est toujours préférable. Il signifie que les deux niveaux sont conservés et que leur relation est explicitée. Le choix dépend du projet, du public visé et des usages prévus pour les données.

Encoder les personnes, les lieux et les références textuelles

Un corpus littéraire peut être interrogé selon les personnages, les lieux, les œuvres citées ou les événements mentionnés. Pour rendre ces requêtes possibles, il faut annoter les références de manière régulière. persName convient aux noms de personnes, placeName aux noms de lieux, et orgName aux organisations lorsqu’elles sont pertinentes pour le projet.

Une simple annotation textuelle peut déjà être utile :

<persName>Nom du personnage</persName> se rend à <placeName>Nom du lieu</placeName>.

Pour relier différentes occurrences à une même notice, on peut attribuer un identifiant stable, généralement avec l’attribut ref ou xml:id selon le besoin. Il faut toutefois distinguer l’identification dans le texte et la description complète dans une liste d’autorité. Une mention peut être reliée à une entrée décrivant les variantes du nom, les dates connues ou les relations avec d’autres entités.

Les identifiants doivent être décidés avant l’annotation massive. Un identifiant qui change sans raison entre deux fichiers rend les comparaisons plus difficiles. Il est également déconseillé de déduire automatiquement l’identité d’une personne uniquement à partir d’une chaîne de caractères : deux personnages peuvent porter le même nom, et un même personnage peut être désigné par plusieurs formes.

Le degré d’interprétation doit être indiqué. Identifier une forme comme une personne réelle, un personnage fictif, un lieu historique ou un lieu imaginaire peut nécessiter une décision éditoriale. Lorsque l’identification reste incertaine, le corpus doit pouvoir conserver cette incertitude plutôt que de la masquer.

Représenter les notes, les variantes et les corrections

Les œuvres littéraires existent souvent sous plusieurs formes : manuscrits, éditions successives, épreuves corrigées ou traductions. Un corpus peut vouloir reproduire une version précise ou comparer plusieurs témoins. Dans les deux cas, il faut distinguer le texte principal et les informations qui l’accompagnent.

L’élément note peut représenter une note éditoriale, une note de l’auteur ou une note de bas de page. Son type ou sa place doivent être documentés pour éviter de confondre ces fonctions. Pour les variantes, app, lem et rdg permettent généralement de représenter une leçon retenue et des leçons concurrentes. La modélisation exacte dépend du projet et du niveau de détail recherché.

Pour une suppression ou un ajout dans un document, les éléments del et add peuvent conserver la trace de l’intervention. Les attributs comme resp, type ou place peuvent préciser qui est associé à cette action, sa nature ou sa position. Une correction éditoriale ne doit pas être encodée comme si elle appartenait au texte original.

Cette prudence est importante pour l’analyse. Une recherche sur les mots effectivement présents dans une édition ne doit pas produire le même résultat qu’une recherche incluant les corrections ou les variantes. La structure TEI permet de conserver ces dimensions, mais l’outil de consultation ou d’analyse doit ensuite décider comment les traiter.

Conserver les repères de l’édition source

Lorsqu’un texte est transcrit depuis un livre, un manuscrit ou un fac-similé, les repères matériels facilitent la vérification. La balise pb peut signaler un changement de page. D’autres éléments permettent de représenter des lignes, des colonnes ou des zones selon la nature du document et le niveau de précision retenu.

Ces repères ne doivent pas remplacer la structure littéraire. Un paragraphe ne devient pas une nouvelle unité parce qu’il traverse une page. Il faut conserver séparément la continuité du texte et l’emplacement dans la source. Cette séparation permet de produire une lecture fluide tout en offrant un accès aux références utilisées par l’édition critique.

Les attributs de numérotation et d’identification doivent être utilisés avec cohérence. Une référence de page peut correspondre à la pagination imprimée et non au numéro d’image d’un fichier numérisé. Lorsque les deux sont utiles, il est préférable de les distinguer explicitement dans les métadonnées ou dans les attributs prévus par le modèle retenu.

Valider un fichier XML-TEI

Un fichier XML doit d’abord être bien formé. Cela signifie notamment que les éléments sont correctement imbriqués, que chaque élément ouvert est fermé et que les valeurs d’attributs sont correctement délimitées. XML est sensible à la casse : p et P ne sont pas équivalents.

Un document peut être bien formé sans respecter la structure TEI choisie. La validation avec un schéma permet de vérifier les éléments autorisés, leur ordre, leurs attributs et leurs relations. La TEI peut être personnalisée afin de retenir un sous-ensemble adapté au projet. Cette personnalisation doit cependant être documentée, car elle modifie les possibilités de lecture du corpus par d’autres outils.

La validation doit intervenir régulièrement, et pas seulement à la fin. Une méthode pratique consiste à :

  1. créer une structure minimale valide ;
  2. ajouter une unité textuelle courte ;
  3. valider le fichier ;
  4. ajouter progressivement les annotations ;
  5. corriger les erreurs avant de poursuivre.

Il faut aussi vérifier la validité éditoriale, qui ne se réduit pas au contrôle automatique. Un fichier peut être techniquement valide tout en mélangeant des conventions, en annotant seulement certaines occurrences ou en attribuant le même identifiant à des entités différentes. La relecture humaine, les tests de recherche et la comparaison avec la source restent indispensables.

Organiser un projet d’encodage de corpus

L’encodage gagne en fiabilité lorsqu’il repose sur une méthode explicite. Avant de saisir les balises, il est utile de rédiger une courte politique d’encodage. Elle peut préciser le type d’édition, les structures retenues, les règles de normalisation, les catégories d’entités et la gestion des incertitudes.

Un tableau de décision peut servir de référence commune :

QuestionDécision à documenterExemple de conséquence
Quelle source est transcrite ?Édition, manuscrit ou ensemble de témoinsRenseignement de sourceDesc
Les graphies sont-elles conservées ?Transcription diplomatique ou régulariséeUsage éventuel de orig, reg ou choice
Quelles structures sont encodées ?Chapitres, scènes, strophes, paragraphesOrganisation avec div, lg, l et p
Quelles entités sont identifiées ?Personnes, lieux, œuvres ou organisationsUsage régulier de persName et placeName
Comment les corrections sont-elles signalées ?Correction intégrée ou variante conservéeUsage de corr, sic, add, del ou app

Il est préférable de conserver les fichiers sources, les versions intermédiaires et les règles de transformation. Un dépôt organisé permet de retrouver l’origine d’une modification et de reconstruire une version précédente. Les noms de fichiers, les identifiants et les conventions de date doivent rester stables.

Les transformations vers HTML, PDF ou d’autres formats ne doivent pas être confondues avec le fichier maître. Le XML-TEI conserve les données structurées ; une feuille de transformation détermine ensuite leur présentation. Cette distinction protège les informations éditoriales lorsqu’une nouvelle interface ou un nouvel usage est envisagé.

Les erreurs fréquentes à éviter

Plusieurs erreurs reviennent dans les premiers projets XML-TEI :

Une autre difficulté consiste à vouloir tout encoder dès la première version. Un projet peut commencer par une structure fiable et un nombre limité d’annotations, puis s’enrichir. L’important est de savoir ce qui est représenté, ce qui ne l’est pas encore et pourquoi.

Une méthode de travail en six étapes

Pour un corpus littéraire de taille limitée ou moyenne, le déroulement suivant offre un cadre opérationnel :

  1. Définir l’objectif : lecture, édition critique, comparaison de témoins, recherche linguistique ou combinaison de ces usages.
  2. Décrire les sources : identifier les éditions, manuscrits, numérisations et éventuelles transcriptions intermédiaires.
  3. Établir les règles : choisir les structures, le niveau de normalisation, les entités à annoter et les conventions d’identifiants.
  4. Construire un échantillon : encoder un passage représentatif comprenant les difficultés attendues.
  5. Valider et relire : contrôler la syntaxe XML, le schéma TEI et la fidélité au document source.
  6. Étendre progressivement : appliquer les règles au reste du corpus en enregistrant les cas particuliers et les décisions nouvelles.

Cette progression réduit le risque de devoir reprendre tous les fichiers après une décision tardive. Elle permet aussi de vérifier si les balises choisies sont réellement utiles pour les analyses prévues. Dans un corpus littéraire, la qualité dépend moins du nombre de balises que de la stabilité des distinctions opérées.

FAQ : questions courantes sur l’encodage XML-TEI

Le XML-TEI est-il réservé aux spécialistes de l’informatique ?

Non. Une connaissance de base de la logique XML est nécessaire, mais l’essentiel du travail concerne les décisions éditoriales : identifier les structures, décrire les sources et expliciter les interventions. Des outils peuvent faciliter la validation, sans remplacer ces choix.

Faut-il encoder chaque détail typographique ?

Pas nécessairement. Le niveau de détail dépend de l’objectif. Une édition destinée à la lecture n’a pas les mêmes besoins qu’une étude de la mise en page d’un manuscrit. Il faut surtout encoder les informations utiles et documenter les éléments laissés de côté.

Peut-on moderniser l’orthographe dans une édition TEI ?

Oui, si cette décision est annoncée et si la relation avec la forme source est conservée lorsque cela est nécessaire. Les mécanismes comme choice, orig et reg permettent de distinguer plusieurs niveaux.

Un fichier TEI peut-il contenir plusieurs versions d’une œuvre ?

Oui. La TEI propose des structures pour représenter des témoins et des variantes. Le modèle doit toutefois être choisi en fonction de la tradition textuelle étudiée et de la précision attendue.

Quelle est la priorité pour commencer ?

La priorité est de rédiger des règles d’encodage simples, de les tester sur un extrait et de valider régulièrement les fichiers. Une documentation claire vaut mieux qu’un balisage abondant mais incohérent.

En savoir plus à ce sujet :

Tous droits réservés | © Copyright dim-humanites-numeriques.fr.