domingo, 22 de mayo de 2011

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”.

jueves, 19 de mayo de 2011

La evolución desde el Z39.50 al OAI

Biblioteca Palafoxiana, Puebla, México
(Foto Marfiles y Rosas)

Como hemos presentado en nuestros últimos “post”, el protocolo Z39.50 fue un hito histórico en la historia de los metadatos y de los catálogos colectivos. Se desarrolló como una solución al deseo de interconectar bibliotecas lo que creó facilidades y significó un paso adelante en el intercambio de registros MARC. Dedicamos este “post” al cómo y al por qué, manteniendo la idea de compartir metadatos e interconectar sistemas diferentes, se llegó a la necesidad de explorar soluciones radicalmente distintas, a otros esquemas de interoperabilidad como el OAI-PMH, que surgieron con el cambio del milenio. Hoy iniciaremos la conversación sobre el tema para, en otra ocasión, abordar la perspectiva histórica y profundizar con más detalles. La idea es seguir entendiendo la evolución del estado del arte en soluciones para compartir metadatos e interconectar bases de datos, documentales o bibliográficas.

Lo aparentemente ideal no es la solución mejor
Como expresamos en otro momento, Z39.50 se definió con tres características ideales del desiderátum de la interoperabilidad bibliotecaria: la consulta en tiempo real de una biblioteca a otra, la interrogación simultánea a varias bibliotecas y la posibilidad de interconectar bibliotecas presentando una interfaz única al usuario.

La paradoja es que estas tres características, consideradas esenciales, tuvieron que ser revisadas primero y dejadas de lado después, porque en la práctica, el Z39.50 resultó tan ideal, que no pasó todas las pruebas de nivel práctico y no derivó en una herramienta fácil de implementar y usar cotidianamente en muchos contextos donde inicialmente se planteó como una posible solución. Especialmente en el caso de las bibliotecas más pequeñas o de redes medianamente grandes. Es decir, se encontraron desventajas a la solución ideal y por ello, sin abandonarlo completamente, se buscaron soluciones complementarias alternativas.

Problemas prácticos
A pesar de sus indudables ventajas y sus grandes aportes, que expusimos en nuestro “post” anterior (Ventajas y aportes del Z39.50...), la experiencia de uso también registró algunas desventajas de Z39.50 como protocolo de intercambio bibliotecario:

En efecto, se trataba de un protocolo muy completo que establecía una manera explícita de intercambiar registros MARC, un formato que como hemos visto era bastante exhaustivo y permitía describir el detalle de cada registro de metadatos recuperado. El problema con el Z39.50 era que no resultaba fácil de implantar en un servidor bibliotecario. A nivel del cliente, es decir, del sistema que consulta, la solución fue más fácil de lograr, pero si sólo se puede consultar en una dirección, no se están desarrollando realmente esquemas de red ya que una de las condiciones del compartir institucional es la bidireccionalidad.

En algún sentido la conclusión de la experiencia inicial con el protocolo Z39.50 fue que se trabajó sobre la base de una implementación que de alguna manera resultaba demasiado buena para ser verdad.

La solución más terrestre
La solución fue dejar de buscar lo ideal y buscar algo más terrestre. No pensar en soluciones distribuidas sino en esquemas centralizados, no consultar sino cosechar, sin importar que esto significara repetir registros y abandonar las tres características esenciales enumeradas arriba. Era preferible olvidarse de una solución en tiempo real, de la consulta simultánea a varias bases de datos y de la interfaz única para el usuario, si estas, sin pretenderlo, se convertían en trabas reales para el desarrollo de los servicios de valor agregado que se desean en las redes de bibliotecas, institucionales o interinstitucionales.

Por este camino se llegó, en el nuevo milenio (2001-2002), al protocolo OAI-OMH, mucho más sencillo, más claro, menos, aparentemente, ideal pero mucho más fácil de implementar. Seguiremos en la próxima oportunidad entendiendo las desventajas del Z39.50 para poder comprender así los aportes del OAI.

viernes, 13 de mayo de 2011

Ventajas y aportes del protocolo Z39.50 a la historia de las bibliotecas

Biblioteca Nacional de Belarús (Bielorusia)

Después de haber trabajado el concepto de interoperabilidad para entender por qué las redes de bibliotecas necesitaban de un protocolo de interoperabilidad, que permitiese la interconexión de sistemas diferentes, y después de haber conversado (en nuestro post anterior) acerca de las características principales del protocolo Z39.50, comentamos a continuación las ventajas de la aproximación que se siguió al diseñar e implementar esta solución que marcó un hito histórico en la historia de las bibliotecas. El tema es así importante y nos prepara para trabajar con los aprendizajes de esta gran experiencia internacional. Para el profesional de Ciencias de la información es bueno saber que no todo fue color de rosas y que hubo dificultades a las que hubo que enfrentarse al compartir metadatos con Z39.50, aún pensando que la solución diseñada fue, en principio, muy completa y muy bien definida. Conocer la historia ayuda a comprender por qué vinieron luego otras soluciones menos sofisticadas y más sencillas.

(Remitimos al lector a nuestro post anterior para conocer lo que es el Z39.50 y el concepto de interoperabilidad bibliotecaria y al anterior a ese, para entender el problema a resolver desde la idea del desarrollo de catálogos colectivos de redes de bibliotecas).

Ventajas del Z39.50
Como solución de interoperabilidad bibliotecaria, el Z39.50 aportó muchas ventajas. Entre ellas:

1. Permite la interconexión de sistema bibliotecarios diferentes en un mecanismo que funciona con simetría, en las dos direcciones, siempre que se trate de sistemas que implementan el protocolo tanto como cliente Z, como servidor Z.

2. Un mismo cliente Z puede consultar simultáneamente varios servidores Z. El protocolo permite que se consoliden las respuestas para presentárselas al usuario. Esto habilita fácilmente la definición de redes bibliotecarias, institucionales, temáticas o geográficas.

3. El usuario final de una biblioteca no tiene que aprender varias maneras de consultar una biblioteca ya que el cliente Z presenta, bajo una única interfaz, la del sistema al que el usuario está acostumbrado, las consultas y respuestas de los distintos servidores. Esto resulta muy cómodo y útil para el usuario.

4. El protocolo interconecta sistemas en tiempo real, por lo que cualquier registro incorporado en un sistema pasa a estar automáticamente disponible en los otros. El catálogo colectivo está así, de un modo natural, permanentemente actualizado.

5. Los metadatos que se pueden compartir son muy exhaustivos desde el punto de vista bibliotecario porque los registros se intercambian con el formato MARC que permite una descripción muy detallada de cada registro.

6. El valor agregado que un sistema da a los metadata internos que maneja pasa a estar automáticamente disponible para los registros recuperados a través del protocolo.

Dejaremos para la siguiente oportunidad el comentar y analizar las desventajas y las soluciones que se buscaron en la próxima etapa.

viernes, 6 de mayo de 2011

El protocolo Z39.50

Una de las ventajas del protocolo Z39.50 es que permite a los usuarios
consultar todas las bibliotecas de una red con una misma interfaz.
En la fotografía dos voluntarios del programa de "tecnicos adolescentes"
de la Biblioteca Regional del Condado de Kitsap en Port Orchard (detalles)

En nuestro “post” anterior, estuvimos hablando de la evolución de los catálogos colectivos en redes de bibliotecas y explicamos como éstos se desarrollaron a partir de dos precondiciones: la existencia de esquemas de metadatos universales, adecuados para describir recursos de información en forma normalizada, y la definición de protocolos de interoperabilidad, adecuados para definir cómo es que dos sistemas bibliotecarios se interconectan para intercambiar sus metadatos. Ambos problemas estaban razonablemente resueltos, conceptualmente, para finales de la década de los 80, con el formato MARC y el protocolo Z39.50. A partir de allí comenzó una historia de evolución continua. De MARC hemos hablado, por lo que esta vez ampliamos la exposición del Z39.50, orientándonos a entender sus características más relevantes, su importancia, ventajas, desventajas y evolución.

Nacimiento y primeros cambios
El protocolo Z39.50 está firmemente ligado a la historia de las redes de bibliotecas. Se inició en 1988 con su primera versión, que sirvió para ganar experiencia de interacción e interconexión bibliotecaria. Con esta experiencia se mejoró la aproximación a la solución y se produjeron herramientas más desarrolladas a comienzos de los años 90, luego que los aportes del trabajo inicial fueran sintetizados en las versiones 2 y 3 del protocolo.

Las tres características más importantes del protocolo de interoperabilidad bibliotecaria Z39.50 son: el tiempo real, la interrogación simultánea y la interfaz unificada para el usuario. Explicamos estas propiedades a continuación.

Interoperabilidad bibliotecaria
Se habla de interoperabilidad cuando los sistemas cooperan para entenderse. Cuando los sistemas hablan entre si y son capaces de intercambiar información. Esto pudo hacerse a nivel de las bibliotecas y de las aplicaciones en general cuando la capa de abajo, la interconexión de computadores, la Internet, estuvo bien resuelta.

Hoy en día, estamos muy acostumbrados a la interoperabilidad porque la Web, desarrollada a partir de los años noventa, ha facilitado aún más las cosas, pero es interesante saber que no siempre fue así, que no siempre la interconexión de sistemas fue realidad. También es cierto conocer que la interoperabilidad bibliotecaria fue anterior a la Web, para bien y para mal. Para bien porque se disfrutó antes, y para mal, porque esto la hizo más difícil.

Tiempo real
El Protocolo Z39.50 permite la interconexión, en tiempo real, a través de Internet, de sistemas bibliotecarios. El sistema que consulta se conoce como cliente Z, y el sistema consultado como servidor Z.

En tiempo real significa que apenas un sistema A cambia, la siguiente consulta que se realiza desde un sistema B permite a éste enterarse de que el sistema A cambió. No es exactamente lo que ocurre siempre. Es interesante saber que las alternativas que vinieron después del Z39.50 simplificaron un poco la interconexión, prescindiendo del tiempo real para ganar en sencillez de implementación.

Interrogación simultánea
La interrogación simultánea es la capacidad de interrogar en el mismo lapso de tiempo a varios sistemas a la vez. Es decir, el poder preguntarle a un segundo aún antes de que llegue la respuesta del primero y a un tercero antes de que llegue la respuesta del segundo.

Adicionalmente, se entiende que lo interesante de la interrogación simultánea es la capacidad de consolidar las respuestas, sabiendo que se trata de varias respuestas a una misma pregunta.

Interfaz unificada para el usuario
El protocolo Z39.50 no solamente permitió la interconexión bibliotecaria en tiempo real con interrogación simultánea, también definió cómo hacer para presentar una interfaz unificada al usuario.

En efecto, el usuario final de un sistema que posee Z39.50 sólo aprende a usar un único sistema, ya que todos los otros sistemas serán presentados ante él como sistemas uniformes que permiten ser consultados de la misma manera y presentan sus resultados de la misma manera.