Cronaca di una codifica: scelte informatiche e scelte testuali nella rappresentazione XML-TEI della prosa medievale documentaria

L’articolazione della struttura logica del testo, nel punto in cui il livello logico si sovrappone fondendosi senza soluzione di continuità con il livello strutturale formale, il punto cioè in cui tendono a confluire forma e semantica, questa articolazione nel campo della prosa ha fatto emergere con più prepotenza rispetto a quella in versi il parziale gap esistente fra la matrice librario-tipografica della terminologia TEI e alcuni aspetti della mise en page manoscritta medievale.

Se da un lato l’utilizzo del tag <p> (paragraph) si imponeva come un obbligo per il fatto di rappresentare una sorta di marca distintiva della scrittura in prosa in opposizione al tag <l> per la scrittura in versi, cosa definire paragrafo nella realtà testuale medievale è stato invece abbastanza problematico, così come l’assenza di una nomenclatura standardizzata (e quindi ufficiale e condivisa) per quel che riguarda gli attributi relativi ai vari livelli di articolazione del testo, assenza che conduce inevitabilmente a proposte personali.

Poniamo a confronto i due mondi:

Nel primo caso possiamo individuare con facilità:

un contenitore capitolo, che dovremo identificare con un generico tag <div>, al quale a mio avviso dovrebbe essere d’obbligo associare almeno un attributo @type, un @xml:id e, consigliato, un @n, al fine di rendere ogni oggetto identificabile e quindi ricercabile e manipolabile. Considero quindi auspicabile un markup di questo tipo:

<div type=chapter xml:id=CHIPs1ch1 n=I>

(la forma dell’xml:id è ovviamente a scelta di ognuno, ma non sarebbero superflue anche in questo caso regole condivise per la sua costruzione. Nella formulazione che si propone, l’xml:id va letto come: CHIP [Comédie Humaine Illusions Perdues] s1 [section 1] ch1 [chapter 1])

Il contenitore-capitolo (mi chiedo se non sia auspicabile un tag specifico, che rappresenterebbe per la prosa il pendant logico di quel che il tandem <ls><l> rappresenta per la scrittura in versi) contiene i contenitori-paragrafo <p>, tipograficamente identificabili grazie a una serie di espedienti grafici: uno, fisso e universale, alla fine, cioè un a capo; e molteplici, variabili e contestuali, all’inizio, cioè rientri, forme specifiche delle lettere, ecc.

Il contenitore-paragrafo a sua volta contiene i contenitori-frasi <s>, delimitati nella mise en page tipografica da una lettera maiuscola all’inizio e da un segno di punteggiatura forte alla fine, o in modo più complesso, dalla presenza di segni di punteggiatura di media forza come ; e :.

Il contenitore-frase infine (un infine relativo dal momento che in realtà è possibile scendere sotto il livello della parola per arrivare al carattere, <c>) contiene le parole che compongono il testo, <w>.

               Capitolo
                    Paragrafo
                         Frase
                              Parola

In senso inverso, salendo al di sopra del capitolo, potremmo trovare altri contenitori possibili, variamente (dal punto di vista terminologico) identificabili: libro, parte, sezione ecc. Una matrioska di <div> (auspicabilmente contrassegnati da un @type) fino al macrocontenitore coincidente con l’opera stessa.

Se ora passiamo alle carte manoscritte, è evidente come le regole del gioco appena descritte risultino in alcuni casi inadeguate. In particolare, risulta molto forzata proprio la nozione di paragrafo, che pone un problema di base: cosa è identificabile in questa pagina come paragrafo? E come capitolo? E titolo? E frase?

La prima idea è stata quella di svincolarsi totalmente dalla terminologia/tags abitualmente associati alla prosa in una codifica TEI e proporre un’articolazione della logica del testo tutta basata sul tag <div>, opportunamente caratterizzato di volta in volta tramite il @type. Soluzione che, di fondo, non faceva che spostare il problema, dal momento che era poi necessario elaborare una nomenclatura specifica per i valori del @type: sotto l’apparenza di una scelta più anodina si faceva semplicemente basculare il problema dal nome dei tags al valore degli attributi.
Considerati quindi pro e contro, per una questione di omogeneità con le pratiche correnti, e anche per una questione ‘simbolica’, si è deciso in seconda battuta di recuperare i tags più tipici, che connotano quasi potremmo dire ‘esteticamente’ un file XML-TEI. L’elaborazione del modello è partita dal caso concreto su cui si stava lavorando, il ms. Grenoble 861, uno dei tre manoscritti latori del testo del Roman de Troie en Prose 2, e se ne è poi verificata la tenuta dapprima sugli altri due manoscritti testimoni di Prose 2, ms. Paris n.a.f. 9603 e ms. Oxford Douce 196, e successivamente su altri manoscritti in prosa. Pur nelle varianti, il sistema sembra aver tenuto.

Per prima cosa si è quindi identificato come contenitore mediano o centrale del testo (dei livelli superiori si parlerà in conclusione), visivamente ben definito, il blocco rappresentato da una rubrica e dal testo che la segue, testo che normalmente inizia con una lettera messa in evidenza attraverso qualche espediente grafico, generalmente un’iniziale filigranata. Si possono avere casi in cui la rubrica è assente, e sarà allora la sola iniziale a funzionare da identificatore del contenitore.

A questo blocco, identificato da un <div>, in mancanza di meglio per ora (si tratta di scelte terminologiche che richiederebbero discussioni condivise e non certo iniziative personali), si è attribuita la definizione di capitolo: @type=chapter. La rubrica è stata invece codificata attraverso un <head> @type=rubric. E si è infine attribuito, con un po’ di arbitriaretà e forse anacronismo (non celati né negati) come per il capitolo, la definizione paragrafo e il tag <p> alla porzione di testo identificata da una iniziale. Di fatto, nella maggior parte dei casi capitolo e paragrafo collasseranno l’uno sull’altro ma non si escludono casi in cui sotto una stessa rubrica saranno presenti potenzialmente più ‘paragrafi’.

Questa quindi la struttura portante proposta:


          <div type=chapter>
               <head type=rubric>
               <p>

Ad alimentare però dubbi più spinosi ci hanno pensato le strutture al di sotto del blocco testuale appena identificato, strutture che fuoriescono dalla questione articolazione logica dell’opera per ricadere in quella articolazione sintattica del testo. Il blocco definito come paragrafo è infatti spesso ritmato da maiuscole più o meno, o per nulla, decorate, a cui comunque, per il loro ruolo, ho deciso di attribuire il tag <hi>, come per le altre iniziali, con il valore dell’attributo @type="init-sec" per secondary initial. Normalmente, a questa iniziale fa da pendant di chiusura un punctus, ma non mancano anche casi in cui si ha la sola iniziale o il solo punctus. Al di là delle varianti, sembra comunque possibile generalizzare l’esistenza, al di sotto del blocco sopra individuato, di una segmentazione testuale di secondo livello delimitata da molteplici combinazioni possibili di iniziali e punctus, e dotata di compiutezza di senso e autonomia. Quanto alla sua definizione, ci si tornerà fra poco.

Tale segmentazione a sua volta può diventare contenitore di un’altra tipologia di segmento, sempre delimitata da un punctus ma non marcata da un’iniziale, e abbastanza corrispondente a quella che in senso moderno potremmo definire frase o inciso. Quel che può succedere, assumendo come struttura di riferimento questa tripartizione di livelli, è che i due contenitori appena citati in molti casi collassino l’uno sull’altro, cioè coincidano, così come avviene per il capitolo/paragrafo. Un po’ di ridondanza è il prezzo da pagare nel momento in cui si cerca un modello che possa essere generalizzato: se in alcuni casi c’è coincidenza fra i due livelli, in altri i due contenitori sono invece ben distinti e distinguibili. Questi segmenti rappresentano l’ultimo livello nell’articolazione del blocco testuale e, sempre con la consapevolezza di un minimo di anacronismo, si è attribuito loro il tag <s> sentence, benché talvolta, raramente a dire il vero, non contengano alcun verbo e talvolta separino i membri di un elenco, con un uso del punctus che assomiglia di più a quello della virgula suspensiva. Ma, lo si ribadisce ancora una volta, nel momento in cui si cerca un modello da generalizzare, ci si vede sempre costretti a ragionare in media e a passare sopra a qualche imprecisione.

In media la strutturazione proposta sta reggendo alla prova. È ovvio però che la definizione sentence vada intesa in senso contestuale con riferimento all’articolazione del testo manoscritto, e non in senso moderno. D’altronde, non era possibile applicare il tag <s> al contenitore superiore, intermediario fra quello che è stato definito paragrafo e questa unità minima individuata, dal momento che in quel caso la stonatura sarebbe stata anche maggiore, dato che questo contenitore di norma eccede quel che è definibile come frase. Parimenti, sempre per un problema di taglia ma in senso inverso, il contenitore intermedio mal si sarebbe adattato alla nozione di paragrafo, rispetto al quale risulta troppo limitato. In mancanza di una terminologia condivisa e ufficiale per la descrizione dell’articolazione del testo manoscritto medievale, e per non abusare in modo personale della terminologia retorica composta da membrum, colon, comma etc., si è quindi, un po’ banalmente forse, codificato questo contenitore intermedio con un @type="sub-par" per sub-paragraph.

La struttura finale adottata dall’attuale codifica di Prose 2 è dunque la seguente:


     <div type="chapter">
          <head type="rubric">
               <s>
                         <w>
                         <w> ...
               <s> ...
          <p>
               <seg type="sub-par">
                    <s>
                         <w>
                         <w> ...
                    <s>
                         <w>
                         <w> ...
               <seg type="sub-par"> ...

Come si è detto, e non si è negato, attribuzione di tags e terminologia adottata possono essere discutibili per via di alcune forzature che nascono dallo scontro fra la realtà manoscritta e l’origine tipografica della TEI. In alternativa, tutto il sistema potrebbe essere concepito ricorrendo a un sistema omogeneo di <div>, tag generico e non mentalmente connotato, ciascuno caratterizzato da un valore dell’attributo @type consono alla realtà manoscritta. Ma fissare gli elementi di questa nomenclatura richiede discussione e condivisione, e al di là dell’omogeneità apparente, allo stato attuale, sarebbe stata una scelta che non faceva altro che spostare il problema di fondo: quale nome attribuire ai vari contenitori testuali della pagina manoscritta? E, ancor prima, come individuare i contenitori-articolatori del testo medievale?

*This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Sklodowska-Curie grant agreement No 886478

LaTex2TEI : de LaTex à XML-TEI en quelques clics

Récemment, la capacité de médiation du logiciel TEI-Med.it (conçu pour l’automatisation de la production des fichiers TEI-XML à partir d’un fichier .txt) a été mise à l’épreuve dans le contexte d’une conversion de LaTex à TEI-XML : le résultat, très satisfaisant (peut-être parce que l’encodage LaTex n’était pas très complexe!), est une nouvelle version du logiciel que j’appellerai LaTex2TEI (LaTex to TEI). Le contexte de cette expérience d’adaptation était le projet Ausiàs March (Edición sinóptica de las poesías de Ausiàs March a partir de todos los testimonios manuscritos e impresos en su contexto literario) http://www.cervantesvirtual.com/portales/ausias_march/ de l’Universitat d’Alacant. Ce projet, financé par le Ministerio de Economía y Competitividad del Gobierno de España, a vu la numérisation de l’œuvre du poète sous le format LaTex ; aujourd’hui, la nécessité s’impose de faire migrer ces centaines de fichier de LaTex à TEI-XML.

Le passage à TEI signifie évidemment un enrichissement de l’encodage textuel, le glissement des préoccupations typographiques aux préoccupations sémantiques. Le changement radical dans l’encodage des abréviations est emblématique :

ce qui en LaTex est une simple question d’italique
p\textit{er}
en TEI-XML deviendra une question de signes abréviatifs et d’expansions
<choice>
<abbr>p</abbr>
<expan>per</expan>
</choice>

Le passage de LaTex à TEI nous oblige dans certains cas à une contextualisation de la donnée afin de récupérer tous les éléments que l’encodage LaTex a sous-entendu : dans ce cas, il faut interpréter dans son contexte la valeur du tag \textit{$} qui, à travers l’indication de l’italique, signale la présence d’une abréviation; et dans le contexte de l’abréviation, il faut interpréter ultérieurement la donnée LaTex pour en déduire que le tag \textit{$} marque les lettres restituées. Je parle de nécessité de contextualisation parce que le même tag \textit{$} est utiliser ailleurs pour indiquer toute autre chose, par ex. un mot en évidence nécessitant également d’une représentation typographique en italique.

Il est évident que le niveau différent de détail entre les deux systèmes oblige forcément à une intervention humaine à la main afin d’intégrer ou corriger l’encodage TEI-XML obtenu. Mais, naturellement, l’aspiration était celle de réduire au minimum cette intervention, aussi bien pour des raisons très pragmatiques (il y ont des centaines de fichiers à convertir) que pour des raisons de qualité du travail (réduire l’intervention humaine signifie réduire la possibilité d’erreur).

J’ai donc pensé d’appliquer aux fichiers LaTex le même principe d’équivalence qui est à la base du fonctionnement de TEI-Med.it : au lieu de l’équivalence entre ASCII/Entities et tags TEI-XML, ici l’équivalence est entre tags LaTex et tags TEI-XML. En plus de ces équivalences automatiques (qui ne sont pas toujours possibles), le logiciels LaTex2TEI : 1. encapsule le vers dans la balise <l>, 2. engendre les attributs @n e @xml:id, et 3., c’est une option, encode les deux hémistiches avec la balise <seg>. Voici quelques exemples du tableau de conversion :

\begin{estrofa} = <lg type="cobla" n="$" xml:id="$">
\end{estrofa} = </lg>
\numero{$} = <l n="$" xml:id="$"> </l>
/ = <seg type="hemistiquio" xml:id="$"> </seg>
[pag] = <pb n="$" facs="$"/>
\textsc{$} = <c rend="large">$</c>
\interlin{$} = <add place="interlinear">$</add>
\tatxat{$} = <del rend="barred">$</del>

Le point plus critique a été l’automatisation de la conversion des abréviations. Le seul élément qui me permettait d’identifier l’abréviation dans l’encodage LaTex proposé était la présence du tag \textit{$}. Le principe pour l’automatisation a été donc : tous les mots qui contiennent le tag \textit{$}, par ex. p\textit{ar}abla, seront encapsulés dans cette structure TEI-XML :

<choice>
<abbr>p’’abla</abbr>
<expan>parabla>;/expan>
</choice>

Le contenu du tag \textit{$} est ignoré en <abbr> et inséré en <expan>, d’où la nécessité d’une intervention humaine après la conversion en TEI-XML pour introduire le signe abréviatif. Avec un peu plus de travail on pourrait arriver à automatiser aussi ce passage.

La plupart du travail manuel à faire est au niveau du file .tex, où l’on doit tout simplement effacer certaines parties et modifier de petits détails : cela signifie travailler avec un format beaucoup plus simple à manipuler que le code XML. Voici un exemple; le symbole ///// signifie effacer :


///// \documentclass[12pt]{article}

///// % --------------------------------------------------------

///// \input{../preamble}

///// \renewcommand{\espaiAbansEtiquetaPoema}{\vspace{0ex}}
///// \renewcommand{\espaiAbansSeccio}{\vspace{0ex}}

///// % --------------------------------------------------------

\begin{document}

///// \begin{estrofa}

///// \espaiAbansEtiquetaPoema

///// \poema{(b 31) [1]}\\

///// \end{estrofa}


\begin{estrofa}
\numero{1} [25r] Axi com cell / qui'n lo somnis de lita *
\numero{2} he son delit / de foll pensament ve
\numero{3} ne pren ami / quil temps passat, me te
\numero{4} limaginar / qu'altre be, noy habita
\numero{5} sentint venir / l'aguayt de, ma, dolor
\numero{6} sabent de cert / que'n ses mans, he de jaure
\numero{7} temps de venir / en ningun bem, pot caure
\numero{8} \c{c}o que's no res / en mi, es lo millor
\end{estrofa}

///// \begin{estrofa}%Extra
///// \begin{tornada}
///// Tornada.
///// \end{tornada}
///// \end{estrofa}


\begin{estrofa} **
\numero{41} Plena de seny / quant, amor, es molt vella
\numero{42} absen\c{c}a es / lo verme qui, la guasta
\numero{43} si fer metat / durament, no contrasta
\numero{44} he creure poch / sil'enueios, consella
\end{estrofa} ***

\end{document}

* pour le résultat final de l’XML c’est mieux de déplacer l’indication de la page hors du vers ** et *** il faut changer estrofa en tornada.

Une fois ces petites interventions faites, il suffit d’ouvrir le terminal :

latex2tei.py -t -x -s [-g]
latex2tei.py -t nom_fichier.tex -x nom_fichier.xml -s sigle_ID [-g 0/1]

-t : nom du fichier LaTex qui doit subir la conversion
-x : nom du fichier TEI-XML qui sera le produit de la conversion
-s : sigle qui doit précéder le numéro de l’xml:id
Si l’on donne la valeur 1 à -g on aura aussi la division des vers en hémistiches (<seg>).

Voici le résultat (j’exclue le TEI-Header pour des raisons d’espace) dans la forme complète, avec <seg> :

<text>
 <body>
   <div type="poem" xml:id="Adiv1">
     <pb n="49r" facs=""/>
     <lg type="cobla" n="1" xml:id="Alg1">
       <l n="1" xml:id="Al1">
         <seg type="hemistiquio" xml:id="Al1s1">AXicom cell:</seg>
         <seg type="hemistiquio" xml:id="Al1s2">quin lo sompnis delita</seg>
       </l>
       <l n="2" xml:id="Al2">
         <seg type="hemistiquio" xml:id="Al2s1">Del temps;
           <choice>
             <abbr>p˝sent</abbr>
            <expan>present</expan>
          </choice></seg>
         <seg type="hemistiquio" xml:id="Al2s2">nom trobe amador</seg>
       </l>
etc.

Il s’agit pour le moment d’une version très simplifiée du logiciel, qu’on peut définir compacte : le set des tags LaTex est déjà incorporé dans le logiciel. On pourrait avoir naturellement une version plus complexe, au même niveau de la version originale de TEI-Med.it, avec un .csv des tags géré de façon autonome par les utilisateurs sans rien toucher au niveau du logiciel.

Le site DigiFlorimont : une dynamique statique

LA PERSPECTIVE DE LA PORTABILITÉ (divide et impera)

L’architecture du site DigiFlorimont digiflorimont.huma-num.fr repose sur un choix de base, à la fois technique et conceptuel : la séparation claire entre l’espace de gestion des textes encodés (selon le standard TEI-XML) et la superstructure du site qui héberge, entre autres, l’espace de gestion des textes encodés. En d’autres termes, on a identifié trois contextes :

a. le site, avec ses éléments constitutifs (les pages) et ses éléments fonctionnels (le menu pour la sélection des pages);
b. le cadre fonctionnel pour la manipulation des textes (choix des feuillets des manuscrits, des épisodes, outils d’exploration des textes etc.);
c. les textes (représentation HTML des textes encodés en TEI-XML).

Dans la conception de l’architecture DigiFlorimont, le bloc composé par b. et c. a été regardé comme autonome de a. : ce bloc constitue une partie du contexte-site mais une partie indépendante et autonome qui pourrait vivre tranquillement ailleurs; ainsi que le contexte-site ne souffrirait pas de l’absence de cette partie, au moins du point de vue formel. Dans cette architecture les textes représentent des bâtiments-dépendances plutôt que des murs porteurs.

Le projet DigiFlorimont met donc à disposition de la communauté deux produits éditoriaux : l’ensemble du site DigiFlorimont, qui a l’ambition de se présenter comme l’archive pluridisciplinaire d’une tradition littéraire, celle du Roman de Florimont, contenant une multiplicité de données; et la singularité des textes, voire des éditions diplomatiques/interprétatives de chaque manuscrit du Roman de Florimont. Ces éditions sont consultables dans le contexte du site mais elles en sont indépendantes : chaque texte peut être téléchargé localement sans besoin de télécharger l’ensemble du site, chaque texte peut être cité directement à travers un lien et incorporé dans un autre site comme une simple page HTML.

Par ex., à travers le lien digiflorimont.huma-num.fr/flsite/txtpar.html l’utilisateur a accès direct à l’édition du ms. G

à travers le lien digiflorimont.huma-num.fr/flsite/flsyn.html on peut renvoyer directement à la visualisation synoptique des éditions

En d’autre termes, le projet DigiFlorimont veut mettre à disposition un Site mais aussi, et peut-être surtout, des Textes; et il veut interpréter le Réseau comme un canal de transmission des données plutôt qu’une vitrine de consultation avec beaucoup de limites : la condition numérique des textes ne doit pas impliquer forcément que leur consultation soit “condamnée” à se réaliser exclusivement dans la dimension espace-temps soutenue par une connexion Internet.

LE CHOIX DE LA STABILITÉ (monumentum aere perennius

Le site DigiFlorimont a été développé à travers une architecture totalement statique. Aujourd’hui cette technologie est souvent regardée comme obsolète, et elle semble complètement dépassée par l’emploi généralisé des CSM dynamiques (content management system ou système de gestion de contenu). La clé du fonctionnement d’un site développé à travers un CSM est la création de la page HTML “à la demande” : à chaque fois qu’une page est “sollicitée” par un utilisateur (phase request) côté browser, elle est crée ex novo côté server, en récupérant le contenu d’une base de données et en l’exécutant à travers un moteur de template, et elle est renvoyée au browser (phase response); chaque page est donc assemblée à partir des modèles et des contenus pour chaque demande adressée au server.

Pour la plupart des sites, il s’agit d’un overhead (surcharge) totalement inutile qui ne fait qu’augmenter la complexité du processus tout en engendrant des problèmes de performances e de dépendance à l’égard du CMS et des softwares utilisés, avec, par conséquent, un impact négatif sur la portabilité.

En réalité, la plupart des sites dont la finalité est une publication ne changent que lorsque leurs auteurs modifient ou ajoutent du contenu. Cette considération, évidemment, ne s’applique pas aux sites qui permettent des interactions avec les utilisateurs, par ex. les sites d’e-commerce (de commerce en ligne) ou les social (réseaux sociaux). La diffusion massive de ces derniers, accompagnée par la disponibilité croissant de tools (outils) pour la publication (apparemment) user-friendly comme WordPress, a probablement conditionné le choix d’une architecture dynamique même lorsqu’elle n’est pas seulement inutile mais désavantageuse pour la typologie de site en question.

Un site statique rend les pages disponibles immédiatement à chaque requête sans qu’il soit nécessaire de les créer à chaque fois du côté du server; en d’autres termes, aucun composant du site n’est généré exprès au moment de la request, tous composants “existent” déjà, et persistent. Par conséquent le caching (mise en antémémoire) est beaucoup plus efficace et les réponses sont immédiates. Mais à côté de ces considérations relatives à l’efficacité du système, il ne faut pas oublier qu’un site statique est surtout un site beaucoup plus sûr : d’un site statique on peut faire très facilement une copie off-line (hors ligne), et cette copie peut être transférée, toujours très facilement, sur un ordinateur ou sur un support externe (CD ou clé USB). Cette portabilité qui n’altère nullement l’architecture de la ressource numérique nous offre les meilleures garanties pour la conservation des textes et en même temps elle permet une consultation hors-ligne, une condition qui, malgré la diffusion désormais capillaire du Réseau, peut se révéler très utile dans certains cas.

En bref : les sites statiques sont des sites dont les pages ne subissent pas de changements, ni d’apparence ni de contenu, en fonction de déterminés facteurs; autrement dit, les pages d’un site statique apparaissent toujours les mêmes jusqu’au moment où, éventuellement, le webmaster apporte une modification.

Cette typologie de site, nettement majoritaire dans la première phase évolutive du Réseau, a été successivement dépassée par les architectures dynamiques, suite à l’avènement des CMS modernes qui ont énormément accru le nombre de techniciens capables de mettre en place un site dynamique.

Un préjugé répandu parmi les non-experts est de considérer les sites statiques comme des sites où chaque élément est forcément immobile, voire condamné à la stase. La réalité est bien différente : les animations, les effets spéciaux et tous les dispositifs graphiques qui confèrent à la page web une illusion de vie ou une allure vivante sont réalisables dans les sites statiques dans la même mesure, voire plus, que dans les sites dynamiques, grâce aux ressources logicielles (HTML, CSS, Javascript) mises à disposition par les browsers modernes; paradoxalement, en fait, la structure “fermée” de nombreux sites dynamiques nous empêche souvent d’exprimer notre créativité avec la même liberté que les sites statiques. Et tout cela sans sacrifier la standardisation et donc la portabilité : le logiciel utilisé côté client, contrairement à celui utilisé côté server, doit en fait garantir la compatibilité à la fois avec tous les navigateurs existants ET avec tout ce qui a été produit dans le passé. Toutefois, cette compatibilité universelle et pérenne n’est pas du tout garantie par les choix des producteurs des browsers, lesquels, au contraire, auraient plutôt la tendance à introduire des fonctionnalités propriétaires, poussés par une logique monopolistique et par un esprit de clocher dont ils ont fait preuve dans le passé; le véritable garant (et beaucoup plus efficace, compte tenu de la puissance inégalable des implications économiques) est la pression du marché : seul le marché exige impérativement la visibilité des sites dans le temps et sur toutes les plateformes (les éditions de textes médiévaux peuvent tranquillement disparaître sans secouer le marché).

Dans cette lutte entre deux tendances opposées, particularisme et universalisme, on a heureusement à disposition des règles et des outils permettant de contourner les tentatives menées, malgré tout, par certains producteurs d’introduire des éléments propriétaires, à leur avantage.

Un site statique bien conçu est, et doit être, cross-browser : cela signifie que son apparence et son fonctionnement ne changent pas d’un navigateur à l’autre.

Pour résumer. Les avantages d’un site statique sont les suivants :

1. Indépendance de la plate-forme d’hosting (d’hébergement);
2. Augmentation de la rapidité de réponse du site;
3. Meilleur classement dans les recherches Google;
4. Plus de sécurité par rapport à la conservation des contenus;
5. Possibilité de consultation off-line (hors ligne);
6. Indépendance par rapport aux technologies propriétaires;
7. Indépendance par rapport aux tools (outils) de développement et de publication;
8. Facilité de mise à jour;
9. Séparation entre les données et leur représentation graphique;
10. Utilisation d’outils élémentaires;
11. Possibilité d’impression des textes en PDF.

Les sites statiques présentent bien sûr des inconvénients : l’architecture statique, on l’a déjà dit, est totalement inappropriée dans le contexte où une interaction avec les utilisateurs est nécessaire, comme dans le cas du commerce en ligne ou dans les forums. Mais là il s’agit de cas très particuliers. En réalité, le problème majeur (et général) est la nécessité de savoir maîtriser des outils spécifiques, notamment HTML et CSS et, dans certains cas, le langage Javascript. Face à cette difficulté objective (mais non insurmontable), le succès des sites dynamiques comme WordPress réside essentiellement dans la simplicité de l’interface mise à disposition de l’utilisateur. Mais cette apparence user-friendly se révèle au fond une «cage dorée», imposant de nombreuses limitations : il s’agit de limitations acceptables (ou non, ça dépend du caractère de l’auteur) dans le cas de la publication d’un blog personnel, mais sans aucun doute presque insupportables dans le contexte d’une publication complexe.

EN CONCLUSION

Portabilité et pérennisation : voici les deux mots d’ordre du projet DigiFlorimont. Il me semble qu’il s’agit des deux mots d’ordre qui interprètent correctement l’esprit TEI :

Since 1994, the TEI Guidelines have been widely used by libraries, museums, publishers, and individual scholars to present texts for online research, teaching, and preservation

Les textes sont mis à disposition dans le Réseau (avec tous les avantages offerts par ce dernier en termes de discussion et de visualisation) pour être consultés, utilisés mais également archivés, en garantissant factuellement la pérennisation et la fruition collective. La réalisation concrète passe souvent à travers la statique; les désirs peuvent souvent rêver face à la dynamique, mais alors ils se voient aussi obligés de faire face au destin des outils utilisés.

Dans cette optique de online research, teaching, and preservation, il serait souhaitable que l’idée de standard dans le contexte TEI s’étende de l’encodage des données à l’ensemble des outils nécessaires pour la visualisation et l’exploitation de ces données.

Où en sommes-nous avec l’édition numérique? (pas encore au sommet)

En réalisant en première personne un projet d’édition numérique concernant des manuscrits médiévales inédits, j’ai du faire face, « sur le terrain », à une série de difficultés auxquelles j’ai essayé de donner en partie une réponse personnelle en produisant des outils-prototypes (TEI-Med.it, TEI-Med.pub); mais ces questions nécessitent, bien sur, d’une réflexion beaucoup plus ample et qui doit débaucher sur un véritable standard à proposer à la communauté scientifique.

Grace à l’expérience du projet DigiFlor (http://digiflorimont.huma-num.fr), j’ai pu donc constater l’existence d’un GAP: celui entre la complexité et la subtilité de la réflexion théorique (qui dans certains cas manque quand même d’homogénéité) et la nature des outils numériques à disposition. Au lieu de représenter désormais une pratique courante, la réalisation d’une édition numérique à partager sur le Web avec la communauté académique, mais aussi avec le public des étudiants et (à ne pas exclure de la réflexion) des passionnés, se révèle encore une tache lourde à réaliser. Le philologue se confronte à une série de difficultés à chaque étape de son travail, de la conception à la publication des données. Ce gap est d’autant plus regrettable que l’application du numérique se révèle en effet, sous plusieurs points de vue, particulièrement efficace dans le domaine des études linguistiques et littéraires de la textualité médiévale. A l’heure théorique des Big Data et du développement d’une sémantique du Réseau, nous avons besoin de données structurées en quantité exponentielle, et nous avons besoin de les produire de façon aisée. Un standard solide et partagé et des outils efficaces représentent le socle sur lequel cette opération culturelle repose.

Philologie et numérique

S’occuper de textes du Moyen Age en langue vulgaire signifie se confronter à une réalité qui a au moins deux caractéristiques frappantes: une transmission manuscrite et un état de la langue « en formation ». Tout ça signifie: 1) une condition du Texte qui a été bien synthétisée pas les expressions classiques « mouvance » (Zumthor) et « variance » (Cerquiglini), 2) une condition de la langue à laquelle on pourrait appliquer tout court les mêmes expressions ; et par conséquence : 3) la nécessité d’appliquer à ces textes des méthodes d’analyses particulières pour leur reconstruction, celles de la critique textuelle, 4) la nécessité d’interpréter la langue, mais aussi 5) la nécessité même d’interpréter correctement l’écriture physique de ces langues et de ces textes en plus des modalités de travail du copiste et des intervenants successifs.

Jusqu’à la révolution numérique, le format livre avec ses deux contraints: 1) celle du format papier bidimensionnel et statique et 2) celle de la publication à travers une maison d’édition ou une revue, a toujours imposé au philologue/éditeur une série de choix pragmatiques qui n’avaient rien à voir avec des questions méthodologiques. La préférence a été toujours accordée aux éditions critiques, en privilégiant de cette façon l’étape finale du processus philologique et en cachant les matériaux, les manuscrits individuels grâce auxquels le bâtiment de l’édition critique a été édifié. Le format numérique offre en substance la possibilité de porter à la lumière de façon explicite le travail du philologue, en permettant aussi une critique plus consciente et constructive. En plus, il permet de sauvegarder et exploiter des données, celles des manuscrits, qui étaient normalement perdues au nom de la reconstruction textuelle.

Le processus éditorial

Il peut être synthétisé en quatre étapes :
1) Modélisation de l’édition (représentation des phénomènes textuels
à travers un encodage XML-TEI) ;
2) Réalisation des fichiers textuels, encodés et non ;
3) Exploitation des éditions (traitement des données et publication en ligne) ;
4) Pérennisation des données.

Le chercheur qui souhaite démarrer un projet d’édition numérique doit se confronter à deux problèmes :

1)la généralité du standard XML-TEI qui est ouvert sur le phénomène textuel sans distinction ni de langue, ni de genre, ni d’époque. Ce standard dialogue avec tout le monde dans le domaine du Texte mais cette généralité signifie aussi pour l’éditeur, en plus qu’ouverture et liberté, nécessité de créer à chaque fois, de façon autonome, un sous-standard adapté aux exigences de son domaine textuel spécifique. À mon avis, cet espace d’autonomie et d’interprétation personnelle des solutions affaibli et complique l’échange des données ;
2) cette même généralité affecte les instruments à disposition pour la réalisation et la publication des données structurées.

D’un coté, donc, et c’est particulièrement grave, la production des données structurées est un processus lent et lourd parce qu’on utilise des editors qui ont été conçus comme des editors XML tout court, successivement intégrés avec des extensions TEI. Mais, on n’a pas encore conçu des editors expressément adaptés aux exigences de la transcription/édition textuelle. Le résultat est la multiplication des solutions personnelles, liées à l’inventive de chacun mais aussi à ses possibilités techniques (connaissances personnelles ou disponibilité de soutien), et souvent la renonce, par le chercheur, à la réalisation d’un encodage complexe à cause du temps nécessaire à sa réalisation à travers les instruments disponibles.

De l’autre coté, aussi les instruments de publication se présentent à l’enseigne de la généralité, en raison, on explique, d’un désir de flexibilité : un instrument de base pour Tous à adapter par Chacun. Mais, les avantages offerts par la flexibilité risquent d’être annulés par la complexité des opération d’adaptation de l’instrument aux exigences spécifiques du chercheur. Dans la pire des situations, l’humaniste qui ne peut pas compter sur un soutien technique se verra obligé à s’adapter à l’instrument, tout en renonçant à la spécificité de son projet et provocant de cette façon une inversion des rôles intellectuellement inacceptable : au lieu de se mettre au service du chercheur, l’outil numérique s’impose à lui.

Enfin, chaque étape de ce processus est indépendante l’une de l’autre, ce qui signifie obliger l’humaniste à se confronter, à chaque fois, à des problématiques nouvelles qui peuvent même remettre en discussion les résultats de l’étape précédente.

Bref, face à un projet d’édition, le temps de la recherche « effective » risque d’être largement minoritaire par rapport au temps de l’ « organisation » de la recherche.

La perspective?

La nécessité de standardiser et centraliser, après la fleuraison des initiatives individuelles, est désormais évidente, et projet comme Biblissima (http://www.biblissima-condorcet.fr) sont éloquents dans ce sens : il faut désormais rassembler les individus en communautés afin de ne pas gaspiller les énergies, ne pas créer des doublons, et garantir par contre des parcours productifs fluides et partagés. Les plateformes Transkribus (https://transkribus.eu/Transkribus/) et la toute récente TextualCommunities (https://textualcommunities.org) offrent quelques réponses mais pas la réponse globale. Et surtout, encore une fois, elles se présentent comme des outils génériques. Le seul projet qui soulage l’éditeur au niveau de la modélisation, en lui offrant un outil calibré sur un domaine textuel spécifique, est Epidoc (http://www.stoa.org/epidoc/): il s’agit d’un sous-standard TEI expressément conçu pour les textes épigraphiques et devenu désormais essentiel pour quiconque s’approche à l’édition de cette typologie textuelle de l’Antiquité.

Ce qui me semble nécessaire d’offrir désormais à l’éditeur des textes du Moyen Age serait donc une « boîte à outil » qui lui permet de gérer le processus d’édition du début (modélisation) jusqu’à la fin (publication), avec la garantie du soutien d’une communauté spécifique, bien à l’aise avec les questions possibles concernant ces textes, afin que les problèmes techniques ne représentent pas un obstacle à la réalisation de ses recherches et, en dernière analyse, à l’application fructueuse du Numérique aux Humanités. La centralisation des outils et la standardisation du processus rendraient aussi beaucoup plus simple la mise en place de plateformes collaboratives pour la production des données textuelles, facilitant la participation d’étudiants mais aussi de passionnés. L’existence de règles partagées et bien claires permettrait en fait un contrôle plus aisé de la qualité des données produites.

Une bouffée d’oxygène. Editer brisant les engrenages.

LA QUESTION GÉNÉRALE

Mon expérience personnelle d’historienne-philologue du Moyen Âge (donc d’humaniste tout court mais avec une connaissance de base de certains instruments informatiques m’ayant permis de ne pas tomber au départ dans la piège de l’enthousiasme naïf) qui s’est plongée dans l’expérience nouvelle de l’élaboration et du traitement numérique du texte a été marquée au début par un double sentiment, à la fois de satisfaction intellectuelle et de déception. Satisfaction intellectuelle, pour la conscience des possibilités indiscutables offertes par cet instrument “éthéré” en terme de représentation et analyse de cet objet “multifacette” qui est le texte manuscrit médiéval. Déception, à cause de la dyscrasie existante entre les intentions et leur réalisation, de la lourdeur des instruments et des processus. La technologie, voire le Numérique, pour le fait d’être quelques fois mal adapté à un contexte (très) spécifique, risque de devenir un poids mort au col de la pensée, voire des Humanités.
Ce que j’ai trouvé insupportable a été le fait d’être de facto limitée dans mes choix et dans mes perspectives par les caractéristiques des instruments tels que je les repérais “sur le marché”.

À la technologie je demande deux choses:
du point de vue intellectuel, j’espère que son altérité épistémologique, tout en entrant en collision avec mes catégories mentales, m’aide a y réfléchir de façon critique et amplifie la rigueur de ma pensée;
du point de vue pratique, j’exige qu’elle se plie à mes desiderata afin d’atteindre les objectifs que je considère necessaire d’atteindre.

Produire des choses simples, presque banales, avec des instruments très complexes et en gaspillant une quantité excessive de temps (qui en dernière analyse sera du temps “volé” à la réflexion interpretative): voilà, à mon avis, le cauchemar qui risque d’agiter le sommeil d’un humaniste confiant ses espoirs à la couple “clavier-écran”. Le travail sur l’ergonomie du travail est devenu donc, au fil de ces mois et au fur et à mesure que j’avançais dans l’étude de la réalité texto-numérique, le deuxième objectif de mon projet: faire des choses complexes, même très complexes, avec des instruments simples, même très simples; humaniser le numérique plutôt que numériser les humanités.

LA QUESTION PARTICULIÉRE

Démarrer un projet d’édition numérique signifie se confronter essentiellement à trois problèmes:

1. celui de la structuration des données;
2. celui de la production des fichiers textuels structurés selon notre modèle;
3. celui de la manipulation et visualisation de ces fichiers.

Si le premier est domaine de l’intellect (qui doit tenir compte de la structure technique) et le troisième surtout d’une certaine habilité de manipulation des instruments (qui doivent s’adapter aux nécessités du modèle intellectuel), le deuxième est en absolu le règne du digitale: c’est à nos doigts que la tache de la création matérielle est confiée. On parlera successivement du premier et du troisième élément de ce processus. Pour le moment, on va aborder le deuxième problème qui, me semble-t-il, représente un des obstacles les plus évidents par rapport à une production massive d’éditions numériques. Obstacle d’autant plus gênant si l’on considère que le modèle épistémologique susceptible de s’imposer est celui des Big Data. Nous avons donc besoin d’éditions nombreuses et complexes, nous avons besoin de Données.

LES OPINIONS DES AUTRES

Visiter des blogs personnels où “fouiller” la littérature grise – mais, souvent, combien de lumière intellectuelle dans ses méandres! – toujours plus présente dans le Réseau surtout sous forme de publications de diapositives de présentation: voilà un voyage qui souvent nous fait apercevoir de façon plus claire l’existence de doutes, de problèmes, et d’idées encore à l’état embrionnaire mais déjà prometteuses. En bref, on peut regarder à l’espace de la littérature grise comme à une agora de libre échange d’idées en dehors des formalismes et du bon-ton des publications académiques officielles. Á suivre, donc, deux exemples qui synthétisent parfaitement la problématique en examen.

Le premier extrait est une réflexion de Florence Clavaud (Archives Nationales et École des chartes) qu’on peut tirer d’une des meilleurs présentations du standard XML-TEI en circulation dans le Réseau sous forme de diapos. Il s’agit du matériel lié au Stage d’écdotique du 5 mai 2011 qui s’était tenu à Lyon (Institut des Sources Chrétiennes, UMR 5189). Á la page 17, nous pouvons lire:

TEI dans le processus d’édition: deux grands cas d’usage
. Conversion de fichiers préexistants
Cas fréquent […]
. Production directe de fichiers TEI
Cas encore rare, et les plus favorable au chercheur finalement (sur le plan intellectuel, et en terme de résultats). On manque d’outils confortables; les plus génériques et performants sont des éditeurs XML, qu’on peut certes adapter.

Et encore, p. 31:

[…] les outils ergonomiques sont rares […]

C’est tout dit, rien à ajouter.

J’ai ensuite “croisé” la vieille page personnelle de Tara Andrews, professeur de DH à l’Université de Wien (un peu difficile à repérer), avec Sa solution au problème (TEI:Markup, mis à jour 16 Mai 2014), mais seulement après avoir conçu et réalisé la mienne. Heureusement, pour moi, j’ai découvert:

1. d’avoir élaboré une solution un peu differente, ce qui justifie le fait de la présenter;
2. d’avoir élaboré cette solution selon les mêmes principes, ce qui m’a rassurée par rapport à mes choix. Le polygénisme de la même (presque) solution est quand même une forme de garantie par rapport aux potentialités d’une idée et à sa capacité de répondre à des exigences réelles et surtout partagées par plusieurs personnes.

TEI XML is a wonderful thing […] The problem is the transcription itself. I do not want to be switching back and forth between keyboard layouts in order to type “<tag attr=“attr”>arrow-arrow-arrow-arrow-arrow</tag> every six seconds. It’s prone to typo, it’s astonishingly slow, and it makes my wrists hurt just to think about it. I also don’t really want to fire up an XML editor, select the words or characters that need to be tagged, and click a lot. That way is not prone to typo, but it’s still pretty darn slow, and it makes my wrists hurt even more to think about.

Text:TEI:Markup is my solution to that problem. It defines a bunch of singles or double-character sigils that represent tags. These are a lot faster and easier to type; I don’t have to worry about typos; and I can do it all with a plain text editor, thus minimizing use of the mouse.

Celle de Tara Andrews n’a été la seul confirmation. Ma première inspiration a été la syntaxe compacte proposé par le Manuel d’encodage de la BFM-Manuscrits de Lyon. Puis, tandis que je précisais les termes de Ma solution, j’ai rencontré d’autres “copains” dans la syntaxe SGML du Projet Charrette, dans la documentation technique du Projet Christine de Pizan, etc. J’en parlerais successivement. Pour le moment, je presente cette solution personnelle.

TEI-MED ET TEI-MED.IT

D’abord j’ai mis en place une représentation simplifiée des étiquettes TEI, en partie inspirée à la forme Entity (&…;) de XML, en partie s’appuyant sur le code ASCII. J’ai appelé cette syntaxe TEI-Med: TEI-Médiateur. Le fichier .txt ainsi produit était transformé en fichier .xml grâce à un script s’appuyant sur un simple fichier .csv. Ce fichier permet d’associer les éléments de la syntaxe TEI-Med à un développement TEI-XML, avec l’avantage de pouvoir éventuellement modifier les étiquettes XML tout simplement modifiant le fichier .csv et relançant le processus de production. De cette façon on pourrait même penser de produire plusieurs fichiers .xml du texte avec des solutions d’encodage différentes.

L’abréviation d’un tilde de nasalité, marquée en TEI-Med comme &n;, peut générer soit, par ex:
ma solution d’encodage
<expan corresp=“#ab-tilde-n”><ex>n</ex></expan>
soit une solution plus classique
<choice><am><g ref=“#tilde”/></am><ex>n</ex></choice>
ou, pour les lettres ramistes:
<c ana=“#lram-c”>u</c>
ou une solution plus répandue
<choice><orig>u</orig><reg>v</reg></choice>

Il suffit de créer deux fichiers .csv différents.

En plus, le script produit automatiquement, sans aucune intervention des doigts:
1. l’encodage du vers <l> </l>
2. l’encodage de chaque mot <w> </w>

3. le tout accompagné par un @xml:id et/ou un @n

Mais le but était celui d’offrir à l’humaniste un instrument à utiliser de façon autonome, sans l’aide d’un informaticien, une fois naturellement adapté l’instrument à ses besoins spécifiques. Voilà donc que l’idée est évoluée et on a créé un milieu de travail, très simple, très… Unix (mais il marche bien aussi sous Mac): TEI-Med.it, TEI-Médiateur-éditeur.
Trois onglets s’ouvrent sur notre écran et en peu de seconds on peut voire notre fichier .txt en TEI-Med se transformer en fichier .xml en TEI-XML.

Première fenêtre, pour le .txt: on peut y écrire directement ou télécharger un fichier externe.

Deuxième fenêtre: elle montre la première phase de transformation, celle qui correspond à l’élaboration des entités; l’éditeur produit automatiquement un fichier .txt avec ce résultat et un fichier .log qui signale les erreurs.

Troisième fenêtre: une fois le fichier .txt corrigé, on lance la deuxième phase, celle de la transformation en .xml; encore quelques erreurs à corriger, naturellement, et puis dans notre dossier de travail nous pouvons récupérer le fichier .xml définitif prêt à se présenter au monde.

POUR RÉSUMER:

1. j’écris: Nel mez&add-int;(z)o&del-ex;(di)del cammin di&sub-ex-inl;(questa,nostra)vita

2. j’obtiens d’abord: Nel mez<add place=”interlinear”>z</add>o<del rend=”expunged”>di</del>del cammin di<subst><del rend=”expunged>questa</del><add place=”inline”>nostra</add></subst>vita

3. et enfin:

<l n=”1″ xml:id=”DCl1″>
      <w xml:id=”DCl1w1″>Nel</w>
     <w xml:id=”DCl1w2″>mez<add place=”interlinear”>z</add>o</w>
     <w xml:id=”DCl1w3″><del rend=”expunged”>di</del></w>
     <w xml:id=”DCl1w4″>del</w>
     <w xml:id=”DCl1w5″>cammin</w>
     <w xml:id=”DCl1w6″>di</w>
    <w xml:id=”DCl1w7″><subst>
           <del rend=”expunged>questa</del>
          <add place=”inline”>nostra</add></subst></w>
    <w xml:id=”DCl1w8″>vita</w>
</l>

L’ambition (on est en train d’y travailler) est celle d’ajouter une quatrième fenêtre: encore un click et notre fichier .xml va se transformer en fichier .html. Mais il faut attendre encore un peu. 

Pour terminer, pourquoi une bouffé d’oxygène?
Parce que me retrouver face à Oxygen m’avait donné une sensation d’étouffement.