2. Historia y desarrollo del OAI-PMH

Contenidos de esta parte de OAI para principiantes, tutorial en línea del Open Archives Forum

• Origen del OAI-PMH
  
• El encuentro de Santa Fe
  
• Desafíos y soluciones propuestas
  
• El alba de un protocolo
  
• Historial de versiones OAI-PMH
  
• Implementación flexible: diversas opiniones sobre como implementar OAI-PMH
  
• Resumen
  
• Siete definiciones importantes
  
• Fuentes de información adicional
  

Los orígenes de la OAI se encuentran en el desarrollo de los repositorios (denominados archivos) de e-print (ediciones preliminares electrónicas). Los repositorios de e-print se crearon con el fin de comunicar los resultados de la investigación académica en curso antes de la evaluación por pares y su publicación en una revista científica. El primero de ellos fue xxx (posteriormente arXiv), que comenzó cubriendo la física de las altas energías en 1991 y fue más tarde ampliado para abarcar la física, más los campos relacionados de matemáticas, ciencias no lineales e informática. Le siguió CogPrints para la psicología, la lingüística y la neurociencia. La Networked Computer Science Technical Reference Library (NCSTRL) proporcionaba acceso a los informes técnicos sobre ciencias de la computación, ya fuesen depositados en xxx o en repositorios departamentales de las instituciones de investigación colaboradoras. Del mismo modo, RePEc proporcionaba a a los autores del campo de la economía la posibilidad de enviar documentos de trabajo a sus archivos departamentales o, si no había ninguno, al archivo EconWPA de la Washington University. Además, la Networked Digital Library of Theses and Dissertations (NDLTD) construyó una biblioteca digital de tesis y tesinas electrónicas, realizadas por los estudiantes de las instituciones asociadas.

En todos los casos, el mecanismo para alimentar estos repositorios era a través del depósito del autor. (Dentro de la OAI, y para los fines de este tutorial, un e-print se define como un documento archivado por el propio autor). Las interfaces web permitían interactuar con estos repositorios y se proporcionaban algunas herramientas de búsqueda.
Se diseñaron diferentes interfaces para los distintos repositorios, por lo que los usuarios finales se veían obligados a aprender distintas interfaces para acceder a los diferentes repositorios y herramientas de búsqueda. El "protocolo de Guildford" proporcionaba interoperabilidad entre los archivos RePEc, mientras que los repositorios NCSTRL empleaban el protocolo Dienst. Estos protocolos hicieron posible varios servicios al usuario final, incluyendo la búsqueda y navegación por los repositorios de cada grupo. NDLTD elaboró un flujo de trabajo para el envío de material, y desarrolló un XML DTD (Document Type Description) para ETDs electrónicas, además de proporcionar una biblioteca digital de ETDs. Sin embargo, en este contexto diverso poco o nada se hizo a favor del intercambio de metadatos autónomos, y aún, en el ámbito de los nuevos instrumentos de comunicación académica, fueron tomando formas más iniciativas independientes. Durante este proceso determinados actores clave llegaron a constatar que la interoperabilidad era una cuestión cada vez más importante que debía abordar la comunidad e-print.

"el impacto conjunto de estas y futuras iniciativas puede ser sustancialmente superior cuando se pueda establecer la interoperabilidad entre ellos [archivos de e-print]"
(Ginsparg, Luce, Van de Sompel, UPS Call, July 1999)

Se habían identificado dos de los principales problemas de interoperabilidad desfavorables para la repercusión de los archivos de e-prints: los usuarios finales se enfrentaban a múltiples interfaces de búsqueda haciendo más difícil la búsqueda de recursos, y no existía ningún método automatizado para compartir los metadatos. Las soluciones que se estaban explorando incluían la búsqueda simultanea en varios archivos (por un lado) y la recolección de metadatos de los archivos (por otra parte) con el fin de proporcionar servicios de búsqueda centralizada. En julio de 1999 Paul Ginsparg, Rick Luce y Herbert Van de Sompe de Los Alamos National Laboratory envió una convocatoria a un grupo restringido de expertos técnicos para asistir a una reunión de Santa Fe, New Mexico en octubre del mismo año. Ginsparg se dedicaba a arXiv, y Van de Sompel estaba entonces asociado a la Universidad de Gante. Propusieron la creación de un servicio universal para el autoarchivo por parte de los autores de documentos académicos (Universal Preprint Service, o UPS). El UPS sería "una capa básica y libre para la información académica, por encima de la que podrían prosperar tanto servicios gratuitos como servicios comerciales". Los primeros pasos para su creación sería la identificación o creación de tecnologías y marcos de interoperabilidad para la difusión de e-prints. Esto se anunció a un público más amplio bajo el titular "la Open Archive Iniciative se dirige a la promoción de soluciones de autoarchivo de autor".

Los objetivos del encuentro de Santa Fe eran: debatir las cuestiones relativas a la interoperabilidad, acordar el inicio de los trabajos en un prototipo promocional de un servicio de biblioteca digital basándose en los principales repositorios de e-prints existentes, y establecer un foro para la continuación de los trabajos sobre la interoperabilidad de soluciones de autoarchivo. Para preparar el encuentro, se emprendieron algunas trabajos previos. Van de Sompel inició un proyecto que simulaba algunos aspectos de la interoperabilidad de archivos de e-prints distribuidos. Thomas Krichel (University of Surrey & RePEc) experimentó con la conversión de datos de iniciativas de e-prints existentes a metadatos ReDIF, formato empleado por en RePEc. Michael Nelson (NASA Langley) tomó estos datos y los utilizó para crear varios archivos construidos siguiendo las líneas de su concepto de Smart Object Dumb Archives. Los datos utilizados provenían de CogPrints, NASA, NCSTRL, RePEc y xxx. El objetivo de este trabajo no fue posicionarse acerca del camino a seguir en la arquitectura del UPS, sino facilitar el debate acerca de ello en el encuentro de octubre.

¿Búsqueda simultánea o recolección?

La elección de que camino tomar en el desarrollo de un marco arquitectónico para la UPS fue una cuestión clave en esta etapa inicial. Dos posibles enfoques fueron la búsqueda simultánea de múltiples archivos a partir de un protocolo como el Z39.50, o bien la recolección de metadatos en uno o más servicios "centrales", moviendo los datos en masa y poniéndolos más cerca de la interfaz de usuario.

La experiencia en bibliotecas digitales indicaba que la búsqueda simultánea no era fácilmente escalable, pues el servicio de búsqueda se degrada al nivel del servidor más lento y menos fiable del conjunto objeto de la búsqueda simultánea. Por ejemplo, NCSTRL encontró que la búsqueda distribuida de un pequeño número de nodos era viable, pero era muy mala para más de 100 nodos. En el Reino Unido, la Resource Discovery Network (RDN) descubrió que incluso con la búsqueda en sólo cinco portales simultaneamente había problemas de bajo rendimiento y de disponibilidad de la interfaz de navegación, y los desarrolladores buscaron una solución factible de una base de datos centralizada. Cuantos más servidores se busquen simultáneamente, mayor es la probabilidad de encontrar algún servidor más lento o poco fiable.

También existe el problema de saber que servidores emplear para una búsqueda simultanea. Las descripciones de colecciones- donde acaso estén disponibles - pueden ser inconsistentes de uno a otro repositorio, no fueron diseñadas para la comunicación máquina-máquina y requieren un examen que lleva mucho tiempo al usuario final. Las diferencias en la sintaxis de los lenguajes de consultas y la variación de las características de la búsqueda (entre servidores y con el paso del tiempo) introducen complejidad, sea para el usuario final como para el software de búsqueda simultánea, o para ambos. La agrupación ordenada de resultados de servidores distribuidos presenta aún más problemas técnicos y de la interfaz de usuario, y el diferente tamaño y tipología de las bases de datos objeto de la búsqueda simultánea pueden sesgar los resultados. Una interfaz de navegación es muy difícil de construir cuando los metadatos por los que vamos a navegar están distribuidos por una serie de repositorios. Se sugirió que una solución sería reunir todos los registros de metadatos en un solo lugar.

El prototipo de UPS aportado en el encuentro de Santa Fe mostraba una biblioteca digital de varios archivos proporcionando servicios a partir de una colección de metadatos recolectados desde varios archivos. Su arquitectura hacía uso de NCSTRL y de una versión modificada del protocolo Dienst. De esta manera, el número de nodos que se buscaban podría reducirse a uno, proporcionando una mejora significativa del rendimiento. Se podía proporcionar un servicio de búsqueda utilizando un lenguaje de consulta, un conjunto de atributos de búsqueda y un algoritmo de ordenación de resultados. Además, el disponer de los metadatos hace más fácil construir estructuras de navegación por ellos.

Proveedores de Datos y Proveedores de Servicios

La arquitectura UPS identifica dos funciones lógicas: "Proveedores de Datos" y "Proveedores de Servicios". Los Proveedores de Datos manejan el depósito y la publicación de los recursos en un repositorio y "exponen" los metadatos de los recursos del repositorio para que puedan ser recolectados. Ellos son los creadores y conservadores de los metadatos y de los repositorios de recursos. Los Proveedores de Servicios recolectan los metadatos de los Proveedores de Datos. Ellos emplean los metadatos recolectados con el fin de proporcionar servicios. El tipo de servicios que se pueden ofrecer son: una interfaz de búsqueda, un sistema de evaluación por pares, etc. Hay que tener en cuenta que una organización 'proveedora' puede desempeñar ambas funciones, tanto proporcionar datos para su recolección como servicios para el usuario final. El cambio clave de arquitectura fue el alejarse de los interfaces dirigidos exclusivamente a usuarios humanos, y proporcionar interfaces a los repositorios tanto a usuarios humanos como a máquinas para la recolección.

En seguida se cambió el nombre de UPS (Universal Preprint Service), en parte, para evitar posibles dificultades relacionadas con el hecho de que UPS es una marca comercial de un servicio de entrega de paquetes, y en parte porque se reconoció que no todos los e-prints son preprints. El proyecto en el que este servicio universal ahora se desarrollaría se llamó Open Archives initiative - abreviado OAi, después OAI - nombre que se había extendido en los debates previos.

De los debates y de las experiencias se desprendía que, a fin de facilitar la recolección de de metadatos debía haber un acuerdo en torno a:

• Un protocolo de transporte - por ejemplo HTTP o FTP
• Un formato de metadatos - por ejemplo, MARC o Dublin Core, por ejemplo
• Una base para el control de calidad de los metadatos - conjunto de elementos obligatorios, convenciones sobre nombres y materias, etc.
• Propiedad intelectual y derechos de uso - ¿quién puede hacer qué con qué?

El acuerdo inicial en los temas clave permitió desarrollar un protocolo para la recopilación de metadatos, llamado el Convenio de Santa Fe, en honor al encuentro donde se alcanzó este acuerdo.

La Convención de Santa Fe fue la primera encarnación de la Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH). Se basaba en el prototipo de UPS, en el modelo RePEc / Servicio SODA / Proveedor de datos, el Protocolo Dienst, y la labor del grupo de Santa Fe.
El eje de la Convención de Santa Fe era "optimizar la búsqueda de e-prints".

El OAI-PMH 1.0 introdujo el conjunto de elementos de Dublin Core no cualificado definido como un mínimo para la interoperabilidad de los metadatos. Se basaba en la Convención de Santa Fe, las reuniones de la Digital Library Federation, el trabajo en la Cornell University, y los comentarios de los alfa-testers. Se amplió el enfoque para facilitar la búsqueda de todos aquellos "objetos tipo documento". Se trata de una especificación de interoperabilidad de nivel bajo, basado en un modelo de recolección de metadatos. Se basaba en HTTP, empleando peticiones HTTP GET / POST y respuestas XML. Hay que tener en cuenta que no se trata de un protocolo de búsqueda, si no que se basa en el modelo de la recolección de metadatos. OAI-PMH 1.1 fue una revisión de la especificación 1.0 que tenía en cuenta los cambios de la nueva especificación XML Schema. Tanto las versiones 1.0 como la 1.1 fueron de naturaleza experimental.

El OAI-PMH 2.0 es una revisión profunda del protocolo, y no es compatible con v.1.x. Se basaba en el OAI-PMH 1.x, los comentarios de la lista OAI Implementers, las deliberaciones del foro OAI Tech, y los comentarios de los alfa-testers. Una vez más el objeto del protocolo se amplía y ahora se dice que se trata "el intercambio recurrente de metadatos de recursos entre distintos sistemas". Todavía es una especificación de interoperabilidad de bajo nivel basado en un modelo de la recolección de metadatos. La v.2.0 es un protocolo estable, no experimental y OAI y se ha comprometido a que las revisiones posteriores del protocolo sean compatibles hacia atrás.

OAI-PMH posibilita una implementación flexible. Debido a que es un protocolo sencillo basado en HTTP y XML, permite una implementación rápida. Hay disponibles un cierto número de herramientas de desarrollo, que se discutirán más adelante en este tutorial. Los sistemas pueden ser desplegados en una gran variedad de configuraciones, como se ilustra en los siguientes diagramas. Los metadatos y el texto completo de los recursos se suelen poner accesibles libremente, pero esto no es un requisito. El OAI-PMH también puede utilizarse entre grupos cerrados, para la distribución de metadatos únicamente, y en aplicaciones comerciales.

Varios Proveedores de Servicios

Varios Proveedores de Servicios pueden recolectar a varios Proveedores de Datos.

Agregadores

Los Agregadores se sitúan entre Proveedores de Datos y Proveedores de Servicios.

Recolección combinada con búsqueda

El enfoque de la recolección se puede completar con la
búsqueda basada, por ejemplo, en Z39.50 o SRW

Los primeros impulsores desarrollaron soluciones distintas, pero se reconocía la necesidad de la interoperabilidad. Como respuesta, el encuentro de Santa Fe dio como resultado un apoyo considerable a la OAI, que promueve la interoperabilidad a través del desarrollo del OAI-PMH como un estándar abierto, y la difusión de información acerca de OAI-PMH. OAI-PMH es un mecanismo de bajo costo para la recolección de registros de metadatos de un sistema a otro - de los Proveedores de Datos hacia los Proveedores de Servicios. Varios Proveedores de Servicios pueden recolectar a varios Proveedores de Datos, garantizando una mayor difusión de los metadatos. OAI-PMH no es un protocolo de búsqueda, pero su utilización puede servir de apoyo para los servicios de búsqueda, es una capa sobre la que construir otros servicios.

El desarrollo de los últimos dos a tres años ha visto como se pasa de lo específico a lo genérico - desde la búsqueda de los e-prints a compartir las descripciones de cualquier recurso. Aunque el Dublin Core no cualificado se establece como requisito para una interoperabilidad básica, OAI-PMH se puede extender a cualquier formato de metadatos que puedan ser codificados en XML. Se basa en HTTP para las peticiones (y control de acceso, compresión, códigos de error, etc.) y en XML para las respuestas, está adaptado a la web y por tanto, atraviesa con facilidad los cortafuegos. Eso permite a los Proveedores de Servicios decir "proporcióneme todos sus registros o solo algunos ", donde "algunos" se basa en fechas, sets o en formatos de metadatos. Simple y basado en la tecnología existente, OAI-PMH es fácil de implementar con muchas herramientas de desarrollo que pueden ocultar el protocolo a los desarrolladores.

E-print
Un e-print es un documento autoarchivado por su autor. Habitualmente se emplea este término en el sentido que el contenido del e-print es el resultado de la investigación científica o académica.

Objeto tipo documento
Un objeto tipo documento es una unidad de información digital comparable a un documento de papel. El término designa un recurso relativamente simple y estable. No incluye, por ejemplo, artefactos multimedia o servicios interactivos.

Recurso
Un recurso es algo que tiene identidad. Son ejemplos típicos: un documento electrónico, una imagen, un servicio (p. ej., el informe meteorológico de hoy), y una colección de otros recursos. No todos los recursos son "recuperables" en la red; p.ej., los seres humanos, las empresas y los libros encuadernados de una biblioteca se les considera también recursos.
(Definición de Guidelines for implementing Dublin Core in XML de Andy Powell y Pete Johnston)

XML
XML es el acrónimo de Extensible Markup Language (Lenguaje de Marcado Extensible). XML es un lenguaje para crear otros lenguajes. Define una manera de describir la información. XML se puede validar con una DTD o esquema que recoge los elementos del lenguaje creado. Existen mapeos XML para un cierto número de formatos de registro de metadatos.

DTD
DTD es el acrónimo de Document Type Definition (Definición de Tipo de Documento). Un DTD es la especificación formal de la estructura de un documento.

Dublin Core
Dublin Core (DC) es un formato de metadatos definido por consenso internacional. El Conjunto de Elementos de Metadatos Dublin Core define quince elementos para la descripción y búsqueda de recursos sencillos, todos son recomendados, y ninguno obligatorios. DC se ha ampliado con más elementos opcionales, los elementos cualificadores y los vocabularios.
(Definición basada en metadata glossary de UKOLN y Metadata in a nutshell de Michael Day)

Interoperabilidad
La interoperabilidad es la capacidad de los sistemas, servicios y organizaciones para trabajar juntos de un modo transparente hacia objetivos comunes o diferentes. En el ámbito técnico se apoya, entre otros, en los estándares abiertos para la comunicación entre sistemas y para la descripción de recursos y colecciones. La interoperabilidad se considera aquí, principalmente en el contexto de la búsqueda y acceso a los recursos.

Artículos

Lynch, C.A. Metadata Harvesting and the Open Archives Initiative. ARL Bimonthly Report 217, August 2001
http://www.arl.org/newsltr/217/mhp.html

Van de Sompel, Herbert, Krichel, T., Nelson, M. L. and others. The UPS Prototype: An Experimental End-User Service across E-Print Archives. D-Lib Magazine, vol.6, no. 2. February 2000.
http://www.dlib.org/dlib/february00/vandesompel-ups/02vandesompel-ups.html

Van de Sompel, H., Lagoze, C. The Santa Fe Convention of the Open Archives Initiative. D-Lib Magazine, vol.6, no.2. February 2000.
http://www.dlib.org/dlib/february00/vandesompel-oai/02vandesompel-oai.html

Sitis Web

OAI Web site: http://www.openarchives.org/