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.

Laisser un commentaire

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

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