La interoperabilidad es uno de los pilares fundamentales de cualquier repositorio institucional moderno. Gracias al protocolo OAI-PMH (Open Archives Initiative – Protocol for Metadata Harvesting), plataformas como DSpace, Omeka, EPrints y muchos otros sistemas pueden intercambiar metadatos de forma estandarizada, permitiendo la construcción de bibliotecas digitales, portales nacionales, recolectores temáticos y servicios de preservación digital.
En teoría, si un proveedor OAI cumple correctamente con el estándar, cualquier consumidor debería poder cosechar sus registros sin inconvenientes.
En la práctica, sin embargo, las cosas no siempre son tan simples.
Durante el desarrollo de un proyecto basado en DSpace 7, nos encontramos con un escenario particularmente interesante: una colección OAI aparentemente perfecta, validada desde múltiples herramientas, era incapaz de finalizar su cosecha desde DSpace, mientras que otros sistemas la importaban sin ningún inconveniente.
Después de varias horas de análisis, pruebas cruzadas y descartes, descubrimos que el problema no estaba donde esperábamos.
Cuando el error parecía estar en el proveedor OAI
Todo comenzó con la configuración de una nueva colección cosechada desde un repositorio DSpace
La configuración era aparentemente sencilla:
- Proveedor OAI válido.
- Set existente.
- Formato de metadatos DIM.
- Colección correctamente registrada en DSpace.
La cosecha iniciaba normalmente. Los primeros registros eran importados correctamente. Posteriormente el proceso terminaba abruptamente mostrando un error bastante conocido para quienes trabajan con XML:
XML document structures must start and end within the same entityInmediatamente después aparecía otro error:
org.hibernate.LazyInitializationExceptionLa conclusión inicial parecía obvia:
"Existe un registro XML mal formado."
Era una hipótesis completamente razonable y fue precisamente la primera que intentamos demostrar.
Primera hipótesis: existe un XML inválido
La colección contenía 413 registros.
Lo primero fue descargar manualmente la respuesta completa del proveedor OAI utilizando la operación ListRecords.
Cada página fue almacenada localmente y posteriormente validada mediante:
xmllint --noout archivo.xmlEl resultado fue concluyente:
- Todos los XML eran completamente válidos.
- Ninguna página presentó errores.
Segunda hipótesis: un registro específico está corrupto
Era posible que el XML general fuese correcto, pero que alguno de los registros individuales presentara problemas al recuperarse mediante GetRecord.
Para comprobarlo:
- se extrajeron todos los identificadores OAI;
- se ejecutó un GetRecord para cada uno;
- cada respuesta fue nuevamente validada con xmllint.
El resultado volvió a sorprender.
- Los 413 registros respondieron correctamente.
- No apareció ningún XML inválido.
- No apareció ningún carácter ilegal.
- No apareció ningún error SAX.
La hipótesis quedaba descartada.
Tercera hipótesis: el problema era el servidor OAI
También evaluamos la posibilidad de un problema intermitente del servidor. Durante varias horas repetimos pruebas utilizando:
- ListRecords
- GetRecord
- resumptionToken
- metadataPrefix=dim
Las respuestas fueron siempre consistentes.
El proveedor OAI funcionaba correctamente.
Entonces apareció una pista importante
Si el problema no estaba en el XML...
¿Por qué DSpace fallaba?
Decidimos cambiar completamente el enfoque. En lugar de seguir analizando el proveedor, probamos exactamente la misma colección utilizando otro software.
La elección fue Omeka.
El resultado fue revelador:
- La colección completa fue importada correctamente.
- Los 413 registros fueron incorporados sin errores.
Aquello cambiaba completamente el escenario, ya no podíamos afirmar que el problema estuviera en el proveedor OAI. Para descartar cualquier particularidad propia de la instalación utilizada, repetimos exactamente la misma configuración en otra instalación completamente distinta.
Esta vez sobre:
- otro servidor;
- otra base de datos;
- otra instalación limpia;
- DSpace 8.
El resultado fue exactamente el mismo: La cosecha comenzó normalmente. Importó alrededor de 180 registros. Posteriormente volvió a aparecer exactamente el mismo error:
XML document structures must start and end within the same entityseguido nuevamente por:
org.hibernate.LazyInitializationExceptionEn ese momento ya no se trataba de un problema de infraestructura. El comportamiento era reproducible en distintas instalaciones y distintas versiones de DSpace.
¿Qué estaba ocurriendo realmente?
Revisando el código y los registros de depuración apareció un detalle muy interesante. La cosecha OAI en DSpace ocurre en dos etapas distintas.
- Primero se ejecuta ListRecords, obteniendo el listado de registros. Hasta ese momento todo funciona correctamente.
- Posteriormente DSpace comienza a ejecutar internamente múltiples solicitudes GetRecord para reconstruir completamente cada ítem utilizando la biblioteca oclc-harvester2.
Es precisamente durante esa segunda etapa donde aparece el error SAX:
XML document structures must start and end within the same entitySin embargo, todas las pruebas manuales utilizando exactamente esos mismos GetRecord devolvían XML completamente válido.
Es decir:
- el servidor respondía correctamente;
- el XML era válido;
- xmllint lo aceptaba;
- Omeka lo aceptaba;
- únicamente DSpace producía el error.
Un último experimento
Antes de dar por concluido el análisis decidimos modificar únicamente un parámetro de la colección.
En lugar de utilizar la modalidad habitual de cosecha:
- Recolectar metadatos y referencias ORE.
Configuramos la colección para:
- Recolectar solo metadatos
- utilizando Simple Dublin Core.
La diferencia fue inmediata.
- La cosecha finalizó correctamente.
- Los 413 registros fueron importados.
- Sin errores.
Lo que aprendimos
Esta experiencia dejó varias lecciones muy interesantes. La primera es que un mensaje de error aparentemente evidente no siempre apunta al verdadero origen del problema. Durante buena parte del análisis estuvimos convencidos de que existía un XML defectuoso, sin embargo, todas las pruebas demostraban exactamente lo contrario.
También aprendimos la importancia de validar una hipótesis utilizando herramientas independientes, si solamente hubiésemos probado desde DSpace, probablemente habríamos concluido que el proveedor OAI estaba incumpliendo el estándar.
El hecho de repetir exactamente la misma cosecha utilizando Omeka permitió demostrar que el proveedor funcionaba correctamente.
Finalmente, reproducir el problema tanto en DSpace 7.6 como en DSpace 8 fortaleció aún más la hipótesis de que el comportamiento corresponde a una limitación —o eventualmente un bug— en el flujo de cosecha de DSpace cuando trabaja con DIM y referencias ORE.
Recomendaciones para administradores de DSpace
Cuando una cosecha OAI falle con errores XML, conviene seguir un proceso sistemático antes de atribuir el problema al proveedor.
En nuestra experiencia recomendamos:
- Validar manualmente todas las respuestas ListRecords mediante herramientas como xmllint.
- Comprobar individualmente los GetRecord.
- Repetir las pruebas utilizando otro consumidor OAI, por ejemplo Omeka, para determinar si el comportamiento es reproducible.
- Revisar cuidadosamente los registros de DSpace para identificar en qué etapa del proceso aparece el error.
- Probar temporalmente la modalidad Recolectar solo metadatos, especialmente cuando el proveedor también ofrece soporte para Simple Dublin Core.
Este enfoque permite separar con mucha mayor precisión los problemas del proveedor OAI de los problemas propios del cliente de cosecha.
Conclusión
Uno de los aspectos más interesantes del soporte técnico especializado es que muchas veces el verdadero problema no es el que muestran los mensajes de error.
En este caso, todo apuntaba inicialmente hacia un XML corrupto.
Después de validar más de cuatrocientos registros, analizar respuestas OAI completas, repetir la cosecha en múltiples plataformas y comparar el comportamiento entre distintas versiones de DSpace, la evidencia condujo hacia una conclusión muy distinta: el proveedor OAI cumplía correctamente con el estándar, mientras que el problema sólo aparecía bajo un flujo específico de cosecha implementado por DSpace.
Este tipo de investigaciones permiten fortalecer los ecosistemas de repositorios institucionales, mejorar la interoperabilidad entre plataformas y generar evidencia útil para toda la comunidad de DSpace, OAI-PMH, bibliotecas digitales y preservación digital.