¿Por qué cosechar en lugar de buscar en tiempo real los metadatos que necesitamos?

Biblioteca Geral da Universidade de Coimbra, una legendaria biblioteca
con una historia que se remonta al siglo XVI, ya que existía en la
ciudad de Coimbra incluso antes del establecimiento de la
Universidad en 1537.
(Ver: Historia en la Wikipedia y Foto en Marfiles y Rosas)

Desde hace muchos años los profesionales de la información aprendieron la necesidad de desarrollar esquemas de metadatos. Primero se transitó el camino de la exhaustividad y luego, con la amplificación de los recursos de información y la Internet, se aprendió que una cierta sencillez era necesaria en muchos casos. Así se recorrió la senda que va del MARC al Dublin Core, sin abandonar el MARC. Pero además de los esquemas de metadatos hacían falta los protocolos que normaban el cómo compartirlos. También en este caso se comenzó con una propuesta sofisticada para luego comprender que una cierta sencillez puede ser mejor en muchos casos. La evolución fue entonces desde el Z39.50 al OAI-PMH, recorrido en el que, en forma análoga al del caso anterior, se llegó al segundo sin abandonar el primero. Pero en tránsito al OAI-PMH hay, para el profesional de la información, puntos interesantes que conviene tener claros: ¿Por qué puede ser mejor cosechar metadatos que consultarlos en tiempo real? O algo más básico todavía: ¿Qué significa, en información, cosechar metadatos?

Cosecha de metadatos
La idea de que cosechar metadatos es mejor que buscarlos en tiempo real no es evidente. Cosechar metadatos significa tomar todos los metadatos producidos en un repositorio de información externo y traerlos hasta un servidor local para consultarlos desde el servidor local. La primera ventaja es bastante clara: después del trabajo de cosechar los metadatos, las consultas son todas locales y por ello se esperaría que fueran rápidas y de funcionamiento seguro. Pero las primeras desventajas son también muy fáciles de apreciar: cosechar es un trabajo, hay que tener capacidad local para almacenar todos los datos que provienen del proveedor remoto y, muy importante, es muy fácil que se obtenga información no actualizada, porque, al fin de cuentas, no se consulta en línea el servidor remoto, sino una imagen local, creada por el cosechador en el momento que realizó la cosecha.

¿Por qué puede ser mejor cosechar que buscar en tiempo real?
La respuesta tiene que ver con la experiencia que se desarrolló con el protocolo Z39.50 y que resumimos en nuestro post anterior al hablar de las desventajas de este protocolo.

En teoría es mejor consultar información completamente actualizada en tiempo real, pero en la práctica pueden surgir problemas si el servidor remoto o la red a través de la cual éste se accede no está disponible en el momento de consultar. En ese caso muchas veces se preferiría la respuesta no actualizada de una recuperación reciente que la respuesta de cero registros que se obtiene del servidor puntualmente inaccesible.

Uno necesita muchas veces consultar varios servicios de información remotos y si intenta hacer la consulta simultánea en tiempo real, como lo permite el Z39.50, la consulta termina siendo consolidada a la velocidad del más lento, por lo que la efectividad del tiempo real puede desaparecer.

Por otro lado, el abaratamiento de los costos de almacenamiento y de procesamiento hacen la cosecha de muchos servidores cada vez más viable.

En términos prácticos, por las razones anteriores, cuando se quiere consultar algunas decenas de servidores, la idea del tiempo real puede no ser apropiada. Por ello hubo un momento en que los responsables de ciertos servicios de información líderes se pusieron de acuerdo para decirse, que si, contrariamente a lo que parecía inicialmente, es mejor cosechar metadatos, lo que necesitamos es un protocolo que nos ayude a hacer bien, en forma sencilla y práctica, esta cosecha. Así fue que llegamos al OAI-PMH, un protocolo para compartir metadatos a través de un esquema de recolección de metadatos y del que continuaremos hablando más adelante.