TEI

Du Web sémantique au web de données, 2ème partie : retour sur un des articles de Roger T. Pédauque

got — Tue, 04 Mar 2008 02:13:18 +0100

Dans un billet récent écrit à l'occasion des dix ans de XML, Jean-Michel Salaün regrettait que les pistes esquissés dans le second texte de l'initiative Roger T. Pédauque intitulé « Le texte en jeu. Permanences et transformations du document » n'aient pas été suivies. Et, pour cause me semble-t-il, si ce deuxième article, comme les deux autres d'ailleurs, apporte incontestablement des pistes de réflexion et certaines idées intéressantes, il comprend des contre-sens et des erreurs si manifestes qu'il n'est possible de s'en servir comme base de travail qu'après une critique attentive, sans compter sur le style que Jean-Michel Salaün lui-même dans le billet cité plus haut qualifie « d'un peu abscons » et que je qualifierais plus volontiers de charabia jargonnant.

A l'heure où le Web sémantique pointe avec plus de prégnance le bout de son nez, il n'est pas inutile de revenir sur ce texte, comme sur les deux autres, pour construire une nouvelle réflexion. C'était d'ailleurs leur but : susciter le débat et la réflexion, sans présager des évolutions futures et selon l'état de l'art du moment. Or, il semble bien qu'une nouvelle étape est sur le point d'être franchie, si ce n'est pas déjà le cas. A titre personnel, si, à l'époque de rédaction du texte, je n'étais pas en mesure de m'immiscer dans le débat, j'espère, aujourd'hui, pouvoir apporter ma pierre à l'édifice.

Avant d'entrer dans le vif du sujet, je voudrais rappeler, pour mémoire, que cette initiative avait été lancée par le réseau thématiques pluridisciplinaires dédié au document, le RTP-DOC d'où le pseudonyme Roger T. Pédauque pour signer les textes collectifs, placé sous le patronage de feu le département STIC du CNRS. L'objectif était de réfléchir selon une approche pluridisciplinaire à la notion de document dans le contexte des changements induits par le numérique.

1- Retour sur la notion de texte et son analyse

Si je souscris totalement à la méthodologie initiale annoncée, à savoir repartir de la notion de texte pour redéfinir le concept de document, il est erroné d'affirmer que cette notion n'a pas été étudiée par les chercheurs, en particulier les linguistes, lorsque les premières DTD ont été créés pour SGML au début des années 1990 en vue d'encoder des textes .

Il existe des références incontournables dans la littérature anglo-saxonne, à commencer par l'article fondamental de Steven DeRose, David Durand, Elli Mylonas et Allen Renear, « What is text, really ? » paru en 1990 dans la revue Journal of Computing in Higher education. Je vous engage à relire cet article, écrit au moment où l'initiative de la TEI n'en est qu'à ses balbutiements, tant il reste encore d'actualité ¹ . Les auteurs démontrent la pertinence du modèle de construction hiérarchique de la structure logique d'un texte qu'ils nomment le modèle OHCO (Ordered hierarchy of content object) et qui constitue la base des langages à balise, de SGML et, donc de XML. A travers différents exemples, ils montrent l'apport de ce modèle pour l'exploitation informatique du texte.

Évidemment, le modèle du codex imprimé est encore très présent dans les idées exposées, mais cet article dont il faut se souvenir de la date de rédaction constitue une base indéfectible et citée encore régulièrement par les spécialistes de l'encodage. Les auteurs ont précisé certaines idées dans un second article : « Refining our Notion of What Text Really Is: The Problem of Overlapping Hierarchies », revenant sur le problème bien connu de l'overlapping, problématique absente, malheureusement, de l'article de Roger.

De même, il n'est pas une présentation, formation, tutoriel sur la TEI, sans retour initial sur la notion de textes. Il suffit pour s'en convaincre de parcourir les documents mis à disposition sur le site du consortium. M'inspirant modestement de ces documents pour ma présentation de la TEI à l'ADBS, il y a quelques semaines, j'avais proposé cette définition à la notion de texte :

« Un texte est la représentation sur un support d’une construction logique de phrases formant une unité. »

Elle n'est évidemment ni complète, ni parfaite, à commencer par l'utilisation de la notion de phrase que je remplacerais par « portions d'information ». En effet, et c'est une seconde erreur de l'article de Roger, les DTD créées pour encoder le texte ne reposent pas sur le concept de phrases, mais sur un concept plus générique de divisions ou blocs d'information, la fameuse balise <div> que l'on retrouve aussi bien dans TEI, docbook que HTML et, à un niveau de granularité plus restreint, au concept de chaînes de caractères référencées (inline element), qui prend la forme de la balise <rs> et dérivés (persName, geoName, hi, emph...) dans la TEI ou en HTML. L'erreur des auteurs de l'article repose, mais peut-être que je me trompe, sur l'idée que ces différentes DTD ont été construites par des linguistes. Si on ne peut nier leur apport, il ne faut pas oublier que la TEI a été créée par des chercheurs issus de toutes les disciplines des sciences humaines, que Docbook a été créé par Norm Walsh qui, aux dernières nouvelles, n'est pas linguiste, et que HTML a été créé par Tim Berners-Lee, qu'on ne présente plus.

Ainsi, si le postulat de départ est bon, l'état de l'art ne semble pas complet ² ce qui entraîne des fausses affirmations et, aussi, peut-être, une mauvaise interprétation du but et du rôle de XML dans l'exploitation informatique des textes ce que viennent, d'ailleurs, confirmer les deux problèmes suivants.

2- La fausse croyance de la prévalence du fond sur la forme

Voilà, un argument maintes fois entendu, l'utilisation de XML étant basé sur la séparation entre la structure logique du texte (désigné par les termes « fond » et « contenu » dans l'article) et sa structure physique (sa mise en forme), l'apport de la forme (mise en page, graphisme, design) à l'appréhension et à la compréhension du texte serait nié par les mécanismes d'encodage. Il existerait une prévalence implicite du fond sur la forme. Il me semble que cet argument est le signe d'une incompréhension des raisons qui ont poussé à cette séparation et d'une méconnaissance du fonctionnement concret de XML.

Repartons, si vous le voulez bien, des buts qui ont vu la mise en place de la TEI, qui constitue la première DTD pour encoder les textes et une source d'inspiration pour les suivantes. Le but initial était de partager une syntaxe et des règles communes de balisage en vue de l'échange des corpus informatisés. Cette idée est d'ailleurs toujours présente dans la TEI, puisque le guidelines a pour titre, Guidelines for Electronic text encoding and Interchange . Dans ce contexte, l'encodage de la structuration logique du texte assurait l'échange du texte dans une version facilement exploitable par des logiciels et des applications. La séparation entre structure logique et structure physique ne relève donc pas d'une quelconque posture épistémologique, mais constitue plutôt un moyen d'assurer l'échange et l'exploitation du texte encodé dans des contextes différents ³ .

Pour autant, structure logique ne signifie pas forcément que les caractéristiques physiques d'un texte ne sont pas encodées. Cela dépend tout simplement du but poursuivi et des besoins de traitement du texte. C'est d'ailleurs la raison pour laquelle j'ai conservé la notion de « support » dans ma définition du texte. La TEI offre précisément les moyens d'encoder toutes les caractéristiques physiques du texte traité, dans la mesure où ils font partie intégrante de son appréhension et méritent, à ce titre, un traitement particulier. Citons, par exemple, le changement de ligne (<lb/>), le changement de page (<pb/>), le changement de mains dans un document manuscrit (<handSchift/>), ou encore les abréviations (<abbr>) pour rester dans le registre de la paléographie.

Par ailleurs, la TEI offre avec l'attribut rend disponible pour tous les éléments la possibilité d'indiquer le rendu/la mise en forme de la portion encodée. L'attribut style joue exactement le même rôle pour HTML. De plus, toujours en HTML, toutes les pages possèdent un lien vers une feuille de style qui exprime la mise en forme de la page grâce au langage CSS, format tout aussi pérenne, ouvert et libre que XML. Ce mécanisme de lien est très clairement exprimé dans les recommandations de HTML. D'ailleurs, la montée en puissance, ces dernières années, du couple HTML-CSS est une preuve que la séparation n'est pas vécue comme un abandon de la forme, mais plutôt comme un moyen de rationaliser le développement de sites Web, d'en assurer un suivi, une maintenance et une évolution simplifiés, tout en économisant de la bande passante.

Enfin, un dernier exemple démontre l'irrecevabilité de cet argument : la mise au point récente et l'utilisation de schémas XML pour décrire les documents issus d'un traitement de texte. Dans ce cas, le fichier XML comprend des informations de mise en forme physique du texte ce qui démontre bien que cette séparation n'est pas à faire sur le contenu lui-même, mais sur la structure logique. Or, dans ce cas, la mise en forme participe de la structure logique du texte, c'est pourquoi la plupart des informations de mise en forme sont présents directement dans le fichier XML.

3- XML et la grammatisation du document

Cette connaissance approximative du rôle et du fonctionnement de XML apparaît de manière encore plus explicite dans la thèse qui sous-tend l'ensemble de l'article, à savoir les rapports entre XML et l'évolution de la grammatisation du document.

Les auteurs appliquent, à l'évolution des langages documentaires utilisant XML, le concept de « grammatisation » forgé par Sylvain Auroux, à la suite de Jacques Derrida, et qui désigne la matérialisation de « la substance d'une expression en éléments matériels discrets et manipulables ». Ce faisant, ils distinguent trois postures dans l'utilisation de la syntaxe XML marquant un contrôle de plus en plus accru du contenu du texte :

« DTD », dont le but est d'annoter et de manipuler des documents ;
« Schémas », dont le but est d'échanger des données entre applications ;
« RDF/S, Ontologies/OWL » dont le but est d'effectuer des inférences formelles sur le contenu.

Or, cette analyse pose plusieurs problèmes. En premier lieu, elle traduit une confusion de taille entre la syntaxe XML et le modèle d'encodage de l'information sous-tendu par XML, à savoir un arbre. Si les deux premières postures utilisent à fois XML en tant que syntaxe et en tant que modèle, la troisième posture a pour base le modèle de graphes, sous-tendu par l'utilisation de RDF, et peut se traduire par une syntaxe XML, mais aussi d'autres syntaxes : Turtle, N-triples ou N3.

L'information encodée grâce aux DTD et aux Schémas forme un arbre dont les nœuds sont constituées par les différents éléments ou balises utilisés. Dans le cas de RDF, l'information encodée forme un graphe, selon le schéma « sujet-prédicat-objet » et constitue un modèle plus générique d'encodage de l'information, l'arbre étant un type particulier de graphes.

Cette distinction entre modèle et syntaxe est d'autant plus importante que les deux premières postures n'ont pas le même rôle que la troisième. Les DTD et les schémas définissent un cadre ou une grammaire pour valider la structure de l'information encodée en vue de son échange et/ou d'une transformation, qui, au passage, ne pose aucun problème grâce à l'utilisation de XSL ⁴ . RDF schéma et OWL permettent de définir les relations entre différents types de ressources (document, page Web, objet, personne, concept...) pour échanger des données hétérogènes et y appliquer des inférences. Par exemple, une ontologie définie selon RDFS ou OWL permet de définir qu'une ressource de type « Personne » entretient une relation de nature « connaît » avec une autre ressource de type « Personne ». Ils ne servent en aucun cas à valider un document RDF. Ils offrent « simplement » un vocabulaire commun pour exprimer des prédicats sur des types de ressources.

De plus, la structuration d'information en XML selon un cadre défini dans une DTD ou un schéma dépend d'un contexte précis et se pense sur l'ensemble de l'information encodée. Ainsi, une même information peut être encodée de manière complètement différente tout en restant valide selon un schéma et sans que la nature du message soit différente. La structuration d'information en RDF se conçoit, quant à elle, au plus proche de la donnée elle-même dans le contenu même du message véhiculé par l'information.

De ce point de vue, le modèle exprime une idée tout à fait juste, à savoir que ces trois postures constituent une évolution dans l'exploitation de différents niveaux de granularité de l'information, pour en arriver à l'exploitation par une machine du message véhiculé par l'information. Pour autant, si les « Schémas » constituent bien une évolution des « DTD », offrant la possibilité de contrôler les types de données comme une date, une chaîne de caractères, un booléen.., la troisième posture relève d'un paradigme différent et ne peut être assimilé à une évolution, mais plutôt à un complément.

D'ailleurs, les deux aspects ont évolué de façon concomitante ces dernières années. La communauté XML a mis au point des technologies telles que Relax NG ou schematron pour mieux contrôler et valider la structure des données, offrant les outils pour vérifier ce que les auteurs nomment la « validité sémantique », tandis que la communauté RDF a amélioré les moyens de définir une ontologie avec OWL mais aussi d'autres systèmes d'organisation des connaissances, comme les thésaurus avec SKOS. De même, deux langages de requêtes spécifiques ont été développées, Xquery pour XML et SPARQL pour RDF ce qui démontre bien que les deux modèles sont différents.

Enfin, un aspect essentiel a été occulté dans cette analyse. A aucun moment, les auteurs n'introduisent le rôle joué par le protocole HTTP et le concept des URI dans cette évolution. Or, l'échange de données entre les applications n'est possible que dans la mesure où nous disposons à la fois avec XML d'une syntaxe indépendante des plates-formes et des logiciels, mais aussi d'une couche de transport, un protocole de communication commun, HTTP et dans ce réseau, un moyen normalisé d'identifier et de localiser une ressource grâce aux URI. Ainsi, XML schéma représente bien une évolution naturelle dans les outils de validation et de contrôle de l'information encodée, mais il ne saurait être dissocié de HTTP, s'il est conçu dans le cadre des échanges de données entre applications. Or, si les grands éditeurs (IBM, Sun, Microsoft, Oracle, SAP et consorts) se sont rués sur XML et en ont fait la base des architectures SOA, c'est précisément, parce que le couple HTTP+XML constituait la réponse à la problématique des middlewares et de l'EAI, très en vogue à l'époque et largement remis en cause aujourd'hui.

4- Le Web sémantique ne se limite pas aux ontologies !

La confusion évoquée précédemment provient certainement d'une mauvaise interprétation des buts poursuivis par le Web sémantique et, dans ce cadre, du rôle précis de RDF et des ontologies. De ce point de vue, cet article constitue un bon exemple des méprises dont je parlais dans un précédent billet.

Ainsi, pour les auteurs, le Web sémantique vise à « construire un métalangage, fondé sur les ontologies, représentant de façon formelle le contenu des documents qui pourra donc servir de base à des modélisations informatiques ». Or, les ontologies ne constituent pas la base du Web sémantique, mais elles y participent, constituant une des briques. C'est RDF, dont il est fait malheureusement trop peu allusion dans l'article, qui constitue la base des technologies du web sémantique. En limitant le Web sémantique aux ontologies, les auteurs ont naturellement porté le débat sur les problématiques déjà connus dans l'intelligence artificielle, à savoir, pour faire court, la dangerosité de modéliser l'ensemble des connaissances du monde selon une ontologie imposée et unique ce qui réduit inévitablement le sens porté par un texte à une interprétation. De ce point de vue, la partie intitulée « Questionner le Web sémantique » est un conglomérat de tous les fantasmes véhiculés par cette idée d'ontologie universelle.

Or, comme le rappelle James Hendler dans cette réponse à Clay Shirky, au contraire de systèmes traditionnelles de représentation de la connaissance (les bases de connaissances auxquels fait allusion l'article) centralisés et imposant de partager la même définition des concepts communs, le Web sémantique est plus flexible et n'impose pas l'utilisation d'une seule ontologie, les mécanismes étant suffisamment puissants pour introduire des inférences entre deux données qui n'utilisent pas la même ontologie. Cette puissance est offerte par le modèle de base qui sous-tend tout l'édifice du Web sémantique, à savoir RDF. Ainsi, contrairement à ce qu'affirment l'article et les tenants du concept de Web socio-sémantique, le Web sémantique n'est pas anti-social et ne dépendrait pas d'une communauté ou d'un contexte social donné et imposé.

Même si les technologies du Web sémantique offrent le moyen de représenter « de manière formelle des contenus [nda : est-ce à assimiler à la notion de texte ?] via les ontologies » en vue d'une exploitation par une machine, le but initial du Web sémantique est plutôt d'échanger à une très large échelle des données de nature hétérogènes, ce que ne permet pas XML qui impose l'utilisation de schémas identiques ou une transformation préalable, et, éventuellement, grâce aux systèmes des ontologies, d'y appliquer des mécanismes simples d'inférence. Ainsi, le Web sémantique ne s'intéresse pas directement au texte en lui-même, mais aux données qui le décrivent ou le caractérisent, ce qu'on appelle communément les métadonnées, ou à des données précises à l'intérieur du texte comme le permet RDFa.

5- Évolution du Web sémantique depuis l'écriture de l'article

L'article constitue un bon point de repère pour évaluer l'évolution du Web sémantique et son appropriation. Les différentes briques et technologies du Web sémantique sont habituellement représentées sous la forme d'un cake. Or, au gré des recherches, ce cake évolue et la dernière version est largement différente de la version proposée par l'article.

Dans cette nouvelle version, à la base, nous trouvons toujours les URI qui permettent d'identifier les ressources (sujet ou, éventuellement, objet d'un triple) et les prédicats. RDF est le modèle de base pour l'échange des données et peut éventuellement s'appuyer sur XML, dans le cas de l'utilisation de la syntaxe RDF/XML. Au-dessus, on trouve SPARQL pour effectuer des requêtes, RDFS et OWL pour définir des vocabulaires RDF, assimilables à des ontologies et RIF, un langage de définition de règles. XML schema et les namespaces ont complètement disparus du cake, englobés dans la brique XML.

De même, si, à terme, les technologies du Web sémantique devrait améliorer la recherche d'information par une meilleure caractérisation des données et des relations qu'elles entretiennent entre elles, nous savons aujourd'hui que cela n'est pas son but initial, mais plutôt une conséquence. Ainsi, à une vision top-down qui a longtemps été l'axe privilégié par les recherches sur le Web sémantique, il se substitue peu à peu, entre autres par l'écosystème initié par le Web 2.0, une approche bottom-up dans lequel ce sont les annotations portés par l'utilisateur ou les données structurés qu'ils génèrent qui sont exploitées par les technologies du Web sémantique. De ce point de vue, Dbpedia est un exemple parfait. Partant du contenu mis à disposition sur wikipedia, le projet Dbpedia vise à mettre à disposition cette masse d'informations en RDF pour une meilleure exploitation par les machines de ce gisement de données.

6- Retour sur l'exemple donnée en annexe de l'article

En annexe du document, un exemple illustre les trois postures abordés dans l'article. Malheureusement, il comprend un certain nombre d'erreurs. Ainsi, le manque de maîtrise des technologies dont il est fait preuve pourrait expliquer en partie les contre-sens de l'article.

L'exemple utilisant une DTD ne pose pas de problèmes particuliers, si ce n'est qu'il aurait mérité un balisage plus fin. Si, à première vue, le schéma semble bien défini dans le second exemple, sa déclaration est complètement fausse. Dans le cas d'un schéma, il ne faut pas utiliser de doctype, le schéma étant déclaré dans l'élément racine du fichier XML. De plus, il est obligatoire de déclarer l'espace de nom par défaut correspondant au schéma XML ce qui nous donne :

<?xml version="1.0" encoding="UTF-8"?>
<CRH 
    xmlns="http://www.rogerpedauque.fr/casclinique/ns/"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.rogerpedauque.fr/casclinique/ns/ http://www.rogerpedauque.fr/casclinique/ns/casclinique.xsd">
       [...]
</CRH>

L'exemple de RDF est complètement faux et démontre une incompréhension totale de son fonctionnement : les espaces de noms ne sont pas déclarés, il met en lumière la confusion entre le modèle XML et le modèle RDF. Voici approximativement ce qu'il pourrait obtenir :

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:med="http://www.rogerpedauque.fr/casclinique/">
   <rdf:Description rdf:about="urn:hopital-toto:patient/1050">
      <med:poids>78</med:poids>
      <med:taille>169</med:taille>
      <med:tension>14-8</med:tension>
      <med:saturation>98</med:saturation>
      <med:symptome_constate rdf:resource="urn:hopital-toto:symptome/030"/>
   </rdf:Description>
   <rdf:Description rdf:about="urn:hopital-toto:symptomes/030">
      <rdfs:label>Douleurs thoraciques</rdfs:label>
      <med:maladie rdf:resource="urn:hopital-toto:maladie/100"/>
   </rdf:Description>
   <rdf:Description rdf:about="urn:hopital-toto:maladie/100">
      <rdfs:label>Péricardite</rdfs:label>
      <med:symptome rdf:resource="urn:hopital-toto:symptome/030"/>
   </rdf:Description>
</rdf:RDF>
         

En guise de conclusion

Outre les contre-sens relevés, il me semble que l'analyse et la réflexion n'ont pas été menées à son terme. C'est finalement le plus frustrant dans cet article, ses conclusions ne sont pas à la hauteur de ses ambitions. Ainsi, il n'aboutit à aucune définition concrète et simple de la notion de texte au point même que l'interrogation initiale disparaît peu à peu et, lorsqu'il aborde les pistes les plus intéressantes, il ne la poursuit pas. Or, une phrase et une idée me paraît essentiel dans cet article : « On peut se demander dans ce modèle [nda : le Web sémantique] si la notion de document a encore un sens ». Voilà, précisément, la question essentielle à se poser !

Quelques notes en passant

1Les auteurs de l'article étaient d'ailleurs pour la plupart impliqués dans l'élaboration de la TEI.

2Pour connaître certains des auteurs de l'article de Roger, je sais pertinemment qu'il connaisse parfaitement les deux articles d'Allen Renear et alii.

3Le principe est le même pour LaTeX et je ne crois pas avoir entendu cet argument le concernant, tant il tomberait très rapidement à l'eau vu le profil des développeurs originaux de ce logiciel.

4p. 22, les auteurs affirment : « en l'état actuel de la technologie, peu de langages transformationnels sont capables de garantir l'invariance de niveau 1 (le résultat ne sera pas nécessairement bien formé) et aucun ne préserve le niveau 2 [nda : la validité de l'encodage de l'information selon un schéma] », alors que XSL qui date de 1999 garantit précisément ces deux niveaux de validité...

La TEI : principes et fonctionnements

got — Mon, 28 Jan 2008 20:51:53 +0100

L'ADBS m'a donné l'occasion, la semaine dernière, de me replonger avec grand plaisir dans la TEI à l'occasion d'un 5 à 7. Le but ce cette séance était d'en présenter le principe et le fonctionnement. Ma présentation s'attache donc à montrer les particularités de la TEI et en quoi elle constitue une solution générique à l'encodage des textes en repartant des buts poursuivis par l'encodage et de la démarche particulière de sa conception.

Je me suis inspiré pour la mettre au point des documents, en particulier une présentation de Lou Burnard, Sebastian Rahtz et Matthew Driscoll faite à l'occasion d'une formation à Sofia, mis à disposition sur le nouveau site du consortium TEI dévoilé à l'occasion de son 20ème anniversaire et de la sortie en version finale de la nouvelle version, la P5.

Après toutes ces mois à m'intéresser à RDF, cela a aussi été une opportunité pour préciser dans mon esprit les différences entre RDF et XML et d'affiner mes réflexions sur le concept de texte et de document. Mais, c'est une autre histoire que j'espère pouvoir partager avec vous dans les semaines qui viennent, s'il me reste un peu de temps ;-)

Bonne lecture !

Un peu de lecture

got — Sat, 24 Mar 2007 15:41:51 +0100

En attendant que je réussisse à émerger, ce qui ne devrait pas tarder (un billet est en train de mûrir, je vous le promets), je propose à ceux que ma prose manquerait un peu de lecture. Tout d'abord, sur Archives SIC, l'archive ouverte spécialisée en sciences de l'information et de la communication, je me suis enfin décidé à y déposer mes articles et mes communications (enfin une partie). Certains sont « inédits », en particulier les deux derniers sur l'utilisation du Web sémantique pour mettre en lumière les réseaux sociaux dans les sources historiques et sur un modèle conceptuel pour encoder les chartes à partir de ODD, d'autres traînent déjà à droite à gauche, ainsi que sur ce blog. Sur le site de TELMA, vous trouverez le support de la formation que j'ai faite à l'URFIST sur les enjeux éditoriaux et techniques de la diffusion en ligne des sources historiques ainsi que quelques ressources sur le modèle OAIS. Ce diaporama qui comprend une centaine de diapos constitue en quelque sorte une synthèse de mes six années de travail à l'École des chartes.

Bon, je vous laisse, il faut que je termine ma dernière édition électronique pour l'École des chartes, un superbe travail mis au point par Frédéric Duval et Françoise Vielliard sur les traductions d'oeuvre classique faite au Moyen Âge, c'est du très lourd (allez, en avant-première, je ne résiste pas à vous en donner l'URL : http://elec.enc.sorbonne.fr/miroir/) et il faut que je prépare mon intervention à la table ronde organisée lundi matin par le BBF au salon du livre sur les wikis. Si certains d'entre vous sont présents lundi au salon, n'hésitez pas à venir me voir, ce sera avec plaisir de discuter un peu avec vous.

Pour commencer l'année en douceur

got — Thu, 04 Jan 2007 07:37:48 +0100

Comme il est de bon ton de commencer l'année en vous présentant les meilleurs vœux, je n'échappe pas à la règle et je vous souhaite à tous une bonne et heureuse année 2007. Pour ma part, elle risque d'être décisive en de nombreux points, mais j'espère qu'elle sera un peu moins « bougeante » que 2006.

Pour bien commencer l'année et comme il fallait que je blogue (Manue me donne envie en bloguant à côté de moi ;-) ), je vous propose les supports d'un cours sur la TEI que j'ai donné à l'ENSSIB aux futurs conservateurs au mois de décembre dernier. Pour les besoins du cours, j'avais rassemblé sur une page de ce site tous les liens et tous les fichiers dont nous avions besoin pour les trois séances de TD qui faisaient suite à un cours magistral par Lou Burnard lui-même, s'il vous plaît ! A la suite du cours, j'ai complété cette page avec un lien vers le diaporama et vers les corrigés des exercices. C'est brut de décoffrage, mais je me suis dit que ça pourrait toujours servir, ne serait-ce qu'aux élèves qui ont suivi ce cours1 et que je remercie au passage pour les bons moments que j'ai passé en leur compagnie pendant ces trois jours à l'ENSSIB : TD sur la TEI. ENSSIB (18-20 janvier 2006).

Quelques notes en passant

1 Je dédicace ce billet à la personne (élève-conservateur ?) qui est arrivée sur ce blog à partir d'un moteur de recherche avec la requête : « enssib tei poupeau site »

Des nouvelles du monde XML

got — Fri, 15 Dec 2006 22:26:04 +0100

J'ai à nouveau mon agrégateur rempli de billets sauvegardés vu que ces derniers temps, j'ai plus fait le tri que lire réellement ce qui y passait. Il y a un moment où il faut se résoudre à vider tout cela. Commençons par les billets autour de XML.

Il semble que le format Relax NG, norme ISO, s'impose définitivement face à XML schema pour définir des grammaires XML. Après le billet de Elliote Rusty Harold, « Relax wins », faisant état des nombreuses grammaires ayant choisi Relax NG (c'est aussi le cas de la P5 de la TEI), Tim Bray, à l'origine de XML et employé de chez Sun, déclare sur son blog qu'il s'agit d'un moment important dans la vie de XML et avoue que XML schema « craint » (« XML schema suck »). Bob du Charme revient aussi sur cet événement important. Cela sent le mea culpa et c'est une bonne nouvelle, tant XML schema fut décrié dans la communauté. Si vous voulez en savoir plus sur Relax NG, vous pouvez consulter librement en ligne le livre sur le sujet en anglais d'Eric Van der Vlist (Eric, à quand une traduction en français ?) paru aux éditions O'Reilly.

Eliot Kimber, de retour de XML 2006 (je vais y revenir) a écrit un post très intéressant sur un format actuellement à l'étude chez Adobe , Mars, une grammaire XML pour décrire les documents PDF. Conscient de l'importance des standards basés sur XML pour le futur de la gestion de l'information numérique et sa conservation, Adobe répond, à mon avis, à travers cette proposition au format bureautique basé sur XML, Open Format Document, le format d'Open Office entre autres et Open XML, le format promu par Microsoft, qui vient d'ailleurs de devenir officiellement une norme ECMA, avant de passer à l'ISO (?), ainsi qu'à la critique récurrente faite à PDF des problèmes qu'il peut poser sur le long terme. D'ailleurs, ce format est basé sur le même principe, un fichier zip comprenant des fichiers XML. Les formats utilisés sont nombreux. Parmi ces derniers, on notera l'utilisation massive de SVG, le format vectoriel mis au point au W3C. Je vous conseille la lecture de la FAQ et du guide.

Du côté du W3C, une nouvelle recommandation assez prometteuse est actuellement à l'étude : Xproc. Il s'agit d'un langage pour standardiser les interactions, entrées et sorties autour de documents XML, incluant la validation, la transformation, l'interrogation, l'inclusion... Bref, tout ce que vous pouvez effectuer avec des fichiers XML. Le principe me fait furieusement penser à celui des pipelines du framework Cocoon pour ceux qui connaissent. A travers un document XML, vous exprimez les différentes étapes et moyens par lesquels vous voulez interagir avec un ou des document(s) XML. La lecture du billet de Oleg Tkachenko pourra vous en apprendre plus.

L'interrogation full-text de documents XML commence à avoir le vent en poupe. Ça me semble logique, vu que Xquery va atteindre, enfin, dans les jours/semaines qui viennent le statut de recommandation, cette partie constitue la prochaine brique essentielle pour le monde XML. Alors que les ajouts indispensables à Xquery sont à l'étude au W3C, j'y ai déjà fait allusion, les annonces des implémentations de XQFT (Xquery Full Text) comme le montre cet article de l'ACM se succèdent au point qu'IBM en propose une étude sur son site. XQFT va devenir, à n'en pas douter, un enjeu stratégique et industriel très rapidement et les cellules R&D des éditeurs de moteur de recherche feraient bien d'étudier tout cela très vite.

La conférence annuelle XML 2006 a eu lieu du 5 au 7 décembre 2006 à Boston. Cette conférence a marqué les 10 ans de XML. Si vous voulez en savoir plus, je vous renvoie aux nombreux compte-rendus sur le sujet dans la blogosphère : en français par Eric Van der Vlist, en anglais par Eliotte Rusty Harold sur Cafe con Leche, par Mike Champion, par Uche Ogbuji, par Rike Jellife.

J'ai fait allusion dans un précédent billet à l'attribut role et aux possibilités qu'ouvrirait son implémentation. Il semble que le W3C veut le mettre en avant, puisqu'une Working draft vient de sortir à ce sujet : « XHTML role attribute. A module to support role classification of elements ».

Norman Walsh, le père de Docbook entre autres choses, propose sur son site des feuilles de style XSL 2 pour accéder au Web services de Flick'r. Cela pourrait constituer une solution simple à implémenter pour interroger les Web services. A surveiller de près.

Et pour finir et faire la transition avec le Web sémantique qui fera certainement l'objet d'une autre pelote de liens, je vous recommande la lecture de ce billet de Bob du Charme qui propose une étude des possibilités du couple XML/Xquery par rapport au couple RDF/Sparql. Ce billet fait suite à un courriel de Lee Feigenbaum sur la mailing-list du groupe d'intérêt du W3C dédié à l'apprentissage du Web sémantique. Le billet de Bob du Charme présente l'intérêt de replacer les différentes technologies dans leurs contextes et montre en quoi elles répondent chacune à des utilisations précises et différentes.

Les réalités dans l'encodage XML

got — Sun, 05 Nov 2006 11:06:01 +0100

Depuis que nous nous sommes revus1 à Digital Humanities en juillet, Christian Vandendorpe 2 et moi débattons du problème de l'encodage en XML des caractéristiques physiques d'un document. Cette discussion qui a trouvé une première issue à Victoria, ainsi que la préparation d'une communication sur l'encodage des chartes médiévales pour le Consortium des corpus de français médiéval, m'ont amené à réfléchir à un des problèmes que je rencontrais dans l'encodage en XML, en particulier des éditions critiques : mettre en lumière les différents niveaux/types de renseignements qu'on peut trouver dans un document.

Nous sommes bien d'accord que le XML est basé sur l'idée de séparer le contenu de la mise en forme des données. Cela permet d'assurer l'interopérabilité entre les différents outils et plate-formes permettant de l'exploiter et de le traiter.

Cette règle a peut-être tendance à nous faire oublier qu'un document se compose à la fois de données et d'un support. La conservation en bibliothèque a pour but d'assurer l'intégrité de ce couple et les chercheurs en histoire du livre ont montré que la mise en forme avait de l'importance dans l'organisation et l'appréhension de l'information. Lorsqu'on encode l'édition d'un texte manuscrit, il n'est donc pas inutile d'encoder certaines informations qui relèvent de caractéristiques physiques du document source3 : changement de lignes, de pages ou de mains, dans le cas d'un manuscrit, les abréviations... Dans ce cas, les informations encodées n'ont rien à voir avec le rendu à l'écran. Elles font partie intégrante du document source transcrit. Ces informations physiques deviennent alors des informations logiques et elles relèvent des buts fixés par l'encodeur.

Or, même si leurs études croisées avec le texte du document en lui-même sont fondamentales, nous sommes d'accord que ces deux types d'informations ne sont pas de même nature, c'est ce que j'appelle une réalité. Dans le cas de l'édition d'un manuscrit, le document encodé est composé d'au moins deux réalités :

les caractéristiques physiques du support du texte ;
le texte en lui-même, les données brutes.

La mise en lumière des réalités encodées permet de mieux appréhender le balisage et évite les erreurs dans le choix de balises. Cela permet de prendre conscience des différents niveaux d'informations contenues dans le document et aider à son analyse et son traitement. Mon exemple se limite à deux réalités, mais d'autres exemples sont plus complexes. Dans le cas de l'édition critique d'une charte, par exemple, l'encodage de l'édition critique de la charte reflète l'événement relaté dans la charte (une donation par exemple), l'analyse du chercheur, le texte qui relate l'événement et le support physique avec la prise en compte pour ces deux dernières réalités qu'il existe plusieurs supports du texte différents (original et copies).

Mais, revenons à mon exemple et à son encodage. Encoder ces deux réalités posent le problème de l'overlapping. En XML, les balises ne peuvent pas se chevaucher. Si j'encode les caractéristiques physiques et la structure logique du texte, un paragraphe peut commencer sur une page et finir sur une autre, on ne peut pas écrire :

<page>Blabla</page><page> blabla</page>

Dans ce genre de cas, la TEI préconise l'utilisation de « milestone », c'est à dire des balises vides qui donnent une information sur le point précis, dans notre exemple, le changement de pages :

Blabla <pb/> blabla

Mais, bien souvent et en TEI en particulier, l'encodage de la structure logique prend le pas sur les caractéristiques physiques. Après tout, on pourrait vouloir encoder en priorité les caractéristiques physiques et simplement à titre d'appui la structure logique. Il serait intéressant, me semble-t-il, de permettre la réciproque ou mettre au même plan les deux réalités.

C'est pourquoi certains font d'autres propositions : encodage dans deux fichiers séparés des deux réalités ou utiliser les namespaces pour différencier les deux arbres en mettant de côté le problème de l'overlapping, le multi-hierarchical XML, dont j'ai parlé dans mon précédent billet.

Ces deux solutions n'apportent pas de réponses entièrement satisfaisantes. Dans le cas de deux fichiers séparés, il faut quand même mettre au point un système de pointeurs qui permet de synchroniser les deux niveaux d'informations dans les deux fichiers différents qui se traduira bien souvent par l'ajout de balises. Au final, je ne sais pas si cela facilite véritablement le processus. Quant à la deuxième solution, elle propose une utilisation des namespaces qui n'est pas conventionnel, ce qui pourrait poser des problèmes au cas où les deux réalités utilisent le même schéma, donc le même namespace. Pourtant, cette dernière solution a le mérite de mettre le doigt sur un autre problème en proposant d'ailleurs une réponse. Le XML n'offre aucun moyen de mettre en lumière une des réalités encodées, ce qui permettrait de repérer rapidement et facilement une des réalités et, ainsi, en optimiser son traitement, son interrogation et son indexation. C'est particulièrement crucial dans le cas où les différentes réalités sont encodées avec les mêmes balises comme dans une page Web. C'est ce cas que je vous propose d'étudier dans le prochain billet.

Quelques notes en passant

1 J'ai pour la première fois eu l'honneur de rencontrer Christian Vandendorpe à un colloque organisé à l'ENSSIB : les défis de la publications sur le Web.

2 Christian Vandendorpe, que je remercie pour nos discussions et nos échanges, spécialiste de la théorie du texte et de l'hypertexte est l'auteur d'un très bon livre sur l'hypertexte, Du papyrus à l'hypertexte, dont je recommande à tous la lecture.

3 Il existe un champ de recherche spécialisé par cette question : la critique génétique des textes dont le laboratoire ITEM est le spécialiste.

Victoria, le Canada et la TEI, suite et fin

got — Mon, 30 Oct 2006 16:48:13 +0100

Comme toutes les bonnes choses ont une fin, je m'apprête dans quelques heures à quitter Victoria et à reprendre l'avion pour rentrer à Paris, des souvenirs, des idées, des pensées pleins la tête, comme à chaque fois que je repars d'un colloque.

Comme certains d'entre vous ont eu l'air d'apprécier mon précédent billet (Merci encore Jean-Paul), je m'en vais vous conter la fin de ces journées. En fait, cela va aller assez vite (j'en vois certains qui sont rassurés dans la salle). Je n'ai pas vraiment assisté à un SIG, pris par l'écriture de mon précédent billet et la perspective de la poster session. D'ailleurs, cette dernière s'est bien déroulée, le poster que j'avais fait a été apprécié (encore merci à Nico et Manue pour leur coup de main). Notre projet de numérisation des cartulaires numérisés a fait l'admiration des différents bibliothécaires présents qui se sont succédés pour savoir comment nous utilisions METS. Quant aux geeks de la TEI et aux chercheurs, c'est surtout theleme, notre manuel en ligne de sciences auxiliaires qui a retenu leur attention. Quant aux autres posters, je n'ai pas vraiment eu le temps de les voir et pour la plupart ils correspondent aux interventions dont je vous ai parlé.

Je vous fais grâce des interventions de rigueur dans la vie d'une association, pour arriver à la keynote de clôture. Greg Crane, responsable de la bibliothèque numérique Perseus, nous a présenté sa vision de la « vie intellectuelle à l'âge de Google ». Après avoir analysé notre monde actuel et les problèmes des sciences humaines aujourd'hui par rapport à celui-ci, analyses que je partage avec lui, il a présenté ce qui représente sa solution, c'est à dire son projet. Son idée est simple, nous devons absolument faire de la masse, pour être présent, marquer notre territoire et montrer aux tutelles que l'investissement en sciences humaines est rentable. Pour cela, il faut aller discuter avec Google, Microsoft ou Yahoo pour récupérer l'OCR et y appliquer un balisage structuré en TEI, mais très lâche.

Soyons honnêtes, c'est très impressionnant, son sytème a l'air de bien fonctionner. Mais, j'avoue que son discours m'a gêné. Est-ce que notre métier doit être le même que celui de Google ou Yahoo ? Est-ce-qu'il faudrait que nous allions jouer sur leurs terrains ? Ou est-ce-que nous pouvons mettre en avant une véritable différence et la cultiver ? J'avoue que je n'ai pas les réponses à ces questions. Pour autant, j'ai vu dans cette keynote la différence culturelle qui peut exister entre les chercheurs nords-américains et nous autres Européens (je partageais cette analyse avec ma collègue et amie du King's college Elena Pierrazo). Au final, je ne crois pas qu'il faille blâmer ou regretter cette position, après tout, c'est certainement cette vision qui sera celle de demain, mais, au bout du compte, je suis persuadé qu'il faut que toutes les positions coexistent : les googles qui font les grandes masses, les bibliothèques qui en font moins, mais avec des qualités de numérisation et de métadonnées plus importantes, les chercheurs qui font de la transformation de masse de l'OCR en XML structuré ou encore les chercheurs qui encodent très finement leurs corpus en TEI. Oui, il y a de la place pour tout le monde et aucune des différentes visions n'est meilleure que l'autre, elles se complètent tout simplement.

Cette keynote a marqué la fin de l'assemblée générale, mais je n'en avais pas fini pour autant, puisque j'ai eu la chance d'assister le lendemain (cad hier) au TEI board, le conseil d'administration restreint de la TEI. On n'imagine pas, lorsqu'on utilise la TEI, l'énergie, l'argent, les discussions et les débats qu'il faut pour faire vivre un standard comme celui-ci. J'avais parfois l'impression que dans cette chambre d'hôtel transformée en salle de réunion se jouait l'avenir d'un des standards les plus importants de notre discipline. Heureusement, les gens qui sont à la tête de la TEI ont conscience des enjeux. Pour autant, il faut quand même avoir conscience de l'extrême fragilité du modèle, le TEI consortium, indispensable pour maintenir les guidelines, en faire la promotion... vit en très grande partie aux adhésions des institutions. Alors, si, dans votre institution ou au cours d'un projet, vous utilisez la TEI, pensez que votre projet vit grâce au consortium et à toutes ces personnes et adhérez au consortium. C'est, me semble-t-il un échange de bon procédé et qui, en plus, vous permettra d'assister à l'assemblée générale annuelle et de rencontrer cette formidable et très sympathique communauté.

MAJ (05/11/2006) : Vous pouvez aussi consulter les notes de Sharon Goetz beaucoup plus précises que les miennes. Merci Sharon !

Causeries sur la TEI à l'autre bout du monde

got — Sat, 28 Oct 2006 20:58:34 +0200

Après Manue, c'est à mon tour de traverser l'Atlantique pour assister à un événement annuel en relation avec ma communauté. J'ai même poussé le vice à traverser le continent nord américain d'est en ouest jusqu'à Victoria, ville située au Canada dans la région de la Colombie britannique sur la côte pacifique à quelques centaines de kilomètres de Vancouver et ainsi rejoindre mes camarades, amis et collègues de la TEI pour l'assemblée générale annuelle des membres du consortium.

Après un périple de 16 heures, deux lignes de métro, un RER, trois avions et un bus pour finir, j'ai pour la première fois de ma vie mis le pied hors d'Europe et, même si le colloque ne me laisse pas le temps d'apprécier pleinement la ville, le peu que j'en ai vu ne me déçoit pas. Quant aux 12 heures d'avion, qui, je dois l'avouer, m'inquiétaient, ça a été l'occasion de survoler le Groënland, instant magique que je ne suis pas près d'oublier.

Mais, trêves de bavardages, je n'ai pas fait plusieurs milliers de kilomètres pour faire du tourisme (franchement quelle idée !!...), mais pour travailler (c'est bien plus sérieux ! ;-) ). L'assemblée générale de la TEI est l'occasion d'entendre des communications assez théoriques sur l'encodage, la TEI, son évolution, ses défauts, XML, son évolution, ses défauts et comment améliorer tout ça. Je dois avouer que c'est souvent fumeux et que la langue de Shakespeare ne m'aide pas, mais il y a parfois quelques bonnes idées, comme cette tentative de Liam Quin du W3C de détendre les chercheurs que nous sommes sur les questions que nous nous posons avant d'encoder un texte. Il appelle cela l'anxiété du balisage, auquel il ajoute l'anxiété de la trace qu'on veut laisser, l'analyse était bonne, mais les propositions décevantes. Je retiendrais aussi les idées de John Lavagnino du king's college qui a expliqué en quoi le langage de la TEI évoluait et comment l'étude de cette évolution, même inconsciente, pouvait aider à mieux organiser le guidelines.

Heureusement, les communications ne se limitent pas à des papiers théoriques et à des keynotes et nous avons eu le droit à quelques rapports d'expériences.

Stéphan Sinclair, développeur d'hyperpro, un outil d'analyse lexicale en ligne sur lequel j'étais tombé il y a quelques mois, et Anthony Sapp nous ont présenté leurs recherches dans le domaine de la visualisation d'informations. Ils nous ont présenté plusieurs interfaces dont deux ont retenu mon attention. La première est une expérience assez novatrice de lecture (non, je rassure mes lecteurs fans de Thursday next, il ne s'agit pas d'Ultraworld) des pièces de théâtre, puisque vous pouvez visualiser sur un ascenseur dans une colonne à droite la répartition des tirades des différents personnages, dans une colonne adjacente, le texte en lui même et dans une dernière partie une animation du mouvement des personnages représentées sous forme de rond. Mon explication ne me semble pas clair, désolé... La seconde est un outil de représentation de l'information sous forme de mandala. Il représente graphiquement les interactions entre différentes informations que vous déterminez non pas simplement sous forme de graphes, comme avec omnigator dont j'ai déjà parlé, mais aussi sous forme de mandala. L'outil reste à creuser, mais l'idée est assez intéressante.

En vrac, nous avons eu une présentation d'un projet de visualisation géographique de corpus encodés en TEI par l'université de Bergen, une présentation du logiciel XTF, un framework de publication de document XML mis au point par la bibliothèque de l'université de Californie dont Manue a parlé justement cette semaine et qui me fait furieusement penser à SDX et la présentation par Béatrice Pincemin (oui, je ne suis pas le seul Français et ça fait bien plaisir !) du corpus des droits de l'Homme en TEI et la démonstration d'un projet en cours sur le livre the yellow book qui propose des documents en Word au téléchargement et un tourne-page en flash ce qui a eu pour effet de rayer définitivement le projet de ma mémoire. Deux autres projets ont retenu plus particulièrement mon attention :

L'inévitable communication sur les problèmes de l'overlapping et sur les moyens de représenter deux arbres XML dans un seul fichier XML (c'est à dire un seul arbre..), en particulier pour permettre la description physique d'un ouvrage et sa description logique. La solution proposée, cette fois-ci, est séduisante, mais cela s'arrête là. Michael Best et Peter van Hardenberg de l'université de Victoria proposent d'utiliser les namespaces pour différencier les deux arbres, de mettre en place chacun des arbres séparemment et ensuite de les mixer dans un seul fichier. Du point de vue de la représentation de l'information, c'est assez intéressant. Mais, outre le fait qu'un namespace XML a pour utilité d'indiquer quels schémas XML sont utilisés dans le fichier XML, leurs propositions est limité par les outils de traitement des fichiers XML, en particulier Xpath qui ne prévoit pas ce genre de cas.
Le second est une recherche en cours en Allemagne pour la mise en place d'un Grid autour des textes. Ils ont mis au point une interface visiblement open-source pour permettre aux auteurs de travailler et l'architecture en grid permet de décentraliser les données, et ainsi d'augmenter les capacités de stockage et d'interrogation. Ça m'a fait penser à la proposition de Stéphane Pouyllau sur un data center pour les SHS en France mixé avec la réflexion de Pierre Mounier sur SHS 2.0. C'est à dire comment centraliser tout en décentralisant...

Ce matin (oui, il est 8h du matin ici et la journée n'est pas encore vraiment commencé) a lieu la réunion des SIG, des groupes d'intérêts particuliers qui doivent aider au développement de la TEI et la poster session pendant laquelle je vais présenter un poster sur les projets de l'École des chartes dans le domaine des sources historiques (encodées en TEI évidemment !), avant d'affronter cet après-midi les interventions de rigueur dans la vie d'une association, bilan moral, financier et élections... Bref, encore une longue journée en perspective !

En quoi la TEI constitue aujourd'hui une bonne solution ?

got — Wed, 11 Oct 2006 21:24:26 +0200

Parmi les grammaires XML existantes, il en existe trois qui se détachent pour encoder des textes : Docbook mis au point par Norm Walsh dont le but est d'encoder les manuels techniques, XHTML 2 (eh ! oui) qui me semble une solution simple et efficace, améliorant les défauts de hiérarchisation de l'information que présentait HTML puis XHTML 1 et TEI dont la vocation initiale est d'encoder les textes en sciences humaines et en littérature entre autres. Je mets de côté Open XML et Open Document qui sont les grammaires utilisées respectivement par Microsoft Office et Open Office dont le but ne me semble pas exactement le même que celles citées précédemment.

A la différence des deux autres, TEI occupe une place à part de par sa nature et son fonctionnement, en particulier avec la nouvelle version dite P5 qui ouvre des perspectives très importantes et pourraient bien réconcilier un certain nombre de communautés qui, pour des raisons diverses, bonnes ou mauvaises, ne l'utilisaient pas. En expliquant justement ce qui fait la particularité de TEI et les nouvelles possibilités de P5, je voudrais montrer en quoi elle constitue aujourd'hui une bonne solution et répondre ainsi à la question qu'on me pose souvent : pourquoi devrais-je choisir la TEI ?

La TEI : guide, schéma, DTD ou usine à gaz ?

Le but de la TEI n'est absolument pas hégémonique, le consortium, qui en a la charge depuis 1987, composé de chercheurs et de bibliothécaires du monde entier ne gagne rien si le nombre d'utilisateurs augmente. Son but est plutôt d'offrir des solutions efficaces pour répondre aux besoins d'encodage de l'information en vue de son exploitation bien-sûr, mais surtout en vue de son échange et de son partage. Je ne vais pas expliquer les avantages d'un standard dans ce cas, il me semble que vous en êtes tous conscients.

Dans mon premier billet sur la TEI, j'ai expliqué en quoi elle ne constituait pas une DTD en tant que tel, mais un framework. C'est plus que jamais le cas avec cette nouvelle version. Le processus de mise en place de la TEI n'y est pas étranger. Le schéma XML (quelque soit le format utilisé pour le décrire : DTD, XML schema ou RelaxNG) n'est qu'une conséquence du guide proposé par le consortium qui s'attache à définir, repérer et donc normaliser les différentes informations sur lesquelles se rejoint une communauté suffisamment importante d'utilisateurs. Vu les problématiques concernées par la TEI, il n'est pas étonnant de se retrouver avec plus de 450 éléments et c'est là que le bat blesse.

Le problème se pose alors aussi bien pour les concepteurs de la TEI que pour les utilisateurs : comment maintenir une telle librairie de plus de 400 éléments ? Comment apprendre et s'approprier la TEI ? Est-ce-que la TEI n'est pas une énorme usine à gaz ? Même avec ces 450 éléments, la TEI ne comprend pas la balise que je cherche, j'en veux pas.... Bref, il est évident que nous sommes face à un outil puissant, assez complet, mais difficile à prendre en main, fruit de compromis entre différentes personnes dans une communauté et même différentes communautés. Heureusement, le consortium TEI a pris les choses en main, en inventant un format pour décrire sa propre grammaire issue de la TEI appelé ODD (One document does it all) et l'outil pour générer une DTD; un XML schema et/ou un schéma RelaxNG à partir de ce fichier : Roma. Avec ces deux outils, la TEI mérite plus que jamais son appellation de framework.

Vous avez dit bizarre1, non j'ai dit 'ODD'

Dans la précédente version, la TEI proposait le modèle de la pizza pour construire une DTD issue de TEI. Le modèle s'appuyait sur le classement des différents éléments de la TEI en trois groupes : un module-noyau (« core tagset »), différents modules de base (« base tagset ») et différents modules additionnels (« additional tagset »), répondant à des besoins particuliers comme l'encodage de transcriptions de corpus oraux, l'encodage de dictionnaires ou encore d'apparat critique pour ne donner que quelques exemples1. Dans ce modèle, il était possible de retenir un ou plusieurs modules en plus du core et d'un module de base. Par ailleurs, une DTD dite TEILite rassemblant tous les éléments de base pour encoder un texte était mise à la disposition des utilisateurs. Dans ce modèle, ce n'était donc pas les ingrédients de la pizza que vous choisissiez, mais les ingrédients des différentes parts.

La nouvelle version abandonne le système de la pizza, mais conserve les systèmes de modules, en y ajoutant en plus la notion de classes d'éléments. Ces classes renvoient au comportement de l'élément dans votre grammaire : où je peux placer mon élément ? quels attributs sont disponibles pour cet élément ? Un élément peut appartenir à une ou plusieurs classes. Grâce au format ODD qui est en fait un fichier XML utilisant une grammaire dérivée de la TEI, vous allez alors pouvoir choisir les modules que vous voulez utiliser, mais en plus vous allez pouvoir :

changer le nom d'un élément (le traduire en français par exemple, personnellement je suis contre cette pratique, mais chacun fait comme il veut) ;
supprimer les éléments qui ne vous intéressent pas ;
changer le comportement d'un élément, c'est à dire le changer de classes ;
Ajouter un attribut et le rattacher à une classe ;
ajouter un nouvel élément en le reliant à une classe, un module et/ou même un élément ;
contraindre la valeur d'un attributs ou d'un élément.

Bref, vous allez construire votre grammaire XML adaptée à vos besoins, en vous appuyant sur la TEI, et tous les changements par rapport à la « TEI canonique », c'est à dire les éléments et les attributs, leurs noms, leurs comportements et leurs sémantiques décrits dans le guide, seront indiqués dans ce fichier ODD. Cerise sur le gâteau, ODD vous permet aussi de fournir la sémantique de chaque élément de votre grammaire à partir duquel vous pouvez générer une documentation complète. Pour les hard-coders, il est possible d'écrire directement son fichier ODD en XML, la documentation est disponible, mais je vous rassure, il est possible de le faire avec Roma, une interface en ligne user-friendly (il reste encore des améliorations à apporter, mais c'est de mieux en mieux) qui vous permettra aussi de générer à partir d'un fichier ODD ou de votre « customisation en ligne » un schéma dans votre syntaxe préféré : DTD, XML schema ou RelaxNG. Évidemment, RelaxNG offre plus de possibilités de contraintes, en particulier sur les valeurs.

Quid de l'interopérabilité avec ODD ?

Mais, j'entends déjà la question qui vous taraude : « c'est bien joli, c'est très souple, mais quid de l'interopérabilité ? ». Question légitime, que je me suis d'ailleurs posé. En fait, cette question se situe à trois niveaux. Au niveau d'une communauté précise d'utilisateurs partageant le même type de textes et les mêmes besoins, ODD va permettre de fixer le schéma de façon encore plus précise, répondant à des besoins spécifiques et surtout de le documenter.

Plaçons-nous maintenant au niveau de la communauté des utilisateurs de TEI, dans ce cas, il faut en revenir à la TEI telle qu'elle est décrite dans le guide. Or, le fichier ODD comprend toutes les spécifications de votre grammaire et les modifications par rapport à la « TEI canonique ». Ainsi, si vous avez ajouté un élément, vous l'aurez rattaché à un des éléments génériques de la TEI et il sera même possible de faire référence à une règle de transformation dans un fichier XSL cité dans le fichier ODD. Bref, dans ce cas, tout est la disposition pour migrer le fichier encodé selon cette grammaire vers un fichier « canoniquement valide » avec la TEI qui devient un format pivot d'échanges permettant la mise en place d'outils qu'on pourra partager. Enfin, même si certains éléments ont été changés, il existe quand même de grandes chances que les éléments décrivant la structure globale (les éléments de macro-structures) soit toujours les mêmes. Dans ce cas, l'interopérabilité n'est pas garantie à 100%, mais vous pourrez au moins travailler sur la structure générale du texte encodé.

Avec la mise en place de ODD et de Roma, la TEI se révèle encore plus proche des besoins des utilisateurs et se positionne comme une solution incontournable pour l'encodage de textes. Elle fait montre d'une maturité dont peu de schémas XML peuvent se vanter. Avec le précédent billet sur l'encodage, j'espère que vous êtes maintenant « armés » pour faire vos choix.

Quelques ressources pour finir

Si vous voulez en savoir plus sur ODD, quelques ressources (en anglais exclusivement) :

Lou Burnard, One document does it all, diaporama sur ODD
Lou Burnard et Sebastian Rahtz, Relax NG with son of ODD, Extreme Markup Languages 2004, Montréal, Québec, 2-6 août 2004.
Syd Bauman et Julia Flanders, Odd customizations, idem.
Laurent Romary, Uncovering the TEI and ODD, a pedagogical strip-tease, diaporama ppt.

Quelques notes en passant

1 Pour mes lecteurs non anglophones, ODD est l'acronyme de Document does it all dans le cadre de la TEI mais le mot signifie aussi bizarre en anglais.

1 Si vous voulez en savoir plus, cf le billet cité plus haut : la modularité de la TEI.

Qu΄est-ce-qu΄on encode ?

got — Wed, 13 Sep 2006 23:01:40 +0200

Lorsqu'on encode un fichier en XML, bien souvent, on ne prend pas le temps, avant de se lancer à proprement parler dans le codage, de réfléchir à une question simple, mais pourtant essentielle : qu'est-ce-qu'on veut encoder ? Cette question a l'air anodine, mais la réponse peut faire varier de façon très importante la structure du fichier et le choix des balises. Je voudrais essayer de montrer avec ce billet l'impact de cette question dans les stratégies d'encodage.

Avant de continuer et après tous ces semaines à parler de RDF, il est peut-être utile de rappeler que le XML, dans son utilisation première, est un langage à balises permettant de caractériser une portion d'informations à l'intérieur d'un document. A l'inverse de RDF, dont le but est de décrire l'information en elle-même, c'est à dire son sens, XML permet de décrire la structure de l'information dans le contexte d'un document précis. Ainsi, une même portion d'informations peut être encodée de différentes façons dans deux cas différents avec la même grammaire XML, alors qu'elle a le même sens. A travers cette définition et les billets précédents sur RDF, j'espère que la différence apparaît mieux.

L'extensibilité de XML est infinie, il est possible d'encoder chaque mot voire chaque lettre si vous le souhaitez. Évidemment, si vous utilisez une grammaire XML, vos possibilités seront restreintes par celle-ci. Mais, certaines grammaires comme la TEI1 ouvrent ces possibilités.

Lorsque je suis en face d'un nouveau texte à encoder, je me pose toujours la même question : quelles informations sont utiles à encoder ? L'encodage représentant un travail fastidieux, il est inutile de surcharger le choix de balises ce qui complique souvent inutilement le fichier XML. Deux critères me permettent de faire mes choix :

Pour quels informations l'auteur ou l'éditeur veut-il voir une mise en avant dans le résultat final mis en page que ce soit en papier ou avec un navigateur Web ? Pourquoi ces informations-là ? (exemple : un titre d'ouvrages ou un mot étranger sont habituellement mis en avant pour faire apparaître leurs particularités, on va le rendre graphiquement en italique)
Quels informations veulent-ils ensuite utiliser pour dresser des listes, des index ou mettre en place des interrogations ?

La plupart du temps, ces deux critères/questions me permettent de résoudre 95% des choix de balises pour les portions informations à encoder à l'intérieur d'un paragraphe, ce qu'on appellerait les micro-structures. Ces questions se limitent bien souvent à dresser un rapport entre le temps d'encodage et les possibilités d'exploitation souhaitées de cet encodage.

Pour autant, ces deux questions ne résolvent pas le problème de la structure générale du fichier, ce qu'on pourrait appeler les macro-structures. Dans ce cas, la question essentielle est : qu'est-ce-qu'on encode ? accompagnés d'une série de questions : quelle est la nature du document encodée ? Quel est le but poursuivi par l'encodage de ce document en XML ? Quel stratégie d'encodage je vais adopter ? Pour bien comprendre les enjeux de cette question, je vous propose deux exemples, un avec HTML et l'autre avec TEI.

Pendant des années, nous avons utilisé les tableaux HTML pour construire nos pages Web. Si on y réfléchit bien, ce principe, qui était dû à une mauvaise compréhension et prise en charge de CSS par les différents outils (éditeurs ou navigateurs), mais aussi à l'utilisation abusive de mauvais éditeurs WYSIWYG, revenait en réalité à encoder le graphisme et non la structure de la page Web en HTML. Dans ce cas, on ne se posait pas la question (d'ailleurs on ne se posait aucune question), le rendu final à l'écran constituait le but unique poursuivi.

Aujourd'hui, heureusement, les choses ont changé et on applique assez scrupuleusement la séparation de la mise en forme et du contenu, paradigme au cœur de XML. La structure du code HTML reflète (ou du moins est censé refléter) la structure d'une page Web. D'ailleurs, on pourrait tout à fait mettre en lumière un modèle pour toutes les pages Web, puisqu'elles sont en gros constituées de trois parties/divisions :

Un « cartouche » contenant les informations sur la page : nom du site, titre de la page..., bref, en quelque sorte les métadonnées, même si elles sont visibles ;
Un ou des menus de navigation qui sont en fait des listes de liens ;
Le contenu proprement dit de la page Web.

La construction du code source d'une page Web en HTML impose donc cette réflexion de base sur les stratégies d'encodage. Elle aurait d'ailleurs peut-être permis une prise de conscience plus tôt de ce qui apparaît aujourd'hui comme une évidence, à savoir l'utilisation de CSS pour le graphisme et la mise en forme de la page Web.

Cette question sur le but poursuivi par l'encodage se pose de façon encore plus criante dans l'utilisation de la TEI. Comprenant pas moins de 450 éléments, la TEI est, en outre, très générique. Il est donc possible d'encoder un même document de plusieurs manières différentes. Dans le cadre de mon travail à l'École des chartes, nous sommes amenés à encoder des textes de nature différente en TEI. Il serait pour nous inconcevables d'utiliser la même structure TEI pour encoder un inventaire de manuscrits, l'édition d'un manuscrit littéraire ou encore l'édition d'un chartrier (ensembles des actes, c'est à dire pour faire vite des papiers administratifs, d'une institution laïque ou ecclésiastique au Moyen Âge et à l'époque moderne).

D'ailleurs, revenons quelques instants sur les sources historiques. Dans ce cas, certains nous reprochent de ne pas assez travailler sur la source en elle-même. Mais, notre but n'est pas d'encoder la source, mais l'édition critique de la source qu'a mis au point le chercheur. Cela signifie que la structure du fichier TEI ne reflète pas la structure de la source ce qui dans nombreux cas est d'ailleurs pratiquement impossible à faire, mais la structure d'une édition de sources, c'est à dire non seulement le texte de la source transcrit, mais aussi ce qu'on appelle l'apparat critique : analyse du chercheur, notes de bas de page, collations (le fait d'indiquer les différences entre les copies manuscrites d'un même texte)... C'est pourquoi, je ne fais pas un fichier TEI par acte, c'est à dire par source, mais un fichier TEI pour l'ensemble de l'édition d'un chartrier, car cela correspond à un ensemble documentaire logique et au but poursuivi par l'encodage (et par la publication, d'ailleurs).

Alors, la prochaine fois que vous avez un problème pour encoder votre document XML, faire votre choix de balises en TEI par exemple, arrêtez-vous quelques instants, levez le nez de votre machine et demandez-vous : « Mais au fait qu'est-ce-que je suis en train d'encoder ? ». La réponse devrait vous mettre sur la voie.

Quelques notes en passant

1 Pour ceux qui ne suivent pas ou qui sont de nouveaux lecteurs de ce blog, la TEI, Text encoding initiative, est un guide de balisage mis au point par un consortium indépendant et servant à encoder en XML les textes issues de la recherche en sciences humaines ou à vocation littéraire. Si vous voulez en savoir plus, le mot-clef/tag TEI sur ce blog devrait vous renseigner.