18 mar 2012

Catálogo bibliotecario en el entorno moderno de la información.


El intenso desarrollo y la expansión de Internet han tenido una influencia significativa en la formación y el funcionamiento de la información. El advenimiento de Internet ha aumentado notablemente el número de fuentes y la cantidad de productores de información. El fuerte aumento de los recursos electrónicos ha empujado el desarrollo de esquemas de metadatos para clasificarlos. La inmensa cantidad de la información disponible a través de Internet ha creado la necesidad de motores de búsqueda que permitan encontrar la información necesaria de una forma rápida y correcta. Estos buscadores han creado una seria competencia para los catálogos bibliotecarios.
Comparando con el rápido desarrollo de las tecnologías de Internet, el desarrollo de las bibliotecas no es tan dinámico. Al día de hoy el mundo bibliotecario en muchos aspectos sigue siendo bastante cerrado. Los catálogos y bases de datos de las bibliotecas en muchos casos no están accesibles para las aplicaciones Web, los buscadores no pueden indexar sus contenidos, a pesar de que los catálogos pueden estar abiertos para los usuarios. Esto lleva al hecho de que las bibliotecas están perdiendo su papel tradicional como el principal custodio y proveedor de la información.
Los catálogos de bibliotecas a menudo no están diseñados para soportar múltiples esquemas de metadatos. En muchas bibliotecas el esquema principal de datos, y a veces la única, está basada en el formato MARC.
El formato MARC fue creado por un equipo de bibliotecarios de la Biblioteca de Congreso (EE UU) liderados por Henriette Avram. La Biblioteca del Congreso es el organismo clave para este proyecto. El formato está basado en la normativa ISO 2909: “Format for Bibliographic Information Interchange on Magnetic Tape”. Basta con mirar la estructura de los registros MARC para tener claro que este sistema de metadatos fue desarrollada en los albores de la informática, cuando un disco duro todavía no existía y la información se almacenaba en cintas magnéticas enrolladas en bobinas. La capacidad de una bobina estándar fue de 20-40 MB y los tamaños máximos solo alcanzaban en algunos mecanismos de gama alta con la densidad de grabación de 243 bits/mm, lo que permitía escribir 140 MB en 730 metros de cinta.
Un catálogo MARC es una pila de registros guardados uno detrás de otro, y cada registro contiene toda la información completa. De esta forma la información se duplica en los registros que tienen los mismos datos. Aunque parece que un registro MARC es pequeño, el tamaño de un catálogo completo es enorme, comparando con el tamaño que pueda tener el mismo catálogo guardado en una base de datos relacional. En una base de datos con muchas tablas, la información está repartida entra las tablas, lo que permite evitar duplicidad de datos. Pero un registro MARC debe tener toda la información en el mismo, y como resultado, los datos se repiten constantemente. De esta forma un catalogo de registros MARC tiene mucha información duplicada. Por ejemplo, en una base de datos que contiene 100 libros de un autor, el nombre del autor se va a duplicar 100 veces.
La necesidad de tener toda la información en un registro MARC produce otro problema a la hora de catalogar: hay que controlar que la misma información siempre se escribe igual. A no ser así, en el catálogo pueden aparecer diferentes valores para la misma información. Esto puede provocar problemas a la hora de buscar o cuando se necesita agrupar registros por un campo.
La difusión del formato MARC ha marcado un nuevo problema – el problema de la compatibilidad entre catálogos. En el mismo tiempo que programadores de la Biblioteca del Congreso de EE.UU. trabajaban en el proyecto MARC, Gran Bretaña estaba trabajando en su propio proyecto similar que nombraron British National Bibliography o BNB MARC. A pesar de que en ambos países utilizan Inglés, las diferencias nacionales en las normas de catalogación fueron tan notables, que la versión de MARC inglesa y americana salieron incompatibles. Para superar este problema en 1968 los dos grupos iniciaron un proyecto conjunto MARC II, que debería tener en cuenta las normas nacionales de catalogación.
Pero el problema no ha sido superado y como el resultado en los años 70 aparecen cerca de 20 versiones diferentes del formato MARC: UKMARC, USMARC, AUSMARC, CANMARC, IBERMARC, DANMARC, NORMARC, etc. La tendencia continuó en los años siguientes. En la actualidad existe cerca de 50 formatos MARC. El problema de compatibilidad se fue agravada por el hecho de que no todas las bibliotecas han elegido el formato MARC como la base, por ejemplo en Alemania desarrollaron el formato MAB, muy diferente de los de más.
Las dificultades surgieron cuando las bibliotecas intentaron hacer intercambio de datos. Incluso las bibliotecas que se tomaron como la base el formato MARC, no podían comunicarse, puesto que tenían criterios diferentes a la hora de hacer la especificación de sus catálogos electrónicos.
Para superar la incompatibilidad de los formatos en 1977 la Federación Internacional de Asociaciones de Bibliotecarios (IFLA) comenzó a trabajar en realización de formato MARC universal (UNIMARC), que debería garantizar el intercambio entre las diferentes versiones de MARC. En 1987 IFLA publicó directrices para el formato UNIMARC y en los 90-s UNIMARC extiende bastante en Europa. En el año 1999 EE.UU. y Canadá unieron sus formatos USMARC y CANMARC, y como el resultado apareció el formato MARC 21.
Cuando XML salió a la luz, muchos creyeron que este lenguaje de marcado puede reemplazar a MARC. XML tiene ciertas ventajas. En XML no hay un conjunto predefinido de campos y se puede crear sus propias etiquetas según necesidades. Esta flexibilidad permite adaptarse muy fácil para trabajar con la variedad de catálogos. Además, dentro de un XML se puede insertar fragmentos de texto original, imágenes y sonido. También es importante tener en cuenta que XML es muy popular y los creadores han hecho bastante para su uso en Internet.
Incluso dentro del proyecto MARC han hecho pasos para utilizar XML. Por ejemplo, crearon MARCXML. Pero MARCXML es sólo un esquema que utiliza el XML como un contenedor para una entrada MARC21, sin cambiar la especificación de formato. Sin embargo, el uso de MARCXML facilita en gran medida el procesamiento de registros MARC, ya que existen muchos programas para trabajar con XML en diferentes lenguajes de programación.
Además, MARCXML integra mejor los catálogos de bibliotecas en el entorno de Internet. Un texto en formato XML puede ser fácilmente transmitido por el protocolo HTML, mientras que para transmitir un registro en el formato MARC original hay que utilizar un protocolo especial Z39.50 y utilizar programas especiales, la mayoría de los cuales son comerciales.
En algún momento muchos creyeron que formato MARC era demasiado viejo y era necesario buscar un reemplazo. En el año 2002, Roy Tennant, un orador de renombre internacional y un experto en tecnologías de información, escribió un artículo titulado “MARC must die”, en el que explicaba los problemas derivados de la utilización de este formato en la práctica.
Sin embargo, no se puede pasar por alto que durante mucho tiempo se ha creado una gran cantidad de registros MARC y las bibliotecas han invertido tanto esfuerzo y recursos para el desarrollo MARC, que sería prudente no abandonar su uso. Lo lógico es usarlo con más eficiencia. Pero hay que señalar, que a diferencia de las bibliotecas clásicas, las bibliotecas digitales modernas, al no estar vinculadas tanto con el MARC, pueden utilizar los últimos avances en tecnologías de información de forma mucho más eficaz para almacenar los datos y realizar las búsquedas eficientes.
Para mayor claridad veremos las diferentes estructuras en una imagen. El primer diagrama muestra una conexión al catálogo directa. En el segundo se puede ver como se accede a un servidor-Z a través de Internet, usando una pasarela- Z. El tercer diagrama muestra un catálogo organizado con la base de datos. El uso de la tecnología Java Database Connection (JDBC) permite conectar cualquier tipo de la base de datos y presentar datos tanto en MARC como en otros formatos, para lo que existe una gran variedad de librerias Open Source para Java. El uso de Java también nos permite trabajar bajo cualquier sistema operativa.
En el año 2008 apareció el esquema Dublin Core (DC). Se trata de un simple conjunto de 15 campos principales para la descripción de documentos y otros objetos digitales, principalmente en Internet. Los elementos DC pueden ser complementados por calificadores. Debido a su tamaño compacto y su simplicidad el esquema DC se popularizó rápidamente.
DC no fue creado para sustituir MARC, aunque había opiniones que esto podía pasar. En efecto, el esquema DC es más adecuada para el uso con herramientas de búsqueda, pero los registros DC no son muy detallados y no pueden contener la misma información que puede tener un registro MARC. Pero la cuestión es, ¿hasta que punto es necesario detallar una descripción para encontrar un recurso en Internet? ¿Se puede encontrar cualquier recurso, utilizando la búsqueda por el texto completo sin usar meta-descripción?, lo que actualmente hacen los motores de búsqueda en Internet.
Las discusiones llevaron a una propuesta para definir 4 niveles para catalogar recursos electrónicos en función de la importancia del recurso:
  • entradas MARC completas
  • entradas DC complementarias
  • entradas DC simples
  • el uso de palabras claves para las búsquedas
Y en cualquier caso el nivel de detalle en la descripción debe ser determinado por el catalogador para cada recurso o para una categoría de los recursos.
Las bibliotecas digitales modernas por lo general, a parte de a las colecciones de la biblioteca clásica, ofrecen colecciones de archivos e incluso colecciones de museos. Aquí cabe señalar que el MARC puede describir los documentos con un pequeño número de relaciones jerárquicas (colecciones de obras, series monográficas), pero esto no es adecuado para realizar descripción de archivos que tienen jerarquías muy profundas. MARC21 contiene algunos campos para describir los archivos y manuscritos, pero estos campos son a veces inútiles, porque les falta profundidad jerárquica. Los archivos trabajan con formato EAD (Encoded Archival Description), que fue desarrollado especialmente para describir archivos y colecciones de manuscritos.
Sin embargo, el formato MARC, tan apreciado en las bibliotecas, que la comunidad de Internet está obligada a contar con él. Por ejemplo Google en su proyecto Google Books permite utilizar formato MARC para importar catálogos de las bibliotecas que quieran unirse al proyecto. Con esto Google pretende crear un amplio catálogo virtual para encontrar libros en cualquier idioma. En la realidad Google no está haciendo solo un catálogo, también está digitalizando los libros enteros, que le permita ofrecer a los usuarios a realizar búsquedas por el texto completo, incluso en los materiales que están protegidos por los derechos de autor.
MARC sigue siendo un componente muy importante de la infraestructura bibliotecaria, pero junto a él es importante utilizar otros sistemas que proporcionan mejoras en el intercambio de la información. De lo contrario la comunidad bibliotecaria seguirá siendo una sociedad cerrada dentro de Internet.

1 comentario :

Anónimo dijo...

Incredible points. Solid arguments. Keep up the amazing work.


Here is my page; Chiropractor

Related Posts Plugin for WordPress, Blogger...