Contenidos de esta parte de OAI para principiantes, tutorial en línea del Open Archives Forum
| General: cuestiones iniciales | Arriba |
Antes de implementar OAI-PMH, se deben tener en cuenta una serie de decisiones organizativas que afectarán a su implementación.
Proveedor de Datos
Proveedor de Servicios
Proveedor de Datos y Proveedor de Servicios
| General: formatos de metadatos | Arriba |
Como ya se ha señalado, Dublin Core (DC) no cualificado es el formato de metadatos básico necesario para la interoperabilidad. Sin embargo, algunas áreas temáticas y comunidades necesitan otras especificaciones de metadatos. Es posible que necesiten describir de forma especial recursos con estructuras complejas, como es el caso, por ejemplo, en la comunidad archivística. Cualquiera que sea el formato de metadatos elegido, se debe llegar a un acuerdo sobre su uso entre los Proveedores de Datos y los Proveedores de Servicios, y se debe poner a disposición del público la definición de un esquema XML para su validación. El procedimiento para definir y declarar un esquema XML se describe al final de este tutorial. Ya está disponible un esquema XML OAI-DC. Además, se puede encontrar otro esquema XML ya disponible que se ajuste a sus necesidades.
NOTA: En el momento de la preparación de este tutorial, se había iniciado una discusión en la comunidad OAI que puede dar lugar a un cambio de estatus del DC no cualificados de "obligatorio" a "recomendado". Visite el sitio oficial de OAI para conocer las últimas noticias sobre este tema.
| General: sets | Arriba |
El soporte para construir Sets es optativo en OAI. Sin embargo, los Sets han demostrado ser especialmente útiles en dar soporte a la prestación de servicios especializados basados en la recolección selectiva de metadatos. Los Sets definen grupos de metadatos en un repositorio, y los metadatos se pueden agrupar por cualquier característica que proporcione una partición razonable para una recolección selectiva. Algunos ejemplos de Sets definidos por organizaciones y comunidades son las que se basan en los títulos de revistas o publicaciones seriadas, en clasificaciones o categorías temáticas , en colecciones (por ejemplo, basadas en temas o disciplinas), en tipos de recursos y en autores. Los registros de metadatos individuales pueden incluirse en un set, o en más de uno, o en ninguno. Un repositorio puede soportar Sets basados en tantas definiciones de grupo como se considere útil.
Los Sets de OAI pueden ser jerárquicos. En este caso, los Sets hijos son recolectados como parte de su Set padre. El significado de la jerarquía de Sets no se define en el protocolo OAI. La definición de la jerarquía de sets puede ser interna en un repositorio, pero a menudo se fundamenta en un acuerdo entre los Proveedores de Datos o entre los Proveedores de Datos y los Proveedores de Servicios.
| General: estructura organizativa | Arriba |
Un agregador se puede establecer entre los Proveedores de Servicios y algunos Proveedores de Datos. En este caso, los Proveedores de Servicios deben conocer la identidad de los Proveedores de Datos que han sido agregados. Esto permite a los Proveedores de Servicios evitar los duplicados que pudieran surgir en la recolección del agregador y del Proveedores de Datos original.
Los Proveedores de Servicios que proporcionan portales temáticos serán capaces de implementar la recolección selectiva si los correspondientes Sets han sido definidos e implementados por los Proveedores de Datos que recolectan.
| General: herramientas para implementar OAI-PMH | Arriba |
Si bien es posible desarrollar uno su propio software OAI, esto no es necesario, ya que hay disponible una serie de herramientas de software, muchas de ellas bajo los términos de una licencia de código abierto (o similar). La OAI mantiene una lista de herramientas de software OAI (http://www.openarchives.org/tools/) con enlaces a las fuentes de esas herramientas. En el momento de la preparación de este tutorial, la lista incluye el Repository Explorer para la exploración y la validación de repositorios OAI, así como herramientas que soportan específicamente OAI-PMH, como GNU EPrints (eprints.org) de la Universidad de Southampton, DSpace de HP lab y MIT libraries, y PHP OAI Data Provider de Universidad de Oldenburg. Las herramientas que usted elija dependerá de consideraciones tales como el tipo de repositorio o servicio que se está implementando y las habilidades técnicas de las que dispone el equipo de desarrollo. Por ejemplo, si está creando un archivo de e-prints entonces es posible que desee considerar la posibilidad de utilizar el paquete de software GNU EPrints, por otra parte DSpace proporciona un marco de gestión digital de activos, que incluye consideraciones de preservación, y la ventaja que ofrece PHP OAI Data Provider es que soporta compresión inmediata con el fin de reducir de forma significativa la carga en la transferencia de datos. También se enumeran en OAI una serie de herramientas de software relacionadas con el XML y Unicode que pueden ser útiles para la implementación de Proveedores de Datos y de servicios conformes con OAI.
Además, una treintena de herramientas relacionadas con OAI se describen en el OA-Forum Final Report on Technical Issues (descargar en http://www.oaforum.org/documents/). Este informe también incluye una comparativa detallada de GNU EPrints y DSpace .
| Proveedor de Datos: requisitos previos | Arriba |
Estas son las cosas que debe, debería o puede tener en cuenta para implementar OAI-PMH como Proveedor de Datos:
| Proveedor de Datos: componentes y arquitectura | Arriba |
Componentes
El Analizador Sintáctico de Argumentos valida las peticiones OAI.
El Generador de Errores crea respuestas XML con los mensajes de error codificados
La Consulta a Base de Datos / Extracción de Metadatos Locales recupera los metadatos del repositorio, de acuerdo al formato de metadatos requerido.
El Generador XML / Creación de la Respuesta crea las respuestas XML con la información de los metadatos codificada.
El Control de Flujo lleva a cabo la secuencia de listados parciales para los repositorios "más grandes". Utiliza la señal de reanudación como mecanismo de control.
Este diagrama ilustra un ejemplo de arquitectura para un Proveedor de Datos.
| Proveedor de Datos: ejemplo de diagrama de flujo | Arriba |
Este diagrama de flujo de la recepción de una petición HTTP y el envío de la respuesta XML correspondiente. Es un ejemplo que muestra el procesamiento de una petición concreta.
Este es un diagrama de flujo del procesamiento de un ejemplo de petición a un Proveedor de Datos. En general, los rombos representan condiciones, y dentro de los rectángulos se describen, de modo informal, determinadas acciones. El Proveedor de Datos al recibir una petición OAI tiene que analizar la consulta y en primer lugar decidir de qué tipo es, dentro de los seis tipos válidos de petición , o si el tipo de petición es ilegal. En el segundo caso (el parámetro Verb tiene un valor no estándar) se traduce en un mensaje de error al Proveedor de Servicios (badVerb). En caso de que el tipo de petición suministrado sea ListIdentifers el analizador sintáctico tiene que comprobar el siguiente parámetro metadataPrefix, pues este argumento es obligatorio para la petición ListIdentifiers.
Si no se ha proporcionado ningún parámetro la única posibilidad de que la petición sea válida es que tenga un parámetro resumptionToken que debe ser conocido por el Proveedor de Datos. En este caso, el Proveedor de Datos lee los parámetros, almacenados localmente, que representan los argumentos de la petición original y la información que indica cuantos identificadores han sido proporcionados ya al Proveedor de Servicios. Si el argumento resumptionToken está vacío o tiene un valor desconocido se tienen que generar entonces un mensaje de error.
El único valor válido del parámetro metadataPrefix es oai_dc porque suponemos que el Proveedor de Datos del ejemplo sólo puede ofrecer Sets de metadatos en el esquema Dublin Core no cualificado. Si este el caso los otros parámetros opcionales, que en el gráfico están descritos de manera informal en aras de la simplicidad, tienen que ser validados por el analizador sintáctico. Los parámetros permitidos son from, until y set. En este proceso, se deben proporcionar mensajes de error si los parámetros tienen valores ilegales o si la consulta contiene otros parámetros no permitidos para este tipo de petición.
Posteriormente, los parámetros recibidos proporcionados por la consulta, o - en caso de una consulta resumptionToken reanudada - leída desde el sistema local tiene que ser ensamblada en una consulta SQL que luego se debe enviar a la base de datos. Si esto produce más de 100 registros (100 en el ejemplo es el número máximo de identificadores entregados de una vez), el Proveedor de Datos tiene que generar una nueva señal de reanudación y almacenarla localmente, junto con los parámetros de la consulta y la información de cursor. La señal de reanudación ha de incluirse también en la respuesta XML al Proveedor de Servicios. Por supuesto, la respuesta XML también contiene los identificadores devueltos por la base de datos.
| Proveedor de Datos: señal de reanudación | Arriba |
Este diagrama ilustra el empleo de la señal de reanudación para controlar el flujo del diálogo entre un Proveedor de Servicios y un Proveedor de Datos.
La señal de reanudación debe aplicarse para el manejo de listados "largos" . El Proveedor de Datos lo inicia, y se utiliza para almacenar parámetros (como set o from) y el número de registros ya enviados.
La señal de reanudación puede tener opcionalmente los siguientes elementos XML dando una pista al Proveedor de Servicios de la longitud total prevista del listado:
El protocolo exige a los Proveedores de Datos la capacidad para responder correctamente si se le reenvía la señal de reanudación más reciente de una consulta. Esta característica permite a los Proveedores de Servicios recuperarse de los errores de red sin necesidad de volver a enviar el listado completo desde el principio.
| Proveedor de Datos: señal de reanudación y cambios en la base de datos | Arriba |
Hay un problema con respecto a la implementación de la señal de reanudación si la base de datos cambia durante una operación de recolección, como se ilustra en el siguiente diagrama. El gráfico muestra el caso posible de que entre la primera petición y la petición de reanudación el contenido de la base de datos del Proveedor de Datos ha cambiado. Si el Proveedor de Datos solo recuerda el número total de registros ya entregados de la petición, la mezcla con los listados de la reanudaciones puede ocasionar inconsistencias. Hay dos posibles soluciones. Una solución es duplicar los datos en una "tabla de petición". La otra es almacenar la fecha de la primera petición con el resto de parámetros y utilizarlo como argumento adicional until.
| Proveedor de Datos: representación de datos | Arriba |
Los Proveedores de Datos deberían utilizar las siguientes representaciones de datos recomendadas.
Los Proveedores de datos deberían utilizar un elemento XML separado para cada entidad en el caso de los múltiples valores de un dato, como en los siguientes ejemplos.
| Proveedor de Datos: compresión | Arriba |
La compresión en un método para reducir el tráfico y mejorar el rendimiento. Es opcional para los Proveedores de Datos y Proveedores de Servicios. La compresión se maneja al nivel de HTTP.
Los recolectores pueden incluir una cabecera Accept-Encoding en sus peticiones para especificar las preferencias de compresión. Los recolectores sin cabecera Accept-Encoding siempre recibirá los datos sin comprimir.
Los repositorios deben soportar codificación HTTP identity. Los repositorios deberían especificar las codificaciones soportadas mediante la inclusión de elementos compression en la respuesta a identify.
| Proveedor de Datos: pruebas | Arriba |
Cuando considere que su aplicación esté preparada para ejecutarse, cree algunas peticiones OAI-PMH, envíelas a su interfaz OAI y compruebe los resultados.
Para ello puede utilizar el Repository Explorer de la Universidad de Vermont (http://re.cs.uct.ac.za/) navegando por su repositorio. Repository Explorer nos permite de forma automática e interactiva probar la conformidad de nuestro repositorio. Le permite proporcionar argumentos a través de formularios HTML. Las respuestas se validan conforme a OAI-PMH.
Le permite verificar su repositorio frente a cada uno de los verbos OAI-PMH uno a uno, establecer los parámetros necesarios de tiempo, prefijo de metadatos, identificación, Set, y señal de reanudación. De este modo, se pueden probar todos los aspectos del protocolo, y verificar la conformidad de los resultados de las consultas con la sintaxis prevista.
Repositorio Explorer soporta las siguientes lenguas: chino, inglés, español, francés, alemán, coreano y portugués. Se puede elegir cómo se muestran los resultados, en XML original, XML descompuesto, o ambas . Hay también disponibilidad para validación de esquemas.
| Proveedor de Datos: registro | Arriba |
Una vez que se ha asegurado que su aplicación funciona según lo previsto, puede registrarla en el sitio oficial de registro de Proveedores de Datos. (http://www.openarchives.org/data/registerasprovider.html)
El registro requiere que proporcione el URL Base de su implementación Proveedora de Datos. OAI realiza entonces un test amplio de conformidad (incluyendo pruebas de estados de error, entre otras), y le proporcionará información sobre comportamientos incorrectos (si los hubiese). En caso de conformidad, su implementación Proveedora de Datos se añadirá a la lista oficial. OAI realiza controles periódicos de los Proveedores de Datos registrados para confirmar que todo está bien.
| Proveedor de Servicios: requisitos previos | Arriba |
Hay tres requisitos de infraestructura técnica previos para implementar un Proveedor de Servicios OAI-PMH que recolecte metadatos de Proveedores de Datos por medio de OAI-PMH:
| Proveedor de Servicios: componentes y arquitectura | Arriba |
La gestión de archivos implica la selección de los repositorios a recolectar. Las entradas de la lista de repositorios a recolectar pueden incluirse manualmente o bien añadir o eliminar automáticamente mediante el registro oficial.
El componente de peticiones crea las peticiones HTTP y las envía a los repositorios OAI (Proveedores de Datos). El solicita los metadatos empleando los verbs permitidos en OAI-PMH. Se puede hacer recolección selectiva utilizando parámetro set.
El programador de tareas lleva a cabo la recuperación regular y sincronizada de los archivos asociados. El caso más sencillo sería el inicio manual de las tareas, pero se puede automatizar, por ejemplo, como una tarea cron.
El control de flujo se implementa a través de la señal de reanudación, dividiendo el listado de resultados en secciones incompletas con una nueva solicitud para obtener más resultados. Un error HTTP 503 (servicio no disponible) permite el análisis de la respuesta para extraer un periodo "reintentar después de".
El mecanismo de actualización ejecuta la consolidación de los metadatos que han sido recolectados con anterioridad (agrupación de los metadatos antiguos y los nuevos). El caso más sencillo sería borrar todos los metadatos "antiguos" de cada repositorio antes de recolectarlos de nuevo. Una alternativa razonable es hacer una actualización incremental (de parámetro) - introducir nuevos metadatos y sobrescribir los metadatos cambiados o borrados (asignación realizada utilizando identificadores únicos) .
El analizador sintáctico de XML examina las respuestas recibidas de los repositorios, las valida utilizando el esquema XML, y convierte los metadatos codificados en XML a la estructura de datos interna.
El normalizador transforma los datos en diferentes formatos de metadatos en una estructura homogénea. Por ejemplo, unifica la representación de la fecha, el autor, el código de lenguaje. Puede establecer equivalencias o traducir entre diferentes lenguajes.
La base de datos recibe el resultado de la equivalencia, realizada por el normalizador, entre la estructura XML de los metadatos y la base de datos relacional que gestionará los valores de los elementos. Una alternativa es utilizar una base de datos XML.
El detector de duplicados fusiona registros idénticos de diferentes Proveedores de Datos. Una de las posibilidades para implementarlo es a través de un identificador único para cada ítem (por ejemplo, el URN). Sin embargo, esta solución no suele ser factible y no está libre de riesgos o errores.
El módulo de servicios proporciona el servicio real al "público". El fundamento de la provisión de servicios es la recolección y almacenamiento de los registros de los archivos asociados. Es decir, que únicamente utiliza la base de datos local para las peticiones etc., y, por tanto, no realiza llamadas a los Proveedores de Datos durante el proceso.
| Proveedor de Servicios: señal de reanudación | Arriba |
La señal de reanudación es opcional desde el punto de vista de los Proveedores de Datos. Sin embargo, es obligatorio para los Proveedores de Servicios con el fin de recuperar listas completas en respuesta a las peticiones del protocolo que devuelven listas (ListRecords, ListIdentifiers, ListSets) a fin de reanudar la secuencia de los listados incompletos. Para proporcionar control de flujo, la señal de reanudación debe "reconocer" que la respuesta del Proveedor de Datos contiene una lista incompleta y reenviar entonces la petición OAI al Proveedor de Datos para obtener la siguiente parte del listado.
| Proveedor de Servicios: prueba y registro | Arriba |
Pruebe su implementación OAI-PMH recolectando Proveedores de Datos registrados (conformes OAI). Existe una lista de Proveedores de Datos registrados en el sitio Web de la OAI, enlazada desde la página Community , bajo el encabezamiento Interoperability Participants. Dependiendo del servicio que proporcione, usted puede tener planificado recolectar Proveedores de Datos que no aparecen aquí. Sin embargo, las pruebas de su aplicación, con algunos de los Proveedores de Datos registrados le asegurará que usted tiene un recolector OAI-PMH que funciona.
Este tutorial no se ocupa de como implementar servicios para el usuario final, sólo de la puesta en marcha de la recolección de registros sobre los cuales se basan, al menos en parte, estos servicios (Al final de esta parte del tutorial, se proporcionan algunos ejemplos de diferentes tipos de servicios basados en OAI.) Una vez que Ud. haya probado el comportamiento de su Proveedor de Servicios de recolección, y una vez que se ha asegurado usted mismo que la aplicación que proporciona el servicio al usuario final está funcionando como se esperaba, puede registrarse como Proveedor de Servicios en el sitio oficial de registro (http://www.openarchives.org/service/registerasprovider.html). Se le pedirá que proporcione el nombre completo de su servicio, una descripción del tipo de servicio, la cobertura ofrecida (es decir, disciplina o temática), la dirección URL de una página Web asociada a su servicio, la dirección de correo electrónico de una persona de contacto, y una lista de los Proveedores de Datos que recolecta. Esto será en forma de página Web que usted pone en su propio servidor para facilitar la actualización, y para lo cual se proporciona una plantilla HTML. Usted simplemente tiene que enviar la dirección URL de esa página a OAI para que sea añadida a la lista de Proveedores de Servicios.
| Siete definiciones importantes | Arriba |
Metadatos
Información estructurada acerca de recursos (digitales y no digitales). Los metadatos se pueden utilizar para dar soporte a una amplia gama de operaciones sobre esos recursos. En el contexto de los servicios basados en metadatos recolectados a través de OAI-PMH, la operación más común es la búsqueda y recuperación de recursos
Uso aceptable
Términos y condiciones que establece qué pueden hacer los Proveedores de Servicios con los metadatos recolectados de un Proveedor de Datos o grupo de Proveedores de Datos. En la reunión de Cornell (septiembre de 2000), donde se acordaron las bases del protocolo OAI, se hizo la elección explícita de trasladar los temas en torno al uso aceptable a las comunidades que implementan el protocolo OAI.
El OAI-PMH no se ocupa de cuestiones del uso aceptable de los metadatos recolectados, aunque sí permite la inclusión de un contenedor "acerca de" adjunto a cada registro de metadatos recolectado. Normalmente este tipo de contenedor "acerca de" se podría utilizar para especificar los términos y condiciones de la utilización de un registro de metadatos. De esta manera, las comunidades individuales pueden expresar los términos y condiciones relativas a la utilización de metadatos a nivel de registros individuales. Además, a nivel de repositorio, la respuesta al verbo Identify permite la posibilidad de incluir un contenedor abierto de "descripción". Las comunidades pueden utilizar este contenedor para incluir información de los términos y condiciones para todos los registros de metadatos del repositorio. Desde una perspectiva técnica, éstos proporcionan una forma que permite a las comunidades especificar los términos y condiciones para el uso de metadatos recolectados a partir de sus repositorios.
Agregador
Un agregador OAI es un Proveedor de Servicios y un Proveedor de Datos. Es un servicio que reúne metadatos de varios Proveedores de Datos y después los pone a disposición de otros empleando OAI-PMH.
Control de flujo
La gestión del control de flujo entre el Proveedor de Datos y Proveedor de Servicios
para asegurar que ninguno de los extremos de la transacción sufre sobrecarga.
Representación de datos
En este contexto, el formato en el que se dispone un tipo particular de dato con el fin de proporcionar interoperabilidad entre los repositorios.
Servicio de valor añadido
Un servicio que se basa en la recolección de metadatos, y añade valor para sus usuarios a través de, por ejemplo, la normalización y el enriquecimiento de los metadatos recolectados. Algunos servicios, entre otros, son: servicios de búsqueda, enlace a las citas, cubiertas de las revistas, servicios de revisión por pares.
Conformidad
Un repositorio se considera conforme con OAI si al probarlo con el protocolo OAI responde a cada una de las peticiones del protocolo con una respuesta válida con su esquema XML, y responde también a peticiones mal formadas con los errores y excepciones apropiados.
| Fuentes de información adicional | Arriba |
-- Sitios Web y listas de correo electrónico --
Open Archives Initiative (OAI)
sitio oficial
http://www.openarchives.org
OAI-PMH protocol specification
http://www.openarchives.org/OAI/openarchivesprotocol.htmlOAI-PMH implementation guidelines
http://www.openarchives.org/OAI/2.0/guidelines.htmOAI tools
http://www.openarchives.org/tools/OAI general mailing list
http://www.openarchives.org/mailman/listinfo/OAI-general/OAI implementers discussion list
http://www.openarchives.org/mailman/listinfo/OAI-implementers/
Open Archives Forum
http://www.oaforum.org
OA-Forum Review of Technical Issues
Linked from http://www.oaforum.org/documents/OA-Forum Information Resource
http://www.oaforum.org/oaf_db/
Dublin Core
http://dublincore.org
-- Ejemplos de herramientas --
Repository Explorer
http://re.cs.uct.ac.za//
GNU EPrints
http://software.eprints.org/
DSpace
http://www.dspace.org/
PHP OAI Data Provider
http://physnet.uni-oldenburg.de/oai/
-- Ejemplos de Proveedores de Servicios --
ARC - A Cross Archive Search Service (experimental research service)
http://arc.cs.odu.edu/
Dokumenten- und Publikationsserver der Humboldt-Universität zu Berlin (search service, German language user interface)
http://edoc.hu-berlin.de/oaisearch/
iCite (citation index)
http://icite.sissa.it/
NCSTRL—Networked Computer Science Technical Reference Library (search engine)
http://www.ncstrl.org/
my.OAI (value-added search interface to a selected list of metadata databases)
http://www.myoai.com/
Physnet (simple search interface to an experimental OAI harvester)
http://physnet.uni-oldenburg.de/oai/query.php
ProPrint (printing-on-demand service, German and English language user interfaces offered)
http://www.proprint-service.de/
Copyright © 2003 University of Bath. All rights reserved. Last modified: 14 Oct 2003 16:36
Authored in CALnet |
Traducción española de: Domingo Arroyo. Ministerio de Cultura, Dirección General de Libro Archivos y Bibliotecas. |