Descripción

Este desarrollo se describe de manera sintética en el artículo:

Sánchez, J. A., Razo, A., Córdova, J. M., Villegas, A. 2006. Dynamic generation of OAI servers. Proceedings of the Joint Conference on Digital Libraries (JCDL 2006, Chapel Hill, NC), 258-259.

Sinopsis

Este documento describe un proyecto orientado a permitir la generación de servidores de metadatos bajo la iniciativa OAI para colecciones almacenadas en bases de datos XML.

Dada la heterogeneidad de las diferentes colecciones para las cuales se generarán servidores OAI, se decidió orientar la generación de servidores para colecciones de documentos almacenados en bases de datos XML nativas. De igual manera se desarrolló una herramienta que permite extraer ciertos datos de los documentos de una colección y utilizarlos para especificar los valores de elementos en una estructura fija de documentos XML, sobre los cuales se aplican las consultas recibidas por el servidor. Otra herramienta que se desarrolló permite generar la configuración de cada servidor a partir de ciertos datos especificados y acordes a cada colección, con la finalidad de que sea a través de esa configuración donde se hagan cambios y que éstos se vean reflejados en el funcionamiento del propio servidor.

Finalmente podemos decir que la arquitectura de cada servidor OAI-XML está definida a través de componentes, donde la comunicación entre ellos se rige a través de interfaces;de tal manera que se pude sustituir un componente por otro, siempre y cuando el elemento sustituto implemente la interfaz correspondiente.

1. Introducción

1.1 Contexto

Diversas universidades, institutos de investigación y otras organizaciones orientan sus esfuerzos al establecimiento de mecanismos que mejoren el intercambio de información sobre determinados campos de interés. Una de las principales iniciativas que han surgido al respecto es la Iniciativa de Archivos Abiertos (OAI, por sus siglas en inglés), la cual desarrolla y promueve estándares de interoperabilidad que intentan facilitar la difusión de contenidos. Una de sus características principales es habilitar la compartición y publicación de metadatos y texto completo para bibliotecas digitales. Su protocolo define un mecanismo de acceso común para la recolección de registros conteniendo los metadatos de acervos [Van de Sompel & Lagoze 2001]. OAI cobra gran importancia dentro del contexto de bibliotecas digitales ya que establece una base firme para la generación de servicios de interoperabilidad y para la creación de federaciones de bibliotecas digitales.

Este documento describe XOAI, un generador de servidores de metadatos bajo la iniciativa OAI para colecciones almacenadas en bases de datos XML; teniendo como cuadro científico el Laboratorio de Tecnologías Interactivas y Cooperativas (ICT), que a su vez forma parte del Centro de Investigación en Tecnologías de Información y Automatización (CENTIA) de la Universidad de las Américas-Puebla.

1.2 Motivaciones y Objetivos

En el contexto del Programa de Bibliotecas Digitales de la UDLA [Sánchez 2004] se está experimentando con nuevas formas de modelar datos y, en consecuencia, nuevas formas de almacenamiento y recuperación de la información que se traduzcan en una manera más natural y rápida de crear nuevas colecciones digitales [Sánchez et al 2004].De forma particular se está experimentando el modelado de datos semi-estructurados, ya que únicamente se contemplan datos no estructurados y estructurados.

Un estudio al respecto fue abordado por Proal [2003] quien propuso modelar de una forma alternativa el esquema que se tiene para almacenar y recuperar la información; orientándose de forma particular a una colección de tesis digitales. Para dicho propósito y dado que el lenguaje de marcado XML es el principal exponente de los datos semi-estructurados, propuso modelar dicha colección como un conjunto de documentos XML almacenados en una XML-DB. Los resultados de esta investigación propiciaron un interés mayor en experimentar la utilización del modelo de datos que define XML, así como el uso de bases de datos XML para el almacenamiento.

Dado el auge de XML, es claro que el número de colecciones semi-estructuradas almacenadas en bases de datos XML [Graves 2002] aumentará de manera significativa. Como con otros tipos de colecciones, será necesario compartirlas y crear federaciones, para lo que es útil el protocolo OAI-PMH.

De manera análoga a como se ha hecho para bases de datos relacionales [Villegas 2005], XOAI generaliza la construcción de servidores para la compartición de metadatos bajo la iniciativa OAI para colecciones almacenadas en bases de datos XML.

Como objetivos específicos podemos mencionar:

  • Construir una plataforma que permita la generación de servidores de metadatos.
  • Dado que los servidores de metadatos que se generarán tienen como base la iniciativa OAI y en particular, el hecho de apegarse a la definición del protocolo establecido por dicha iniciativa; es necesario garantizar la mayor flexibilidad para que dichos servidores se adapten a posibles cambios originados principalmente, por las variaciones entre una versión y otra del protocolo.
  • Proporcionar una forma sencilla y transparente de configurar tanto el servidor como la colección a utilizar para la compartición de los metadatos. Con esto se logra:
  • 1.- Permitir un control total del funcionamiento del servidor.
    2.- Contar con una implementación única para cualquier servidor y sólo preocuparse por la configuración.
  • Permitir que los servidores OAI generados puedan funcionar en cualquier plataforma.
  • Demostrar la utilidad del mecanismo de generalización, mediante la construcción automática de servidores para colecciones XML específicas.

2. Diseño y Arquitectura

De manera general, las consideraciones que se tomaron en cuenta como base para el diseño y la posterior implementación de la generación de servidores OAI para colecciones en bases de datos XML, fueron las siguientes:

  • La heterogeneidad de las distintas colecciones de documentos para las cuales se generarían servidores OAI.
  • La necesidad de contar con servidores OAI lo suficientemente flexibles para adaptarse a los posibles cambios que surjan como resultado de las variaciones entre una versión y otra del protocolo definido por OAI.
  • Brindar la mayor transparencia al momento de realizar la configuración de un servidor OAI para la colección que lo necesite.
  • Permitir el control total sobre el funcionamiento del servidor de manera tal que dicho funcionamiento pueda establecerse fácilmente con sólo especificar ciertos parámetros de entrada.
  • Brindar una manera sencilla para poder agregar nuevos formatos de metadatos y que éstos sean tomados en cuenta de forma inmediata por el servidor.
  • Tener el control total de la estructura de las respuestas que el servidor debe enviar a las peticiones hechas por los clientes.

Tomando en cuenta esas consideraciones se decidió lo siguiente:

  • Dada la heterogeneidad de las diferentes colecciones para las cuales se generarán servidores OAI, se decidió orientar la generación de servidores para colecciones de documentos almacenados en bases de datos XML nativas.
  • Dada esa heterogeneidad, fue necesario el diseño de una herramienta que permitiera extraer ciertos datos de los documentos de una colección y utilizarlos para especificar los valores de elementos en una estructura fija de documentos XML, sobre los cuales se aplicarían las consultas recibidas por el servidor. Con esto se logra eliminar un impedimento bastante importante ya que era difícil o hasta imposible implementar ciertas consultas sobre una estructura desconocida e ir estructurando las posibles respuestas (principalmente para consultas en donde se establecen criterios selectivos como rangos de fecha o especificación de conjuntos).
  • Diseñar una herramienta que permitiera generar la configuración de cada servidor a partir de ciertos datos especificados y acordes a cada colección, con la finalidad de que fuera a través de esa configuración en donde se pudieran hacer cambios y que éstos se vieran reflejados en el funcionamiento del propio servidor. Dichos cambios incluirían la definición de nuevos formatos de metadatos que el servidor debería de reconocer de forma inmediata.
  • Especificar una estructura en XML lo suficientemente general y flexible que pudiera contener los metadatos de los documentos XML originales (utilizando los elementos definidos por el estándar Dublín Core), así como una sección en donde pudieran colocarse “tags” para propósitos específicos de cada colección.
  • Definir una arquitecturaModelo-Vista-Controlador, donde la parte de “Vista” dependiera deespecificaciones externas por parte del usuario y que el servidor usaría para dar formato a las respuestas obtenidas al procesar las consultas.

Después de haber establecido ciertas consideraciones y las soluciones que se deberían tomar en cuenta, se procedió al diseño conceptual del proceso de generación de servidores OAI-PMH para los metadatos de colecciones almacenadas en bases de datos XML nativas y a la especificación de la arquitectura que tendrían dichos servidores. En las secciones siguientes se explica a detalle esto.

2.1 Generación de servidores OAI-XML

Para no dar cabida a ambigüedades, se nombrará a los servidores OAI para colecciones en bases de datos XML nativas, como servidores OAI-XML.

De manera conceptual podemos definir al proceso de generación de servidores OAI-XML de la siguiente manera: Dada una colección de documentos almacenados en una base de datos XML nativa, podemos contar con una implementación única para cualquier servidor OAI-XML si (1) obtenemos metadatos descriptivos de cada documento XML que conforma dicha colección, a lo cual nombraremos como “cosecha de encabezados”; y (2) llevamos a cabo un proceso de configuración para obtener detalles específicos de esa colección y de esta manera contar con una colección lista para su acceso.

Después de llevar a cabo los 2 pasos descritos anteriormente, se tiene una colección “configurada” para poder compartir sus metadatos a través de un servidor OAI-XML. En el capítulo siguiente se describirá con más detalle la forma en que se realiza cada uno de estos pasos y se explicará las características que posee una colección después de haber sido configurada. El diseño conceptual del proceso de generación de servidores OAI-XML se ilustra en la figura 1.

Figura 1. Diseño conceptual del proceso de generación de servidores OAI-XML

2.2 Arquitectura del servidor OAI-XML

En esta sección explicaremos a detalle la arquitectura a manera de componentes que tiene un servidor OAI-XML.

2.2.1 Arquitectura a base de componentes de un servidor OAI-XML

Podemos ver a un servidor OAI-XML como un conjunto de componentes, en donde la comunicación entre ellos se establece a través de determinadas interfaces. De tal manera que es posible sustituir alguno de esos componentes por otro, siempre y cuando el componente sustituto implemente la interfaz correspondiente.

Figura 2. Arquitectura a manera de componentes de un servidor OAI-XML

De esta forma, un servidor OAI-XML consta de los siguientes componentes: Despachador, Manejador de Errores y Manejador de Respuestas. Dicha arquitectura puede visualizarse en la figura 2.

  • Despachador: este es el componente principal del servidor, es el encargado de recibir vía HTTP las peticiones hechas por los clientes y dirigirlas en primera instancia al componente encargado de verificar los errores para después, en dado caso de que no haya habido ningún error, dirigir esa misma petición al componente encargado de ir estructurando las respuestas. De tal manera que este componente no tiene conexión directa con la base de datos y sólo funge como un controlador (en lo concerniente a la verificación de los errores y al procesado de las consultas que se dieron de forma correcta).

Sin embargo, es importante señalar que este componente sí llega a tener acceso al archivo de configuración y así saber qué componente debe utilizar como Manejador de Errores y qué componente utilizar como Manejador de Respuestas, así como para saber qué formato de presentación deben tener las respuestas enviadas a los clientes.

  • Manejador de Errores: este componente es invocado por el Despachador para verificar posibles errores originados por una consulta. Tiene conexión con la base de datos porque un error no únicamente puede ser ocasionado por argumentos incorrectos en la consulta; sino también por consultas cuyo resultado sea nulo. Dicha nulidad puede entenderse mejor si pensamos en una consulta que involucre rangos de fechas y en cuyo rango no se encuentre ningún documento almacenado en la base de datos.

Cuando se presenta un error, este componente estructura una respuesta para informar de ese error. Dicha respuesta es obtenida posteriormente por el Despachador para aplicarle el formato correspondiente y de esa manera enviar el informe del error al cliente.

  • Manejador de Respuestas: este componente también es invocado por el Despachador para procesar las consultas que no hayan originado previamente un error. Es el encargado de obtener los datos de la base de datos e ir estructurando las respuestas. Dichas respuestas son obtenidas por el Despachadorparaaplicarle el formato correspondiente y de esa manera enviar la respuesta de su consulta al cliente.

Hemos abordado todos los aspectos relacionados con el diseño conceptual del proceso de generación de servidores OAI-XML y se explicó la arquitectura de un servidor OAI-XML a manera de componentes, describiendo la función de cada componente y la manera en que se comunican.

3. Implementación

A continuación se describe, en términos de programación, la forma en que se implementaron las herramientas que componen a XOAI.

3.1 Herramienta para la generación de encabezados

Esta herramienta permite generar una subcolección de documentos XML con estructura definida, dentro de la colección original.

Como se explicó en la sección anterior, esto permite contar con una colección de documentos cuya estructura es conocida por el servidor y con base en ello define la forma de hacer las consultas. Dichas consultas fueron definidas utilizando principalmente el lenguaje XPath y algunas específicas (principalmente para el manejo de fechas) utilizando XQuery. Las consultas se basan en los 6 tipos de peticiones que define el protocolo de OAI.

A cada uno de esos documentos que se generan se le dio el nombre de encabezado, puesto que contienen únicamente los metadatos asociados a cada documento de la colección y, de forma adicional, fragmentos de esos documentos cuyo propósito es específico a cada colección. La principal utilidad de esa sección definida como “extra”, es la de permitir utilizarla para definir nuevos formatos de metadatos y no estar limitados únicamente a los elementos del estándar Dublin Core. De esta manera podemos incluir ahí los fragmentos del documento original que se necesiten para obtener los valores de los elementos que se requieran para otro formato de metadatos.

En la figura 3 se muestra la estructura que tiene un encabezado . Dicha estructura está dividida en 2 partes: una llamada “required” y otra nombrada como “extra”. La primera permite incluir los metadatos asociados con cada documento, utilizando el estándar Dublin Core. La sección “extra” no está asociada con ningún formato de metadatos, se da libertad total para incluir en ella los elementos o “tags” que cada colección considere importantes.

<header>
<id></id>
<required>
<!--tags del estándar Dublin Core-->
<title></title>
<creator></creator>
<fecha></fecha>
<sets>
<set>
<setPrefix></setPrefix>
<setName></setName>
</set>
</sets>
<subjects>
<subject></subject>
</subjects>
<description></description>
<publisher></publisher>
<contributor></contributor>
<type></type>
<format></format>
<identifier></identifier>
<source></source>
<language></language>
<relation></relation>
<coverage></coverage>
<rights></rights>
</required>
<extra>
<!--tags con propósitos específicos a la colección-->
</extra>
</header>

Figura 3. Estructura de un encabezado

Para ir generando cada uno de estos encabezados la herramienta recibe la especificación de las consultas en XPath que serán aplicadas a cada documento para generarle su correspondiente encabezado. De esta manera se genera una subcolección de encabezados cuya relación es 1 a 1 con la colección original.

Figura 4. Proceso de generación de la subcolección de encabezados

El proceso de generación de encabezados puede verse como una secuencia de 6 pasos, como se muestra en la figura 4 y se detalla a continuación:

1.-El usuario especifica consultas en XPath que se aplicarán sobre cada documento de su colección; así como parámetros para establecer una conexión con su base de datos (BD) y en particular tener acceso a su colección de documentos XML.

2.- Se establece una conexión con la BD y se localiza la colección de documentos.

3.- A cada documento de la colección se le aplican las consultas especificadas con XPath.

4.- Por cada documento en la colección se va generando un nuevo encabezado, el cual contiene los valores obtenidos al aplicar cada una de las consultas.

5.- Todos los encabezados generados se van guardando en una colección nueva nombrada como“Colección de encabezados”.

6.- La colección generada se almacena como una subcolección dentro de la colección original.

Para la implementación de esta herramienta, se creó una interfaz en HTML que contiene un formulario para que el usuario especifique las consultas en XPath para obtener de sus documentos los valores de los elementos del estándar Dublin Core y para obtener los fragmentos que considere importantes para la posterior generación de otros formatos de metadatos. Esos fragmentos son colocados dentro de la sección del encabezado nombrada como “extra”.

Todas las consultas en XPath especificadas por el usuario, así como los parámetros de conexión a su BD, son enviadas a un servlet . Este servlet crea un objeto de tipo “XpathQueries”, inicializando sus atributos con el valor de cada consulta especificada.

Después de que el servlet crea ese objeto e inicializa el valor de sus atributos, crea un objeto de tipo “Generator”, éste último utiliza el objeto de tipo “XpathQueries” para ir obteniendo cada consulta e ir aplicándola a cada documento de la colección. De esta manera va generando cada encabezado hasta cubrir el total de documentos almacenados en la colección. Finalmente crea una subcolección de encabezados dentro de la colección original y regresa el control de la ejecución al servlet para que dicho servlet le envíe un mensaje al usuario informándole del resultado de la generación.

3.2 Herramienta de Configuración

Ya que se tiene generada una subcolección de encabezados ,la utilización de esta herramienta permite generar un archivo de configuración que se almacena en la subcolección de encabezados .

Este documento está dividido en 6 secciones, las cuales se listan a continuación:

  • Sección “general”: En esta sección se colocan los valores meramente descriptivos del repositorio (colección), que lo identifican como un Proveedor de datos ante OAI; como son : Nombre del repositorio, versión del protocolo utilizada, granularidad de las fechas que maneja, correo electrónico del administrador del repositorio, el tipo de compresión utilizada al enviar las respuestas (el cual se fija a “identity”, indicando que no se lleva a cabo ninguna compresión en las respuestas), la indicación de llevar o no un registro de información borrada (la cual se fija a “no”, indicando que el repositorio no llevará un registro de este tipo) y finalmente, el identificador del repositorio para registrarse ante OAI.
  • Sección sin referencia a metadatos (“verbStyles”): En esta parte se especifican las hojas de estilo que el servidor deberá utilizar para dar respuesta a 4 de los 6 verbos definidos por el protocolo de OAI: ListIdentifiers, ListMetadataFormats, ListSets y Identify. No se hace referencia a GetRecord y ListRecords, dado que en esta parte sólo se consideran respuestas que no hacen referencia a un formato de metadatos.
  • Sección “errores”: Esta sección es importante ya que es aquí donde se especifica el manejador de los errores que el servidor deberá invocar y así saber qué tipo de errores debe considerar. En esta sección también se especifican las diferentes hojas de estilo que el servidor debe de utilizar para dar formato a las respuestas, dependiendo del tipo de error que se haya presentado: error de carácter general (causado principalmente por una incorrecta especificación de una consulta) o errores específicos a cada uno de los 6 tipos de peticiones que define el protocolo de OAI. Es por ello que se especifican 7 hojas de estilo.
  • Sección “respuestas”: Es aquí donde se especifica el manejador de las respuestas que el servidor deberá invocar y así saber cómo procesar cada una de las 6 peticiones que se tienen.
  • Sección para el manejo de consultas con XQuery: Es aquí donde se especifica el manejador de las consultas que utilicen XQuery. Este manejador sólo se utiliza cuando la consulta se refiere al verbo “Identify”, ya que se necesita obtener la fecha de creación o modificación más antígua de un documento y era imposible obtenerla mediante consultas con XPath.
  • Sección para definir formatos de metadatos: Es aquí donde se definen todos los formatos de metadatos que deben ser tomados en cuenta por el servidor. La manera de definir un nuevo formato de metadatos es similar al procedimiento que se sigue para especificar un nuevo servlet (en el archivo Web.xml) dentro de un contexto incluido en un contenedor de servlets . Mientras que para definir un nuevo servlet se incluye una nueva sección delimitada por los “tags” <servlet> y </servlet>; para definir un nuevo formato de metadatos, se debe incluir una nueva sección delimitada por los “tags” <format> y </format>. De esta manera el servidor reconoce todos los formatos de metadatos definidos dentro de la sección delimitada por <metadataFormats> y </metadataFormats>.

De esta manera se logra tener definidos todos los aspectos que el servidor debe de tomar en cuenta para su funcionamiento y permite tener un control total de la parte de “Vista” que será enviada al cliente que invoque al servidor (a través de la especificación de hojas de estilo).

En la figura 5 se muestra un ejemplo del archivo de configuración que permite ver las secciones en las que está dividido y que acabamos de explicar.

Figura 5. Estructura del archivo de configuración

El proceso de generación del archivo de configuración (al cual llamamos “collectionDescriptor.xml”) y su posterior almacenamiento dentro de la subcolección de encabezados , puede verse como una secuencia de 4 pasos, como se ilustra en la figura 6.

1.- El usuario especifica todos los valores que debe contener el archivo de configuración (en realidad los únicos que debe proporcionar son los referentes a la sección “general”, porque todos los demás se proporcionan de manera inicial); así como parámetros para establecer una conexión con su BD y en particular tener acceso a su subcolección de encabezados .

2.- Se establece una conexión con la BD y se localiza la subcolección de encabezados.

3.- Se genera el archivo de configuración.

4.- Finalmente el archivo de configuración es almacenado en la subcolección de encabezados.

Figura 6. Proceso de generación del archivo de configuración y su almacenamiento en la subcolección de encabezados.

Para la implementación de esta herramienta, se creó una interfaz en HTML que contiene un formulario para que el usuario especifique los valores que debe de contener el archivo de configuración, así como parámetros para conectarse a su BD y en particular a su subcolección de encabezados. Todos estos valores son enviados a un servlet que crea el archivo de configuración e inicializa su contenido con todos los valores especificados por el usuario. Para almacenarlo en la subcolección de encabezados, el servlet crea un objeto de tipo “XMLResource” que toma de entrada la representación en “String” del archivo de configuración.

3.3 Interfaz de las herramientas desarrolladas

Las interfaces son páginas en HTML que contienen formularios y que están divididos en varias secciones.

3.3.1 Interfaz de la Herramienta para la Generación de Encabezados

Esta interfaz está dividida en 3 secciones. La figura 7 muestra la primera sección que es donde el usuario especifica las consultas en XPath para obtener de cada documento de su colección, el valor para cada uno de los elementos definidos por el estándar Dublin Core.

Figura 7. Interfaz de la Herramienta para la Generación de Encabezados – 1ª. Sección

La figura 8 muestra la segunda sección del formulario, en esta sección es donde se especifican las consultas en XPath para obtener fragmentos de cada documento XML de la colección. Esos fragmentos serán colocados en la parte denominada como “extra” de cada encabezado y de esta manera se pueden utilizar esos fragmentos para la definición de otros formatos de metadatos.

Figura 8. Interfaz de la Herramienta para la Generación de Encabezados – 2ª. Sección

La figura 9 muestra la tercera sección del formulario y es donde el usuario especifica los parámetros para establecer una conexión con su BD y en particular para tener acceso a su colección de documentos XML.

Figura 9. Interfaz de la Herramienta para la Generación de Encabezados – 3ª. Sección

3.3.2 Interfaz de la Herramienta de Configuración

Esta interfaz también presenta un formulario. Dicho formulario consta de varias secciones pero en general pueden considerarse dos secciones: sección para especificar el contenido del archivo de configuración y sección para establecer parámetros de conexión a la BD.

La figura 10 muestra la 1ª. Sección del formulario, la cual se subdivide en varias secciones ya que cada una de esas subsecciones corresponde a una sección del archivo de configuración.

Figura 10. Interfaz de la Herramienta de Configuración – 1ª. Sección

La figura 11 muestra la 2ª. sección del formulario y es donde el usuario especifica los parámetros para establecer una conexión con su BD y en particular para tener acceso a su subcolección de encabezados, ya que el archivo de configuración es almacenado en esa subcolección de encabezados.

El formulario se proporciona con ciertos valores de inicio, de tal manera que el usuario sólo necesita especificar los datos que describen a su repositorio y los referentes al establecimiento de una conexión con su BD.

Figura 11. Interfaz de la Herramienta de Configuración – 2ª. sección

3.4 Implementación del servidor OAI-XML

Para la implementación del servidor OAI-XML se recurrió al uso de interfaces y del polimorfismo de la programación orientada a objetos. De tal manera que el servidor consta de varios componentes y la forma en que estos componentes se comunican es a través de interfaces. Se puede sustituir un componente por otro, siempre y cuando el componente sustituto implemente la interfaz correspondiente y mediante el uso del polimorfismo, no importa cuál sea el nombre de ese nuevo componente ya que la comunicación se rige por medio de la invocación de los métodos que se definen en la interfaz implementada por cada componente.

Bajo este esquema podemos considerar a la propia base de datos como un componente externo (estereotipado), ya que es posible sustituir una base de datos por otra, siempre y cuando dicha base de datos implemente la interfaz correspondiente definida por la iniciativa XML:DB.

En la figura 12 pueden verse los componentes de un servidor OAI-XML, así como las interfaces que cada componente implementa.

Figura 12. Componentes de un servidor OAI-XML y las interfaces que implementan

4. Resultados

Aunque se realizaron varias pruebas sobre colecciones para comprobar la utilidad de las herramientas desarrolladas sin importar la estructura de los documentos XML almacenados en cada colección, sólo se presentan en esta sección las pruebas más formales hechas sobre dos colecciones de documentos XML en particular. En general las dos colecciones permitieron verificar el correcto funcionamiento del servidor OAI-XML.

La primera es una colección de encabezados que contienen los metadatos de algunos documentos de la colección de Tesis Digitales. La segunda es una colección de documentos XML que describen Manuscritos Antiguos y que fue proporcionada por la Universidad de Valladolid en España.

4.1 Colección de encabezados para la colección de Tesis Digitales

Para esta colección sólo se utilizó la herramienta de configuración ya que los encabezados fueron generados de forma manual, sin utilizar la herramienta para la generación de encabezados. El propósito de esta colección fue la de permitir ver la utilidad que brinda la sección nombrada como “extra”, ya que en esta sección se incluyeron algunos otros elementos o “tags” que fueron utilizados para definir otro formato de metadatos para que dicha colección no estuviera limitada sólo a la utilización del estándar de metadatos Dublin Core.

Se generaron más de 700 encabezados y se almacenaron en una colección. Posterior a eso se utilizó la herramienta de configuración para generar el archivo de configuración de esta colección de encabezados.

Las pruebas hechas sobre esta colección sirvieron de base para el diseño y la implementación de la herramienta para la generación de encabezados y de esta manera, evitarle al usuario una tediosa generación manual de los encabezados para su colección.

En la figura 13 se muestra un ejemplo de los encabezados generados y en la figura 14 se muestra el archivo de configuración que fue generado para esta colección.

INSERT LATER

Figura 13. Ejemplo de un encabezado para la colección de Tesis Digitales

INSERT LATER

Figura 14. Archivo de configuración para la colección de Tesis Digitales

4.2 Colección de manuscritos antiguos

Esta colección consta de 301 documentos XML que describen Manuscritos Antiguos. Estos documentos se almacenaron en una colección, posteriormente se utilizó la herramienta para la generación de sus encabezados, generándose 301 encabezados. Después se utilizó la herramienta de configuración y se generó y almacenó el archivo de configuración.

Esta colección no define conjuntos y se nos indicó qué consultas en XPath deberían hacerse para obtener el contenido de los elementos utilizados en cada encabezado. Los Manuscritos que se describen datan del siglo X y por tal razón no se tiene una descripción precisa sobre el mes y el día de su creación. Se acordó entonces agregar mediante consultas en XPath, un año y un día y por simplicidad se acordó agregar “01” para mes ydía. De manera adicional se definieron consultas en XPath para obtener fragmentos que podrían ser de utilidad para el administrador de esa colección (en este caso la Universidad de Valladolid) y se colocaron en la sección definida como “extra” dentro de cada encabezado. También se modificó la consulta en XPath para obtener la descripción de cada Manuscrito y de esta manera desplegar el siglo en el que fue hecho cada Manuscrito.

En la figura 15 se muestra un ejemplo de los encabezados generados y en la figura 16 se muestra el archivo de configuración que fue generado para esta colección.

INSERT LATER

Figura 15. Ejemplo de un encabezado para la colección de Manuscritos Antiguos

INSERT LATER

Figura 16. Archivo de configuración para la colección de Manuscritos Antiguos

5. Conclusiones

XOAI proporciona una plataforma sencilla para la generación automática de servidores OAI para colecciones almacenadas en bases de datos XML, específicamente bases de datos XML nativas.

Las herramientas desarrolladas permiten que cualquier colección de documentos XML pueda ser configurada para compartir sus metadatos a través de un servidor OAI-XML. Proporcionan una forma sencilla para configurar dichas colecciones y permiten contar con una implementación única de los servidores OAI-XML, evitando con ello la necesidad de lidiar con aspectos de configuración.

El diseño y la implementación realizados bajo el modelo MVC (Modelo-Vista-Controlador) permiten que el usuario tenga el control total sobre la presentación final de las respuestas que el servidor envía al cliente; así como del funcionamiento del propio servidor. Con esto podemos decir que se aprovechó al máximo las ventajas que ofrece XML para lograr la separación entre los datos obtenidos y la presentación final de los mismos y que además se pudo demostrar su utilidad como mecanismo para definir aspectos de configuración y funcionamiento, a través de la generación y utilización de archivos de configuración que rigen el funcionamiento de cada servidor OA-XML.

El estado actual de las herramientas desarrolladas permite configurar fácilmente servidores OAI-XML. La utilización de los encabezados , específicamente la colocación de fragmentos de cada documento XML en la sección nombrada como “extra”, aporta flexibilidad para la generación de otros formatos de metadatos; sin embargo, no se proporciona una herramienta que permita actualizar dichos encabezados y la única forma que se tiene de hacerlo es mediante una regeneración completa a partir de la colección actualizada. La solución a esto sería el agregar una herramienta que permitiera actualizar ciertos encabezados ya sea de forma parcial o total o actualizar todos los encabezados pero sólo partes específicas de éstos, como podrían ser las secciones nombradas como “extra” de cada encabezado.

6. Trabajo a futuro

El estado actual del proyecto permite definir los siguientes puntos como trabajo a futuro:

  • Definir herramientas que permitan la actualización de los encabezados , a través de la utilización de un lenguaje de actualización para documentos XML como XUpdate.
  • Definir herramientas que de forma visual permitan la generación, al menos parcial, de hojas de estilo que el usuario utilizaría para agregar otros formatos de metadatos o simplemente para definir otros formatos de respuestas que el servidor deberá tomar en cuenta. De esta manera el usuario tendría una forma sencilla de generar sus hojas de estilo y de manera inmediata podría ir viendo los resultados que se obtendrían al aplicar las transformaciones especificadas en esas hojas de estilo.
  • Fomentar el uso de las herramientas desarrolladas en otros grupos de investigación para obtener cierta retroalimentación al utilizar nuevos y diferentes tipos de colecciones de documentos XML.

Referencias

  • Chaudhri,A. et al 2003. XML Data Management: Native XML and XML-Enabled Datadase Systems . Pearson Education Press.
  • Graves M. 2002. Designing XML Databases . Prentice Hall, New Jersey.
  • Gutiérrez, A. & Martínez, R. 2001. XML a través de ejemplos . Alfaomega, Ra-ma.
  • Horton,I. 2003 . J ava 2. SDK 1.4 Edition . Wiley Publishing.
  • Perkins,J. A new way of making cultural information resources visible on the web: Museums and the Open Archives Initiative . 2001. CMI Consortium, disponible en:
    http://www.archimuse.com/mw2001/papers/perkins/perkins.html, último acceso en abril de 2005
  • Proal, C. 2000. UVA : Interfaces para la visualización de grandes colecciones digitales . Tesis de Licenciatura Departamento de Sistemas Computacionales, Universidad de las Américas-Puebla. Cholula, Puebla.
  • Proal, C. 2003. Modelos alternativos para almacenamiento y recuperación de información de bibliotecas digitales . Tesis de Maestría, Departamento de Sistemas Computacionales, Universidad de las Américas-Puebla. Cholula, Puebla.
  • Sánchez, J.A. , Proal, C. , Maldonado-Naude,F. 2004. Supporting Structured, Semi-Structured and Unstructured Data in Digital Libraries. Encuentro de Ciencias de la Computación (ENC 2004, septiembre).
  • Sánchez J. A.. 2000. Bibliotecas Digitales Interoperables y de Alto Rendimiento en el Contexto de la Iniciativa Open Archives , Reporte Interno. ICT. Laboratorio de Tecnologías Interactivas y Cooperativas, Universidad de las Américas - Puebla.
  • Steegmans.B. et al . 2004. XML for DB2 Information Integration . IBM RedBooks. Disponible en:
    http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246994.html?Open, ultimo acceso en abril de 2005.
  • Takagiwa, O. et al. 2002. The XML Files: Development of XML/XSL Applications Using WebSphere Studio Version 5 . IBM RedBooks. Disponible en:
    http://www.redbooks.ibm.com/abstracts/sg246586.html, ultimo acceso en abril de 2005.
  • Van de Sompel, H. & C. Lagoze. The Santa Fe Convention of the Open Archives Initiative. D-Lib Magazine 2000, disponible en:
    http://www.dlib.org/dlib/february00/vandesompel-oai/02vandesompel-oai.html,último acceso en abril de 2005.
  • Van de Sompel, H. & C. Lagoze. The Open Archives Initiative: Building a low-barrier interoperability framework . 2001, disponible en:
    http://www.openarchives.org/documents/jcdl2001-oai.pdf, último acceso en abril de 2005.
  • Villegas, A. 2005. VOAI , Generador de Servidores . Tesis de Licenciatura Departamento de Sistemas Computacionales, Universidad de las Américas-Puebla. Cholula, Puebla.
  • Warner, S. Exposing and Harvesting Metadata Using the OAI Metadata Harvesting Protocol: A Tutorial. 2001. HEP Libraries Webzine. Disponible en:
    http://library.cern.ch/HEPLW/4/papers/3/, último acceso en abril de 2005.
  • Xalan. 2005. Manual de referencia . The Apache Software Foundation, disponible en:
    http://xml.apache.org/xalan-j/, ultimo acceso en abril de 2005.

About XOAI


Descripción


Descarga


Uso


Trabajo relacionado


English version