Decomate II: un modelo unificado para una biblioteca digital distribuida

Ferran Jorba

Introducción

Tradicionalmente los editores editan, los intermediarios distribuyen, y las bibliotecas compran y sirven a sus usuarios los documentos en papel necesarios para desarrollar su labor. Pero con la llegada de los formatos digitales, los editores editan, distribuyen, quieren suprimir a los intermediarios y servir directamente a la comunidad usuaria de las bibliotecas. Pero difícilmente los editores pueden integrar. La integración, la creación de colecciones duraderas a partir de fuentes diversas, continúa siendo la labor de las bibliotecas, a pesar de los intentos de agentes de subscripciones y otros agregadores para asumir esta función.

La tendencia de buena parte de los editores de revistas científicas que disponen de versión digital de sus publicaciones es ofrecer, bajo contrato, acceso a estos documentos desde su servidor Web. Los usuarios de cada universidad o centro de investigación tienen que conectarse a cada uno de los catálogos de los editores para consultar los artículos. La interfaz de usuario es propia de cada editor, igual que sus posibilidades de búsqueda y navegación. A medida que el número de editores aumenta, mayor es la dispersión del fondo bibliográfico de la biblioteca, también mayor es la diversidad de tipos de acceso para los usuarios, y menores las garantías de completud al efectuar las búsquedas bibliográficas. Los usuarios tienen que memorizar cuál es el editor de cada revista y aprender las interfaces de cada uno de ellos.

Esta situación no es muy distinta a la de intentar buscar libros a partir de los catálogos (en papel) de los editores: cada editor publica su catálogo en un formato, tamaño, organización y posibilidades diferentes, e incluso en lenguas distintas. Los hay excelentes y otros no tan buenos, pero seguro que no hay dos iguales. Los catálogos de las bibliotecas han unificado, desde siempre, esta dispersión bajo unos criterios únicos, ya se trate de libros, discos, vídeos, mapas o documentos en distintas lenguas, y se usa una única interfaz para todos ellos, tanto en los antiguos catálogos manuales de fichas como en los actuales informatizados.

Decomate II1 es un modelo de biblioteca digital en el que se acentúa el concepto bibliotecario de colección, en el sentido clásico de "aquello que la biblioteca ha adquirido" que, en el mundo digital, se extiende a "derecho de acceso o uso". En cualquier caso, en Decomate se trata de que sea la biblioteca quien ofrezca a los usuarios la interfaz homogénea –el catálogo, en definitiva–, de los documentos que forman parte de su colección. Su rol es definir la colección adecuada a las necesidades de los usuarios a los que sirve, y facilitar el acceso a los materiales a los que tiene derecho. En el caso de las versiones digitales de las revistas, una opción sencilla es mantener en el Web de la biblioteca, páginas HTML con apuntadores (URL) a los servidores remotos a las que la biblioteca tiene acceso. Una opción mejor todavía, en caso de disponer de una aplicación de gestión con interfaz Web, es proveer de los URLs desde el propio catálogo. Con ello se consigue acceso a nivel de título de revista, pero no al artículo. El objetivo de Decomate II es mantener este criterio de unicidad del catálogo en los documentos digitales, a la vez que dar acceso a nivel de artículo.

Para implementar Decomate II nos hemos basado, siempre que ha sido posible, en estándares. Las bibliotecas han tenido, desde hace mucho, un enorme interés en ellos; si no fuera así, no hubieran podido cooperar e intercambiar servicios como lo han estado haciendo desde hace años. En este sentido, instituciones públicas como las universidades y centros de investigación alguna cosa pueden enseñar, creo, a las empresas privadas, en este caso los editores. Muchos de ellos creen que como ofrecen una interfaz Web, ya son estándares. Usar una herramienta estándar garantiza la interoperabilidad sólo entre la aplicación cliente y el servidor, pero su nivel de integración es todavía débil para el usuario final. Desde su punto de vista, el que dos o más editores dispongan de servidor Web no le permite, por ejemplo, realizar búsquedas simultáneas en más de un servidor. De hecho, cuantos más editores dispongan de servidores, menor será la integración. Además, empiezan a emerger fondos importantes de documentación científica cooperativa al margen de los editores comerciales2, cuya importancia puede crecer tanto como, en su contexto, la del software de distribución libre, y que las bibliotecas no pueden ignorar3.

Decomate II se basa en los resultados obtenidos en un proyecto anterior, Decomate4, con lo cual tres de los socios del actual proyecto ya disponen de una aplicación en explotación y de una colección importante de documentos en formato digital, tanto de registros bibliográficos como en textos completos, principalmente en PDF. La UAB, por ejemplo5, dispone del texto completo de unas 320 revistas de tres editores (Elsevier Science, Kluwer Academic Publishers y Servei de Publicacions de la UAB), que comprenden más de 130.000 artículos desde 1995 hasta la actualidad, con actualización semanal, y que cubren la mayoría de las disciplinas académicas que se imparten en la universidad.

El núcleo de Decomate II

En una visión simplificada, el sistema antecesor del actual Decomate II, Decomate, consiste en un servidor de información bibliográfica y un servidor de documentos. Entre ellos hay un intercambio de claves PGP para que no sea posible acceder a los documentos sin haberse autentificado previamente en el servidor principal.

Decomate II extiende esta división de tareas a un sistema mucho más distribuido. Tanto es así que se ha diseñado un Broker6 como pieza principal que las distribuya. La autentificación, por ejemplo, la realiza un proxy especializado7, con interfaces LDAP, SQL, Samba y dbm. El servidor de información bibliográfica, del que hablaremos más adelante, es a su vez cliente Z39.508, entre otros. La gestión de los perfiles personalizados de novedades bibliográficas la realiza otro servidor más, que es un cliente genérico SQL. En general, podemos decir que todas las piezas de Decomate II tienen una interfaz suficientemente clara y limpia con el Broker como para que puedan ejecutarse en máquinas independientes. Así lo hemos demostrado, por ejemplo, durante las pruebas de integración entre los equipos de las distintas universidades, que hemos probado las piezas de unos u otros cambiando solamente el nombre del servidor y el puerto con el que tenía que dialogar, estuvieran en Holanda, Londres o Barcelona.

El Broker (es decir, el distribuidor de tareas), se comunica con cada uno de estos servidores secundarios vía TCP/IP con mensajes XML. La definición de este protocolo ha tenido –y tiene todavía– una atención prioritaria para los desarrolladores del proyecto. Se escogió XML9 como lenguaje definición de interfaces10 porque, como lenguaje textual que es, permite una mayor interoperabilidad que los interfaces binarios. Al mismo tiempo, XML permite enviar mensajes de complejidad arbitraria sin ambigüedad y de manera normalizada. A este protocolo de aplicación lo hemos llamado XREP (XML Request & Response Protocol)11. En la versión de desarrollo actual, un mensaje XREP se transmite directamente sobre TCP/IP: el servidor reconoce que el cliente envía un mensaje XREP porque empieza con la etiqueta <xrep> (a diferencia de un GET o un POST de HTTP) y sabe cuándo termina al recibir </xrep>. Así de sencillo. Está en estudio la posibilidad de transmitir estos mensajes sobre HTTP (concretamente en su versión 1.112, debido a que puede mantener las conexiones abiertas en más de una petición) para aumentar así la interoperabilidad de Decomate II con otros servidores externos al sistema.

El Broker actúa al mismo tiempo de servidor HTTP13 y generador de interfaces de usuario, y es el intermediario14 entre el navegador y los servidores secundarios, mientras que éstos son los que proporcionan una interfaz uniforme entre el Broker y las fuentes de información. La generación de interfaces de usuario, en este caso páginas HTML estándar, se construye mediante la transformación de los mensajes XML con plantillas XSL15, con lo cual estas interfaces deberían ser completamente configurables.

El acceso a las bases de datos bibliográficas se realiza vía Z39.50. A diferencia de HTTP, que es un protocolo sin estado (stateless), en el que cada petición es independiente de las anteriores, en Z39.50 existe un inicio de sesión, unas operaciones de búsqueda y reutilización de los resultados y una finalización. No es fácil compaginar estos dos modelos16. Para conseguirlo, en Decomate II se ha escrito el MultiProtocol Server (MPS), un servidor multiprotocolo y multihilo que mantiene las sesiones abiertas con el servidor Z39.50 durante un tiempo (timeout) predeterminado. Forma parte del protocolo la búsqueda simultánea en más de un servidor, y esta funcionalidad existe ya en los primeros prototipos de Decomate II.

Posteriormente se añadirá un desduplicador de los resultados para eliminar, a petición del usuario, los registros bibliográficos iguales en más de una base de datos, para así facilitarle la recuperación de la información.

Otras funcionalidades

Decomate II dispone de servicios personalizados. Esto significa que para usar el sistema hace falta identificarse17. Pero para ello no se trata de duplicar las bases de datos de autentificación que ya existen en

nuestras instituciones. Para ello el proxy de autenticación se comunica con los servicios disponibles: LDAP, Samba, bases de datos en SQL o dbm. Puede configurarse una jerarquía de prioridades en la autentificación usuario/palabra de paso contra más de uno de estos servicios.

Otros servicios de personalización son las novedades bibliográficas individualizadas. Cuando un usuario ha realizado una búsqueda interesante, puede almacenarla para su ejecución periódica. Los resultados de estas búsquedas se almacenan durante un tiempo en el servidor, además de enviarse, opcionalmente, vía correo electrónico al usuario que la ha solicitado.

Finalmente, como funcionalidad avanzada, también dispondrá de una interfaz gráfica de consulta de tesauros, implementada como applet Java. Los usuarios podrán consultar este espacio conceptual en forma de red para marcar los términos más o menos relevantes para la información buscada. El applet generará una búsqueda al MPS, que la transmitirá a las bases de datos escogidas.

Un sistema como éste sería incompleto sin un seguimiento estadístico que permita a la biblioteca evaluar las publicaciones más y menos usadas. Estas estadísticas se generan a partir de la actividad del Broker y se almacenan en un servidor de bases de datos relacional. A través de vistas SQL consultadas vía ODBC con un paquete ofimático estándar, desde la biblioteca disponen de la información necesaria para tomar las decisiones que mejoren el servicio.

El Consorcio Decomate

Parte importante del proyecto es el análisis de la oferta de publicaciones electrónicas en un ámbito temático, las ciencias económicas, en el cual sobresalen las cuatro bibliotecas universitarias participantes. Debido a esto el proyecto tiene como subtítulo Developing the European Digital Library for Economics. Para su desarrollo, los socios del consorcio disponemos de autorización por parte de los editores de consultar de manera cruzada los documentos almacenados en las cuatro instalaciones de prueba. Con ello se podrá estudiar el comportamiento de los usuarios en un consorcio multinacional, y valorar la oportunidad de crear uno permanente.

La aplicación resultado del proyecto se distribuirá según el modelo Open Source, seguramente con licencia GNU, igual que se hizo con su antecesor, Decomate. Aunque la plataforma principal de desarrollo es Tru64 Unix18, también se intenta mantener la compatibilidad con Linux y Solaris.

Ferran Jorba
dirección de correo ferran [dot] jorba [at] uab.es
Servei d’Informàtica
Universitat Autònoma de Barcelona

NOTAS

  1. La página oficial se encuentra en http://www.bib.uab.es/decomate2, donde se publica toda la documentación relevante. El proyecto está liderado por la Universidad de Tilburg (Holanda), y los socios desarrolladores son la London School of Economics y la Universitat Autònoma de Barcelona. También colaboran el European University Institute de Florencia y SilverPlatter Information Ltd., de Londres. Se inició en Febrero de 1998 y durará 30 meses, hasta el 31 de Julio del 2000.

  2. Motivados tanto por la voluntad de liberar la literatura científica de la barrera del papel como de las barreras de los precios de las suscripciones a las revistas. Véase el ejemplo de la iniciativa Universal Preprint Service (nombre provisional) en http://vole.lanl.gov/ups/ups1-press.htm, que agrupa a un número importante de iniciativas ya preexistentes.

  3. Ya existe una interfaz de consulta desde Decomate II al repositorio RePEc (http://netec.mcc.ac.uk/RePEc/) de artículos de investigación en economía.

  4. El proyecto DECOMATE, también con financiación parcial de la Unión Europea, se desarrolló entre 1996 y 1998. Su página está en http://www.lse.ac.uk/DECOMATE

  5. La aplicación se encuentra en explotación en http://decomate.uab.es

  6. Para una exposición clara de la arquitectura de aplicaciones basada en Broker, puede consultarse Frank Buschmann, et al. Pattern-Oriented System Architecture: A System of Patterns, Chichester, etc.: Wiley, 1996, p. 99-122.

  7. En rigor, a todos los servidores secundarios de Decomate II sería más correcto llamarlos "proxies", ya que median entre el Broker y los servidores finales (Z39.50, SQL, LDAP, etc.).

  8. Z39.50 es el protocolo estándar utilizado para las consultas cliente/servidor en los sistemas de gestión de bibliotecas y bases de datos bibliográficas, entre otros. Véase http://www.niso.org/z3950.html o bien http://lcweb.loc.gov/z3950/agency/.

  9. XML es, brevemente, una simplificación de SGML recomendada por el Web Consortium. La última versión de la especificación se encuentra en http://www.w3.org/TR/REC-xml.

  10. IDL, Interface Definition Language (F. Buschmann et al, op. cit., p. 111).

  11. El nuestro no es el único ejemplo de uso de XML para codificar mensajes entre clientes y servidores. Otros ejemplos son las XER (XML Encoding Rules, http://asf.gils.net/xer/) o el XML-RPC (http://www.xml-rpc.com/).

  12. RFC 2068 (ftp://ftp.rediris.es/docs/rfc/20xx/2068).

  13. De hecho, en Decomate II no hace falta un servidor HTTP externo al mismo, dado que hay uno que forma parte de la distribución.

  14. El Broker de Decomate II sería de la variedad message passing (F. Buschmann et al, op. cit. p. 117).

  15. XML Stylesheet Language, el estándar de estilos para documentos XML del Web Consortium (http://www.w3.org/Style/XSL/).

  16. Sebastian Hammer, John Favaro, "Z39.50 and the World Wide Web", en D-Lib Magazine, March 1996 (http://www.dlib.org/dlib/march96/briefings/03indexdata.html>)

  17. Existen otros motivos para esta identificación: la mayoría del material accesible está sujeto a contratos con los editores y sólo está disponible para la universidad que ha pagado las licencias.

  18. Anteriormente llamado Digital Unix, y originalmente OSF/1.