MATTHEW J. DOVEY
ASÍ QUE QUIEREN CREAR UN CATÁLOGO
COLECTIVO
Sobre las
diferentes maneras
de crear
catálogos colectivos.
En un pasado
no tan distante, si un grupo de bibliotecas deseaba ofrecer un catálogo único y
en línea de sus colecciones tenía que adoptar un modelo de catálogo colectivo
físico; es decir, habría ingresado sus registros de catalogación en una sola
base de datos. Más recientemente, se comenzó a trabajar en los catálogos
colectivos virtuales, por medio de los cuales la interfase de usuario ofrece un
acceso integrado a catálogos múltiples como si fueran uno solo. Pero ninguno de
estos dos modelos es una panacea. Pero ninguno de estos dos modelos es una
panacea. Ambos tienen ventajas y desventajas, y la decisión de cuál adoptar
depende de cada caso en particular.
Antes de
comenzar a analizar los diferentes modelos (el físico y el virtual), me
gustaría hablar sobre algunos elementos de la teoría de recuperación de
información. Hay dos conceptos principales: exhaustividad y pertinencia.
Exhaustividad consiste en recuperar en una búsqueda toda la información que a
uno le interesa. Por ejemplo, si se buscara el término "Tchaikovsky"
en un catálogo bibliográfico, el índice de exhaustividad sería bajo si el
catálogo incluyera además de "Tchaikovsky" otras variantes -como
"Chaikovsky"- y no utilizara referencias cruzadas entre las distintas
formas de escribir el nombre. Pertinencia, por otra parte, consiste en que los
resultados de la búsqueda estén relacionados. Por ejemplo, si se buscara "Cyril
Smith", el índice de pertinencia sería bajo si incluyera una gran cantidad
de resultados sobre el político cuando en realidad nos interesaba el pianista.
Los usuarios Web, en particular, están acostumbrados a un índice bajo de
exhaustividad y pertinencia, ya que los
motores de búsqueda Web son bastante pobres en este aspecto. Pe bastante pobres
en este aspecto. Pero esto no es
sorprendente, puesto que lograr un índice alto cuando se buscan datos no
estructurados o semiestructurados es una tarea muy difícil. Algunos
argumentarían que es imposible, dado que los problemas para lograrlo están
estrechamente relacionados con la inteligencia artificial (para lograr un
índice alto de exhaustividad y pertinencia, los algoritmos deben tener cierta
noción de la consulta y los datos buscados). Por el contrario, los
bibliotecarios y usuarios de OPAC (Catálogos de Acceso Público en Línea) están
acostumbrados a obtener un índice muy alto de pertinencia y exhaustividad, en
especial de esta última. Esto se debe a la gran dedicación puesta en la creación de registros de catalogación, que
son a veces estructurados y muy complicados, y también a las normas uniformes
aplicadas (como AACR2).
Los modelos
físicos conservan un índice alto de exhaustividad y pertinencia, ya que ofrecen
una base de datos única, con normas de catalogación compartidas y una sola
política de indización. Voy a ampliar brevemente este último punto. Aunque dos
sistemas de bibliotecas contengan registros creados conforme a las mismas
normas de catalogación (y a normas de catalogación (y a las interpretaciones de
esas normas), la indización entre ellas puede diferir: un sistema puede agrupar
los ISSN e ISBN en el mismo índice, mientras que otros pueden indizarlos por
separado, incluir autores en el índice temático, colocar las funciones
primarias y secundarias en índices separados, etc. Un usuario típico se
acostumbrará a las características de cada sistema (por ej., cómo escribir
Tchaikovsky para recuperar todos los resultados) y logrará regularmente un
índice alto de exhaustividad y, en muchos casos, también de pertinencia.
El problema
con los modelos físicos es su mantenimiento. Hay como mínimo cuatro modelos
sobre cómo construir un catálogo físico:
En el primer
modelo, el catálogo colectivo es el catálogo principal para las bibliotecas
participantes. Este es el caso del Catálogo Colectivo de la Universidad de
Oxford (Oxford University Union Catalogue, OLIS). La Biblioteca Bodleian, junto
con las bibliotecas de las facultades, departamentos y universidades
dependientes, todas (o casi un tercio) están suscriptas a un solo sistema de
bibliotecas y a un solo catálogo. Este modelo tiene ciertos beneficios Este
modelo tiene ciertos beneficios, puesto que centraliza el costo del soporte
técnico y las bibliotecas no tienen que afrontar los mismos problemas en forma
independiente. Pero es evidente que le traería problemas a las que ya tienen
sus propios sistemas y quieren adoptar uno nuevo. También necesitaría una mayor
colaboración por parte del grupo para fijar las políticas de indización y
catalogación (si bien sostengo que el modelo colectivo virtual puede no ser una
alternativa). Aún así, si las bibliotecas que están desarrollando un nuevo
catálogo colectivo no tienen sistemas, tienen poco soporte local de tecnología
de la información y "se llevan
bien", este modelo es efectivo y vale la pena tenerlo en cuenta. El
aumento en la velocidad y confiabilidad de la red hace que sea apropiado hasta
para las bibliotecas geográficamente dispersas. No obstante, no soporta
situaciones en las cuales una biblioteca es miembro de más de un catálogo
colectivo.
En el
segundo modelo, los registros se exportan de los catálogos locales al
colectivo. Al igual que los dos modelos siguientes, da por sentado que las
bibliotecas del grupo tienen sus propios catálogos en línea o sus propios
sistemas de bibliotecas. Es el modelo adoptado por el tecas. Es el modelo
adoptado por el servicio COPAC del Reino Unido, y son cada vez más las
bibliotecas universitarias de ese país que envían sus registros a una base de
datos centralizada. Incorporar una biblioteca nueva no es un asunto trivial ya
que se deben establecer los mecanismos para exportar, lo cual puede requerir
una conversión de los registros. Sin embargo, esto se hace más fácil a medida
que aumenta el número de bibliotecas, puesto que es probable que las nuevas
bibliotecas estén utilizando los mismos sistemas o similares a los ya
existentes. Este modelo también centraliza el soporte que se necesita, así que
es apropiado donde hay poco soporte local de tecnología de la información para
las bibliotecas del grupo. Si bien trata de hacer hincapié en los estándares
mínimos, no maneja totalmente la compatibilidad de los registros importados,
pero puede adoptar una política uniforme de indización. Un problema importante
con este modelo es el tiempo transcurrido entre que se cataloga un ítem en el
catálogo local y en el catálogo colectivo. Esto dependería de la frecuencia con
que se exportan los registros. Hay que recordar que en el caso de todas las
bibliotecas, menos las más pequeñas, ya existe una gran discrepancia entre los
fondos reales y el catálogos fondos reales y el catálogo en línea (colecciones
que todavía necesitan ser catalogadas, nuevas adquisiciones cuya catalogación
completa requiere varios días, etc.), de modo que unos pocos días de diferencia
entre el catálogo local y el central tal vez no signifiquen un problema
importante. Borrar o corregir registros en el catálogo local y cómo hacer una
copia en el catálogo central son otros problemas que tienen solución. Sin
embargo, la demanda de soporte local de tecnología de la información puede
aumentar si la biblioteca pasa a ser miembro de un gran número de catálogos
colectivos de este tipo. Un problema que este modelo no puede solucionar es la
información volátil local, como la de circulación (por ej., si el ítem está
prestado), pero siempre se puede obtener haciendo una búsqueda separada en el
catálogo local (posiblemente automatizado y transparente para el usuario).
En el tercer
modelo, se catalogan los registros en el catálogo central y luego se los
importa al local. Este es el modelo adoptado por OCLC, en particular en su
proyecto CORC. En este caso, las bibliotecas participantes catalogan los
recursos de Internet en forma centralizada (usando una interfase Web) y después,
periódicamente, se importan al catálogo local. Una de las ventajas es que las
políticas de catalogación e indización se determinan en forma centralizada,
pero permite que cada biblioteca miembro use su propio sistema. Además, es fácil decidir qué registros deben
ser locales solamente (si una biblioteca que abarca una variedad de materias
fuera miembro de un catálogo colectivo especializado en una sola materia). Esto
impone la necesidad de un mayor grado de soporte local de tecnología de la
información, puesto que importar al catálogo local es un problema local y las
bibliotecas participantes deben llegar a un acuerdo con respecto a qué
políticas de catalogación usar. Este modelo no trata directamente la
información local volátil, como el estado de los préstamos, si bien cuenta con
recursos.
Un último
modelo consiste en actualizar en forma dinámica el catálogo central y el local
al mismo tiempo; es decir, una catalogación distribuida. El protocolo Z39.50
(que describiré más adelante) ofrece un servicio de actualización de catálogos.
Lo podría utilizar un cliente de catalogación (y cada vez son más los que que
soportan ahora este protocolo) para enviar la actualización del catálogo (ya
sea agregar, borrar o modificar registros) a un servidor proxy, que envía las
actualizaciones a los catálogos central y local o los coloca en lista de espera
si los catálogos no estuvieran disponibles en el momento. Por otra parte, al
actualizar el catálogo local se podrían copiar registros en el catálogo central
en tiempo real o quedar en cola. En ambos casos, tal vez sea necesario
modificar los registros utilizando las mismas soluciones que para los modelos
de importación y exportación antes mencionados. Muchos de los principales
sistemas comerciales de bases de datos distribuidas trabajan con este modelo,
que ofrecería la indización uniforme del modelo COPAC sin el problema de demora
en las actualizaciones, y hasta podría incluir actualizaciones de la
información volátil local como el estado de los préstamos. La tecnología para
realizar la mayoría de estas cosas ya existe, así que los costos centrales y
locales en tecnología de la información serían similares a los del modelo
COPAC. No obstante, hasta la fecha no vi este modelo en práctica.
Más
recientemente, observamos la aparición de modelos virtuales, cición de modelos
virtuales, conocidos dentro de la comunidad de bibliotecas electrónicas del
Reino Unido como "clumps", término acuñado más por casualidad que
deliberadamente. El modelo de base ofrece al usuario una sola interfase que
hace "búsquedas cruzadas" en los catálogos participantes en paralelo
y fusiona los resultados, como si fuera un único catálogo. La opinión general
es que este modelo es más costo-efectivo, más elástico y más fácilmente
escalable que los modelos físicos. Aunque no objetaría que los modelos
virtuales puedan reunir todas estas ventajas,
no se puede garantizar automáticamente que este modelo sea costo-efectivo.
De hecho, un estudio reciente del servicio COPAC reveló que era más
costo-efectivo continuar así que
adoptar un modelo físico. Para lograr costo-efectividad, muchas veces se
usa el protocolo Z39.50 debido a su adopción dentro del mundo bibliotecario.
Hay buenas introducciones al Z39.50 pero, en muy breves palabras, se trata de
un protocolo genérico que permite a un software cliente (en general, un gateway
Web para el proyecto "clump") consultar una base de datos (en
general, un catálogo bibliotecario) y obtener resultados. Estaba diseñado
originalmente para consultar una base de datos por vez, pero ser una base de
datos por vez, pero se defiende bien con las consultas a bases de datos
múltiples en paralelo.
Sin embargo,
el problema principal de los catálogos colectivos virtuales es que las bases de
datos tienen políticas diferentes de catalogación e indización. A menudo se
cree, erróneamente, que son más fáciles de crear porque no requieren de un
acuerdo o consentimiento sobre estos temas. Pero de inmediato nos encontramos
con un problema informático conocido como "buscando bases de datos
semánticamente heterogéneas", que ocurre, en especial, cuando hacemos
búsquedas en dominios diferentes (por ej., archivos y museos, y también bibliotecas).
Una vez más, el problema reside en obtener un buen índice de exhaustividad y
pertinencia (en especial, exhaustividad), y los problemas son muy similares a
los que se presentan con los datos no estructurados. La tecnología puede darnos
buenos resultados, pero no tan buenos como los alcanzados a través de una
práctica uniforme de indización y catalogación. Muchos de los proyectos
"clumps" llegaron a esta conclusión. Además, mientras que un usuario
se puede acostumbrar a las características de los OPAC individuales, los OPAC
múltiples consultados en paralelo, cada uno con sus propias características,
son más difíciles de aprender y de ajustar.
Agregar un
nuevo catálogo a un "clump" colectivo virtual puede ser bastante
fácil, siempre que el nuevo catálogo soporte el protocolo Z39.50 y tenga un
buen soporte local de tecnología de la información. Pero si el grupo está
conformado por bibliotecas pequeñas que cuentan con muy poco soporte local de
tecnología de la información -o ninguno en absoluto-, es muy importante
determinar que el sistema bibliotecario soporte Z39.50. Por lo tanto, el modelo
virtual es más costo-efectivo en el primer caso que en el último. Asimismo, si
bien trasladar el catálogo al "clump" colectivo virtual puede ser una
tarea bastante directa y rápida, configurarlo correctamente para que los
resultados sean coherentes -en particular, con buena exhaustividad y
pertinencia- es algo difícil. De hecho, puede ser tan difícil como agregar una
biblioteca nueva a un catálogo colectivo físico. Otra dificultad es si una
biblioteca pertenece a dos catálogos colectivos virtuales que requieren
configuraciones diferentes, pero existen iniciativas internacionales, como Bath
Profile, que buscan evitarlo.
Otra ventaja
que afirman tener los modelos virtuales es que son más elásticos, ya que es más
económico ejecutar gateways múltiples que bases de datos físicas múltiples, y
se pueden hacer búsquedas en el gateway aún no estando todas las colecciones
disponibles. Es cierto, sin embargo, que creer que esta es una ventaja depende
de la importancia que tenga para uno la exhaustividad. En el catálogo colectivo
físico, podemos encontrar todo o nada (si el catálogo no está disponible),
mientras que el catálogo virtual tal vez no recupere los resultados de todos
los miembros del grupo porque un determinado catálogo no estaba disponible,
porque tardaba en responder, etc. Un punto sujeto a discusión es cuál es
"mejor" para el usuario. Para aquel que trata de localizar todas las
copias de un ítem en un catálogo colectivo, la "elasticidad" del
catálogo virtual puede ser más un fastidio que una bendición.
Otro tema
importante en relación a los catálogos colectivos virtuales es la
escalabilidad. Los catálogos colectivos físicos se pueden ampliar casi hasta el
infinito, siempre que los recursos centrales están disponibles. Los virtuales
están disponibles. Los virtuales no están limitados por los recursos centrales,
sino por temas más fundamentales como el ancho de banda de la red. Hay distintas
opiniones con respecto a cuántas bases de datos se pueden consultar en forma
paralela con efectividad. Según los expertos, pueden ser entre 10 y 100. A esto
no contribuye el hecho de que existan dos maneras diferentes de hacer una
búsqueda paralela. La más común consiste no sólo en realizar la búsqueda en
paralelo, sino en recuperar también los resultados en paralelo. En este caso,
si se hace una búsqueda cruzada en diez catálogos y el resultado son 100
registros, se estarían volcando mil registros a la red. Es evidente que no se
ajusta muy bien a escala, pero sí permite que la interfase clasifique los
resultados (por ej., por autor). Otra manera es hacer la búsqueda en paralelo y
sólo recuperar los registros a medida que se necesitan. Es más escalable, pero
hace más difícil mostrar los resultados clasificados de otra manera que no sea
por catálogo. El Z39.50 puede soportar
otro tipo de clasificación además de los catálogos (es decir, se envía un
pedido de búsqueda, se pide al catálogo que clasifique los resultados y después
recupera los resultados que se necesitan, lo cual resolvería el problema, pero
son pocos los sistemas de bibliotecas que soportan este método.
Una solución
para el problema de escalabilidad es estimar los conocimientos anticipados; es
decir, preseleccionar los catálogos individuales dentro del grupo de acuerdo
con lo que el usuario busca. Existen varios métodos. Uno consiste en darle al
usuario información sobre el valor de
la colección de los catálogos individuales. Otro consiste en codificarla para
que sea legible por computadora, posiblemente generada en forma automática
desde los índices, y dejar que el gateway seleccione los catálogos en base a la
consulta y a esta información. Estos métodos necesitan una mayor investigación,
pero parecen ser menos efectivos para los grupos basados en materias (que
tendrían un valor muy similar) que para los grupos regionales o geográficos,
pero en ninguno de estos casos se obtiene una buena exhaustividad. Los mecanismos
para automatizar este conocimiento anticipado no se alejan mucho de la idea de
centralizar los índices, lo que da lugar a otro modelo de catálogos colectivos
no investigado todavía. Hay catálogos múltiples que se indizan localmente o en
forma centralizada. El usuario busca en los índices centrales y después
recupera los registros directamente de los catálogos individuales. En
comparación con los otros modelos mencionados, esta sólo sería una ventaja si
la cantidad de datos en un registro fuera mucho más grande que la indizada, y
sería particularmente útil si esa información fuera volátil (como la
información de circulación).
Todavía hay
problemas técnicos en los catálogos colectivos virtuales. El soporte que ofrece
el proveedor para el Z39.50 es mayor, pero aún debe mejorar. Algunos no lo
consideran importante; la mayoría cree
que lo es, pero el soporte brindado es mínimo (por ej., no soportan
características como clasificar). Aún hay problemas dentro del estándar.
Recientemente se determinó que el método para la devolución de información de
fondos bibliotecarios estaba por debajo del estándar y, por lo tanto, la
información sobre fondos y préstamos que los sistemas recuperan (si es que lo
hacen) es aleatoria. Todavía hay que tratar los problemas de escalabilidad y de
conocimientos anticipados. No obstante, no todos los problemas son técnicos y
muchos de ello son técnicos y muchos de ellos, como las prácticas de
catalogación e indización, son importantes y se deben resolver cualquiera sea
el modelo adoptado. La tecnología sola no puede resolver todos los problemas.
Cuando
estamos por embarcarnos en el desarrollo de un catálogo colectivo, se plantea
la duda de qué modelo elegir. Esto depende, en parte, de qué bibliotecas
integran el catálogo. Si son medianamente pequeñas y tienen poco soporte
técnico local, recomendaría adoptar un modelo colectivo físico, que tiene un
mayor costo centralizado en tecnología de la información, pero en conjunto no
es muy diferente del costo del modelo virtual. Este modelo reparte el costo (y
la búsqueda también) entre las bibliotecas locales y, por lo tanto, es más
apropiado para las que utilizan sistemas más grandes con buen soporte local de
tecnología de la información. Otro problema son los requisitos y las
expectativas de los usuarios. Si se busca un índice de exhaustividad y
precisión comparable con el de los OPAC, los modelos físicos tienen una clara
ventaja y no es muy probable que esto vaya a cambiar. No obstante, la mayoría
de los usuarios que están acostumbrados a hacer búsquedas en la Web van hacer
búsquedas en la Web van a estar más que contentos con menos que una búsqueda
perfecta.
Referencias
1. Para más detalles acerca de los proyectos
sobre "clumps" de bibliotecas electrónicas, dirigirse a
http://www.ukoln.ac.uk/services/elib/projects/
2. Para más datos sobre el Oxford Union
Catalogue, ingresar a http://www.lib.ox.ac.uk
3. Para más información acerca de COPAC,
dirigirse a http://www.copac.ac.uk
4. El estudio sobre la viabilidad del Z39.50
para el servicio COPAC está en
http://www.curl.ac.uk/projects/z3950.html
5. Para más detalles acerca de CORC,
dirigirse a http://www.oclc.org/oclc/corc/index.htm
6. Una buena introducción al Z39.50 se puede
encontrar en ht.uk/issue21/z3950/intro.html">http://www.ariadne.ac.uk/issue21/z3950/intro.html
7. Hay un artículo sobre Bath Profile en
http://www.ariadne.ac.uk/issue21/at-the-event/bath-profile.html
8. Algunos artículos sobre la búsqueda de
bases de datos heterogéneas distribuidas están en: "Federated database
systems for managing distributed, heterogenous and autonomous databases".
Sheth y Larsen (1990). ACM Computer Surveys No 22.
"Impact of Semantic Heterogeneity on Federating
Databases". R. M. Colomb
(1997). Computer Journal, British Computer Society, Vol 40, No
5. ISSN 00104620.
Detalles
sobre el autor
Matthew J.
Dovey
Gerente de
Investigaciones y Desarrollo
Servicio de
Automatización de Bibliotecas
Universidad
de Oxford
Email:
matthew.dovey@las.ox.ac.uk
Sitio Web:
www.lib.ox.aef="www.lib.ox.ac.uk">www.lib.ox.ac.uk
URL: http://www.ariadne.ac.uk/issue23/dovey/intro.html
Traducido
con la correspondiente autorización del autor.
Departamento
de Informática y Sistemas.
Facilitado
por la Biblioteca Nacional
de la República Argentina