EAD-TEI et TEI-EAD : quelques réflexions sur la conversion des notices de manuscrits médiévaux d’un format à l’autre

Le cycle des métadonnées est un système complexe, sur lequel j’ai écrit il y a déjà fort longtemps lorsque je travaillais au département des Métadonnées de la Bibliothèque nationale de France, lorsqu’il s’appelait département de « l’information bibliographique et numérique (IBN) »[1]. Après avoir changé de métier, la problématique a pris un tour différent et, délaissant les conversions d’EAD, d’Intermarc, d’Unimarc, de Dublin Core, de formats européens (TEL+ et Europeana), les uns vers les autres, j’ai travaillé davantage avec TEI et, quelques années plus tard, la question EAD-TEI et retour est revenue. En effet, dans le projet « Saint-Bertin, centre culturel du VIIe au XVIIIe s. »[2], j’ai eu besoin de créer une structure TEI à partir de l’EAD issu de la retroconversion du Catalogue général des manuscrits (celui de J. Michelant) [3], puis j’ai commencé à préparer l’export de retour pour rendre au CCFr le fruit des travaux.

Ce faisant, avec Laura Lebarbey, Ekaterina Novokhatko et Jean-Baptiste Camps, nous avons établi des feuilles de transformation correspondant à notre format TEI et à notre format EAD, que nous avons publiées dans la partie « sources et ressources » du site Saint-Bertin (https://saint-bertin.irht.cnrs.fr/site/php/sources_ressources.php).

Philosophie des formats

Ces transformations ne peuvent cependant pas être regardées comme réglant les problèmes que peuvent poser les conversions souhaitables d’une famille de format à l’autre, sachant que différentes institutions ou applications vont permettre des réalisations très différentes de notices en EAD ou en TEI.

Le premier obstacle est que les deux formats ont une philosophie différente. L’un est fait pour « enrichir » du « texte » (Text Encoding Initiative) et l’autre pour « décrire » des « archives » (je triche un peu, ici, puisque le mot « encoded » se trouve aussi dans Encoded Archival Description). Bref, revenons à la question qui précède l’origine de ce billet : pourquoi transformer EAD en TEI ? Évidemment, en France, parce qu’EAD s’est imposé pour décrire des objets pour lesquels le format n’a pas été pensé (les manuscrits médiévaux) en raison de la structure unifiée du CGM qui décrit des fonds avec des archives et de sa conversion à une époque où le module msDesc n’était pas publié. Mais, aujourd’hui, TEI/msDesc s’impose aussi pour une chose qui n’est pas sa mission principale, à savoir faire des catalogues de manuscrits (médiévaux).

Structure

La conséquence immédiate est que le module <msDesc> avec lequel on veut faire correspondre l’ensemble d’EAD n’est qu’une petite partie de la TEI et peut s’intégrer à différents niveaux.

Dans le projet HIMANIS  (https://www.himanis.org/), où nous devions travailler simultanément avec des éditions électroniques, des index, des inventaires sans édition, nous avons pris la décision de stabiliser l’emplacement de <msDesc> à l’intérieur de l’arborescence[4].

Les chemins qui mènent à msDesc sont les suivants :

(teiCorpus) > TEI > teiHeader > sourceDesc > listWit > witness > msDesc 
(teiCorpus) > TEI > text > group > text > front > div[@type=’tradition’] > listWit > witness > msDesc

Cette décision a été étendue au projet Saint-Bertin, même si, dans celui-ci, il n’était pas question d’éditer les textes contenus dans chaque manuscrit. Malgré cela, nous sommes passés d’une structure

TEI > text > body > listBibl > msDesc 

à une structure

teiCorpus > TEI > teiHeader > sourceDesc > listWit > witness > msDesc. 

Ainsi, nous avons rendu à <msDesc> sa place dans <sourceDesc> et nous ne donnons pas directement le texte en teiCorpus > TEI > text > p (généralement vide), comme les collègues d’Oxford (cf. https://github.com/bodleian/medieval-mss/tree/master/collections), qui indiquent systématiquement

<p><!--Body paragraph provided for validation and future transcription--></p>. 

En l’occurrence, avec nos travaux en « lecture par ordinateur », il se pourrait que l’élément <p/> se remplisse très rapidement ! Pour autant, en décrivant un objet unique par définition, nous savons que les niveaux listWit > witness sont techniquement superfétatoires ; ils sont ici un rapprochement des formats entre nos différents projets.

Pour ce qui est de <teiCorpus>, on constate qu’Oxford a préféré diviser chacune de ses notices en un fichier XML de racine <TEI> plutôt que de réunir les catalogues dans des <teiCorpus>. C’est accessoire du point de vue de la modélisation, mais, évidemment, pour une conversion, ce n’est pas négligeable.

Par ailleurs, on pourra faire remarquer ici qu’une logique maximaliste aurait fait transformer aussi les TEI > text > group > text en teiCorpus > TEI (etc.). La chose serait louable, mais n’est plus à l’ordre du jour pour l’instant.

D’éventuelles conversions « génériques » devront prendre des décisions sur les bonnes pratiques ou rendre aisément paramétrables l’indication du type de fichier source et les résultats souhaités.

Comment préparer une conversion ? Sur le papier !

Ensuite viennent les questions qui sont en général celles sur lesquelles se concentrent les spécifications de conversion : à quel élément faire correspondre quel élément ?

Dans l’idéal, on commence par le haut, c’est-à-dire par la partie théorique. On prend les spécifications de l’EAD (https://www.loc.gov/ead/) et de la TEI (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html) et on prend tous les éléments l’un après l’autre, avec leurs attributs, et on définit une cible.

Cette cible doit être définie de façon contextuelle. Ainsi, par exemple, les éléments <persname> (EAD) et <persName> (TEI) sont parfois équivalents, et parfois devront être dissociés, avec <author> (TEI) et faire l’objet de traitements particuliers pour ajouter les codes de fonction (@role).

Ensuite, il faut gérer les granularités descriptives différentes. Ainsi, pour une donnée aussi fondamentale que les dimensions d’un manuscrit, on devra jongler entre une formulation à plat, en EAD, dans le meilleur des cas dans l’élément <dimensions> et une formulation structurée en TEI

<dimensions>520 x 340 mm (just. 400/420 x 260
mm)</dimensions>
<dimensions scope="all" type="leaf" unit="mm">
          <height quantity="520 ">520</height>
          <width quantity="340">340</width>
</dimensions>
<dimensions scope="all" type="justification" unit="mm">
          <height quantity="400/420">400/420 (sauf f. 96, 260 mm)</height>
          <width quantity="260"/>
</dimensions>

Dans le premier cas, l’information est largement portée par les chaînes de caractères, telles que « (just.) » ou « x » et il faut se mettre d’accord sur l’ordre des informations. De nombreux catalogues, sous l’inspiration diplomatique, donnent la largeur de la justification avant la hauteur, car il s’agit de suivre l’ordre de lecture (on a d’abord une ligne d’une certaine largeur, puis une hauteur en nombre de lignes). De même, à l’intéri

Dans cet exemple, on voit qu’on peut dupliquer l’information en contenu d’attribut et en contenu d’élément, ou choisir de ne pas le faire, ou choisir de ne le faire que si la chaîne de caractères nécessaire pour une description précise est invalide comme contenu d’attribut. L’exemple donné ici pourrait être traité différemment avec répétition de l’élément et un attribut @scope différent, mais cette solution est sans doute celle qui sera le plus souvent utilisée.

Il est évident, dans ce cas, que passer d’un format riche comme TEI à un format pauvre comme EAD est plus facile. En revanche, il faut tenir compte de la gestion des chaînes de caractère pour essayer de structurer une notice TEI à partir d’un document EAD.

C’est là que la multiplicité et la diversité à l’intérieur de chaque format peut se révéler très problématique. Rien qu’en EAD, on connaît : – le format hérité du CGM, dont la documentation n’est pas en ligne à ma connaissance, mais qui est bien attesté par les nombreux catalogues, intégrés dans le CCFr ;

Si on regarde, pour l’élément <dimensions> qui semble la chose la plus objective du monde des manuscrits, on se retrouve avec :

CCFr
BnF
Exemples du manuel de l’ABES
Exemples du vocabulaire de la BVMSM, avec dimensions et justifications, dans les parties de métadonnées et des contenus éditorialisés

On voit, dans tout cela, des petits détails qui feront dérailler les conversions : espace ou pas espace avec un slash ? nombre entier ou simplifié ? plus petit avant plus grand ? indication du feuillet de prise de mesure ? précision de la dimension mesurée ? indication de l’unité de mesure ?

Pour chacune de ces minuscules différences, il faut pouvoir :

  1. (encore une fois) paramétrer facilement le format de base auquel se rattache ou est censée se rattacher la notice
  2. tester systématiquement le contenu des éléments pour voir quel est le pipeline de traitement le plus adéquat. Ainsi, on peut inclure un test : « si la chaîne en EAD contient « (just. ***** x **** mm) », alors créer un élément pour décrire la justification en TEI.
  3. créer une incitation à homogénéiser les notices

Analyser les formats dans leur application : contexte et homogénéité

Une chose qui est très utile, au-delà des spécifications, c’est d’analyser les formats effectivement mis en œuvre. Il est facile, par exemple avec Oxygen, de générer la documentation d’un ensemble de fichiers (Outils > Générer/Convertir le schéma), mais le contexte est souvent noyé dans les récursivités. C’est pourquoi je me sers, à titre personnel, de deux fichiers pour extraire l’ensemble des chemins. Cela me permet de voir l’homogénéité des documents (quand un chemin n’est utilisé qu’une seule fois, il devient suspect, même si le document est valide) et pour m’assurer que je traite bien tous les éléments que j’utilise de façon adaptée au contexte (c’est valable pour une CSS, une transformation de publication ou, ici, de conversion).

Quelques conclusions

En conclusion de ces remarques, voici quelques formulations, peut-être trop rapides.

Dans un monde idéal, on pourrait

  • toujours conserver et modifier l’information dans le format le plus précis, plutôt que de prendre le risque de gérer de l’information par des chaînes de caractères ou de la ponctuation ;
  • éviter aux catalogueurs de voir les données XML en leur donnant des applications où toute information serait nécessairement liée à des données d’autorité ou à des structures prévues. J’ai eu le bonheur de discuter avec Dan Gullo, de la Hill Museum and Manuscript Library il y a quelques semaines à New Haven, et c’est la solution choisie par vHMML et mise en œuvre de façon absolument drastique, depuis le nombre de feuillets jusqu’au nom des auteurs. Une telle contrainte demande un investissement initial important, mais il assure des données propres et systématiques.
  • préparer les conversions sur le papier par l’analyse (a) des formats dans leurs spécifications et (b) des formats dans leurs réalisations, et coder seulement plus tard ;
  • identifier les différentes chaînes de traitement et les paramétrages nécessaires (par exemple, un inventaire EAD > N fichiers TEI ou 1 fichier teiCorpus avec N éléments TEI) ;
  • implémenter des tests sur les chaines de caractères pour vérifier que la conversion ne va pas donner des informations erronées et incompréhensibles ;
  • prévoir un retour vers les fournisseurs de données pour les aider à les homogénéiser (ne serait-ce qu’avec une liste d’alertes sur la présence de données inattendues)

Fichiers utiles

[Lien] Fichier Word contenant le texte des feuilles XSLT du projet Saint-Bertin pour convertir EAD vers TEI et TEI vers EAD, ainsi que les transformations utilisées pour extraire l’ensemble des chemins vers les éléments contenant du texte ou vides, afin de réaliser l’analyse contextuelle.


[1] Dominique Stutzmann, Pauline Moirez. Signaler les ressources numérisées : enrichissement, visibilité, dissémination. Isabelle Westeel; Thierry Claerr. Manuel de constitution de bibliothèques numériques, Electre-Cercle de la Librairie, p. 115-171, 2013, Bibliothèques. 〈hal-01854676〉

[2] https://saint-bertin.irht.cnrs.fr

[3] https://ccfr.bnf.fr/portailccfr/jsp/index_view_direct_anonymous.jsp?record=eadcgm:EADI:FRCGMBPF-627656201-01a.xml

[4] Stutzmann, Dominique, Jean-François Moufflet, et Sébastien Hamel. « La recherche en plein texte dans les sources manuscrites médiévales : enjeux et perspectives du projet HIMANIS pour l’édition électronique = Full Text Search in Medieval Manuscripts : Issues and Perspectives of the HIMANIS Project for Electronic Publishing ». Médiévales : Langue, textes, histoire 73 (2017).


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.