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.