Version classiqueVersion mobile

Qu’est-ce que la Text Encoding Initiative ?

 | 
Lou Burnard

Personnaliser la TEI

Texte intégral

1Comme nous l’avons vu, la TEI est conçue pour s’adapter à un large éventail de choix d’encodage. Elle peut être utilisée pour la simple transcription de lecture d’une source primaire, qu’il s’agisse d’un manuscrit d’auteur, d’une œuvre littéraire imprimée, d’une diffusion audio, ou d’un dictionnaire. Elle peut être utilisée pour des encodages enrichis dans lesquels beaucoup d’aspects de tels textes sont rendus explicites, pour que des logiciels de toutes sortes puissent les traiter, depuis les outils de visualisation et systèmes de publication électronique jusqu’aux packages spécialisés pour l’analyse statistique. Elle peut être utilisée pour fournir toutes sortes d’annotations et de métadonnées additionnelles. Pratiquement personne n’a besoin de tout ce qu’offre la TEI, et pourtant chacun de ses éléments a un usage ou un intérêt pour quelqu’un. Comment est-il possible de choisir uniquement les parties de la TEI dont on a besoin ? Une des premières motivations pour créer des documents TEI est la possibilité de les partager avec d’autres, et de les combiner avec d’autres documents TEI. Comment peut-on communiquer à d’autres ses choix particuliers d’encodage TEI pour rendre possible cette intégration ?

2La TEI propose une manière de répondre à ces questions, tout en satisfaisant l’important besoin de documentation détaillée spécifique aux projets, en fournissant un ensemble d’éléments qui peuvent être utilisés à la fois pour spécifier un schéma en termes de noms et de propriétés formelles des éléments et des attributs qu’il contient, et pour documenter la façon dont ces éléments et attributs sont utilisés dans un contexte donné.

3La notion de schéma est fondamentale en XML : elle fournit une sorte de grammaire pour le document, nommant les composants possibles et déterminant les contraintes qui déterminent l’organisation d’un document XML. Un schéma permet d’exprimer des contraintes telles que « les éléments <p> peuvent apparaître à l’intérieur des éléments <div> » ou « chaque élément <list> peut contenir au moins un élément <item> ». Les règles de ce type peuvent aisément être vérifiées par un processeur automatique (un validateur). Des contraintes telles que « Utilisez l’élément <p> pour contenir des paragraphes, et non des pages » ou « utilisez <placeName> pour les noms de lieux, <persName> pour les noms de personnes et <name> pour tout autre nom » sont beaucoup plus difficiles à vérifier automatiquement, puisqu’elles portent sur la sémantique du contenu plutôt que sur son organisation. De telles règles sont définies par des documents tels que les Guidelines de la TEI, ou par des documents qui s’y réfèrent. La compréhension de ces contraintes sémantiques est extrêmement importante pour les développeurs de logiciels destinés à exploiter pleinement le balisage des documents, tout comme pour ceux qui désirent créer de nouveaux documents encodés de la même façon. C’est particulièrement vrai si le schéma utilisé permet un large éventail d’éléments avec des sens similaires, comme c’est le cas pour un schéma TEI non modifié ou non personnalisé.

4Pour cette raison, une utilisation sérieuse de la TEI réclame une réflexion approfondie sur les éléments qui sont appropriés aux besoins d’un projet, et aussi peut-être sur ce que le projet doit spécifier avec plus de précision que ne le fait la TEI. Par exemple, la TEI n’impose pas de liste de valeurs autorisées pour l’attribut @type utilisé sur l’élément <div>, puisqu’il est probable que ces valeurs seront très variées selon les projets. Au sein d’un projet donné, cependant, il sera certainement utile de s’entendre sur un ensemble de valeurs, et il sera donc nécessaire à la fois de s’assurer que tous les documents n’utilisent que les valeurs de cet ensemble, et que la documentation sur ces valeurs, indiquant ce qu’elles sont et ce qu’elles signifient, est maintenue en même temps que le reste du schéma, et utilisable par les systèmes d’édition et de préparation de documents capables de traiter le XML (tel que le logiciel Oxygen, très utilisé) pour aider et guider l’éditeur de document.

5La TEI propose un ensemble spécial d’éléments qui peut être utilisé pour créer une telle spécification de schéma. Les éléments concernés (<schemaSpec>, <moduleRef>, <elementSpec>, <classSpec> et d’autres) combinent des déclarations XML formelles, destinées à être incluses dans une DTD ou un schéma, et une documentation détaillée avec des exemples, destinée à être incluse dans un manuel technique sur la stratégie d’encodage qui est spécifiée. Pour cette raison, un document utilisant ces éléments est connu informellement comme un « ODD », pour One Document Does it all, soit un document tout-en-un : il fournit l’information nécessaire aux traitements informatiques en même temps que la documentation de cette information destinée à être lue par un être humain, le tout intégré dans un seul document XML. Comme on pouvait s’y attendre, le système TEI lui-même est exprimé en utilisant précisément ce même ensemble d’éléments, mais ici nous nous concentrerons sur son usage pour la création d’une personnalisation de la TEI.

Construire une personnalisation de la TEI

6La personnalisation la plus simple de la TEI est la personnalisation nulle, qui dit simplement « autorisez tous les éléments définis par la TEI ». Le schéma qui en résulte, appelé tei_all, propose (à l’heure de la rédaction de cet ouvrage) quelque 450 éléments différents, et beaucoup, beaucoup de manières différentes de résoudre des problèmes d’encodage qui se recoupent souvent. La taille et la permissivité de ce schéma le rendent plus ou moins inutilisable en pratique – si ce n’est pour un usage très important lié à la conformité à la TEI, sur laquelle nous reviendrons plus loin.

7La personnalisation TEI la plus largement utilisée et la plus fréquemment référencée est la tei_lite, un sous-ensemble d’environ cinquante éléments qui prétend satisfaire les besoins de 90 % des utilisateurs de la TEI, comme le démontrent leurs pratiques de création de textes numériques. Elle a été produite à l’origine pour un atelier de formation à la TEI en 1997, mais au prix de quelques mises à jour elle a continué à être utile dans une grande variété de contextes, au point que certaines personnes la confondent avec le schéma TEI. La tei_lite est incluse (comme un exemple) dans la livraison standard de la TEI, comme source et dans ses formes dérivées.

8Un rapide examen du code source XML de l’ODD de la tei_lite montre qu’il semble être un document TEI typique, avec des éléments <div> contenant des <head>s, des éléments <p>s et <list>s qui contiennent de la prose discursive, ainsi que des éléments <ptr>s pour des renvois et quelques autres éléments spécialisés comme <egXML> pour les exemples en XML. Le schéma spécifié par ce document est représenté, vers la fin du document, par un élément <schemaSpec> qui contient des déclarations comme la suivante :

<schemaSpec ident="tei_lite" start="TEI teiCorpus">
	 <moduleRef key="analysis"include="interp interpGrp pc s w"/>
	 <moduleRef key="linking" include="anchor seg"/>
	 <moduleRef key="tagdocs" include="att code eg gi ident val"/>
	 <moduleRef key="tei"/>
	 <moduleRef key="textstructure" include="TEI argument back body byline closer dateline div docAuthor docDate docEdition docImprint docTitle epigraph front group imprimatur opener postscript salute signed text titlePage titlePart trailer"/>
</schemaSpec>

9L’élément <moduleRef> est utilisé pour faire référence à un module TEI. Un module est simplement un conteneur nommé pour un certain nombre de déclarations d’éléments et de classes TEI. La TEI définit à l’heure actuelle vingt-deux modules, dont chacun correspond à un chapitre dans les Guidelines de la TEI où son contenu est décrit en détails. Par défaut, la référence à un module implique que toutes les déclarations qu’il contient doivent être transférées au schéma qui est spécifié, mais les attributs @include (inclure) et @except (sauf) peuvent être utilisés pour modifier ce comportement par défaut. Donc, dans l’exemple ci-dessus, le schéma créé inclura toutes les déclarations du module appelé tei, mais seulement les déclarations des éléments <anchor> et <seg> du module appelé linking. L’attribut @except aurait aussi pu être utilisé pour sélectionner tout ce module à l’exception des éléments nommés dans sa valeur.

10Un module fournit à l’élément <schemaSpec> une déclaration pour chaque élément sélectionné, sous forme d’un élément <elementSpec>. Celui-ci a plusieurs composants, dont la plupart sont affichés dans la documentation de référence TEI. Il inclut, par exemple :

  • un ou plusieurs éléments <desc> pour fournir une courte description de la fonction de l’élément, éventuellement en plusieurs langues ;
  • un élément <classes> contenant un élément <memberOf> pour chaque classe dont l’élément est membre ;
  • un élément <attList>, contenant une liste structurée de tous les attributs définis localement pour l’élément, en même temps que des informations sur leur type de données et une éventuelle liste de valeurs prédéfinies, exprimées au moyen des éléments <attDef>, <valList> et <valItem> respectivement ;
  • un élément <content> fournissant une déclaration formelle du contenu légal de l’élément, et de manière optionnelle des éléments <constraint> utilisés pour exprimer toute contrainte additionnelle de l’utilisation ;
  • un ou plusieurs éléments <exemplum>, contenant chacun un exemple d’utilisation, tiré dans la mesure du possible de vrais documents, avec un commentaire.

11L’appendice C des Guidelines de la TEI propose une documentation bien mise en page pour chaque élément TEI défini sur la base de telles déclarations.

12En même temps qu’il sélectionne et exclut des déclarations, un <schemaSpec> peut modifier certaines parties d’une déclaration. Un peu plus loin dans l’ODD de la tei_lite, nous trouvons ce qui suit :

<elementSpec ident="TEI" mode="change">
	 <attList>
		 <attDef ident="version" mode="delete"/>
	 </attList>
</elementSpec>

13dont l’effet est de fournir une seconde déclaration pour l’élément <TEI>, en même temps que celle sélectionnée dans le module textstructure. Un processeur ODD doit réconcilier ou unifier de tels doublons, sous le contrôle de l’attribut @mode. Dans ce cas particulier, l’effet est de changer l’<attList> déclaré pour l’élément <TEI> en supprimant l’attribut @ident de cette liste.

14La même procédure est utilisée dans le reste de la personnalisation TEI Lite pour supprimer d’autres attributs non désirés. Par exemple, les attributs @notBefore, @notAfter et d’autres sont proposés par la classe d’attributs att.datable.w3c. La façon la plus simple de les supprimer est donc de fournir une nouvelle déclaration pour la classe, comme ceci :

<classSpec type="atts" ident="att.datable.w3c" module="tei" mode="change">
	 <attList>
		 <attDef ident="notBefore" mode="delete"/>
		 <attDef ident="notAfter" mode="delete"/>
		 <attDef ident="from" mode="delete"/>
		 <attDef ident="to" mode="delete"/>
	 </attList>
</classSpec>

15Une spécification ODD peut inclure ou exclure des éléments et des attributs. Elle peut aussi modifier une déclaration existante en lui ajoutant des contraintes additionnelles. En guise d’exemple, on peut considérer la personnalisation de la TEI appelée Epidoc, qui est largement utilisée par les épigraphistes et autres personnes travaillant sur des inscriptions anciennes. Comme nous l’avons noté plus haut, l’attribut @type sur l’élément <div> n’est contraint en aucune façon par la TEI. La communauté Epidoc a cependant décidé qu’elle souhaitait imposer la présence de cet attribut et autoriser seulement six valeurs prédéfinies. Voici un fragment de l’ODD d’Epidoc qui permet d’obtenir cet effet :

<elementSpec ident="div" mode="change" module="textstructure">
	 <attList>
		 <attDef ident="type" mode="replace" usage="req">
			 <valList type="closed">
				 <valItem ident="apparatus">
					 <desc>pour contenir l’apparat critique ou les notes textuelles</desc>
				 </valItem>
				 <valItem ident="bibliography">
					 <desc>pour contenir l’information bibliographique, les publications antérieures, etc.</desc>
				 </valItem>
				 <valItem ident="commentary">
					 <desc>pour contenir tout commentaire éditorial, toute discussion historique/prosopographique, etc.</desc>
				 </valItem>
				 <valItem ident="edition">
					 <desc>pour contenir le texte de l’édition elle-même ; peut inclure des parties de textes multiples</desc>
				 </valItem>
				 <valItem ident="textpart">
					 <desc>utilisé pour diviser une div[type=edition] en parties multiples (fragments, colonnes, faces, etc.)</desc>
				 </valItem>
				 <valItem ident="translation">
					 <desc>pour contenir une traduction du texte dans une ou plusieurs langue(s) moderne(s)</desc>
				 </valItem>
			 </valList>
		 </attDef>
	 </attList>
</elementSpec>

16Notons que d’autres contraintes pourraient être ajoutées pour vérifier que ces valeurs sont correctement utilisées : par exemple pour vérifier qu’une <div type="textpart"> a toujours comme parent une <div type="edition">.

17Le projet Epidoc montre comment une communauté de recherche particulière peut adapter la TEI à ses propres besoins, et sa personnalisation est une bonne démonstration de ce que rend possible le langage ODD.

Ajouter un nouvel élément

18Le système ODD permet aussi l’ajout à un schéma d’éléments entièrement nouveaux. Dans sa forme la plus simple, cela ne nécessite rien d’autre que l’ajout à la spécification du schéma d’un <elementSpec> pour le nouvel élément, mais pour prendre la bonne décision quant au contenu qui convient à ce nouvel élément il faut une certaine connaissance de la façon dont le système TEI est conçu. Il est par exemple difficile de choisir les classes dont un nouvel élément doit être membre sans savoir quelles sont les classes qui existent et quelles sont leurs interactions. De la même façon, choisir un modèle de contenu approprié pour un nouvel élément requiert une réflexion sur la manière dont sont définis les autres éléments, à supposer que nous souhaitions que notre nouvel élément agisse de manière cohérente avec le reste de la TEI. Et pour finir, parce que c’est un élément non TEI, nous devons prendre soin de le définir dans un espace de noms non TEI.

19Supposons par exemple que nous souhaitons ajouter un nouvel élément <speciesName> pour baliser les noms d’espèces botaniques ou autres qui apparaissent dans un texte. Notre nouvel élément est, sur le plan sémantique, similaire aux éléments existants <persName> ou <name>. On peut donc commencer par examiner la spécification de l’ODD pour ces autres éléments similaires. Par exemple, dans l’<elementSpec> de l’élément <persName>, nous voyons que c’est un membre d’une classe modèle model.nameLike.agent, qui est une sous-classe de la classe plus générale model.nameLike. En ajoutant notre nouvel élément à cette classe, nous nous assurons qu’il apparaîtra dans les modèles de contenu des autres éléments TEI aux mêmes endroits que les autres éléments dédiés aux noms, sans nécessiter d’autre intervention de notre part. Nous remarquons aussi que <persName> est membre de plusieurs classes d’attributs, notamment att.global (qui a elle-même plusieurs sous-classes) et att.canonical, qui semblent toutes deux utiles pour ce que nous souhaitons faire. En ajoutant notre nouvel élément à ces classes, nous nous assurons qu’il utilise ces attributs de la même façon que les autres éléments dédiés aux noms.

20Ensuite, penchons-nous sur le modèle de contenu de notre élément. Le plus simple serait de faire la même chose que pour les autres éléments dédiés aux noms, et de dire qu’il peut contenir du texte simple, mélangé éventuellement à d’autres éléments autorisés au niveau du syntagme, comme <g>, et aux éléments globaux. C’est un besoin si fréquent dans les schémas TEI qu’un raccourci (une « macro ») appelé macro.phraseSeq a été défini pour l’exprimer. Cependant, si nous souhaitons représenter le contenu interne de notre élément <speciesName> (par exemple pour distinguer le composant « nom de genre » du composant « nom de l’espèce »), nous pouvons définir un modèle de contenu plus spécifique, impliquant potentiellement d’autres éléments nouveaux ou d’autres contraintes. Quels que soient nos choix ils doivent être explicitement documentés dans notre ODD, pour que d’autres utilisateurs de nos données puissent voir comment nous avons personnalisé le cadre de base de la TEI.

Personnalisation et conformité

21Pour continuer à être utile, la TEI doit refléter la diversité des pratiques au sein de la communauté de ses utilisateurs. On dit parfois que, si l’on pose la même question à deux chercheurs, on obtiendra au moins trois réponses différentes, et il n’est donc guère surprenant de constater une considérable diversité dans les recommandations de la TEI.

22Néanmoins, l’un des objectifs des Guidelines de la TEI est de guider les pratiques d’encodage. Ce n’est pas un standard qui vous dicte ce que vous devez faire (dans le sens où le font les standards en ingénierie, par exemple, en spécifiant exactement la forme et les dimensions d’équipements électriques). Au lieu de cela, il vous dit comment communiquer à d’autres ce que vous avez fait. C’est pourquoi, dans la section des Guidelines définissant la conformité à la TEI, l’une des caractéristiques essentielles qui est spécifiée est l’existence d’un ODD, définissant un schéma qui peut être utilisé pour valider les documents en question, en même temps que d’autres contraintes éventuelles. D’autres critères essentiels pour la conformité à la TEI incluent la validité formelle quant au schéma tei_all, et le respect de la sémantique définie des éléments TEI qui sont utilisés : un document en conformité avec la TEI peut contenir de nombreux éléments venant d’espaces de noms variés, mais chaque élément de l’espace de noms TEI doit avoir la sémantique définie pour lui par la TEI.

23Considérons par exemple le grand romancier anglais du xixe siècle Bulwer-Lytton. Dans un corpus de documents TEI, nous pouvons espérer trouver son nom entier balisé, et associé à une définition de la personne elle-même, comme ceci :

<persName ref="http://en.wikipedia.org/​wiki/​Edward_Bulwer-Lytton,_1st_Baron_Lytton">
	 <forename>Edward</forename>
	 <forename>George</forename>
	 <surname type="linked">Bulwer-Lytton</surname>, 
	 <roleName>Baron Lytton of<placeName>Knebworth</placeName></roleName>
</persName>

24Mais dans d’autres nous trouverons des versions avec un balisage moins informatif, ou utilisant différents éléments TEI, comme :

<p>
	 <rs type="name">Baron Lytton of Knebworth</rs>
</p>

25ou :

<p>
	 <name type="person" key="BWLY">The Right Honourable the Lord Lytton PC</name>
</p>

26ou :

<p>
	 <persName ref="#BWLY">First Baron Lytton of Knebworth</persName>
</p>

27De telles variations sont prévisibles : les priorités des projets varient considérablement. Pour certains, il est suffisant de montrer simplement qu’une chaîne de mots est un nom ; pour d’autres, il est important de distinguer les noms de personnes des noms de lieux ; pour d’autres encore il est essentiel de lever toute ambiguïté entre les références à des entités nommées, comme on les appelle. Le résultat de tels projets ne peut clairement pas être combiné d’une manière directement interopérable sans quelques efforts supplémentaires. Peuvent-ils tous être considérés en conformité avec la TEI ?

28Une personnalisation explicite, utilisant les fonctionnalités d’ODD que nous avons esquissées dans cette section, est la façon la plus simple pour un projet de communiquer ses propres décisions quant à la façon dont la TEI doit être appliquée, et c’est donc la façon la plus simple de s’assurer que ses documents peuvent être échangés avec d’autres. Un projet peut simplement supprimer (par exemple) l’élément <rs> de son schéma, ou spécifier une liste fermée de valeurs autorisées pour son attribut @type. Il peut choisir d’utiliser l’un ou l’autre (ou les deux) attributs @key et @ref pour associer différentes versions du nom d’une personne avec les données concernant cette personne, et donc lever tout ambiguïté les concernant. De tels choix peuvent être rendus explicites dans un schéma personnalisé, et donc nous dire quelle approche a été adoptée dans un ensemble donné de documents pour le balisage du nom d’un individu, parmi les nombreuses possibilités. Et puisqu’il est aussi possible de générer un ODD automatiquement à partir d’un ensemble de documents XML TEI, nous pouvons aussi distinguer une personnalisation à dessein – exprimant les pratiques d’encodage souhaitées par les créateurs des documents – d’une personnalisation de fait, exprimant les pratiques d’encodage utilisées.

29Si le modèle de la TEI est conçu pour être personnalisé, comment peut-il aussi prétendre être un format d’échange ? Pour l’« interopérabilité », le destinataire d’un document doit être sûr que celui-ci contient seulement des éléments TEI, et que ces éléments ont été utilisés selon les règles définies par la TEI. Sans être modifiées, ces règles permettent tant de variations qu’il est pratiquement impossible pour un développeur d’anticiper toutes les possibilités qu’un logiciel peut avoir à gérer. La disponibilité d’un ODD simplifie considérablement cette tâche, à la fois en limitant les éléments disponibles, et éventuellement en ajoutant de nouvelles contraintes sur le contenu.

CC-BY-NC-ND-4.0

Le texte seul est utilisable sous licence CC BY-NC-ND 4.0. Les autres éléments (illustrations, fichiers annexes importés) sont « Tous droits réservés », sauf mention contraire.

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search