Parce qu’il détermine tous les traitements informatiques qu’il est possible d’effectuer sur le texte, le balisage a historiquement constitué une question fondamentale dans l’histoire de l’informatique. Depuis l’article séminal de Coombs et ses collègues, on a pris l’habitude de distinguer plusieurs types de balisages : procédural, présentationnel, ou descriptif[38]. La supériorité du balisage descriptif sur les autres types de balisage du texte a clairement été établie depuis quelques années. Un tel balisage présente l’avantage notable d’assurer une meilleure distinction entre le contenu et la forme (et donc de séparer les traitements). Cette distinction garantit une meilleure maintenance du texte encodé et une meilleure portabilité des artefacts numériques.

La production d’un balisage descriptif consiste à identifier explicitement la structure sémantique sous-jacente d’un document, cela indépendamment de tout traitement déterminé à l’avance[39]. Il s’agit de distinguer explicitement à l’intérieur du texte différents objets éditoriaux en les encadrant par des balises dont le nom peut être arbitraire. Ce faisant l’auteur d’un balisage fournit une information sémantique et pragmatique suffisante pour produire des vues alternatives sur le document ou bien une édition basée sur la structure du texte. Les trois opérations qui interviennent au cours du balisage sont donc les suivantes :

• la reconnaissance des éléments, reconnaître que l’élément courant est un élément d’un certain type (paragraphe, citation en prose, note de bas de page, etc.)
• la sélection des balises, déterminer le balisage qui s’applique au type d’élément reconnu
• la réalisation du balisage, marquage de l’élément.

[40]

L’idée d’un balisage descriptif qui repose sur le fait de marquer le contenu d’un texte par des éléments suggère une représentation du texte qui correspond à ce qu’on a appelé un modèle d’éléments contenus hiérarchiquement imbriqués (OHCO, Ordered Hierarchical Content Objects, en anglais). Dans une telle représentation du texte, les éléments contenus (paragraphes, citations, phrases, notes, etc.) sont présentés à l’intérieur d’une structure hiérarchique. La structure du texte est hiérarchique parce qu’ils résident les uns à l’intérieur des autres. Les objets reçoivent donc des relations linéaires.

Contrairement aux apparences, les logiciels de traitement de texte qui mettent en forme les documents ne simplifient pas la production de documents en éliminant le besoin du balisage. D’une certaine manière cela est devenu plus clair aujourd’hui avec l’adoption des formats XML par Microsoft Word et Open Office. Mais, le balisage requis pour ces formats, tout en étant plus consommateur de ressources, n’atteint pas la même expressivité qu’un simple balisage descriptif. Par ailleurs, les dispositifs d’édition fondés sur un balisage descriptif présentent plusieurs avantages sur le balisage fondé sur la présentation comme LaTex :

• 1° Le processus d’établissement du texte se trouve simplifié par la focalisation sur le contenu plutôt que sur le contrôle du programme (dans le cas d’un balisage procédural) ou de la présentation typographique de la copie (comme avec LaTex)
• 2° Les questions de maintenance sont réduites à un nombre limité de problèmes indépendants du fichier proprement dit. L’actualisation des styles et la mise à jour s’en trouvent facilitées sans risque de corruption des documents.
• 3° Enfin, ils fournissent de meilleurs standards dans le domaine patrimonial et culturel, ou pour l’industrie, du point de vue de la portabilité. Ils permettent en effet le partage aisé des fichiers et réduisent, à terme, les coûts de publication.

Autrement dit, le balisage descriptif offre un certain nombre d’avantages pour l’éditeur. Outre qu’il permet de partager des documents pour collaborer sans se préoccuper d’éventuelles incompatibilités, il offre un gain de temps de production et de gestion en permettant la réalisation de plusieurs éditions successives à partir d’un même fichier source, ou de produire plusieurs manifestations (présentations) d’un même fichier. De surcroît, ce balisage permet le plus souvent la génération automatique de l’information bibliographique directement à partir du fichier source (ce qui réduit les erreurs et permet une citation aisée dans les bases bibliographiques) ou d’inclure directement des documents dans des bases de données en ligne pour la publication et la recherche plein-texte.

Même si la mise en place d’un balisage descriptif du texte, implique le déploiement d’une infrastructure technique sans-doute moins confortable pour travailler que l’utilisation de logiciels de traitement de texte, il faut relever qu’il permet de se concentrer sur le contenu du texte plutôt que sur la présentation physique finale du document. Bien entendu, concernant l’édition de manuscrits historiques, ou de sources primaires, il pourra être nécessaire de traiter la matérialité physique du document. Néanmoins c’est avant tout l’édition du texte qui est ici privilégiée. Dans une telle démarche, il convient en premier lieu de rendre la structure du texte explicite, c’est-à-dire de clarifier à la fois les relations hiérarchiques et séquentielles. Et la présence du balisage détermine la possibilité de traiter les éléments pour une transformation.

Le métalangage informatique XML (Extensible Markup Language) permet le développement de vocabulaires descriptifs de balisages interopérables spécifiques à certains domaines[41]. Son modèle de contenu arborescent est précisément conforme au modèle OHCO. S’il offre une grammaire lisible par la machine, il ne présente pas une réelle sémantique et ne peut donc à lui seul spécifier formellement une sémantique. XML propose simplement une solution rigoureuse, compréhensible par les machines, pour définir un langage de balisage descriptif. La plupart des contenus des bibliothèques numériques aujourd’hui mis à disposition sur le web sont encodés en utilisant un balisage XML. « La large adoption de vocabulaires XML spécialisés comme la TEI rendent disponible une importante information sémantique, mais seulement sous la forme d’une documentation en prose et de pratiques partagées.[42] »

La Text Encoding Initiative (TEI) est un effort international pour unifier les pratiques d’encodage de texte dans le domaine académique. Elle fournit un vocabulaire XML qui permet de produire des modèles de textes que l’on peut utiliser à différentes fins notamment pour l’édition de sources primaires. Plus qu’un schéma générique, elle offre en fait un cadre de travail qui permet de traiter différents cas de figure. Ce cadre de travail se compose d’un vocabulaire, d’une documentation qui en fournit la sémantique en langage naturel, et d’un ensemble de recommandations rassemblées sous l’intitulé de Guidelines. En ce sens, comme le relève Florence Clavaud dans son cours, il s’agit plutôt d’une sorte d’« ontologie générique du texte ».

La Text Encoding Initiative est née d’un constat partagé au sein d’une communauté de chercheurs déjà engagés dans la production de texte numérique qu’ils manquaient de solutions pour faciliter l’échange de textes et d’information sur leur travail. En novembre 1987, une rencontre fut organisée sous l’égide de l’Association for Computers and the Humanities (ACH) au Vassar College à Poughkeepsie avec une trentaine de représentants issus du monde des archives, des centres d’informatique appliquée aux sciences humaines, ou d’organisations professionnelles pour examiner à nouveau la question de la standardisation. S’accordant tous sur le besoin de pratiques communes, ces participants formulèrent une dizaine de principes directeurs[43]. Ceux-ci mettaient notamment l’accent sur la conversion de formats et la nécessité de développer un métalangage pour des schémas d’encodage descriptifs.

L’ACH, rapidement suivie dans son effort de standardisation par l’Association for Literary and Linguistic Computing et l’Association for Computational Linguistics formèrent ensemble la Text Encoding Initiative (TEI) afin de conduire le projet sous une forme internationale et multilingue et développer des recommandations pour la préparation et l’échange de textes électroniques dans le domaine universitaire. Dès 1993, la TEI publiait une première version de ses Guidelines for the Encoding and Interchange of Machine-Readable Texts. Ce rapport proposait un ensemble de conventions pour l’encodage de différents types de textes pour servir dans le domaine des sciences du langage ou des sciences humaines. Cette première publication constitue un jalon important car jamais auparavant les chercheurs n’avaient été capables de formuler un consensus sur les pratiques d’encodage.

Alors qu’elle avait d’abord été fondée sur l’utilisation de la syntaxe SGML (Standard Generalized Markup Language), la TEI a adopté XML dès la première publication de sa spécification en 1996, certains membres de la TEI avaient en effet participé à son développement. Par la suite, les Guidelines ont été étayées par l’apport d’autres spécialités pour prendre en charge une plus grande diversité de textes. On en est aujourd’hui à la cinquième proposition numérotée P5, et elle est organisée autour d’un consortium et d’une importante communauté d’utilisateurs. Conçue comme un modèle générique de structuration et de sémantisation des textes, la TEI présente de nombreux avantages. On relève notamment :

• sa modularité et sa flexibilité
• son expressivité (niveau de granularité)
• le fait qu’il s’agit d’un standard reconnu internationalement (interopérabilité, pérennité)
• le fait qu’elle dispose des propriétés intrinsèques au modèle XML : séparation entre le contenu et a présentation, possibilité de générer plusieurs formats de sortie à partir d’une même source
• son adaptation à l’édition électronique (croisement de sources, fac simili, hyperliens, etc.)
• les possibilités de modulation de l’affichage et d’accessibilité, ses aspects économiques

Mis à part le fait qu’elle soit rapidement apparue comme un standard de fait pour la publication de textes numériques en sciences humaines, ce sont d’abord ces qualités qui expliquent la large implantation de la TEI dans la communauté scientifique. Elle sert de format à de nombreux projets d’envergure internationale (Blake archive[44], Perseus[45], Rosetti[46], etc.). Plusieurs projets français de grande envergure utilisent également la TEI dans le domaine des sciences historiques (BVH[47], Élec[48], le portail Telma[49], ENS Lyon[50], etc.).

Rapidement la TEI a privilégié la publication de recommandations plutôt que celle d’un standard ou d’une norme. L’objectif était de spécifier des conventions d’encodage simples, faciles à employer, relativement compréhensibles, et qui fournissent d’amples mécanismes d’extension afin de pouvoir répondre à des besoins particuliers.[51] Cette modularité avec ses possibilités de personnalisation et d’extension seyait mieux à la recherche. Néanmoins, la TEI s’est rapidement imposée comme standard de fait pour l’encodage de textes numériques dans le domaine des sciences humaines. Plusieurs raisons expliquent en grande partie cette situation. D’une part, la TEI repose sur l’utilisation de syntaxes et de mécanismes XML standardisés par le W3C (World Wide Web Consortium) qui présentent de nombreuses garanties en termes d’interopérabilité et permettent d’utiliser les outils puissants disponibles pour manipuler des arbres XML. D’autre part, l’importante généricité de la TEI lui permet de couvrir une grande gamme de besoins. Cela explique en grande partie l’importante pénétration de la TEI dans la communauté scientifique.

La TEI fournit ainsi, à l’aide d’un vocabulaire et d’une infrastructure technique, un cadre de travail pour la modélisation des textes. Dans la limite de leur expressivité, de tels modèles peuvent être employés à telles ou telles fins. La volonté de la TEI de couvrir l’ensemble des besoins a pour pendant négatif la nécessité de personnaliser son schéma. Et l’utilisation de la TEI suppose l’apprentissage de son vocabulaire. Cette difficulté d’accès, ainsi que la nécessité de manier des outils nouveaux, reste un problème qui n’est toujours pas complètement réglé. Cependant, la TEI a largement été adoptée aujourd’hui dans le secteur académique pour la publication de sources primaires ou l’édition numérique. C’est la raison pour laquelle on peut affirmer qu’elle constitue de ce point de vue un standard de fait qui justifie en grande partie son utilisation dans un projet scientifique comme l’édition des cours de Desgodets.

À de nombreux égards, le large emploi de la TEI est censé répondre à un désir d’interopérabilité et de pérennisation. La promesse des standards est de nous rendre la vie plus aisée : TEI, XML, Unicode ont le potentiel de faciliter l’échange et la réutilisation des documents, c’est notamment la raison pour laquelle on y a recours. Cependant, par sa généricité même, la nature profonde de la TEI qui nécessite d’opérer des choix, ou permet d’être étendue en fonction des besoins, explique en grande partie les difficultés que l’on peut rencontrer lorsqu’il s’agit de rassembler des collections de documents en termes de compatibilité. Il ne suffit pas que les textes soient tous encodés en TEI pour qu’ils soient véritablement interopérables. Chaque document est représentatif du modèle que se fait l’éditeur du texte. Ainsi, la compatibilité ne peut être atteinte que si plusieurs documents suivent le même ensemble de conventions.

Il convient donc de garder à l’esprit que n’importe quelle représentation numérique d’un texte constitue une modélisation de fait, au sens où un modèle est une réduction de la réalité. « Même lorsqu’on se contente de transcrire une page imprimée à l’aide d’un simple éditeur de texte, on formule, sans en avoir nécessairement conscience, nombre de décisions éditoriales telles que le choix de l’encodage des caractères, la manière de représenter tel ou tel aspect typographique avec cet encodage, comment traiter les espaces blancs, ou encore ce qu’il faut faire des choses que l’on n’est pas en mesure d’entrer au clavier comme les figures dans le texte ou les symboles dépourvus de représentation Unicode.[52] » Dès lors, le choix des concepteurs de la TEI qui consistait à caler sa sémantique sur la structure de XML est particulièrement significatif. En effet, le modèle de contenu de XML est fondé sur l’arborescence, il détermine ainsi une grande partie de la sémantique de la TEI.

On considère généralement que SGML puis XML sont des syntaxes adéquates pour exprimer les besoins les plus généraux. Elles ont aussi plusieurs avantages en termes de production et de mise en forme, ou encore pour tourner le texte en base de données. Avec la TEI, le paragraphe d’un texte apparaît par exemple entre deux balises p. Plusieurs paragraphes peuvent être réunis dans une division div. À l’intérieur d’un paragraphe, on peut marquer un nom de personne ou de lieu à l’aide d’éléments persName ou placeName. « Une telle configuration est très commode pour le traitement (processing), puisqu’il est relativement trivial de transformer un élément TEI div ou p en l’élément HTML correspondant, ou encore persName en un hyperlien qui pointe vers les informations concernant la personne désignée. Cependant, cela signifie également que les capacités de modélisation de la TEI sont celles déterminées par XML.[53] »

Dès 2002, Buzetti a avancé que la structure arborescente n’était pas suffisamment expressive pour rendre compte de toute la complexité d’un texte[54], et en 2010 Schmidt a considéré que la TEI constituait un mauvais modèle du texte car elle imposait des interprétations éditoriales sur le texte lui-même[55]. La TEI peut parfois se révéler en partie inadéquate pour traiter par exemple la structure du discours ou la sémantique du texte. Son modèle impose souvent de traiter séparément l’encodage du texte et son inscription sur le support pour les sources primaires. Mais son utilisation a largement prouvé qu’elle constituait un choix, bien qu’imparfait, tout à fait acceptable et suffisant dans la plupart des cas pour le travail académique ou universitaire. Elle constitue d’autant plus une solution qu’elle permet l’utilisation de puissants outils XML.

C’est ici en réalité la question du texte et des différentes lectures que l’on peut en avoir qui est soulevée[56]. Est-ce que le texte peut exister indépendamment de son apparat critique ? Dans de nombreux cas, il n’y a pas de texte proprement dit mais seulement une multiplicité de lectures. Or, la lecture constitue de fait un exercice interprétatif, la TEI présente ici au moins l’avantage de son honnête dans le fait qu’elle met en avant, et au centre, les interventions éditoriales là où elles sont le plus manifestes. Il s’agit donc d’être conscient qu’en adoptant ce qui constitue aujourd’hui un standard de fait dans le domaine académique avec tous ses avantages, il convient en même temps de faire le deuil d’un modèle véritablement générique qui répondrait à toutes les situations. Chaque modélisation du texte mise en œuvre à l’échelle d’un projet traduit d’abord un point de vue sur les textes. C’est une certaine lecture du texte qui est proposée au lecteur par l’éditeur, et une telle lecture traduit avant tout les préoccupations et les questionnements à l’œuvre au moment de l’acte d’édition.

La TEI peut donc se concevoir comme un cadre de travail technique, un framework, qui accompagne l’éditeur ou l’encodeur dans la structuration de l’information. Elle consiste en un ensemble de préconisations qui doivent être adaptées aux spécificités inhérentes à chaque projet éditorial. Comme le relève Florence Clavaud, « cette modularité qui garantit la flexibilité du modèle et sa généralité, peut parfois dérouter l’encodeur inexpérimenté ou le confronter à des choix difficiles ». La définition des solutions d’encodage implique d’opérer des choix entre plusieurs solutions admissibles en en saisissant bien tous les tenants et les aboutissants. Elle implique un aller-retour continuel entre les sources textuelles à traiter et la documentation de la TEI afin de réévaluer les solutions d’encodage envisagées.

Ce besoin de personnalisation s’explique, d’une part parce que le texte est souvent un objet hétérogène, et d’autre part car l’encodeur ou l’éditeur peut avoir des objectifs différents. Dans le cas d’un texte dramatique, il pourra se révéler nécessaire de trouver un moyen pour marquer les locuteurs. Les éléments nécessaires pour traiter le discours oral ne seront sans doute pas les mêmes que ceux requis pour le traitement diplomatique. On n’abordera pas un ensemble de textes composites ou un corpus de la même manière que des textes isolés. Ces différents cas de figure expliquent assez bien le besoin de métadonnées spécialisées pour décrire les contenus.

Ce que propose la TEI c’est un ensemble de mécanismes pour les traiter. « Formellement parlant, les Guidelines fournissent à la fois des règles syntactiques sur la manière dont des éléments et des attributs doivent être utilisés dans des documents valides, mais aussi des recommandations sémantiques sur l’interprétation que l’on doit attacher à certaines constructions syntactiques. En ce sens, elle fournissent à la fois une définition de type de document, et une déclaration de type de document. Plus exactement, on peut distinguer le modèle abstrait de la TEI (TEI Abstract Model) qui définit un ensemble de concepts en rapport, et le schéma TEI (TEI schema) qui définit un ensemble de règles et de contraintes syntactiques.[57] »

Dès l’origine la TEI a été conçue pour être employée comme un ensemble de briques permettant de construire des schémas spécifiques pour un projet donné. Dans cet esprit, la TEI propose un vocabulaire pour décrire les textes sans préjuger de ce que les textes pourraient contenir. Aussi est-il important de comprendre que la TEI ne propose pas un schéma global, mais un ensemble de modules parmi lesquels choisir les éléments qui répondent à ses propres besoins en termes de modélisation.

Cette modélisation s’exprime à l’aide d’un schéma qui est une personnalisation de la TEI. Il s’agit en fait de produire un sous-ensemble de la TEI approprié à son projet. Comme la TEI utilise les technologies XML, il est possible de contrôler la production d’un document dans un éditeur XML ou encore de valider son contenu en l’associant à un schéma qui peut être rédigé dans divers formats (RelaxNG, W3C XML schema, etc.). Un schéma constitue donc à la fois une manière de représenter le modèle de contenu des documents traités et de contrôler leur structure ou leur contenu d’un point de vue technique.

La définition du schéma s’opère au moyen d’aller-retour continus avec les sources textuelles que l’on souhaite traiter. On effectue généralement d’abord une première modélisation à partir d’un échantillon jugé représentatif du corpus. Enfin, lors du passage à l’échelle, il est parfois nécessaire de corriger quelques choix s’avérant inappropriés ou bien encore de renforcer le contrôle par l’intermédiaire du schéma. Le processus d’élaboration du modèle est donc un processus incrémentiel, et le schéma n’est pas d’emblée figé dans le marbre.

L’architecture de la TEI permet de construire un schéma en combinant comme de besoin des déclarations d’éléments et d’attributs. Chaque élément est documenté par un élément de spécification adéquat et dispose d’un identifiant unique dans le système. Pour plus de facilité, ces spécifications sont groupées dans des modules distincts qui peuvent être combinés entre eux. Chaque module détermine un certain nombre d’éléments spécifiques qui peuvent également renseigner des classes particulières. Toutes les classes sont disponibles globalement, indépendamment des modules dans lesquelles elles sont déclarées. Lorsque c’est possible, les modèles de contenus sont définis en termes de classes (classes), les modules peuvent également déclarer certains motifs particuliers (patterns).

Dans l’infrastructure de la TEI, les éléments de la TEI sont organisés au sein de différents modules qui les regroupent par type d’utilisation. Il y a au total vingt-deux modules actuellement définis, dont on trouvera la liste dans le tableau ci-contre. Les trois modules core, header et textstructure, ainsi que tei lorsqu’on utilise Relax NG, doivent être utilisés dans les cas habituels. Certains éléments définis à l’intérieur de ces modules sont employés par d’autres modules ce qui crée des dépendances.

Il faut noter que chaque chapitre des Guidelines couvre l’un de ces modules.

Outre ces vingt-deux modules, les cinq cent quarante-trois éléments de la TEI et leurs attributs sont également organisés en classes de modèle (model class) et classes d’attribut (attribute class) afin de faciliter leur modification. Les éléments d’une même classe peuvent apparaître au même endroit dans un modèle de contenu, il s’agit alors d’une classe de modèle, ou partager un ensemble d’attributs, il s’agit alors d’une classe d’attributs. Dans les deux cas, on dit qu’un élément hérite des propriétés des classes auxquelles il appartient. Les classes (et donc les éléments qui sont membres de ces classes) peuvent également hériter des propriétés d’autres classes.

La liste de ces différentes classes se trouve en appendice des Guidelines aux adresses suivantes :

• liste les classes de modèles : http://www.tei-c.org/release/doc/tei-p5-doc/en/html/REF-CLASSES-MODEL.html
• liste les classes d’attribut : http://www.tei-c.org/release/doc/tei-p5-doc/en/html/REF-CLASSES-ATTS.html

L’intérêt de ces classes est qu’elles permettent de factoriser les déclarations de modèle de contenu. Les classes permettent de rassembler un certain nombre d’éléments afin de pouvoir y faire référence de manière groupée.

Il est enfin possible de déclarer sous forme de macros, les déclarations fréquentes pour réemployer à plusieurs endroits le même bloc de contenu par exemple pour définir le type de données des attributs ou des éléments TEI.

Il est possible de personnaliser la TEI en supprimant des modules un certain nombre d’éléments qui ne seraient pas nécessaires pour le traitement de ses documents ou en modifiant ces classes. Ce faisant, on peut restreindre la manière de traiter certains phénomènes, ou encore, limiter les attributs disponibles sur un élément, et définir pour ces attributs des listes de valeurs ouvertes ou fermées. Au besoin, on peut également modifier le nom des éléments par exemple pour l’internationalisation ou ajouter des éléments, ce qui n’a pas été retenu dans le cadre de notre projet.

Les Guidelines décrivent trois manières de personnaliser (customizing) la TEI :

• 1° Rédiger une spécification de haut niveau pour une représentation en TEI et générer un schéma ad hoc ;
• 2° Utiliser les modules de la TEI et spécifier dans ces sous-ensembles quelles fonctionnalités l’on souhaite activer ;
• 3° Utiliser les modules Relax NG, et rédiger un schéma d’enveloppe.

Il est recommandé de personnaliser la TEI au moyen d’une spécification formelle. L’utilisation de cette approche de haut niveau qui consiste à produire un fichier ODD présente plusieurs avantages : Elle est d’abord indépendante des types de schémas utilisés. Elle permet également de travailler avec les balises habituelles de la TEI. Ensuite, elle autorise l’utilisation des classes mis en place par la TEI. Enfin, l’utilitaire Roma génère un simple fichier portable que l’on peut utiliser pour partager son schéma.

L’ensemble de la TEI est rédigée dans un format source intitulé ODD (One Document Does it All) qui inclue les fragments de schéma, la documentation en prose et la documentation de référence des Guidelines dans un seul document. Une spécification ODD est un document XML-TEI qui utilise le module tagdocs. Lequel module fournit une série d’éléments employés pour spécifier un nouveau schéma, ou des modifications apportées à la structure des éléments TEI afin de générer automatiquement un schéma dans le format choisi et sa documentation correspondante au moyen d’un processeur destiné à cet effet.[58]

Un document ODD se présente comme un document XML-TEI courant comportant une en-tête TEI, un élément front, body et back, le schéma est défini au moyen d’un élément schemaSpec qui va contenir les déclarations. À partir d’un tel document, un processeur ODD sera en mesure de combiner les déclarations des modules désignés et de produire un schéma du type requis et éventuellement une documentation de tous les éléments choisis.

L’outil Roma est un service web mis à disposition par la TEI afin de faciliter la personnalisation des schémas[59]. Le service permet de produire une spécification ODD à l’aide d’une interface graphique permettant de choisir facilement parmi les composants de la TEI. Roma est également un programme qui utilise un ensemble de transformations XSLT produites par la TEI qui permettent de traiter des documents ODD pour produire en sortie différents types de documents : des schémas aux formats requis pour l’édition des documents dans un éditeur XML ou pour la validation de documents XML (Relax NG dans les syntaxes compactes ou étendues, W3C schema, Schematron, etc.), le logiciel est également en mesure de produire une documentation correspondante pour l’ensemble des éléments choisis dans la TEI à partir de la spécification. Enfin, à partir d’une spécification formelle au format ODD, il permet de relancer la personnalisation au moyen de l’interface graphique.

Même s’il est possible de créer les documents ODD manuellement, l’interface graphique sous forme de formulaires proposée par Roma facilite grandement les opérations pour la plupart des tâches courantes. Comme toute application informatique, Roma n’est potentiellement pas exempt d’erreurs ou de bugs. Néanmoins, nous n’avons pas rencontrés de difficultés particulières au cours de nos opérations malgré une réitération régulière de l’édition du schéma avec le logiciel.

Le projet éditorial consistant à publier une collection de matériaux manuscrits sous la forme d’un corpus, chaque source manuscrite devant faire l’objet d’une description appropriée, et pouvant comprendre des images, nous avons éprouvé le besoin d’ajouter plusieurs modules aux quatre modules habituels : tei, header, core, et textstructure. Le module msdescription a permis de prendre en charge une grande partie de la description des manuscrits. transcr est un module spécialisé dans la transcription des sources primaires manuscrites. Le module figures apportait quant à lui les éléments nécessaires pour localiser et documenter les planches dans l’édition. S’agissant d’une édition à caractère historique, nous avons jugé que le module namesdates nous serait utile.

Dans le fichier ODD, à l’intérieur de l’élément schemaSpec, une série d’éléments moduleRef servent à désigner les modules utilisés au moyen d’un attribut key :

L’architecture de la TEI permet une personnalisation plus détaillée au sein de chaque module. Il est possible de supprimer des éléments, de restreindre la liste des attributs, et même d’ajouter des éléments. La spécification que nous avons élaborée à l’aide de Roma a par exemple supprimé un certain nombre d’éléments jugés inutiles à l’intérieur de certains modules de la manière suivante :

Dans la plupart des cas, la suppression d’un élément est une modification propre de la TEI, toutefois certains éléments disposent d’enfants obligatoires. Par exemple, fileDesc doit contenir à la fois titleStmt et sourceDesc. La suppression d’un élément enfant obligatoire dans le modèle de contenu rompt le modèle abstrait de la TEI.

Il est également possible de désigner des éléments ou des classes individuellement avec les éléments elementSpec, classSpec, ou macroSpec. Le type de modification apporté est déterminé par la valeur d’un attribut mode (add, replace, delete, et change) :

On peut également modifier la liste des attributs possibles pour un élément. Celles-ci peuvent être données explicitement au moyen d’un élément attList dans la spécification de l’élément correspondant ou bien être héritées d’une classe d’attribut. Lorsque l’on ajoute un attribut, on doit d’abord vérifier si celui-ci n’est pas déjà défini dans une classe d’attribut. Si tel est le cas, il suffit de rendre l’élément concerné membre de cette classe. Sinon ont doit définir un attribut au moyen de attDef pour l’ajouter à la liste attList de l’élément concerné.

Il est souvent utile de contraindre les valeurs possibles d’un attribut au moyen d’un typage des données. Cela peut être réalisé facilement au moyen de l’élément valList qui est un élément enfant de attDef. De la même manière on peut étendre ou remplacer la liste existante d’attributs proposée par la TEI. Selon les modifications réalisées de cette manière, celles-ci sont plus ou moins propres.

Il peut aussi être intéressant de préciser l’information sémantique de certains éléments qui peut être trop générale par rapport à son utilisation dans le projet (desc dans elementSpec). Les exemples dans exemplum peuvent également être enrichis par ceux du projet. Nous n’avons pas eu le temps de réaliser ces personnalisations, mais il nous semble qu’elles pourraient se révéler utiles avant la publication du schéma.

Le mode modification peut également s’appliquer à des classes. Dans cet exemple, nous avons remplacé à l’aide de Roma un ensemble de valeurs d’attributs pour tout attribut membre de la classe att.internetMedia.

Les manuscrits que nous avions à traiter présentaient généralement une structure textuelle relativement commune qui pouvait facilement être prise en charge à l’aide des éléments structurels offerts par la TEI. Il a systématiquement été établi une division tripartite dans l’édition avec les éléments front pour les parties liminaires, body pour le corps de texte et back pour les paries postérieures. À l’intérieur de ces différentes parties, titlePage avec ses sous-composants permettait de prendre en charge les pages de titre, et une combinaison des éléments div, p, list et tous ses composants, ainsi que seg a paru adaptée et suffisante pour traiter presque tous les cas de figure. Un système de typage des divisions a toutefois été établi pour préciser cette macrostructure en utilisant l’attribut type. La liste fermée des types de division doit encore être restreinte par le schéma.

Les manuscrits des servitudes présentaient quant à eux un cas de figure moins courant. S’agissant pour l’un d’un recueil de coutumes, pour l’autre d’un commentaire sur la coutume de Paris, les deux textes citaient abondamment d’autres textes. L’emploi d’un élément floatingText nous est apparu pertinent pour traiter ces citations car il a l’avantage de permettre de conserver la structure originale de ces textes.

Les manuscrits pris en charge étant souvent des copies au propre, l’emploi des éléments fournis par le module spécialisé de la TEI consacré à la transcription des manuscrits transcr suffisait très largement à couvrir nos besoins. Il s’est trouvé utilement complété par le module certainty pour les difficultés de lectures ou la résolution des abréviations.

Si le traitement de la macrostructure du texte ou de son inscription sur le support ne présentaient pas de problèmes particuliers, la principale difficulté posée par les documents à traiter résidait dans les solutions à mettre en œuvre afin d’organiser les différents éléments du corpus.

L’édition concernait la production de quatre cours qui constituaient ensemble le corpus des cours d’Antoine Desgodets. Du point de vue de la TEI, dès lors que chacun des témoins manuscrits était traité dans un fichier séparé, il paraissait logique de réunir chaque cours au sein d’un corpus. Pour ce faire nous avons utilisé l’une des structures proposées par la TEI avec l’utilisation de l’élément teiCorpus.

Afin de permettre une édition séparée des fichiers de chacun des témoins manuscrits, ceux-ci ont été traités de manière séparée en utilisant le standard du W3C Xinclude[60]. En appliquant la même norme, on a traité séparément certaines section du fichier dans un répertoire séparé intitulé divs.

Dès lors que l’on employait cette structure pour chacun des cours, il a paru logique d’adopter la même pour l’ensemble du corpus des cours de Desgodets. Cette configuration a par la suite été étendue à toutes les parties éditoriales du site web pour plus de facilité dans le développement.

Afin d’identifier chacun des témoins dans l’édition et pour nommer les fichiers, nous avons déterminé une nomenclature. Chaque témoin reçoit un identifiant unique composé de l’initiale du cours et d’un numéro d’ordre dans le corpus. Cet identifiant sert à produire les noms de fichiers en notation camelBack et l’ensemble des identifiants dans l’édition. Les identifiants des parties du texte sont fondés sur la structure TEI du texte en utilisant leur position à l’intérieur des éléments front, body et back.

Les Guidelines proposent trois approches pour aligner des passages textuels lorsque l’on établit une édition critique :

la méthode de localisation référencée :
• où les entrées d’apparat critique sont liées aux blocs de texte identifiés qui contiennent les lemmes respectifs
la méthode d’attachement à double point
• où les entrées d’apparat critique sont liées à des ponts de départ et de fin identifiées dans un texte
la méthode de segmentation parallèle.
• où les entrées d’apparat critique son encodées au moyen d’une transcription du texte connu invariable et de tous les témoins.

La méthode par segmentation parallèle est le plus couramment utilisée lors de l’encodage de sources en XML-TEI pour comparer des témoins. Cette méthode correspond également à une méthode de travail pour l’établissement du texte. Pour notre projet, nous avons retenu la première approche, celle dite de localisation référencée afin de nous faciliter le travail car les manuscrits avaient déjà été transcrits séparément et que l’on n’éditait en réalité qu’un témoin du texte de manière critique pour chaque cours, en se contentant de signaler en note les variantes significatives des autres témoins. Il ne restait donc plus qu’à trouver une solution pour proposer au lecteur un alignement visuel des différents témoins de la tradition du texte.

Bien qu’elle eût été plus satisfaisante, la méthode de segmentation parallèle aurait représenté un travail plus considérable si nous avions voulu fournir toutes les variantes des témoins, surtout pour des textes où nous avions jusqu’à quinze témoins. Une telle méthode s’intégrait assez mal dans notre flux de production. D’une part, seules les variantes jugées significatives étaient rapportées au manuscrit maître édité, ce qui ne permettait pas de reconstituer les différents témoins intégralement. D’autre part, il n’était guère possible d’automatiser l’importation des variantes à partir d’un document de traitement de texte. Nous nous sommes donc contentés d’un récolement manuel des différents témoins pour permettre leur alignement.

L’alignement des témoins nécessitait la détermination d’identifiants uniques pour chacun des segments textuels à traiter. Comme nous l’avons-vu, ceux-ci sont numérotés de manière systématique en fonction de leur position dans la hiérarchie textuelle (éléments div, p, seg, list, item, etc.). Un fichier externe permet d’enregistrer le travail d’alignement des témoins en utilisant l’élément TEI linkGrp et une série d’élément link. Le même mécanisme est employé pour aligner les figures entre les différents témoins.

L’utilisation d’identifiants uniques rassemble plusieurs avantages, ceux-ci permettent d’identifier précisément, à l’exclusion de tout autre, une unité textuelle ou un passage dans l’un des manuscrits. Ils constituent donc une bonne pratique notamment pour la citabilité. Comme on utilise ici l’attribut global de XML xml:id qui doit nécessairement être unique dans un fichier XML, il y a un contrôle d’unicité (ce contrôle s’applique à l’ensemble du corpus car il est compris dans une arborescence de fichiers XML). Enfin, le fait d’utiliser des identifiants uniques, a surtout l’avantage de permettre de traiter les regroupements de paragraphes, les interversions, les ajouts, indépendamment du manuscrit édité (et donc par la suite éventuellement d’éditer toutes les variantes du texte ou le réemploi des sources XML-TEI dans d’autres projets).

Afin de rassembler au niveau de l’ensemble de l’édition toutes les entrées, les index, le glossaire et les références bibliographiques, sont traitées dans un fichier unique qui se trouve à la racine du corpus général.

Si les structures prévues dans la TEI pour les noms de personnes et des noms de lieux nous ont parues satisfaisantes, il n’en allait pas de même pour l’index matière. L’encodage effectué pour le moment n’est pas conforme à la TEI. S’il doit être conservé en l’état, il devra faire l’objet d’une extension de la TEI dans le cadre du projet.

Pour le traitement des entrées du glossaire, l’utilisation de la structure des entrées de dictionnaire, bien qu’un peu trop complexe, a parue relativement bien adaptée au projet.

Les références bibliographiques utilisent l’élément tei biblStruct qui a le mérite d’offrir une structure régulière. La structure proposée par les Guidelines convenait dans à peu près tous les cas de figures, même si on peut regretter un manque de clarté dans le renseignement des artefacts numériques. En revanche la TEI n’offre pas d’élément adapté pour décrire des documents d’archives. À cet effet, nous avons employé les éléments servant à la description des manuscrits.

Afin de faciliter l’édition des fichiers de notes critiques et historiques et l’édition de la liste des figures, ces éléments qui se trouvaient dans l’élément back des fichiers ont été traités dans des fichiers inclus. Transparent du point de vue XML, un tel dispositif permettait d’éditer parallèlement le corps de texte et les notes ou les listes de figure (par exemple dans plusieurs fenêtres d’un éditeur XML).

Un important travail a été mené sur la production des en-têtes TEI et la question des métadonnées. Pour arrêter les choix d’encodages, nous avons examiné un certain nombre de pratiques documentaires[61] et recherché des guides de bonnes pratiques pour la TEI[62] . Lors du travail pour la production des métadonnées à partir de l’en-tête TEI, nous nous sommes aperçus qu’un travail était en cours au sein du consortium cahier pour produire un moissonnage des en-têtes TEI en OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting)[63]. Vérifications faites, et après avoir échangé avec les personnes en charge du projet, il se trouve que nos choix d’encodage étaient relativement conformes aux prescriptions proposées.

La production des métadonnées concernant les images s’est révélée plus ardue. La TEI a d’abord été conçue pour traiter des textes littéraires. Aussi ne prétend-elle pas décrire d’autres objets pour lesquels des langages descriptifs plus spécialisés comme ceux conçus pour les archives, le vocabulaire technique, etc., existent déjà. En effet, il est possible de concevoir des documents composites en mixant des vocabulaires différents. Ceux-ci sont alors placés dans des espaces de nom différents. Avant de nous aventurer dans une telle solution, nous avons essayé d’exploiter au maximum les éléments TEI pour documenter les figures. Une telle description nous semble en réalité permettre la production des éléments Dublin Core habituellement requis pour une bonne documentation des images.

Plusieurs tests d’encodage ont été nécessaires afin de valider ou d’infirmer les choix initiaux. Outre la question des alignements, c’est notamment la définition de l’encodage des figures qui nous a posé le plus de difficultés. La TEI est d’abord conçue pour l’encodage des textes aussi, il peut s’avérer nécessaire de confier la prise en charge de certains éléments à d’autres modèles documentaires. Toutefois, il nous a paru intéressant de chercher à utiliser au maximum l’expressivité de la TEI pour fournir les métadonnées descriptives des planches.

Alors qu’aucun des membres des équipes éditoriales ne disposait de compétences en matière d’encodage XML-TEI, il a fallu développer des méthodes de travail qui permette de produire les textes encodés de manière efficace tout en associant au maximum ces éditeurs au travail. Dans l’absolu, et parce que l’encodage relève à proprement parler du caractère scientifique de l’intervention éditoriale, il aurait sans doute été préférable que tous les auteurs de l’édition soient formés à la TEI. Pour diverses raisons, notamment liées au fait que les éditeurs travaillaient de façon volontaire sur le projet en sus d’autres activités, il n’a pas été possible comme nous l’avions un moment envisagé de former un certain nombre d’éditeurs à l’encodage. Seul l’un d’entre eux a en partie été formé, mais son intervention sur l’encodage est restée relativement limitée.

Rapidement, nous nous sommes orientés vers une approche intermédiaire relativement classique consistant à pré-encoder en utilisant un modèle de document de traitement de texte en vue d’une importation automatisée en XML-TEI. Une telle solution présentait l’avantage de maintenir les auteurs de l’édition dans leur cadre de travail habituel afin de faciliter l’avancement de l’édition. Cependant l’expressivité d’un modèle de document de traitement de texte et de la TEI n’étant pas équivalente, une telle approche n’allait pas sans poser quelques difficultés ou inconvénients dont nous voudrions maintenant rendre compte en évaluant l’approche retenue.

Comme nous l’avons vu précédemment, les choix qui interviennent dans l’encodage d’un document ont un caractère scientifique affirmé. Ainsi, se pose souvent la question dans un projet d’édition électronique de savoir à qui doit revenir le soin d’encoder des documents[64]. Les chercheurs sont généralement peu enclins à s’occuper eux-même de l’encodage des documents qui est habituellement envisagé comme une opération technique. Cela tient en partie au caractère relativement rébarbatif de l’encodage et au défaut d’interface du type What You See Is What You Get (WYSIWIG) pour éditer un texte en TEI.

La complexité de la TEI, et les différentes manières de l’employer, ne rendent guère possible la définition d’une interface graphique générique, à moins de concevoir une interface entièrement personnalisable en fonction de chaque schéma. En effet, la production d’une telle interface implique une mise en correspondance de chaque élément TEI avec un dispositif visuel. Pour proposer un éditeur WYSIWIG, il faudrait en outre déterminer à l’avance le rendu final de ces éléments. On comprend donc que la définition de cet éditeur serait fortement orientée par le point de vue sur le texte exprimé par la modélisation[65].

De par leur utilisation généralisée, on oublie souvent que les logiciels de traitement de texte dits WYSIWIG présentent également un certain regard sur le texte. S’ils donnent l’impression d’éditer le document imprimé final, loin d’être des instruments neutres, ils présentent en réalité un modèle de consultation et d’édition du texte relativement contraignant. Lorsque l’on manie la TEI, il n’est pas difficile de percevoir combien celle-ci offre une plus grande expressivité. Un grand nombre de phénomènes textuels que l’on peut marquer simplement avec la TEI ne sont pas facilement enregistrables avec un traitement de texte. Si l’encodage n’est qu’un moyen, ce défaut d’expressivité ne va pas sans poser problème.

Il aurait été possible de proposer aux auteurs de l’édition de travailler avec le mode auteur de l’éditeur XML Oxygen. Une telle solution présentait l’avantage de concilier à la fois un environnement de type WYSIWIG et d’offrir toute l’expressivité de la TEI. Toutefois, elle impliquait un changement d’habitude de travail, l’apprentissage et l’installation d’un nouveau logiciel, et malgré tout un minimum de connaissances de la TEI de la part des éditeurs. Hormis avec deux des membres de l’équipe, il n’a pas été possible de mettre en place une telle solution. Nous sommes donc partis du cadre de travail même des auteurs de l’édition en utilisant un modèle de document de traitement de texte (en l’espèce, Microsoft Word parce qu’il était le logiciel le plus généralement utilisé au sein des équipes éditoriales) en vue d’une importation automatisée. La distance entre ce que permet ce modèle de document et les règles formulées, et l’expressivité réelle du modèle XML-TEI utilisé, a nécessité certains ajustements dont nous allons également ici rendre compte.

La méthodologie de production des textes retenue impliquait en réalité la préparation d’un langage de pseudo-balises qui puisse servir de base à l’automatisation de la conversion. Des règles de présentation assez précises ont donc été formalisées et soumises aux auteurs de l’édition sous la forme d’un Guide de pré-encodage qui est fourni en annexe.

Puisqu’il s’agissait d’établir une correspondance entre ce que l’on souhaitait traiter avec la TEI et ce pseudo-balisage, la préparation d’un tel guide supposait au préalable d’avoir une idée claire sur l’encodage attendu en sortie. La rédaction du Guide de pré-encodage s’est donc déroulée parallèlement à celle du Guide d’encodage afin de faciliter le travail de mise en correspondance. On s’est appuyé, lorsque c’était possible, sur l’utilisation des styles de document de traitement de texte, ceux-ci sont en effet assez facilement récupérables au moyen d’une transformation XSLT. Deux types de styles sont disponibles dans les logiciels de traitement de texte, les styles de paragraphes et les styles de caractères. Leur combinaison pouvait permettre de traiter en même temps plusieurs phénomènes comme par exemple la présence d’un titre et le marquage d’un terme technique.

L’expressivité des styles de traitement de texte s’avère cependant limitée lorsqu’il s’agit de fournir une version alternative du texte, une correspondance, ou une correction. Il n’est pas non plus possible de marquer plusieurs fois le même passage avec différents styles de caractères. Par ailleurs, nous n’avons pas réussi à récupérer proprement les entrées d’indexation marquées avec Microsoft Word. Pour traiter ces différents cas de figures, nous avons donc défini une syntaxe permettant d’insérer cette information dans le texte. Cette notation constitue en réalité une forme de balisage du texte. Du point de vue du traitement, elle était conçue de sorte qu’on puisse aisément automatiser la récupération à l’aide d’expressions régulières.

Une telle démarche nécessitait en premier lieu l’adhésion des auteurs de l’édition. Afin de s’assurer de l’acceptabilité des consignes formulées et de leur bonne utilisation, celles-ci ont donc au préalable été soumises aux équipes éditoriales en juin 2012. Un premier retour des auteurs de l’édition a permis d’expliciter certaines règles lorsque cela s’avérait nécessaire ou de les enrichir à l’aide d’exemples. Si les éditeurs ont accepté, de bonne grâce, ces consignes d’édition, nous ne sommes pas totalement persuadé que leur signification ait été bien comprise. Ainsi, certains auteurs n’ont réellement pris la mesure de l’utilité de leur travail qu’en visionnant la version web de l’édition.

Faute d’une bonne compréhension des enjeux, la qualité du pré-encodage a été relativement variable. Les inconsistances, ou la liberté prise avec les règles, n’ont pas toujours facilité l’importation des textes en TEI. Mais globalement, les consignes ont été mieux suivies que nous nous y attendions, et les auteurs de l’édition ont fait preuve d’une très bonne volonté. Ainsi, le respect des consignes a généralement permis la récupération du travail effectué, sauf quelques corrections manuelles qui se sont parfois révélées indispensables.

En déterminant les directives pour le pré-encodage, notre objectif restait relativement modeste puisqu’il s’agissait avant tout de pouvoir récupérer la structure des textes édités. Le reste des indications était destiné à faciliter les opérations de rechercher/remplacer et on ne prévoyait pas de chaîne de conversion totalement automatisée. Malgré quelques difficultés, les choix de pré-encodage se sont révélés suffisamment efficaces pour être traités automatiquement. L’importation des textes pré-encodés a été conduite au moyen de feuilles de transformation XSLT (eXtensible Stylesheet Language Transformations) en s’appuyant sur les feuilles de style TEI développées par Sebastian Rahtz[66]. Une série d’outils complémentaires a été développée en XSLT pour sérialiser les traitements et préparer les textes de l’édition.

La transformation d’un document de traitement de texte en un document XML-TEI a grandement été facilitée par l’adoption de la syntaxe XML pour les formats de documents de traitement de texte. Un document au format docx est en réalité un dossier compressé qui comporte plusieurs répertoires et fichiers dont un fichier content.xml qui contient le texte du document et des indications de mise en forme. Dès lors, il est relativement aisé de transformer ce fichier XML en un autre fichier XML dans une syntaxe différente en employant le langage de programmation XSLT (eXtensible Stylesheet Language Transformations) dont c’est la destination.

Les feuilles de styles TEI développées par Sebastian Rahtz (XSL stylesheets for TEI XML) sont un ensemble de transformation XSLT 2.0 destinées à la TEI. On peut à l’aide de ces feuilles de style réaliser la transformation d’un document TEI vers différents formats, HTML (HyperText Markup Language), LaTex, etc., ou encore transformer d’autres documents en des documents TEI. Les transformations sont personnalisables soit en leur passant des paramètres soit en faisant appel aux transformations en les incluant dans un autre fichier et en surchargeant les règles (utilisation d’un wrapper, c’est-à-dire d’une enveloppe). Nous avions d’abord envisagé d’utiliser ce mécanisme pour réaliser une transformation personnalisée des fichiers Microsoft Word.

Après plusieurs essais, nous avons renoncé à cette approche. En partie à cause de l’inconsistance du pré-encodage, il nous a rapidement semblé plus commode de travailler de manière incrémentielle sur les fichiers afin de pouvoir contrôler plus finement la transformation et apporter les corrections éventuellement nécessaires. Aussi, nous avons en pratique plutôt utilisé le service de conversion de fichier mis en place par le consortium TEI, OxGarage[67], afin de récupérer un premier fichier XML-TEI que l’on a ensuite raffiné en lui appliquant plusieurs transformations successives en fonction des cas de figure.

Ce n’est donc pas une chaîne de traitement complètement automatisée qui a été mise en place. Faute de temps, il n’a malheureusement pas été possible de reprendre les feuilles de styles que nous avions écrites pour les réunir en une seule transformation qui puisse venir surcharger les transformations de Sebastian Rahtz. La quantité de fichiers à traiter cinq au total, et leurs différences, n’était pas suffisantes pour justifier cet effort même si cela aurait été intellectuellement plus satisfaisant.

La récupération des segments textuels marqués avec l’utilisation de styles dans le logiciel de traitement de texte ne posait guère de problème puisqu’il suffisait de manipuler un élément XML déjà présent dans le document. En dehors de la structure du texte déjà prise en charge par les feuilles de style TEI, il nous restait à nous occuper des styles de caractères que nous avions définis dans le modèle de document Microsoft Word pour marquer les entrées d’index et les termes techniques.

Comme les notes sont gérées dans un fichier séparé, on utilise la transformation notes.xsl pour préparer le fichier de notes. Cette transformation emploie plusieurs modes pour réaliser plusieurs traitements successifs. Un premier traitement génère à la place d’éléments divGen plusieurs éléments div qui regroupent les différents types de notes en les numérotant. Puis une seconde passe, remplace les notes dans le texte par un élément ref pointant vers l’élément note nouvellement créé..

Les auteurs de l’édition légendaient ou décrivaient les figures à part dans un tableau dont le modèle leur avait été communiqué par avance. La récupération du contenu de ce tableau n’a posé aucune difficulté. Après transformation du document de traitement de texte en document XML, nous avons utilisé une simple feuille de style navigante pour récupérer les données selon la structure voulue.

Il aurait peut-être été possible d’utiliser le même processus pour récupérer les informations descriptives sur les manuscrits et composer l’en-tête du fichier TEI. Mais compte-tenu du caractère crucial des métadonnées présentées dans l’en-tête, on a préféré remplir manuellement les informations afin d’en unifier la présentation.

Afin de faciliter le travail d’importation, nous avions demandé aux auteurs de l’édition, outre le stylage des portions de texte à indexer, de fournir une entrée normalisée et, pour les index patronymique et toponymique, un identifiant pérenne dans le catalogue de la bibliothèque nationale de France. La récupération de ces informations nécessitait l’utilisation d’une expression régulière. Une expression régulière, ou regex (regular expression), ou encore expression rationnelle, désigne une chaîne de caractères que l’on appelle parfois un motif (pattern) et qui décrit un ensemble de chaînes de caractères selon une syntaxe donnée[68]. Celles-ci sont souvent utilisées en informatique dans la manipulation et le contrôle de textes compte-tenu de leur puissance. Elles sont par ailleurs particulièrement utiles pour traiter des données textuelles non structurées.

Comme XSLT est fait pour manipuler des documents XML et que les documents XML sont du texte, l’utilisation d’expressions régulières avec XSLT peut s’avérer particulièrement utile. Avec la version 2 du langage et XPath 2.0, les regex sont supportées par trois nouvelles fonctions : matches(), replace() et tokenize(). On peut également en tirer parti avec l’élément xsl:analyze-string et ses deux éléments optionnels xsl:matching-string et xsl:non-matching-string. En pratique les expressions régulières sont souvent employées dans les situations suivantes :

• pour le balisage lorsque l’on a besoin de convertir du texte en XML, elles permettent d’identifier des motifs dans le document source et de le remplacer par des balises, par exemple si l’on veut placer du texte entre guillemets dans un élément p en TEI
• lors de transformations XML quand les contenus sont balisés de la même manière mais contiennent des contenus différents.

La transformation ttmtChaines.xsl que nous avons mise en place utilise l’élément xsl:analyse-string pour parcourir le texte à l’intérieur des éléments issus du stylage de caractère réalisé avec le traitement de texte pour récupérer les différentes parties de la chaîne de caractère et les traiter. En créant les éléments term, persName, ou placeName, on crée un attribut target qui pointe vers un identifiant en notation camelBack. Cet identifiant est composé grâce à une fonction qui, elle même, analyse la chaîne de caractère qui lui est fournie en entrée.

On extrait ensuite les entités nommées du fichier avec getEntities.xsl pour préparer l’index. C’est manuellement que l’on décide si la cible créée doit être conservée ou remplacée. En effet, l’automatisation fondée sur l’extraction de la forme régularisée du terme ou de l’entité, ne permet pas de tenir compte des pluriels ou des cas complexes.

Comme nous l’avons expliqué plus haut, la numérotation des segments textuels était basée sur un système déterminé par leur position dans l’arborescence TEI. Cette numérotation a été produite automatiquement à l’aide d’une transformation XSLT basée sur la récursion. La transformation prend ainsi l’identifiant du témoin manuscrit comme paramètre puis compose un identifiant en navigant dans l’arbre du document XML. La transformation s’appuie sur des variables pour composer cet identifiant, elle utilise par ailleurs les fonctions de numérotation offertes par XSLT.

Les indications de foliotage ou de pagination avaient été prises en notes au cours de la transcription entre crochets. Cette feuille de style utilise l’élément XSLT 2.0 analyse-string afin de localiser ces marques de pagination dans le texte et leur appliquer un traitement différent selon qu’il s’agit d’une pagination ou d’une foliotation. Elle génère les éléments pb et fw correspondants avec leurs attributs. Comme XSLT est un langage fonctionnel dépourvu d’effet de bord, il n’est pas possible d’utiliser l’incrémentation d’une variable dans une boucle pour traiter la numérotation de ces identifiants. Il nous a donc fallu déterminer une règle fonctionnelle pour les produire. Cette règle utilise la fonction mathématique du modulo pour numéroter une page sur deux.

Sauf dans certains cas l’introduction de marques de paragraphes inutiles dans les titres, nous n’avons rencontré aucune difficulté particulière pour récupérer la structure du texte. L’utilisation d’un modèle de document de traitement de texte pour traiter la macrostructure d’un document ou un double appareil de note se révèle relativement bien adaptée. En revanche, les irrégularités dans le corpus n’ont pas permis de typer automatiquement ces divisions et cette opération a dû être réalisée manuellement. Elle aurait cependant pu être configurée spécifiquement pour chaque cours disposant de la même structure générale.

Les manuscrits du toisé présentaient des paragraphes numérotés. Nous n’avons pas eu le temps de produire une transformation basée sur des expressions régulières pour modifier la structure du texte en répondant à tous les cas de figure. La mise au point d’une telle transformation, même si elle est assez complexe, pourra s’avérer utile compte-tenu du nombre de divisions à créer et du nombre de témoins à traiter.

Lors de l’importation, plusieurs types de problèmes ont été rencontrés concernant l’application des consignes. Ceux-ci concernaient des oublis, un mauvais positionnement du style de caractère provoquant un problème dans la transformation. Afin de s’assurer de la qualité de la transformation réalisée, il a souvent été nécessaire de mettre en place un dispositif de contrôle-qualité s’appuyant sur l’emploi d’expressions XPath afin de compter le nombre d’éléments à traiter et de vérifier le résultat de la transformation. L’utilisation de ces expressions régulières et de ces expressions XPath donne une idée de l’ampleur du travail effectué : pour le seul manuscrit des ordres ce n’est pas moins de 9 098 éléments balisés qui ont été passés en revue pour les seuls éléments renvoyant au glossaire technique. Sur ces entrées, une centaine d’erreurs a du être corrigée, soit une proportion relativement minime. La normalisation des entrées a en revanche été plus chronophage.

La création automatique des éléments de pagination et de foliotage s’est révélée très efficace. Cependant elle posait des problèmes assez importants lorsque des marques de pagination avaient été oubliées ou lors d’erreurs dans la numérotation portée sur le manuscrit. Cette information étant cruciale pour la citabilité, il a fallu vérifier manuellement l’ensemble de la pagination et parfois revenir au manuscrit pour traiter les erreurs.

Bien que l’importation automatique des documents de traitement de texte ne se soit pas avérée dépourvue d’écueils ou de difficultés, l’utilisation de transformations XSLT s’est révélée être une solution particulièrement efficace compte-tenu de l’importance du balisage à effectuer. Sans cette automatisation, il n’aurait pas été possible de traiter manuellement l’ensemble des fichiers. Une telle automatisation nécessite cependant un contrôle qualité relativement serré, c’est pour cette raison que nous avons notamment renoncé à produire une chaîne de transformation continue. Il nous a en effet paru plus sûr de procéder par étapes en contrôlant à chaque fois le résultat de la transformation. Une telle approche permettait également de corriger, au cas par cas, les différents problèmes de respect des consignes. Toutefois, rapportées au nombre d’éléments marqués, et malgré plusieurs inconsistances entre les fichiers, on a été relativement surpris par la qualité du travail effectué. Cependant, l’expressivité du pseudo-balisage ne permettant pas de traiter complètement tous les besoins, il a été nécessaire de revenir à la main sur certains éléments. Si l’utilisation d’un modèle de document de traitement de texte pour préparer une édition critique XML-TEI ne constitue pas une approche idéale, c’est une méthode acceptable et efficace pour préparer l’édition moyennant un travail relativement important de post-traitement conduit par une personne qui dispose d’une bonne connaissance de la TEI.