Integrar bases de datos en un solo buscador

El problema que se paga y no se usa

Una biblioteca universitaria mediana puede tener entre cinco y quince bases de datos comerciales suscritas —del tipo de EBSCO, Scopus, JSTOR, ProQuest o Web of Science, por citar ejemplos habituales de la industria, sin que esto implique que integremos específicamente cada una de estas marcas—, además de su catálogo y su repositorio institucional. Cada suscripción cuesta, se renueva cada año y exige que el usuario sepa que existe, que recuerde su nombre exacto y que entre a su interfaz particular. En la práctica, la mayoría de los usuarios prueba dos o tres fuentes como máximo y se rinde ahí. El resultado es una biblioteca que paga más recursos de los que su comunidad realmente descubre, y esa brecha entre lo que se compra y lo que se usa es, casi siempre, el argumento que termina justificando el proyecto de integración ante rectoría o dirección financiera.

Los protocolos: la parte que decide si la integración es rápida o cara

Hay cuatro caminos estándar por los que una fuente puede conectarse a un metabuscador, y conviene conocerlos porque determinan directamente el esfuerzo del proyecto.

BiblioMeta se integra por estos protocolos estándar (Z39.50/SRU, OAI-PMH, REST y SPARQL, según lo que exponga cada fuente), lo que significa que la conexión con cada base de datos, catálogo o repositorio se construye sobre un estándar reconocido por la industria y no sobre un desarrollo cerrado que solo nosotros podamos mantener.

Qué determina si una base de datos se puede integrar

La pregunta correcta nunca es «¿se puede integrar esta base de datos?» en abstracto, sino tres preguntas concretas: ¿el proveedor expone alguno de estos protocolos, o solo una interfaz web pensada para que la use una persona? ¿La licencia contratada con ese proveedor permite consultas automatizadas desde un sistema externo, o lo restringe explícitamente? ¿El acceso exige autenticación por IP o por sesión —lo que conecta directamente con la capa de acceso remoto— y quién administra esas credenciales hoy? Cuando las tres respuestas son favorables, la integración es una tarea de configuración. Cuando alguna no lo es, deja de ser una tarea de configuración y se convierte en un desarrollo a la medida o, en el peor caso, en una limitación real que ningún proveedor de metabuscador puede resolver sin la cooperación del dueño de la base de datos.

Catálogo, repositorio y bases de datos no se integran igual

Vale la pena separar tres escenarios que se mezclan con frecuencia en una conversación de ventas. Integrar el catálogo del sistema de gestión bibliotecaria (Koha, por ejemplo) suele ser lo más directo, porque los sistemas modernos exponen Z39.50 o SRU de forma nativa. Integrar el repositorio institucional (DSpace, por ejemplo) también es relativamente estándar, porque OAI-PMH es prácticamente universal en repositorios de acceso abierto. Integrar bases de datos comerciales es lo más variable: algunas exponen una API REST documentada y estable, otras solo permiten búsqueda desde su propia interfaz web sin ninguna vía programática, y en ese último caso la conversación con la biblioteca tiene que ser honesta sobre qué sí y qué no se puede prometer.

Dos modelos de conexión: en vivo o por cosecha previa

Los protocolos de la tabla anterior se agrupan, en la práctica, en dos formas de trabajar. Z39.50, SRU y las APIs REST se usan para consultar en el momento: el metabuscador le pregunta a la fuente cada vez que un usuario busca, y la fuente responde con lo que tiene disponible en ese instante. OAI-PMH funciona distinto: sirve para cosechar metadatos por adelantado, en ciclos programados —diarios, semanales—, de modo que lo que el metabuscador muestra de un repositorio o una revista proviene de la última cosecha, no de una consulta en vivo a ese sistema. Ninguno de los dos modelos es superior en abstracto: un catálogo o una base de datos comercial que cambia constantemente se beneficia de la consulta en vivo, mientras que un repositorio institucional, que no cambia con tanta frecuencia, se integra perfectamente bien por cosecha periódica sin que el usuario note la diferencia.

Errores comunes al presupuestar una integración de bases de datos

El más frecuente es tratar «integrar bases de datos» como una sola tarea de tamaño fijo, cuando en realidad cada fuente tiene su propio esfuerzo: no es lo mismo conectar un catálogo Koha con Z39.50 nativo que negociar acceso a la API de un proveedor comercial que primero exige una solicitud formal de credenciales de desarrollador. El segundo error es asumir que, porque una base de datos tiene una interfaz de búsqueda moderna y agradable, eso significa que también tiene una API pública: muchas plataformas comerciales invierten en su propia interfaz web precisamente porque quieren que el usuario navegue dentro de su sitio, y no siempre les conviene facilitar que otro sistema muestre sus resultados en otro lugar. El tercer error es olvidar la licencia: algunos contratos de suscripción limitan explícitamente el número de consultas automatizadas por minuto, lo que puede volver inviable una integración en tiempo real si no se negocia antes con el proveedor.

Bibliotecas con más de un sistema de catalogación

No es raro que una institución tenga a la vez un catálogo y un repositorio construidos sobre plataformas distintas, o incluso dos sistemas de catalogación heredados de fusiones o de decisiones tomadas en momentos distintos de su historia. Ese escenario no impide la integración, pero sí la vuelve doble: cada plataforma tiene su propio esquema de metadatos, sus propios campos obligatorios y su propia forma de exponer los datos, así que el trabajo de diagnóstico y ajuste hay que hacerlo por cada una, no una sola vez para las dos. Es un patrón habitual en la región y, aunque toma más tiempo de levantamiento inicial, no es un obstáculo: lo importante es no subestimarlo al presupuestar.

Lo que hacemos antes de prometer una integración

En los proyectos que hacemos, la primera fase nunca es técnica: es un inventario. Listamos cada fuente que la biblioteca quiere unificar, verificamos qué protocolo expone realmente —no el que dice el folleto comercial del proveedor, sino el que confirma su documentación técnica o su soporte— y revisamos si la licencia vigente permite ese tipo de consulta automatizada. Ese inventario es lo que separa una cotización realista de una promesa que se rompe en la puesta en marcha, y es también la razón por la que nunca cotizamos «integrar todas tus bases de datos» como una línea única, sino fuente por fuente, con su propio esfuerzo y su propio riesgo.

Cuando implementamos esto para una universidad con varias bases de datos suscritas y un repositorio DSpace ya en producción, el patrón que más se repite es que el catálogo y el repositorio se integran en la primera semana, y las bases de datos comerciales toman el resto del proyecto, porque cada proveedor exige su propia coordinación de acceso y de licencia.

Dónde entra el acceso remoto en esta conversación

Integrar una base de datos y darle acceso remoto a un usuario son dos problemas relacionados pero distintos. Una cosa es que el metabuscador sepa preguntarle a EBSCO o a Scopus si tienen resultados para una consulta; otra cosa es que un estudiante, desde su casa, pueda abrir ese resultado y llegar al texto completo sin que el proveedor lo bloquee por no reconocer su dirección IP. Esa segunda pieza es la que resuelve el acceso remoto integrado (proxy) de BiblioMeta Académico, y conviene planificarla junto con la integración de fuentes, no como un proyecto aparte que se retoma después.

Si aún no tienes claro qué es un metabuscador en general, empieza por qué es un metabuscador y cómo funciona. Para la parte del acceso fuera del campus, revisa qué es un proxy de acceso remoto y cómo se integra. Y para dimensionar el proyecto completo, lee cuánto cuesta implementar un metabuscador, donde el número de fuentes a integrar es el factor que más mueve el precio. Integramos catálogo, repositorio y bases de datos suscritas desde nuestro servicio de metabuscador.