Las desventajas del protocolo Z39.50

Biblioteca El Escorial, San Lorenzo, España
(Foto tomada del blog de Marfiles y Rosas)

Los metadatos se crearon para compartir. Como hemos visto han tenido una evolución desde lo más ideal a lo más práctico, tanto en los esquemas de metadatos propiamente dichos, como en los protocolos para interconectar sistemas. Así, después de entender los aportes históricos del MARC, vimos la evolución que nos llevó al Dublin Core. Esta evolución complementó y simplificó el MARC, sin que esto haya significado negar sus aportes e incluso la necesidad de usarlo en contextos bibliotecarios. Luego le tocó el turno a los protocolos y comprendimos por qué hacían falta, examinamos el diseño y los aportes del Z39.50 para luego entender que también los protocolos debían evolucionar para dar entrada a ideas más sencillas y menos completas que las planteadas inicialmente. Llegamos de esta manera a un camino que nos condujo al OAI-PMH. Sin embargo, es bueno todavía detenerse y analizar bien las desventajas que se encontraron en la experiencia práctica con el Z39.50 para poder, como profesional de las Ciencias de la Información, comprender las siguientes soluciones hasta llegar, más adelante, al estado del arte actual.

Algunas desventajas en la experiencia concreta con el Z39.50

Z39.50 fue un buen intento de lograr una solución ideal, completamente descentralizada y completamente basada en la consulta simultánea, en tiempo real, a múltiples sistemas, probado que se entendiesen entre ellos en un idioma universal: el idioma Z, una suerte de esperanto bibliotecario. Como hemos estado señalando la solución trabajó, pero con algunas limitaciones prácticas.

Algunas de los problemas concretos que se encontraron fueron los siguientes:

• Si un nodo no estaba en línea en un momento dado, no se obtenía información del mismo porque el protocolo Z39.50 estaba orientado a proporcionar respuestas en tiempo real. Es decir, el ideal del tiempo real podía convertirse en una limitación.

• Aunque en teoría, con el Z39.50 se pueden consultar muchas bases de datos simultáneamente, en la práctica, se encontró que la solución no escalaba más allá de unas pocas decenas de servicios, ya que al incrementar la cantidad de servidores consultados afloraban rápidamente los problemas de eficiencia y de claridad en la organización de las respuestas.

• Podría pensarse que una solución es escoger de antemano cuáles son los servicios específicos que se desean consultar, pero esto puede no ser tan fácil porque en muchos casos no se sabe a priori. Por otra parte, entre un servicio y otro pueden haber variaciones de atributos de búsqueda importantes como para preguntarse el sentido de la búsqueda simultánea. En cualquier caso, pueden presentarse problemas prácticos al intentar mezclar la data proveniente de varios servidores.

• Un aspecto de rendimiento importante es que la ejecución de una consulta paralela, en el papel muy rápida y efectiva, termina siendo afectada de la velocidad del servicio más lento. Finalmente, resulta difícil construir una interfaz de exploración, apta para el usuario que no sabe que puede buscar, con un protocolo de búsqueda paralela que presupone que se sabe qué buscar y dónde buscarlo.

La solución

Ante los problemas anteriores la solución que se encontró fue revisar si las tres características esenciales de Z39.50, el tiempo real, la simultaneidad y la búsqueda con una única interfaz, eran realmente necesarias. Se llegó a la conclusión de que no y se hizo un viraje histórico: la solución parecía ser reunir todos los registros de metadatos en un único servidor.

Una nueva propuesta no tardó en llegar: el OAI-PMH, un nuevo hito en la historia de los metadatos del cual hablaremos en un próximo “post”.