Ésta es una propuesta de creación de una aplicación de tipo fuente abierta, cuya función será la gestión, presentación y análisis de documentos de diversos tipos, en varios ambientes computacionales. La idea de crear Durito surge a partir de un proyecto de digitalización de fuentes históricas de la Revolución mexicana. Titulado "Testimonios Zapatistas", el proyecto publicará en Internet y en CD-ROM las fuentes capturadas, y requerirá una aplicación que funja de intermediario entre los datos documentales estáticos y el usuario. La primera meta de Durito será alcanzar la funcionalidad que necesita Testimonios Zapatistas para su fase actual. Sin embargo, desde un principio debe diseñarse con objetivos más generales, para poderse adaptar a las futuras etapas del proyecto así como otros propósitos similares. En esta óptica, se propone integrar como tecnologías centrales XML y RDF, ejes de la visión de "Web Semántico" que promueve el World Wide Web Consortium.
Más que una aplicación independiente, Durito será un ensamblaje de componentes ya existentes, disponibles bajo licencias de tipo fuente abierta. La mayor parte del código que habrá que escribir será del tipo "pegamento", que vinculará módulos obtenidos.
Durito será portátil; funcionará cuando menos en sistemas Linux y Windows. Pero nuestra prioridad será lograr un grado razonable de estabilidad bajo Windows. A menos que alguien nos convenza de lo contrario, escribiremos Durito en Perl.
(En los siguientes esquemas, las flechas indican líneas de comunicación o transferencia de información.)
Esquema 1: Configuración local
Esquema 2: Configuración de red
Los datos incluirán documentos que el sistema gestionará, hojas de estilo asociadas (vea el apartado, "XML y codificación estructural"), descripciones asociadas (vea "Descripción de recursos, clases y RDF"), datos generados con anterioridad (por ejemplo, índices de palabras contenidas en los documentos) y elementos del interfaz con el usuario (como imágenes de botones y plantillas de pantallas).
Los "procesos principales de Durito" consistirán básicamente en transformar y ensamblar diversos elementos de la capa de datos, según lo solicitado por el usuario. Las dos funciones que ofrecerá al usuario en un primer momento son: presentación de documentos a partir de un índice de documentos disponibles, y búsquedas.
El browser podrá ser cualquier browser Web relativamente actual y difundido (Netscape 4 en adelante o MSIE4 ó 5 en adelante).
Como puede ver, no he aquí nada del otro mundo. Ahora, desde luego, no descartamos que a futuro se permitan configuraciones más complejas. Por ejemplo: será en algún momento necesario poder colocar elementos de la capa de datos en varias máquinas y accesarlos por medio de una red.
Tanto Durito como Testimonios Zapatistas (TZ) basan su procesamiento de documentos en la codificación estructural. Esto significa que se agregan a los documentos claves que señalan aspectos de su estructura, en vez de su formato. Tal método tiene múltiples beneficios, que incluyen: una mejor separación entre contenido y presentación, y mayor automatización en el análisis del contenido.
Los documentos textuales de TZ utilizan una implementación de XML definido por el Text Encoding Iniciative, proyecto académico que propone la estandardización de documentos digitales y que se relaciona principalmente con investigaciones en las humanidades y disciplinas sociales. En TZ, cada tipo de documento XML es asociado a una hoja de estilo XSLT que lo transforma en HTML.
Ilustramos brevemente. En las transcripciones de entrevistas, normalmente se señala quién habla colocando las iniciales del orador al inicio de su expresión:
Ejemplo 1Ahora, en cambio, en TZ, usamos etiquetas XML para indicar quién habla:LT. Zapata fue un hombre dócil.
RT. No me digas.
Ejemplo 2<u who='LT'>Zapata fue un hombre dócil.</u>
<u who='RT'>No me digas.</u>
Un parser XSLT puede leer el documento XML, transformarlo y convertirlo a HTML según lo determinado por la hoja de estilo XSLT; en este caso, se modifica para que sea más digirible por lectores humanos. Una de las transformaciones que hacen las hojas XSLT que ha elaborado TZ es reemplazar las etiquetas de uso de la palabra (Ejemplo 2) por simples iniciales (Ejemplo 1). Como mencionamos, el documento queda en formato HTML.
En este modelo, el documento de base sigue siendo el de XML. Así, resultaría muy sencillo modificar el formato de presentación de todas las entrevistas, según sea necesario. Una ventaja adicional es que el programa mismo podría identificar cuáles palabras se atribuyen a quién, lo que tiene importancia a la hora de las búsquedas así como en otros procesos de análisis automático.
En nuestro sitio Internet, se detalla el esquema de codificación estructural que utiliza TZ.
Aunque Durito manejará en un primer momento los esquemas de TZ, deberá diseñarse para ser flexible, para a futuro poder emplear sistemas de codificación muy distintos, incluso los que no sean XML ni elaborados con base en los principios de la codificación estructural.
Otro concepto de base que se propone para lograr una gestión inteligente de recursos documentales es la descripción coherente y general de éstos y de sus esquemas de codificación. Aquí vamos más allá de la codificación estructural de documentos: introducimos la codificación de estructuras y conceptos que relacionan los documentos unos con otros y con las funciones del programa.
Esta parte del modelo es la que menos ha sido comprobada por otras aplicaciones. También es la que menos importancia tiene para lograr la funcionalidad que en un principio se requiere. Sin embargo, me parece que es el aspecto más divertido del diseño.
(Debo enfatizar: aún falta mucho trabajo para implementar esta propuesta. Pero quise esbosarla brevamente, para que usted, estimado(a) lector(a), pudiera opinar al respecto, se es que así desee hacer.)
Partamos de una necesidad evidente: la de establecer vínculos entre documentos. En TZ, por ejemplo, una entrevista consistirá en dos archivos: el audio (MP3 o posiblemente OGG) y la transcripción (XML). Además, habrá que asociar el archivo XML a la hoja (o las hojas) XSLT correspondiente(s). Y deberán haber rutas entre la entrevista y otros recursos documentales (como el resumen de ésa, la descripción de la investigación que la generó, la ficha biográfica del entrevistado, etcétera.) Los vínculos al estilo hipertexto serían demasiado rígidos para esta tarea, y no darían cuenta del complejo de conceptos que los motivarían.
El problema es el mismo que está en el fondo de la programación orientada hacia objetos: cómo edificar una estructura lógica que es simultáneamente funcional, compacta, general y rica en significado (y por ende flexible).
La solución que proponemos es de crear un sistema de descripciones y propiedades, organizados en clases. Esto se implementará por medio de RDF, un lenguaje flexible para metadatos definido por el World Wide Web Consortium.
Ilustramos de manera general las posibilidades que RDF ofrece. Dejamos de lado un momento el acervo de TZ e imaginamos otro, que contiene dos tipos de recursos documentales: entrevistas y documentos escritos. Para todos los recursos, tenemos una ficha, un resumen y una transcripción; además, para cada entrevista, tenemos el audio, y para cada escrito hay una imagen escaneada.
RDF nos permite describir este acervo. Para empezar, proporciona un mecanismo para relacionar los cuatro componentes de cada documento, de manera que los enlaces incluyan la información semántica necesaria. Por ejemplo: tanto las entrevistas como los escritos tienen resúmenes; con RDF se crea la "propiedad" general "resumen", que se emplea para vincular todos éstos con su recurso original.
Con tal estructura, el programa puede reconocer qué es un resumen y qué no lo es, y puede modificar su funcionalidad en consecuencia. Cuando el usuario está visualizando un recurso (entrevista o documento escrito) que tiene un resumen asociado, el programa puede presentar en la pantalla la opción de ir a él. El motor de búsquedas puede dar mayor importancia a una palabra encontrada en el resumen. O permitir búsquedas sólo en los resúmenes. O se puede hacer un listado de ellos. Etcétera. Esta flexibilidad se conserva aun si agregamos a la colección otros tipos de documentos, siempre cuando todo lo que es resumen se asocie a la misma propiedad.
Ahora, aumentemos el modelo con el concepto de clases de propiedades. Éste permitirá organizar propiedades jerárquicamente en grupos y sub-grupos, con funcionalidades heredadas a través de la jerarquía.
Mencionamos algunas taxonomías posibles: se podría distinguir entre un resumen de documento, una ficha y una representación completa; así como entre imagen, audio y texto. Esta última categoría podría tener sub-clases: texto sencillo y texto con codificación estructural. Luego texto codificado podría subdividirse en clasificaciones referentes a cada esquema de codificación.
Esquema 3: Taxonomías de algunas propiedades posibles
Con este modelo, varias cosas ya son posibles. Sería sencillo hacer que el programa saque la lista de todos los recursos documentales (entrevistas y documentos escritos), sin entrar en detalles: sólo tomaría en cuenta los recursos asociados a la propiedad "ficha". Pero también podría producir un índice más completo, indicando cuáles representaciones están disponibles para cada recurso. El motor de búsquedas sabría exactamente cuáles recursos son de tipo texto. Éstos son sólo algunos ejemplos de las funciones que este esquema facilitaría.
Sería importante contemplar, tal como propusimos arriba, un mecanismo para identificar el esquema de codificación XML que emplea cada recurso. ¿Por qué? Bueno, supongamos que cada tipo de recurso XML (transcripción de entrevista, transcripción de documento, resumen de entrevista, resumen de documento, ficha de entrevista, ficha de documento) fuera elaborado con un sistema de codificación estructural diferente. No empleo el término "DTD" o "Schema", porque lo que diferencia los esquemas de codificación suele rebasar la simple definición de sintaxis; más bien, me refiero aquí a los conceptos que motivan el uso de diferentes sintaxis. En un caso extremo, dos documentos podrían incluso compartir el mismo DTD, sin que sus respectivos autores hayan usado los mismos criterios en la codificación.
Ahora, algunas funciones de Durito bien podrían aprovechar la información sobre los diferentes esquemas de codificación. Por ejemplo, un motor de búsqueda podría ofrecer al usuario la opción de buscar solamente en ciertas partes de la estructura XML. Consideramos el caso de un tipo de documento que introduce la etiqueta <placeName> para señalar nombres de lugares. Sería útil que el usuario tuviera la opción de realizar búsquedas sólo en topónimos --en este caso, en las etiquetas <placeName>--. Pero ¿qué pasaría si otro tipo de documento en el mismo acervo utilizara otra etiqueta --digamos, <placeNamingWord>-- para la misma finalidad? Si el programa pudiera diferenciar entre ambos sistemas de codificación, y saber cuál es el mecanismo que cada uno emplea para indicar topónimos, podría realizar la búsqueda eficazmente y transparentemente en ambos tipos de documento.
A la larga, al parecer, será fructífero usar este tipo de esquema de recursos y propiedades para representar no sólo vínculos entre recursos sino también aspectos importantes de los esquemas de codificación estructural. Así se lograría algunos beneficios de la codificación estructural aun tratando con sistemas de codificación desemejantes. Los conceptos que se podrían "enseñar" al programa para crear "puentes" entre sistemas incluyen: el tiempo, la ubicación geográfica, las personas, las citas, las fichas bibliográficas. (Imagino que algunos mecanismos desarrollados en el campo de la inteligencia artificial podrían emplearse aquí.)
Con estos ejemplos, espero que quede claro por lo menos las grandes líneas del enfoque que deseo proponer. Entonces, va. Durito deberá funcionar sobre la base de este modelo, o deberá poderse configurar para trabajar con modelos de este tipo.
Las búsquedas en acervos son quizá la herramienta más importante que ofrece la computación para las investigaciones de documentación textual.
Durito tendrá que permitir búsquedas de varios tipos y tomar en cuenta varios parámetros. Por un lado, hay asuntos lingüísticos que podrá manejar el motor de búsqueda: un usuario que busque "ir" deberá encontrar también "va", "fue", "fuera", etcétera. "Bello" deberá encontrar también "bella", "bellas" y "bellos". (En cuanto a este equiparamiento de palabras de una misma raíz, ya tenemos un componente de fuente abierta que mastica verbos castellanos; falta otro que trabaje sustantivos y adjectivos.) Asimismo, sería interesante poder hacer equivalencias entre sinónimos --para que "milpa" además halle "sembradillo"--. (¿Que no hay diccionarios de sinónimos disponibles bajo licencias tipo fuente abierta? Ah...)
Como ya se mencionó, al realizar búsquedas Durito deberá tomar en cuenta elementos de la codificación estructural. Ofrecerá al usuario la opción de buscar en diferentes aspectos de ésta. Incluso, en algunos casos, búsquedas en elementos de codificación tendrán que conjuntarse automáticamente con otras más sencillas. Por ejemplo, habrá documentos que utilizan etiquetas XML para relacionar temas con partes del texto. Una búsqueda por "campesino" podrá ubicar simultáneamente esa palabra, otras derivadas de la misma raíz, sinónimos, y etiquetas que señalan "campesinado" como tema --acordando mayor importancia a los temas coincidentes--.
Habrá la opción de búsquedas sencillas (donde mecanismos como los que acabamos de describir funcionan de manera transparente) así como la de avanzadas (donde el usuario tiene el control total sobre esos mecanismos y puede definir búsquedas compuestas).
Se incluirá la capacidad de buscar una palabra a una distancia especificada de otra, o varias palabras dentro de un mismo etiqueta XML.
Será necesario encontrar (o crear) un lenguaje que permita definir solicitudes de búsqueda compleja. Existen algunas normas más o menos compartidas entre varios buscadores Web; también conocemos un lenguaje que utiliza DynaBase, que es un programa con algunas funciones parecidas a las de Durito.
El motor de búsqueda tendrá que generar un índice de todas las palabras contenidas en el acervo; esto lo haría como parte de un proceso de configuración e integración, anterior a la difusión del mismo (vea abajo, "Durito en dos actas"). El índice contendrá información sobre la ubicación en la estructura XML de cada ocurrencia de cada palabra. Si bien conocemos motores de búsqueda disponibles bajo licencias de fuente abierta, aún no hemos encontrado ninguno que funcione con XML de esta manera.
Hay dos procesos generales que gestionará Durito: el primero, la conformación del acervo. En éste se configurará Durito, se integrará al sistema los documentos así como sus descriptores RDF, y se crearán los documentos de generación automática, entre ellos los índices de palabras que empleará el motor de búsquedas. Este proceso no se llevará a cabo a través de un browser, aunque es imaginable que algún día se realice, por lo menos en parte, por medio de una interfaz GUI amigable y accesible.
El segundo proceso será el de consulta e investigación de los documentos --ése es el que hemos venido discutiendo a lo largo de este texto--.
Es de notar que Durito en ningún momento pretende ser un editor XML ni XSLT. Los documentos XML y sus hojas de estilo asociados tendrán que diseñarse por medio de otra aplicación.
En su etapa actual, el proyecto Testimonios Zapatistas (TZ) pretende crear un prototipo de la versión electrónica y publicable del acervo que trabaja. Ése será difundida en CD-ROM o por Internet y contendrá aproximadamente 15 entrevistas (sonido y texto) así como unos cuantos documentos escritos (sólo texto), entre ellos los resúmenes y fichas de las entrevistas. Hay unas cuantas opciones que tendrán que ofrecerse al usuario:
Para el proceso de comunicación entre Durito y el browser: en la configuración de red, se empleará el servidor Apache. En el caso de una configuración local, podría ser Apache, también (vea "Algunas tareas inmediatas").
Parser XSLT: parece útil Sablotron, del Ginger Alliance.
Parser XML: el Expat sería suficiente.
Motor XQuery, XML-QL, XQL, o algo similar: no sabemos si necesitamos uno de éstos, pero es probable que sí.
Parser RDF y RDF Schema: falta escoger uno.
Para la comunicación entre Durito y la capa de datos: hay una aplicación que tal vez sería útil aquí. Se llama Charlie, también del Ginger Alliance.
Motor de búsqueda: falta escoger uno (debe ser "XML-aware" y permitir búsquedas complejas).
Interpretador del lenguaje humano: para conjugar verbos en castellano, hay el compjugador. Para todos los demás elementos castellanos y para otros idiomas, no tenemos nada.
Sinónimos: no tenemos diccionario de sinónimos castellanos ni programa que lo gestionaría.
Reproductor MP3: posiblemente sea útil distribuir uno de éstos con Durito; hay varios que son gratis.
El sinfín de tareas que tenemos enfrente incluye:
Además de ser las siglas de una frase muy descriptiva de este proyecto, "Durito" es el nombre de un famoso escarabajo rebelde.
Tim Bray, Jean Paoli y C.M. Sperberg-McQueen, editores. Extensible Markup Language (XML) 1.0. Recomendación W3C. Vea http://www.w3.org/TR/REC-xml.
James Clark, editor. XSL Transformations. World Wide Web Consortium, 1999. Vea http://www.w3.org/TR/xslt.
Ora Lassila y Ralph R. Swick, editores. Resource Description Framework (RDF) Model and Syntax, Recomendación W3C. Vea http://www.w3.org/TR/REC-rdf-syntax.
Testimonios Zapatistas, proyecto adscrito a
la Dirección de Estudios Históricos del Instituto Nacional
de Antropología e Historia (México) y apoyado por el Consejo
Nacional para la Ciencia y la Tecnología. Nuestro sitio Internet
estará disponible dentro de poco.
D.R. Andrew Green, 2001. Se permite la redistribución de este texto en los términos de la GNU GPL.