viernes, 29 de abril de 2011

La evolución de los catálogos colectivos

La Biblioteca del Congreso de los EEUU es el lugar donde reside
la agencia de mantenimiento del protocolo Z39.50, un protocolo que
permite compartir los catálogos de muchas bibliotecas en todo el mundo

Desde hace muchos años las bibliotecas se han integrado en sistemas bibliotecarios que las agrupan institucionalmente, geográficamente o temáticamente. Esta integración puso siempre sobre el tapete el problema de cómo construir servicios que operen en línea con la información de múltiples catálogos. O algo más básico aún, cómo formar un catálogo integrado y consistente con la información procedente de múltiples catálogos. También algo más sofisticado: el sueño dorado de cómo una biblioteca podía acceder en línea al catálogo de otra, obtener la información que buscaba y combinarla en línea con su propio catálogo o con las respuestas de varias bibliotecas, un trabajo clave para el desarrollo de Bibliotecas Virtuales y Bibliotecas híbridas. Las respuestas han sido varias y también aquí ha habido una evolución que vale la pena entender.

Del software a los metadatos y de los metadatos a los protocolos
Varias veces, en algunos sistemas bibliotecarios, asociaciones o redes de de bibliotecas se planteó la idea de avanzar a través de la estandarización de los sistemas de software. Pero pronto se vio que por allí no estaba la solución. Tampoco funcionó la idea de crear plataformas de sistemas bibliotecarios gratuitos. La idea de interconectar bibliotecas mediante la unificación del software bibliotecario mostró ser inviable.

La solución debía venir desde un esperanto bibliotecario, el formato MARC, del cual hablamos anteriormente. El MARC era lo suficientemente estricto y universal como para convertirse en una forma de descripción compartida por las bibliotecas. El problema se convirtió entonces en cómo unificar catálogos escritos en MARC, cómo cada biblioteca podía verter su catálogo al MARC y cómo podía entender en línea el catálogo MARC procedente de otra biblioteca o, por lo menos, incorporar fuera de línea registros de metadatos procedentes de otras bibliotecas.

Es decir, se comprendió que no se trataba de unificar el software, sino la manera de compartir y esto es lo que definen los protocolos.

Z39.50
Aún antes de la WWW ya se había diseñado, en 1988, con bastante solidez y flexibilidad, si bien con una cierta complejidad, un esquema para facilitar a las bibliotecas compartir información en tiempo real, a través de Internet, conectando los catálogos de diferentes bibliotecas, aún pensando que éstas podían tener sistemas bibliotecarios diferentes. La solución fue el protocolo Z39.50. Este fue un importante paso hacia adelante, fue adoptado por las bibliotecas grandes y por los mejores proveedores de sistemas, si bien pronto se vio que no se resolvían con él todos los problemas ligados a los catálogos colectivos, que no era una autopista dorada hacia el sueño de una biblioteca universal, que habían limitaciones importantes que tenían que resolverse en forma pragmática, sin que eso significara abandonar el Z39.50.

El Z39.50 abrió sin duda un camino. Su versión 2 fue publicada en 1992 y su versión 3 en 1995. Su legado permanece hasta la fecha, brinda una serie de facilidades al usuario que aún son vistas como una solución ideal, pero en general, se considera que, como protocolo, es demasiado complejo para su implementación en muchos sistemas bibliotecarios.

De esta forma, unos años más tarde de que su uso se extendiera en forma significativa, se hizo evidente que era interesante también poder compartir metadatos en un esquema más sencillo e integrador, que aunque careciese de la capacidad de tiempo real y de todas las virtudes bibliotecarias del Z39.50 fuese más sencillo de implementar. Este fue el espacio sobre el que se desarrolló el protocolo OAI-PMH a partir del 2001, un tema sobre el que hablaremos luego.

viernes, 22 de abril de 2011

¿Cómo ha cambiado Dublin Core en su evolución?

Los 15 elementos esenciales de Dublin Core y su orientación
a ser útil en aplicaciones le abre camino al futuro
(la imagen es un fotomontaje de un transbordador con el
logo de la iniciativa Dublin Core)

Hemos estado hablando de evolución de los conceptos de metadatos y llegamos a Dublin Core. Un conjunto de metadatos cuya virtud es la sencillez y que resolvió, en la segunda parte de los años 90, una tarea pendiente que la humanidad tenía para ese momento. Cómo poder clasificar los ingentes recursos de la Internet dado que hacerlo con los esquemas de metadatos previos, como el MARC, resultaba impráctico de entrada. Pero como ocurre con toda propuesta humana, Dublin Core ha evolucionado en el tiempo y por eso, antes de comentar acerca de otros esquemas de metadatos modernos, nos ha parecido interesante abrir un espacio a la evolución de Dublin Core.

Un trabajo inicial bien hecho
Uno de los aspectos que llama la atención en Dublin Core es que el trabajo inicial de definir los 15 elementos esenciales estuvo muy bien hecho porque, quince años más tarde, estos siguen siendo los mismos: Titulo, Creador, Materia, Descripción, Editor, Contribuyente, Fecha, Tipo, Formato, Identificador, Fuente, Idioma, Relación, Cobertura y Derechos (Ver ¿Cuáles son los metadatos esenciales?). Esto convierte a este conjunto de metadatos en una referencia estable para los profesionales que trabajan con información.

Quince por tres y más
Había que reconocer el hecho con evidencias que, en muchos casos, los 15 metadatos esenciales eran demasiado poco para trabajar razonablemente y clasificar un recurso, de una manera útil.
Para atender este problema, la iniciativa Dublin Core, se vio en la necesidad de definir un poco más de 50 términos, sin dejar de enfatizar los 15 iniciales (Ver http://dublincore.org/usage/terms/)

Dublin Core son varios estándares con una misma esencia
En su evolución Dublin Core ha sido acogido por varias organizaciones de definición de estándares y por eso hoy día podemos ver los metadatos de Dublín Core definidos con varias siglas, con matices diferentes, pero con una misma esencia.

Entre las organizaciones de estándares que han ratificado a Dublin Core están la comunidad conocida como Internet Engineering Task Force (IETF), con su estándar IETF 5013, el American National Standard Institute (ANSI), con su estándar ANSI/NISO Z39.85-2007 y la International Organization of Standarization (ISO), con su estándar ISO 15836:2009.

Es importante destacar que aunque Dublin Core sea expresado como varios estándares en lo formal, esto no afecta el hecho de que podamos seguir conversando de sus términos esenciales, con propiedad, como si se tratase de una única definición.

El futuro de Dublin Core
La evolución natural de la iniciativa Dublín Core ha orientado esta aproximación a los metadatos hacia las aplicaciones, el uso en múltiples contextos, como esquema base en los protocolos de intercambio, búsqueda, recuperación y cosecha de información. Los términos definidos por la iniciativa Dublin Core son un vocabulario popular en los modelos de representación de información, particularmente el RDF. Esta es la razón por la cual, en su evolución, Dublin Core parece seguir proyectándose como el más universal, sencillo y práctico de los esquema de metadatos que usaremos en los próximos años.

sábado, 16 de abril de 2011

¿Cuáles son los metadatos esenciales?

Los participantes de un taller convocado por la OCLC en 1995
se preguntaron: ¿Cuáles son los metadatos esenciales?
Y decidieron desde entonces decidir por concenso

Después de muchos años de esfuerzo sistemático y ante un evidente cambio en los mecanismos de producción, almacenamiento y recuperación de información, una pregunta que en algún momento la humanidad tenía que hacerse era la que se hizo el grupo de personas que en 1995 se reunió en Dublin, Ohio, en un taller convocado por la OCLC. ¿Cuáles son los metadatos esenciales? Aquellos que están en la base de la descripción genérica y simple de cada recurso de información, no importe el tipo que sea.

Los metadatos esenciales
Dublin Core establece un conjunto de 15 elementos básicos para describir un objeto de información. Lo resaltante es que son sólo 15 en lugar de los centenares que tenemos en MARC. Para el que trabaja con información siempre es interesante detenerse en el conocimiento que sintetizan los metadatos Dublin Core. Son realmente esenciales y están definidos en http://www.dublincore.org: Titulo, Creador, Materia, Descripción, Editor, Contribuyente, Fecha, Tipo, Formato, Identificador, Fuente, Idioma, Relación, Cobertura y Derechos.

Los 15 elemento de Dublin Core
1 Título (dc:title)
El nombre dado al recurso. Típicamente un título es un nombre por el que el recurso es formalmente conocido.
2 Creador (dc:creador)
La entidad primariamente responsable de hacer el recurso. Puede ser una persona, una organización o un servicio.
3 Materia (dc:subject)
Un tópico de contenido del recurso. Tipicamente será expresada como palabras clave, frases clave o códigos de clasificación que describen el recurso. La práctica recomendada es seleccionarla desde un vocabulario controlado o esquema de clasificación formal.
4 Descripción (dc:description)
Una descripción del contenido del recurso. Por ejemplo, puede ser un resumen, una tabla de contenido, una referencia a una descripción gráfica del contenido.
5 Editor (dc:Publisher)
Una entidad responsable por hacer el recurso disponible. Puede ser una persona, una organización o un servicio.
6 Contribuyente (dc:contributor)
Una entidad responsable de hacer contribuciones al recurso. Puede ser una persona, una organización o un servicio.
7 Fecha (dc:date)
Una fecha de un evento en el ciclo de vida del recurso. Típicamente la fecha será asociada con la creación o disponibilidad del recurso y se recomiendo usar el formato ISO 8601 (YYYY-MM-DD).
8 Tipo (dc:type)
La naturaleza o género del contenido del recurso. Incluye términos describiendo categorías generales, géneros o niveles de agregación del contenido. Se recomienda seleccionar un valor desde un vocabulario controlado.
9 Formato (dc:format)
La manifestación física o digital del recurso. Puede incluir el tipo de medio o las dimensiones del recurso. Puede usarse para determinar el software, hardware o equipo necesario para operar el recurso. Se recomienda seleccionar un valor desde un vocabulario controlado.
10 Identificador (dc:identifier)
Una referencia no ambigua dada al recurso dentro de un contexto dado. La práctica recomendada es identificar el recurso por medio de una cadena o número que sigue un sistema de identificación formal, por ejemplo: URI, URL, DOI, ISBN.
11 Fuente (dc:source)
Una referencia al recurso del cual el presente recurso está derivado. La derivación puede ser total o parcial. La práctica recomendada es identificar el recurso por medio de una cadena o número que sigue un sistema de identificación formal.
12 Idioma (dc:language)
Un lenguaje del actual contenido del recurso. La práctica recomendada es usar los códigos de dos letras tomas desde la RFC 1766, seguido opcionalmente por un código de dos letras del país tomado del ISO 3166.
13 Relación (dc:relation)
Una referencia a un recurso relacionado. La práctica recomendada es referenciar el recurso por medio de una cadena o número que sigue un sistema de identificación formal.
14 Cobertura (dc:coverage)
La extensión o alcance del contenido del recurso. Típicamente incluye una localidad espacial (un nombre de lugar o coordenadas geográficas), un período temporal (una etiqueta de período o un rango de fecha) o una jurisdicción (tal como una entidad administrativa). Se recomienda tomar un valor desde un vocabulario controlado.
15 Derechos (dc:Rights)
Información acerca de los derechos mantenidos en y sobre el recurso. Típicamente incluye instrucciones sobre el uso del recurso o referencias a un servicio que provee esa información.

¿Por qué son esenciales?
Estos metadatos son esenciales porque no importa si se trata de una biblioteca, un archivo, un museo, un laboratorio o cualquier otra entidad que procesa información. No importa si la perspectiva es, consecuentemente, la del bibliotecólogo, la del archivólogo, la del curador o la del usuario final, estos metadatos son normalmente los más esperados, los más genéricos, los más básicos.

miércoles, 6 de abril de 2011

Lo sencillo como virtud en Dublin Core

Edificio sede de la OCLC en Ohio, Estados Unidos
Foto tomada de flickr

En nuestro “post” anterior conversamos acerca de cómo la transición hacia una sociedad que produce ingentes cantidades de información a velocidades vertiginosas, con una creciente proliferación de formatos y de mezclas, con medios distintos de almacenamiento y presentación de la información, creó un problema que no existía en el mundo antes de la popularización de Internet. Se hizo necesario desarrollar un esquema de metadatos con una aproximación diferente, donde se desistió de la pretensión de la exhaustividad y se dirigió el esfuerzo hacia la resolución de los problemas ligados a la capacidad de respuesta y a la interoperabilidad de las soluciones. Eso nos llevó a esquemas de metadatos diferentes, menos basados en MARC, como Dublin Core y a otros, aún basados en MARC, como MODS. Dubin Core se ha convertido en un estándar ampliamente usado en múltiples contextos y por tanto es obligatorio, para todo profesional que gestiona información, conocer sus esencias y las claves de su éxito.

Nacimiento y evolución
Dublin core se origina a mediados del 95, en un taller de trabajo convocado por la OCLC (Online Computer Library Center) en la ciudad de Dublin (en Ohio, USA, no en la capital de la República de Irlanda). El nombre de “core” o núcleo tiene su origen en la pretensión de lograr sintetizar un grupo de metadatos básico, elemental, que respondiese a las preguntas esenciales que podríamos hacernos en términos genéricos sobre un objeto de información.

La sencillez como virtud
Dublin core se convirtió en poco tiempo en el conjunto de metadatos más comúnmente aceptado en el mundo por bibliotecólogos, archivólogos, curadores y computistas. En gran parte por ser muy lógico en su concepción y muy simple y flexible en su aplicación. También porque desde el principio se usó el consenso entre personas de disciplinas diferentes como mecanismo para la toma de decisiones. Sin duda, el énfasis en la sencillez tiene que ver con el éxito de Dublin Core.

Esto es interesante porque muchas veces pensamos que mientras más mejor, pero ocurre que muchos proyectos exitosos de la Internet lo son precisamente no porque aportaron más sino menos, no llegaron de primero sino mejor, no hicieron un trabajo más completo sino más simple, no agregaron más detalles sino que simplificaron lo que había. Cómo ejemplo, podemos mencionar que la propia Web está basada en el lenguaje HTML, cuya primera virtud fue que hizo fácil compartir, a diferencia de las propuestas anteriores a este lenguaje que hacían énfasis en las capacidades más que en la sencillez. El XML, como lo hablamos en días pasados, no es lo mejor o lo más eficiente como lenguaje para transportar metadatos, pero es simple para entenderlo y usarlo y por eso exitoso. Y así podríamos citar muchos otros ejemplos donde lo bueno es lo sencillo.

La misión simple de Dublin Core
Desde los primeros talleres de trabajo de la iniciativa Dublin Core se insistió en que debía existir y definirse un conjunto de metadatos de núcleo, que deberían considerarse esenciales, que deberían ser pocos pero suficientes para describir en forma genérica y simple cualquier recurso o objeto de información existente, almacenado o descargado desde la Internet. La misión de la iniciativa se enunció también en forma sencilla: proporcionar estándares simples que faciliten encontrar, compartir y gerenciar información.