| VOAI
Un generador automático de servidores de metadatos bajo el protocolo OAI-PMH.
Sinopsis
Este documento presenta Voai, una aplicación que genera automaticamente servidores de metadatos que implementan el protocolo OAI-PMH. Para lograr esto, solo es necesario que el usuario conozca perfectamente la estructura de su colección objetivo, y que tenga conocimiento básico del protocolo de OAI. Haciendo que Voai este disponible públicamente, se proporciona a los desarrolladores de colecciones de un medio de compartirlas y de formar parte de la comunidad de OAI en un periodo de tiempo corto. La implementación actual de Voai utiliza herramientas disponibles gratuitamente y no impone requisitos de progamación a los usuarios. En el trabajo se describe la arquitectura y la implementación de Voai así como los resultados obtenidos de su utilización en la generación de servidores OAI para varias colecciones.
1. Introducción
Para muchos desarrolladores de colecciones digitales, el uso del Protocolo OAI para Recolección de Metadatos (OAI-PMH) [1] se ha convertido en una aproximación con notable éxito para publicar sus contenidos y compartir sus datos descriptivos fundamentales. En esta aproximación, se construyen, para cada colección, los servidores que implementan OAI-PMH y se añaden al registro central como proveedores de datos (data providers). Los proveedores de aplicaciones y de servicios de valor añadido puede, por lo tanto, consultar a los proveedores de datos OAI de una forma uniforme sin que tengan que tener en cuenta la estructura interna variable de las colecciones digitales Nuestro grupo ha estado trabajando en la construcción de un banco de pruebas para bibliotecas digitales que consta de varios servicios y bibliotecas digitales. Albunas de nuestras colecciones, como las tesis digitales o nuestros depósitos de libros antiguos, son adecuados para que estén accesibles públicamente y son susceptibles de ser incluidos como proveedores de datos de OAI. Dado que las colecciones consideradas difieren en su organización y estructura, es preciso construir servidores de OAI-PMH específicos para cada una de ellas. Por otro lado, nos hemos dado cuenta que nuestros colegas están desendo compartir sus depósitos digitales pero o tiene poco personal asignado en sus organizaciones o éste no está familiarizado con el protocolo o la construcción de un servidor OAI. Típicamente, sus organizaciones no están en una posición de invertir tiempo y recursos para hacer que se produzca el desarrollo de servicios de interoperación de modo que sus colecciones lleguen a formar parte de la federación de OAI. Esto se convierte en un obstáculo para el objetivo de generar un entorno abierto, extensible en el que colecciones muy diversas coexistan y las aplicaciones puedan acceder a ellas de forma uniforme. Otra dificultad en este área ha sido la introducción de nuevas versiones del protocolo OAI-PMH. Como se documenta en el sitio web de Open Archives Initiative (http://www.openarchives.org), existía un número significativo de colecciones que eran compartidas con la versión 1.1 de OAI-PMH. Cuando se introdujo la versión 2.0 del protocolo algunos proveedores de datos se adaptaron para soportar la nueva versión, pero algunos no fueron capaces de adaptarse a dicho cambio. En el momento de escribir este trabajo, unos 80 proveedores de datos que se ajustaban a la versión 1.1 de OAI-PMH aparecen como purgados de la comunidad de proveedores de datos de la versión 2.0 del citado protocolo. Pensamos que se necesitan herramientas para apoyar el proceso de construcción de servidores OAI y unirse (y permanecer) en el movimiento de interoperabilidad de OAI. En este trabajo se presenta Voai, un entorno software que facilita la construcción de servidores que satisfagan OAI utilizando el conocimiento básico sobre la colección objetivo para generar el código necesario que implemente el protocolo OAI-PMH. El trabajo esta organizado como sigue: la sección 2 describe la aproximación a Voai y su arquitectura. La sección 3 proporciona detalles de la implementación de nuestro generador de proveedores de datos OAI. Se han realizado pruebas con Voai generando un número de servidores OAI para colecciones reales. Estas pruebas y sus resultados se discuten en la sección 4. Las limitaciones de la implementación actual de OAI, así como el trabajo en curso con el objetivo de mejorar su funcionalidad se discuten en la sección 5. Por último, en la sección 6 se proporcionan las conclusiones e implicaciones del trabajo presentado.
2. La arquitectura de Voai
De nuestra experiencia y nuestra revisión de la literatura hemos deducido las características que consideremos deseables en un sistema diseñado para permitir la generación automática de proveedores de datos OAI. La figura 1 ilustra el entorno global que hemos diseñado para el funcionamiento de Voai. En este escenario, un cierto número de colecciones están dispuestas para ser incluidas en la comunidad de OAI como proveedores de datos. En una aproximación convencional, se deberían construir servidores OAI para cada una de las colecciones. Con Voai, se reciben las especificaciones de cada colección y se utilizan para generar automáticamente el código de un servidor OAI. Ejecutando el código de este servidor, los metadatos de las colecciones correspondientes son accesibles via solicitudes OAI-PMH desde aplicaciones y proveedores de servicios. Ahora, la figura 2 muestra una instancia más específica de la funcionalidad de Voai. La colección Tesis Digitales de la UDLA ha sido modelada y construida como una base de datos relacional. La información de esta colección es proporcionada a Voai para que esta herramienta genere un servidor que implemente el protocolo OAI-PMH. El servidor OAI generado permite que Tesis Digitales sea mundialmente accesible, y que esta accesibilidad sea uniforme y transparente.
Figura 1. Arquitectura de Voai
Figura 2. Generación de un servidor OAI para una colección real
La figura 3 proporciona más detalles de Voai. Para cada uno de los verbos incluidos en OAI-PMH, el administrador proporciona la información básica sobre como se obtienen los metadatos de acuerdo con la estructura de la colección. Para el caso mostrado en la figura 2, la información general incluye los parámetros de conexión de la base de datos o los de identificación para el servidor que se va a generar, como el nombre y dirección de correo de su administrador. Información más específica incluye las consultas SQL necesarias para obtener metadatos como el título, autor, lenguaje y otros que se precisan si se utiliza Dublin Core [7] como estándar de metadatos. Cada vez que se suministra información a un módulo de especificación de Voai, esta información es almacenada en una “base de especificaciones”. Posteriormente, cuando se haya terminado con el proceso de suministrar información a todos y cada uno de los módulos de especificación, la base de especificaciones tendrá en ese momento toda la información necesaria para la generación del código del servidor OAI. Esa información es entonces obtenida por un componente del diseño denominado “generador de código”. El generador de código, como su nombre lo dice,
es aquel componente de Voai que se encarga de construir
el código fuente del servidor OAI a partir de toda
la información que fue suministrada en los módulos
de especificación y que reside en la base de especificaciones.
Además de la creación del código fuente,
el generador de código también crea un componente
llamado “instalador”. Finalmente el usuario coloca al servidor OAI en un servidor Web para que pueda ser accedido públicamente por proveedores de servicios o aplicaciones de manera uniforme.
Figura 3. Componentes
de Voai.
3. Implementación de Voai
Nuestra implementación actual de Voai está disponible como servlets de Java que generalizan la construcción de servidores de OAI-PMH para compartir metadatos que estén almacenados en bases de datos relacionales. La figura 4 muestra la interfaz principal que presenta Voai al administrador que está interesado en generar un servidor OAI-PMH para una colección particular. Como se puede observar, el proceso de generación se puede realizar en tres pasos: proporcionar consultas para cada verbo y para cada atributo requerido por el estándar de metadatos que se está utilizando (por ejemplo, Dublin Core), especificar los parámetros del servidor como el área en la que residirá y comenzar la generación del código actual.
Figura 4. Interfaz principal de Voai.
La interacción con los componentes internos de Voai es bastante flexible, permitiendo al administrador de la colección especificar, examinar y actualizar los parámetros del servidor tantas veces como sea necesario. La figura 5 muestra una interfaz de muestra para modificar los parámetros del servidor que se han introducido previamente para el verbo "Identify" del servidor OAI que se está construyendo para una de nuestras colecciones de prueba. La figura 6 ilustra como se especifican los parámetros para una colección de modo que sus atributos se proyectan sobre los incluidos en un estándar de metadatos dado. En este caso, cuando se definen los parámetros para el verbo "ListMetadataFormats", podemos ver que se ha seleccionado Dublin Core y que para cada uno de sus descriptores se ha establecido una correspondencia con los atributos de la base de datos. Además, se precisan sentencias SQL para que los atributos requeridos se obtengan de las tablas apropiadas de la base de datos relacional.
Figura 5. Modificando las especificaciones correspondientes al verbo Identify
Figura 6. Especificando un formato de metadatos y sus correspondencias
Una vez que se han especificado todos los parámetros del servidor, todo lo que tiene que hacer el administrador es seleccionar la ruta de instalación y posteriormente seleccionar la opción "Generar el servidor OAI" de la interfaz principal y se generará automáticamente el código y será colocado en un la ubicación seleccionada en el paso dos. Las pruebas que hemos realizado se han llevado a cabo con un servidor web Tomcat [8].
4. Resultados
En este momento Voai está disponible para uso público, por lo que podemos recibir realimentación sobre su funcionalidad, robustez y utilidad (por favor, véase http://ict.udlap.mx/cudi/udlatec o contacta con los autores). A continuación se describe la aplicación, con éxito, de Voai para la generación de servidores OAI-PMH para tres colecciones diferentes: un depósito de tesis digitales, una colección de libros raros digitalizados y una colección de incunables. Las dosprimeras colecciones están administradas por la Universidad de las Américas, Puebla, Mexico mientras que la tercera reside en la Universidad de Valladolid, España. En los tres casos, las colecciones están modeladas y almacenadas en bases de datos relacionales utilizando el sistema gestor MySQL. Estamos satisfechos de comprobar como los usuarios de Valladolid fueron capaces de generar su propio servidor OAI, que llevaban planeando construir desde hacía unos meses en un par de horas. 4.1 Tales Como se ha indicado anteriormente, "Tales" es nuestra colección de tesis digitales, que está formada por unos mil documentos [9]. Cada tesis es accesible a través de un URL, que está almacenado como uno de sus metadatos y fue usado como el atributo "identificador" precisado por el estándar Dublin Core. Esto implica que, por tanto, con el fin de obtener el atributo "identificador", fue suficiente una consulta SQL para obtener el URL correspondiente necesario para compartir una tesis. El servidor OAI-PMH generado por Voai fue validado como un proveedor de datos oficial OAI y está disponible en http://ict.udlap.mx:9090/Tales/Oai_tesis. 4.2 CIText Libros Raros Esta colección consta de unos 130 libros raros que se han digitalizado y se pueden acceder mediante un software de visualización y navegación especializado que hemos denominado CITest [10]. Una característica especial de esta colección es que los materiales digitalizados en la actualidad son recuperados desde la base de datos bajo demanda y, por tanto, no es posible generar previamente un URL para un libro dado. Con el fin de satisfacer la necesidad de un atributo "identificador", lo que puede ocurrir también en otras colecciones similares, se amplió Voai por lo que genera un componente del servidor OAI que contacta con el sistema gestor de la base de datos para obtener este tipo de contenido cuando se precisa por las aplicaciones del cliente. Como resultado de la generación del servidor de Voai para esta colección, Voai se extendió para satisfacer un caso que no se había considerado inicialmente. El servidor OAI-PMH fue validado como un proveedor de datos oficial de OAI y está disponible ahora en http://catarina.pue.udlap.mx:9090/u_dl_a/citext/Oai_citext. 4.3 Incunables La Universidad de Valladolid está construyendo su depósito digital para promover la preservación y diseminación de incunables (los libros impresos antes de 1501) que se encuentran depositados en la Biblioteca Histórica de Santa Cruz. El porceso de generación del servidor OAI para esta colección ha sido muy similar al seguido para Tales, excepto para la construcción dinámica de los URL, que no están almacenados en la base de datos, pero se pueden generar fácilmente añadiendo un identificador de recurso local un URL básico. El nuevo servidor OAI-PMH también ha sido validado como proveedor de datos oficial de OAI y está disponible en la dirección: http://guteneberg.dcs.fi.uva.es:8080/OAI_UVA/Oai_incunables. 4.4 Resumen de las características de Voai La tabla 1 proporciona un rersumen de las caracetrísticas proporcionadas por la implementación actual de Voai. Nuestro objetivo ha sido proporcionar un mecanismo claramente dinámico para construir servidores OAI. Por tanto, nuestra versión actual de Voai soporta generación de servidores para colecciones de estructuras arbitrarias con metadatos modelados y almacenados en bases de datos relacionales. Aunque se ha utilizado fundamentalmente MySQL por lo que se ha confiado en el estándar de conectividad JDBC, es posible realizarlo con otros sistemas gestores de bases de datos sin ningún cambio en el código generado por Voai. Como se aprecia en la tabla 1, las colecciones objetivo pueden constar de múltiples tablas y no se necesita modificar el esquema de la base de datos en orden a compartir los metadatos. El usuario que construya un servidor OAI con Voai no precisa escribir ningún programa ni mantener archivos de configuarción complejos. El código del servidor resultante es accesible inmmediatamente desde la red global y puede ser validado para llegar a ser un proveedor de datos oficial. Aunque nuestro diseño también considera otras bases de datos distintas de las relacionales, esta es una posibilidad que se está desarrollando todavía, como se indica en la sección siguiente.
Tabla 1. Resumen de las características de Voai
5. Trabajo inmediato y a futuro
Actualmente se está trabajando sobre un número de áreas para mejorar Voai. A continuación se comenta brevemente nuestro trabajo en curso para soportar colecciones semiestructuradas, basadas en XML y nuestros planes para hacer que Voai sea elástico ante los cambios potenciales en el protocolo OAI-PMH. Aunque es bastante habitual que los desarrolladores de colecciones utilicen bases de datos relacionales para almacenar sus colecciones o al menos sus metadatos, existe un número cada vez más grande de colecciones que utilizan XML para la descripción de la estructura interna de sus documentos y bases de datos XML [11] como su mecanismo de almacenamiento principal. Una nueva versión de Voai, denominada xVoai, hará uso de Xpath y Xquery en hojas de estilo XML para producir el código de un servidor XML para colecciones basadas en XML. Esta versión de Voai ofrecerá opciones de generación de una forma integrada y se espera esté disponible al finales de junio del presente año. Se puede plantear un serio problema sobre la aplicabilidad de Voai si se publica una nueva versión de OAI-PMH. Como se ha indicado en la Introducción, este problema ya ocurrió cuando se publicó la versión 2.0 del protocolo, que sustituía a la 1.1, dejando a un gran número de participantes de OAI fuera de la federación. Realmente Voai está ligado actualmente a la versión 2.0 de OAI-PMH y precisaría adaptarse a los cambios para que pudiera soportar el proceso de actualización a las nuevas versiones del protocolo. Aunque no es fácil predecir la naturaleza y extensión de los los cambios que se pueden producir en este protocolo, estamos trabajando en un a metadescripción del mismo que se pudiera utilizar en el proceso de generación. Esa metadescripción sería el único componente de nuestra utilidad de generación que necesitarfía ser actualizada en el momento de un cambio de versión.
6. Conclusiones
Hemos discutido el análisis, diseño implementación y aplicaciones de Voai, una utilidad pensada para permitir a los desarrolladores de colecciones digitales que deseen unirse a la comunidad OAI como proveedores de datos compartiendo sus metadatos mediante OAI-PMH. Voai permite la generación automática de servidores que implementen este protocolo utilizando la información sobre como se pueden recuperar metadatos específicos de la colección objetivo. Nuestra implementación actual se centra en colecciones para las que el contenido o los metadatos están almacenados en bases de datos relacionales, pero la aproximación es aplicable también y está siendo extendida para incluir colecciones de datos semiestructurados. La aplicación con éxito de Voai para la generación de servidores OAI para tres colecciones distintas nos proporciona una indicación prometedora de que nuestra aproximación se podrá utilizar por un número mucho mayor de desarrolladores de colecciones y contribuirá a expandir la comunidad OAI y al resto de los objetivos de la Open Archives Initiative.
Agradecimientos
Este trabajo ha sido financiado parcialmente por el programa CUDI-Conacyt (proyecto "Agentes y Movilidad en Colecciones Hetogéneas Multimedia"), el MCyT Plan I+D+I (proyecto TIC2003-09268 "Estudio y evaluación de la incidencia de la estructura de los documentos en Recuperación de Información y Bibliotecas Digitales") y CYTED (Proyecto VII.9 RIBIDI).
Referencias
[1] OAI - Protocol for Metadata Harvesting. http://www.openarchives.org/OAI/openarchivesprotocol.html/. Last update on October 2004. Accessed on March 2005.
|
