Página principal

Opac-web-Z39. 50: ¿Redundantes o complementarios? La realidad es multilingüe


Descargar 45.96 Kb.
Fecha de conversión18.07.2016
Tamaño45.96 Kb.
OPAC-Web-Z39.50: ¿Redundantes o complementarios?

La realidad es multilingüe.
Jornadas Españolas de Documentación (FESABID’98)

(6º. 1998. Valencia)


Arantza López de Sosoaga Torija

SABINI Automatización de Bibliotecas

1.- INTRODUCCIÓN
Este año se cumplen 10 años desde la aprobación de la norma Z39.50 en 1988, pero en aquel entonces en España se estudiaba la necesidad de catalogar de acuerdo a un formato MARC, las reglas generales para la construcción de catálogos automatizados y aspectos similares.
Indudablemente hemos avanzado y mejorado mucho desde entonces, pero no debemos seguir haciéndolo de espaldas a la Comunidad Bibliotecaria Internacional, ni empujados básicamente por los desarrollos y modas informáticas del momento.
Gran parte de los avances que se han realizado en esta década se deben a un gran esfuerzo humano, pero ahora el abaratamiento de los equipos, la mejora de las comunicaciones y la generalización de la “vieja Internet” hacen que se apunte el tanto el desarrollo informático: OPACs mejores y más amigables inmediatamente accesibles mediante telnet, rápidos desarrollos de bonitas páginas Web que facilitan el acceso a los catálogos, etc. Pero, ¿se piensa realmente en el usuario? ¿se trabaja realmente para poner toda la potencia de ese desarrollo tecnológico al servicio de la sociedad?

2.- Z39.50 (ISO 23950): BREVE HISTORIA E IDEAS GENERALES SOBRE SU FUNCIONAMIENTO


Z39.50, o más exactamente “Information Retrieval (Z39.50); Application Service Definition and Protocol Specification for Open Systems Interconnection”, es el estándar número 50 desarrollado por NISO (National Information Standards Organization), que era el comité número 39 de ANSI (American National Standards Institute).
Básicamente Z39.50 normaliza el procedimiento para que dos ordenadores se comuniquen cuando se desea recuperar información. Dado que puede implementarse en cualquier plataforma, permite a los distintos sistemas informáticos interoperar para que el usuario final emplee un único interfaz pudiendo acceder con él a múltiples sistemas, con los comandos, formatos y estilos de presentación que le sean familiares.
La primera versión del estándar Z39.50 se aprobó en 1988, y ha quedado obsoleta. En 1990 se establecieron dos importantes grupos que garantizan el desarrollo controlado y la continua evolución del estándar: un grupo de implementadores ZIG (Z39.50 Implementors Group) y una agencia para el soporte del estándar (Z39.50 Maintenance Agency). Fruto de su trabajo se aprueba la versión 2 en 1992 que, además de numerosas mejoras, evita las incompatibilidades con el protocolo de ISO “Search and Retrieve” SR (ISO 10162 y 10163). En los años siguientes se sigue trabajando en el desarrollo del estándar y se cuenta con participación de otros países como Canadá, Australia y países europeos; lo que lleva a una versión 3, aprobada en 1995 y aceptada como estándar ISO (ISO 23950) en Marzo de 1997, garantizando así un estándar de aplicación realmente internacional, que incorpora numerosas mejoras, se mantiene compatible con la versión 2 y, sobre todo, reconoce como medio de aplicación TCP/IP e Internet (aunque en un apéndice, por razones políticas).
Z39.50 es un estándar maduro, con una amplia presencia en la comunidad bibliotecaria, al menos de algunos países. Sus funciones básicas permiten buscar y recuperar información de bases de datos situadas en diversos lugares. El protocolo especifica las estructuras de datos y las normas de intercambio que permiten a una máquina cliente (llamada “origin”) buscar en bases de datos de una máquina servidor (llamada “target”) y recuperar los registros que se identifican como resultado de esa búsqueda.
El “origin” y el “target” convierten sus formas locales de mensajes y respuestas a “lenguaje Z39.50”, permitiendo al usuario final disponer de un único interfaz consistente y familiar para el acceso a bases de datos internas y externas. Aunque el estándar no lo soporta directamente, un buen software cliente puede acceder incluso a numerosos servidores de manera secuencial o simultánea, sin necesidad de repetir las búsquedas en cada uno de ellos.
Las dos facilidades básicas son Buscar y Recuperar. Buscar (Search) se dirige a una o más bases de datos de un servidor y debe contener una pregunta (query). El grupo de registros encontrados como resultado de esa pregunta se llama conjunto de resultados (result set). Están definidos distintos tipos de preguntas (query-types), aunque el protocolo obliga al menos a soportar el tipo 1 (type-1) que se corresponde con preguntas en Notación Polaca Inversa (Reverse Polish Notation) y que pueden consistir en un único punto de acceso o varios ligados por operadores lógicos.
Los atributos de búsqueda que se emplean (attributes) deben pertenecer a un conjunto de atributos (attributes set) que esté definido y registrado en el estándar y que se especifica dentro de la pregunta. El conjunto de atributos empleado en la comunidad bibliotecaria se llama bib-1.
Recuperar (Retrieval) consiste en dos servicios Z39.50: Presentar y Segmentar. En una respuesta Presentar (Present), el cliente solicita los registros encontrados y puede especificar sus requisitos en cuanto a sintaxis (MARC, GRS, etc.), esquema (bibliográfico, holdings, etc.) y otros elementos (completo, abreviado, sólo título y materia, etc.). Si la respuesta excede la cantidad de información máxima negociada entre cliente y servidor, el servidor Segmenta (Segment) la respuesta y sirve el conjunto de resultados por partes.
Estas dos funciones básicas de Buscar y Recuperar se complementan con otros muchos servicios que permiten iniciar una sesión, terminarla, controles de acceso, operaciones sobre conjuntos de resultados, etc. En especial hay dos funciones incluidas en la versión 3, cuya implementación no está todavía demasiado extendida: Scan, que permite acceder a listas ordenadas de términos, y Explain, que permite a un cliente preguntar al servidor sobre los detalles de su implementación con idea de que pueda autoconfigurarse dinámicamente.
La versión 3 también introduce los llamados Servicios Extendidos (Extended Services), que permiten definir tareas que se desarrollan fuera de la sesión Z39.50. El servidor mantiene una base de datos especial con estas tareas definidas por el cliente. Se incluyen servicios como: Conjunto de Resultados Persistente (Persistent Result Set) que guarda el servidor, Pregunta Persistente (Persistent Query) que guarda el servidor, Pregunta Periódica (Periodic Query) que guarda el servidor y la ejecuta periódicamente de acuerdo con la periodicidad marcada por el cliente, etc.

3.- OPAC-WEB-Z39.50: ¿REDUNDANTES O COMPLEMENTARIOS?


El éxito de las páginas Web ha hecho que surjan en algunos medios dudas sobre la necesidad de Z39.50 como si se tratase de desarrollos redundantes, pero esto no es más que una falta de entendimiento de lo que Z39.50 es capaz de soportar y sus múltiples aplicaciones.
Es cierto que el Web se ha convertido en una manera barata y muy extendida de ofrecer un acceso amigable a los catálogos, incluso algunas veces un acceso en línea. Muchos de estos sistemas tienen una apariencia similar y no precisan más que un navegador normal en la máquina cliente, incluso pueden estar dotados de capacidad para transferir ficheros. Pero sigue existiendo el mismo problema desde que el usuario tiene acceso a los catálogos en línea (tanto a través del OPAC, como a través de Web): no hay dos sistemas cuyo interfaz tenga las mismas características y cada uno obliga al usuario a familiarizarse con una estructura distinta, además no suele ser posible pasar directamente los resultados obtenidos para emplearlos en otras aplicaciones, ni es fácil repetir la misma consulta en distintos servidores a través de Web y obtener resultados consistentes.
Estas observaciones no significan que debamos abandonar los desarrollos de accesos a catálogos a través de Web, incluso debemos fomentarlos. Es un buen medio para acceder de forma amigable a un servidor concreto, y para integrar “verticalmente” toda la información que una organización pone a disposición de los usuarios, por ejemplo, cuando un Ayuntamiento desarrolla su página de presentación, ofrece distintos servicios al ciudadano a través del Web y también le presenta su red de bibliotecas municipales permitiendo acceder en línea a sus catálogos.
Pero cuando un usuario necesita realizar una búsqueda a través de Web de informaciones ofrecidas por distintas organizaciones, básicamente encuentra un océano de datos faltos de estructura. O bien recorre uno a uno los servidores que pudieran interesarle, con los problemas de diferencias de interfaz e inconsistencias ya mencionados, o bien se basa en motores de búsqueda. Y, aunque estos motores son cada vez mejores y más importantes, ante una simple palabra clave ofrecen centenas de noticias, difíciles de refinar, en su mayoría carentes de interés ante la búsqueda emprendida y el usuario consume un tiempo considerable para hacerse con unas pocas que realmente le sean válidas. Además, ofrecen solamente la información digital, pero dejan fuera todas las bases de datos de referencias bibliográficas, entre otras.
Por ello, para facilitar al usuario final este acceso “horizontal” a la información de similares características ofrecida por distintas instituciones y servidores, es necesario Z39.50 como un método de acceso bien estructurado que permita buscar en distintos servidores con un único interfaz y resultados consistentes que puedan emplearse para otros fines.
Por último, también es importante recordar que en una institución con un número medianamente elevado de puestos de trabajo, por ejemplo, una biblioteca universitaria, mantener y actualizar clientes en cada PC supone un coste muy elevado, por lo que cada vez es más habitual alcanzar una sinergia entre ambas tecnologías y desarrollar pasarelas sobre Web que facilitan accesos Z39.50 a servidores que cumplen el estándar.

4.- AÚN QUEDA CAMINO POR ANDAR


Aunque la filosofía, desarrollo y futuro de Z39.50 hace ser optimistas en cuanto a sus aplicaciones se refiere y en especial desde el punto de vista del usuario final, que parece claramente favorecido, también es cierto que aún queda mucho camino por andar.
Desde el punto de vista del usuario “no profesional” todo parecen ventajas: Z39.50 ofrece la posibilidad de emplear un único interfaz de usuario, incluso una pasarela Web, para acceder a distintas bases de datos contenidas en distintos servidores sin necesidad de conocer cada uno de ellos. Es cierto que, en la práctica, se encuentran algunas deficiencias como tener que sacrificar parte de la funcionalidad propia de los sistemas nativos y que normalmente no se fusionan (merge) los conjuntos de resultados obtenidos. Pero, por las estrategias de búsqueda que suelen emplear estos usuarios, no representan problemas graves, les permite encontrar la información que buscan y, si necesitan algo más concreto, les facilita la localización de servidores que ofrecen información especializada en el tema de su interés, pudiendo luego dirigirse a esos servidores de manera directa.
Desde el punto de vista del implementador las cosas se complican un poco más. Z39.50 es un estándar muy amplío que ofrece una gran funcionalidad y atiende muy diversos entornos, no sólo el bibliotecario. Ningún desarrollo comercial ni particular soportan el estándar completo, aunque se exigen unos mínimos para garantizar la interoperabilidad. Estas diferencias de un desarrollo a otro conllevan ciertos problemas. Para paliarlos, al menos en un entorno de interés común, se están definiendo perfiles (profiles) Z39.50: conjunto de acuerdos entre desarrolladores que especifican el empleo de Z39.50 (en los puntos donde se ofrecen diversas opciones) para soportar una aplicación, función, comunidad o entorno particulares. Los primeros en desarrollarse fueron GILS (para identificar y localizar fuentes de información federales en USA de disponibilidad pública), ATS (para facilitar un acceso básico a bases de datos bibliográficas), WAIS (para acceder a servidores WAIS), Collections Profile (para acceder a bibliotecas digitales), CIMI (para acceder a la información de los museos).
Muchos de los problemas que se van encontrando en el empleo de Z39.50 terminan resolviéndose con el desarrollo de un perfil específico. La ventaja es que se evita la proliferación de estándares dispares y se garantiza la interoperabilidad al menos en los entornos donde se necesita. La desventaja es que la interoperabilidad no es universal (era una utopía) y que pueden desarrollarse perfiles redundantes para cada pequeño grupo de usuarios obedeciendo más a políticas habituales que a verdaderos requisitos funcionales. Por eso se conserva un “registro de perfiles”, sus definiciones son públicas, y ante la necesidad de uno nuevo se invita a participar en su desarrollo a todos los interesados en una política de trabajo que hasta ahora está funcionando bastante bien.
Desde el punto de vista del usuario “profesional” que quiere aprovechar la potencia del estándar para otras funciones bibliotecarias, también se van encontrando deficiencias, no tanto en el estándar propiamente dicho, sino en el desarrollo de sus aplicaciones. Por ejemplo cuando se trabaja en una red de bibliotecas y quiere llegarse a gestionar el préstamo interbibliotecario. Normalmente deben consultarse numerosos servidores gestionados por distintos sistemas. El personal que se encarga de estas tareas está formado y familiarizado con los distintos interfaces, por lo que la ventaja de uno común no le resulta tan apasionante. Sin embargo su empleo conlleva un considerable ahorro de tiempo que sí se valora.
Adicionalmente el empleo de pasarelas Web a servicios Z39.50 facilita la colaboración de las pequeñas bibliotecas de la red.
Pero empiezan a detectarse los inconvenientes. En este entorno la información relativa a fondos, localizaciones y circulación es vital, y no hay ningún método acordado para facilitarla a través de Z39.50; el empleo que se hace en cada aplicación de los atributos de búsqueda y las combinaciones de atributos es diferente, por lo que los resultados de las búsquedas son muchas veces poco fiables e inconsistentes; no es fácil fusionar los distintos resultados; es necesario unificar los hábitos de catalogación de las distintas bibliotecas para mejorar las búsquedas e incluir datos que faciliten esta mejora como ISSN, ISBN, etc., que no todas las bibliotecas cumplimentan o no lo hacen correctamente (aunque éste no es un problema específico de Z39.50); etc. Algunas de estas cuestiones requieren simples acuerdos entre bibliotecas o entre bibliotecas y desarrolladores fácilmente alcanzables, pero otras son técnicamente más complejas como la información detallada de localizaciones, fondos y circulación.
Al tratar este tema lo primero que surge es la diferencia que presentan las propias bibliotecas a la hora de gestionar este tipo de información tanto para monografías como para publicaciones periódicas. Se hace necesario la definición de un esquema y perfil Z39.50 a seguir al menos en el ámbito de uniones de catálogos con fines de préstamo interbibliotecario. Además, dado que el desarrollo puede llevar algún tiempo, es necesario llegar a algunos acuerdos provisionales que faciliten soluciones intermedias.
La definición de ese perfil se ha iniciado en 1998. No debe interferir en la gestión interna de cada servidor, pero debe garantizar la interoperabilidad de los distintos servidores que lo soporten. Se encuentra con un problema de partida que es la inconsistencia entre el formato USMARC de Holdings y la aproximación al problema de Z39.50. Debe garantizar que se siga empleando ese formato MARC, pero resolver cómo debe hacerse el envío de la información incluyendo la relativa a circulación; debe ser compatible tanto con la versión 2, como con la versión 3 del estándar; debe contemplar la longitud de los registros que contienen información detallada de fondos, que puede llegar a ser considerable. Es un campo en el que sigue trabajando, muchos son los usuarios y desarrolladores que han demostrado interés en el tema y colaboran en la definición y están liderados por la Biblioteca Nacional de Canadá.
Otra situación parecida nos encontramos cuando se trata con uniones de catálogos sopesando la conveniencia de mantener uniones centralizadas o definir uniones virtuales. Z39.50 permite la copia de registros catalogados y preparados para integrar. Esta facilidad está cobrando gran importancia en entornos donde se comparten este tipo de recursos, aunque como siempre afloran los problemas de propiedad intelectual. Una unión virtual de catálogos permite al usuario final el mismo tipo de consultas emulando una unión centralizada, pero presenta numerosas ventajas en cuanto a ahorro de tiempo y recursos, que se ponen especialmente de manifiesto si pensamos en bibliotecas digitales. Pero se encuentran problemas algunos de ellos comunes con los del caso anterior. Debe resolverse el envío de información detallada de fondos, localizaciones y circulación; debe estudiarse el tema de la detección y gestión de duplicados al fusionarse los conjuntos de resultados, en una unión centralizada de catálogos este proceso se realiza una única vez en el servidor que integra la información, que suele ser muy potente y disponer de algoritmos complejos y especializados para ello, en una unión virtual debería hacerlo en cada consulta el cliente, y no suele contar con la potencia necesaria para emplear dichos algoritmos de manera eficaz.
En algunos casos nos encontramos con soluciones intermedias a la espera de la mejora futura de los desarrollos, como la decisión de la Biblioteca Nacional de Australia de mantener durante unos años la unión centralizada de catálogos, pero aprovechar la potencia de Z39.50 para modificar la estrategia de su construcción y facilitar el proceso. Se catalogará desde clientes Z39.50 automatizándose la construcción del catálogo colectivo integrando servicios Z39.50 en los flujos de trabajo de las bibliotecas. Para ello están definiendo un perfil específico.
Podemos mencionar también algunos problemas más que afectan al usuario “no profesional”, aunque tarda algún tiempo en detectarlos por lo que no suelen aparecer reflejados en las primeras evaluaciones que se hacen de proyectos Z39.50; por ejemplo la recuperación empleando palabras clave. Es una búsqueda muy útil cuando el usuario desconoce el autor, título y materia exactos de una obra, o cuando se busca un amplio campo de documentos relacionados con algo. Muchos de los servidores y clientes Z39.50 dicen soportar esta facilidad, pero el empleo que hacen de los atributos de búsqueda y sus combinaciones denotan entre ellos falta de consistencia y fiabilidad, que lleva a la frustración del usuario. Es necesario que se acuerde una semántica que facilite la recuperación por palabras clave igualando entre los distintos desarrollos el uso que se hace de los atributos, valores y posibles combinaciones.

5.- LA REALIDAD ES MULTILINGÜE


Las cuestiones mencionadas en el punto anterior son el fruto de años de aplicación del estándar Z39.50 en algunos países, pero básicamente en EUA (Estados Unidos de América), por lo que los aspectos relacionados con la diversidad de idiomas no figuran. En Europa en general, y en España en particular, si se quiere que este tipo de desarrollos estén realmente al servicio de la sociedad, deben contemplar su realidad multilingüe y la pluralidad de países implicados.
Las normas de catalogación difieren porque son responsabilidad de instituciones diversas, se incluyen literales en los respectivos idiomas dentro de las normas de catalogación, las listas de palabras clave suelen estar en el idioma nacional o ser multilingües, hay diferencias en los juegos de caracteres, la ordenación alfabética difiere de un idioma a otro, incluso en el uso de un mismo idioma en dos países distintos. Para resolver este tipo de problemas son necesarias conversaciones, acuerdos, conversiones de datos en línea y desarrollos técnicos potentes.
La versión 3 de Z39.50 incorpora mecanismos para negociar entre el cliente y el servidor los juegos de caracteres y el idioma. El desarrollo del Explain también resuelve alguno de esos problemas (aunque no está muy extendido) y todos sus mensajes están pensados para un entorno multilingüe. El empleo de Z39.50 en otros países está ayudando a adecuarlo a este tipo de situaciones. Pero si se desea contar con un estándar de audiencia realmente internacional, que respete la pluralidad de culturas e idiomas, debemos empezar a profundizar en ello y colaborar en el desarrollo, porque no es suficiente con negociar un idioma, debe ser posible aprovechar toda la potencia multilingüe que hace tiempo, y “al servicio” de nuestros usuarios, se ha desarrollado en Europa.

6.- CONCLUSIONES


Z39.50 es un estándar internacional, amplio, potente y muy difundido en el mundo bibliotecario entre otros. Presenta numerosas ventajas tanto para el usuario final como para el bibliotecario. Su implantación y desarrollo no va en detrimento del empleo del Web, sino que deben converger en pasarelas Web a servicios Z39.50.
En la actualidad, la implantación del estándar va encontrando diversas deficiencias en las aplicaciones (holdings, inconsistencias entre sistemas, empleo de palabras clave, etc.), pero se están resolviendo y su solución implica al mundo bibliotecario.
Los desarrolladores y bibliotecarios españoles, encabezados por la Biblioteca Nacional y Autonómicas, deben involucrarse en este proceso, aprender de él, beneficiar con ello a los usuarios de la sociedad a la que prestan servicio y aportar elementos diferenciadores que lo enriquezcan.

BIBLIOGRAFÍA


BIBLIO TECH Information Technology for Libraries: “Z39.50: Part 1- an overview”, July 1998, http://www.biblio-tech.com/html/z39.50.html
BIBLIO TECH Information Technology for Libraries: “Z39.50: Part 2- Technical Details”, July 1998, http://www.biblio-tech.com/html/z39.50_part_2.html
BOOKWHERE: “Z39.50 Information Detail”, http://www.bookwhere.com/z3950d.htm
DEKKERS, Makx: “Z39.50 and multi-national/multi-lingual environments”, May 1996, http://www.ub2.lu.se/desire/radar/archive/indexing/schwartz.96/Papers/Dekkers@PICA.html
DEMPSEY, Lorcan; RUSSELL, Rosemary; KIRRIEMUIR, John: “Towards distributed library systems: Z39.50 in a European context”, Program electronic library and information systems, vol 30, nº 1, January 1996, http://www.aslib.co.uk/program/1996/jan/02.hmtl
DENENBERG, Ray: “Structuring and Indexing the Internet”, Decembre 1996, http://lcweb.loc.gov/z3950/agency/papers/italy.html
DENENBERG, Ray: “Z39.50 Recent Developments and Future Prospects”, Octobre 1996, http://lcweb.loc.gov/z3950/agency/papers/kbr.html
HAMMER, Sebastian; FAVARO, John: “Z39.50 and the World Wide Web”, Feb 1996, http://www.oclc.org:5046/archive/webcat/0098.html
ILTIS, Susannah: “Z39.50: An Overview of Development and the Future”, March 1995, http://www.cqs.washington.edu/~camel/z/z.html
LÉVÉJAC, Anne-Lise: “Z39.50: L’Information bibliographique structurée sur le net”, Mar 1997, http://wwwperso.hol.fr/~alevejac/Z3950.htm
LUNAU, Carrol D.: “Availability of Summary Holdings Information from vCuc Targets”, Decembre 1997, http:77www.nlc-bnc.ca/resource/vcuc/vchold1.htm
LUNAU, Carrol D,; TURNER, Fay: “vCuc Pilot Project: Status Report and Preliminary Identification of Issues”, June 1997, http://www.nlc-bnc.ca/resource/vcuc/earticle.htm
LYNCH, Clifford A.: “The Z39.50 Information Retrieval Standard, Part I: A Strategic View of Its Past, Present and Future”, D-Lib Magazine, April 1997, http://www.dlib.org/dlib/april97/04lynch.html
MOEN, William: “The ANSI/NISO Z39.50 Protocol: Information Retrieval in the Information Infraestructure”, http://www.cni.org/pub/NISO/docs/Z39.50-brochure/50.brochure.toc.html
“OPAC/HOLDINGS Profile 1: Profile for retrieving detailed library holdings in a bibliographic environment”, January 1998, http://www.nlc-bnc.ca/iso/z3950/holds6.htm
PAYETTE, Sandra D.; RIEGER, Oya Y.: “Z39.50: The User’s Perspective”, D-Lib Magazine, April 1997, http://www.dlib.org/dlib/april97/cornell/04payette.html
TURNER, Fay; ZEEMAN, Joe: “Z39.50 Keyword Searching of Bibliographic Systems: A Discussion Paper”, June 1998, http://www.nlc-bnc.ca/iso/z3950/keyword1.htm
WELLS, Andrew; PEARCE, Judith; GROOM, Linda; LEE Bronwyn: “Connecting and Sharing: the Emerging Role of Z39.50 in Library Networks”, January 1998, http://www.nla.gov.au/nla/staffpaper/awells2.html
“ZIG Commentaries”, July 1998, http://lcweb.loc.gov/z3950/agency/wisdom.html


La base de datos está protegida por derechos de autor ©espanito.com 2016
enviar mensaje