Low-tech y high-tech: de lápices, sistemas y usability en la edición de textos medievales

Una extendida –y algo exagerada– anécdota cuenta que, durante la primera carrera espacial, los científicos de la NASA descubrieron que los bolígrafos que los astronautas usarían en las misiones de exploración lunar no funcionaban en condiciones de gravedad cero. Haciendo uso de la American ingenuity –y de la también norteamericana cultura del subcontracting–, gastaron millones de dólares para desarrollar un bolígrafo capaz de escribir en gravedad cero, el Fisher Pen. La anécdota continua: los científicos soviéticos, confrontados ante el mismo problema, encontraron una solución low-tech y les dieron a todos sus cosmonautas lápices.

Aunque es un lugar común, creo necesario insistir en el mensaje de esta anécdota: a veces una herramienta o solución high-tech puede dar más dolores de cabeza que una low-tech. Durante la edición del Lucidario he descubierto que esto es especialmente cierto en el trabajo de edición de textos medievales empleando herramientas y procesos de humanidades digitales.

Ocurrió durante la transcripción, cuando elegí Transkribus, un aplicativo que se instala desde un autoejecutable o que funciona desde una interfaz web que se conecta con los servidores de la Read Coop, en vez de eScriptorium. Este aplicativo francés de transcripción automatizada opera con los mismos principios (y en muchos casos con las mismas tecnologías), pero es decididamente más tecnológico. Su instalación solo es posible si uno está familiarizado algo con funciones avanzadas del ordenador y lenguajes de programación. La vía rápida requiere Docker (que se instala desde el terminal) y la lenta (instalación local) tiene una advertencia que deja claro que no es un juego: [This installation] will assume basic knowledge of Unix, virtual environments (pip or any other), environment variables and python/Django. Está luego la cuestión de los requisitos materiales del aplicativo, sobre lo que estoy preparando un artículo con JM Fradejas para el próximo número de Philologia Hispalense. Para ejecutar eScriptorium y entrenar modelos es necesario tener hardware (un servidor local) y recursos humanos (un técnico que sea capaz de mantenerlo).

[Nota bene: esto no quiere decir que Transkribus sea una herramienta low-tech, solamente que es una herramienta mucho más user-friendly: es fácil de instalar y ejecutar, y no requiere de conocimientos avanzados para comenzar a usarla].

Lo mismo ocurre con el tipo de codificación empleado para la transcripción de los testimonios. Uno puede tomar el camino high-tech y más fiel a los manuscritos: transcripción diplomática con grafías medievales (proceso descrito aquí en la filología analógica por Fradejas Rueda). El problema es que estos símbolos no existen en los actuales alfabetos informáticos (no corrientemente).

Hay que acudir a fuentes desarrolladas ah hoc para este trabajo, como la Medieval Unicode Font Initiative, o desarrollar un alfabeto de abreviaturas propio, como lo hace Matthias Gille Levenson (aquí).

El problema es el mismo que con las herramientas de transcripción. Se añaden pasos al trabajo. Tomando este camino, el filólogo debe insertar los símbolos en la primera etapa de transcripción manual y para ello necesita emplear combinaciones especiales de teclado o un teclado virtual. Entre su transcripción y la versión de trabajo, tocará regularizar y desarrollar la mayoría de las abreviaturas. Esto se logra con scripts o expresiones regulares (regular expressions) que desarrollen correctamente todas las abreviaturas (y luego, una inevitable revisión del texto desarrollado por el script). Esto último porque al reemplazar todas las ꝑ por par-, como en ꝑa (para):

Pueden haberse colado muchas abreviaturas iguales pero con diferentes valores –a pesar de que el script considere muchas posibilidades de desarrollo–, por el consabido problema de que los escribas utilizan la misma abreviatura con diferentes valores. Siguiendo con el último ejemplo la p con la lineta puede ser también abreviatura de er o e (y en algún caso, solo de a):

Esto es importante también por el tema de la consabida searchability, es decir, cuán fácil es buscar información específica en el documento resultante, tanto para el creador como para otros usuarios. No basta publicar la transcripción paleográfica en un repositorio en línea, hay que hacer lo mismo con las versiones normalizadas. Esto porque el documento está lleno de caracteres y abreviaciones desconocidas por los editores de texto. Aquí hay algunos ejemplos de estos documentos, producidos por Matthias Gille.

La alternativa low-tech de transcripción es el mucho más simple sistema de transcripción semipaleográfica del Hispanic Seminary of Medieval Studies (descrito aquí). Al ser desarrollado en los años 70, en la infancia de la informática, se hizo lo mejor que se pudo, empleándose los caracteres contenidos en el primer mapa de caracteres ASCII (ASCII 7-bits), un mapa que no contenía ningún carácter no empleado corrientemente en el inglés americano. Aquí las abreviaturas presentadas en el ejemplo anterior se desarrollan completamente entre los guiones angulares: p<ar>a, p<er>o, p<er>latico, p<e>rrochianos (y no perrochianos como podría confundirse un script). El post-procesamiento es bastante más fácil y no se necesita un script. Se puede usar la función búsqueda y reemplazo de cualquier editor o procesador de texto, y cambiar los símbolos < y > por espacios vacíos (no por espacios en blanco), pasando de esto:

A esto:

Y con esto vuelvo a la anécdota de la NASA y los soviéticos, y al tema de la usability (facilidad de uso). Un sistema (cualquiera, de transcripción automática, de codificación o de colación) tiene que ser simple. Esta es una verdad de Perogrullo, pero es algo que a veces olvidamos. Esto explica por qué sistemas operativos como Windows o Mac OS, visuales, intuitivos y de fácil uso –incluso para usuarios poco experimentados– son tan populares y tienen una base enorme de usuarios. Todo el mundo puede aprender rápidamente a usarlos. Y también explica por qué otros sistemas operativos mucho más complejos y adaptables, como los basados en Unix, que requieren a menudo emplear al terminal para instalar funciones y aplicaciones, tienen una base de usuarios tan pequeña.

Cuando uno comienza a usar Linux choca contra una realidad amarga: los problemas de mi versión (release) no serán los mismos que los que tiene la otra versión de Linux (bueno, esto pasa también en Windows y en Mac OS). Pero el problema sigue: los problemas de mi versión de Linux, en mi ordenador, no son los mismos que los problemas de mi versión en otros ordenadores porque el sistema tiene comportamientos diferentes dependiendo del hardware. Basta pasearse por los foros de Ubuntu para darse cuenta del dolor de cabeza que puede ser identificar y luego corregir un problema en Linux si uno tiene un chipset específico.

Vuelvo al inicio de esta discusión: uno quiere usar una máquina para ahorrar tiempo en una tarea. Quiere que la máquina haga la labor repetitiva, que uno pueda revisar luego. Pero en el camino, la máquina no debe requerir que uno obtenga una segunda titulación para poder usarla. La simplicidad del aplicativo o del sistema empleado debe ser acompañada por la capacidad del editor de realizar las tareas donde la máquina falla (o, realmente, no tiene la capacidad de realizar la tarea dada de manera correcta) y el juicio y la experiencia del filólogo son necesarias. Bueno, de tanto escribir, me olvidé de mi lapiz. Hablaré de ello en la próxima entrada.

---

---