1. INTRODUCCIÓN

Los objetos digitales compuestos son documentos formados por un conjunto de documentos que, juntos, forman una entidad lógica nueva con significado propio. Por ello, bajo la óptica de la Teoría General de Sistemas (Bertalanfy, 1976), una agregación web podría considerarse un sistema.

En los documentos impresos, las diferencias entre los elementos de una agregación son, salvo excepciones, meramente conceptuales, pero no físicas. Un artículo impreso, formado por imágenes, tablas, texto, etc., está formado en su origen por documentos distintos pero que, al ser impresos (o incrustados previamente en un procesador de textos tipo Word), pasan a conformar un único documento físico (o lógico).

En la Web, la situación es diferente. Los distintos elementos de una agregación pasan a tener una independencia lógica (se encuentran en ficheros diferentes) y, en algunos casos, incluso física (se encuentran en distintos servidores).

El futuro de la comunicación académica y científica depende en gran medida de la gestión de estas agregaciones, pues su uso trae consigo nuevas necesidades de citación así como la posibilidad de creación y descripción de colecciones de objetos sin importar su ubicación.

Este hecho pone en evidencia la necesidad de definir un estándar que permita identificar, describir e intercambiar agregaciones de recursos. Es decir, de acotar los límites del documento en la Web: su dominio.

La reciente especificación OAI-ORE, cuyos objetivos son la identificación y descripción de agregaciones de recursos web, constituye una novedosa aproximación a este problema.

2. OAI-ORE (Object Reuse and Exchange)

El proyecto OAI-ORE, financiado por la Andrew W. Mellon Foundation y, adicionalmente, por la National Science Foundation y Microsoft, inicia su andadura en octubre de 2006 bajo la tutela de la OAI, estando coordinado por Carl Lagoze, (Cornell University Information Science) y Herbert van De Sompel (Los Alamos Research Library).

Tras casi dos años de trabajo, el pasado 2 de junio de 2008 se puso a disposición, para revisión pública, la versión beta del proyecto (la versión 1 del está prevista para septiembre de 2008), a través de una serie de borradores.

2.1. Objetivos y fundamentos

La implementación de este estándar precisa de las siguientes consideraciones:

• Cómo puede un proveedor de servicios codificar y desglosar descripciones de agregaciones.
• Cómo puede un usuario/máquina descubrir e interpretar descripciones de agregaciones.

Para ello se deben establecer unos parámetros que posibiliten una interoperabilidad entre

• sistemas que gestionen contenido (como repositorios), para proporcionarlo a los proveedores de servicios
• y sistemas que aprovechen el contenido gestionado (como motores de búsqueda), para proporcionarlo al usuario,

de forma que se permita una interoperabilidad más allá de los límites de los fondos de los repositorios.

OAI-ORE representa el dominio de una agregación a través de un grafo. Éste queda formado por nodos (recursos o propiedades) y arcos (relaciones).

La idea radica en la existencia de un nodo (llamado “mapa de recurso”) que describe al nodo que representa a la agregación en sí misma. Este mapa de recurso queda identificado con una URI (URI-R), de forma que ésta de acceso, vía Http, a un fichero donde, en un determinado esquema de metadatos, se proporcione a la persona/máquina todos los recursos y relaciones existentes en el grafo. Es decir, donde se explicite el dominio de la agregación de forma estructurada.

Ejemplos de agregaciones pueden ser:

• Una lista no ordenada de recursos (lista de favoritos).
• Una documento Html multipágina.
• Información recopilada en algún servicio 2.0, como Flickr¹.
• Diversas versiones de un artículo, como las ofrece ArXiv².
• Una e-revista, formada por la agregación de artículos provenientes de distintos
  repositorios.

Finalmente, la idea de recursividad es fundamental. Cada recurso agregado puede ser asimismo una agregación. De esta forma, una agregación podría ser una revista, cuyos agregados podrían ser volúmenes, cuyos agregados serían números, quienes, a su vez, agregarían artículos y, finalmente, éstos agregarían partes componentes como tablas, gráficas o texto.

Cada agregación podría tener recursos asociados con otro tipo de relaciones, no sólo de “parte-todo”, como descripciones bibliográficas, recursos citados, versiones, notas, etc., lo que permitiría la inclusión y uso de datos brutos de investigación (raw data), tal como ya refleja la Declaración de Berlín (2003).

A pesar de que ya existen diversos métodos para enlazar conjuntos de datos científicos con sus publicaciones (basados en identificadores como DOI o en datos embebidos en las publicaciones mediante lenguaje de marcas), se precisa que los elementos del agregado sean entendibles tanto por el humano como por la máquina (Cheung [et. al.], 2007). Ahí es donde precisamente OAI-ORE aporta su verdadero valor.

Algunas de las ventajas de este sistema serían las siguientes:

• Los motores de búsqueda proporcionarían resultados en forma de conjuntos de recursos descritos.
• Los navegadores permitirían la navegación por agregados.
• Las descripciones de los agregados permitirían conocer las mejores estrategias de conservación para los recursos, al entender a cada de ellos como parte de un documento lógico superior.

2.2. Estructuración del mapa del recurso

Las especificaciones describen, de momento, tres formatos para serializar mapas de recursos: RDF/XML, RDFa y Atom.

Este último es una opción muy interesante, pese a que se pierda algo de expresividad. La filosofía de Atom, basada en la noción de feed al cual se le asocia un número de entradas, tiene una clara similitud con OAI-ORE. Así, un feed se puede hacer corresponder con una agregación y, cada una de las entradas del feed, con cada uno de los recursos agregados.

2.3. Localización de recursos

La localización de mapas de recursos, por personas o máquinas, es lo que da verdadero sentido a la especificación. El borrador OAI-ORE muestra varios métodos para llevar esto a cabo:

• Orientados a la localización de un mapa de recurso

  Se basan en proporcionar la URI-R embebida en el recurso agregado para que la persona/máquina acceda a su serialización. Se pueden diferenciar métodos opacos al usuario (mediante el elemento link de Html o el Http link header), o visibles (mediante links en el cuerpo del Html).

• Orientados a la localización de muchos mapas de recursos

  Se basan en la recuperación en masa de mapas. Los métodos establecidos en la especificación, de momento, son: OAI-PMH, Sitemaps y redifusión de feeds (RSS o Atom).

3. ASPECTOS INTERESANTES A DEBATIR

a) Aunque la iniciativa nace en un contexto científico, ¿podrá expandirse hacia otras formas de publicación, como la informativa, con agregados como la prensa digital?

b) Pese a que las especificaciones anuncian futuros desarrollos de nuevos formatos de estructuración de mapas de recursos, ¿en qué papel quedarán los esquemas de metadatos de objetos complejos ya existentes, como METS?

c) El desarrollo de vocabularios específicos queda en manos de los diferentes sectores. ¿Debería la comunidad bibliotecaria definir los tipos de relaciones entre recursos basándose en la taxonomía de Tillett (1987)?

d) El análisis automático de las descripciones de los mapas de recursos, ¿abrirá nuevos caminos en Cibermetría?

e) Como resulta más difícil movilizar personas que bytes, si costoso es que los autores ejerzan el autoarchivo, ¿qué ocurrirá cuando, además, deban aportar datos complementarios de sus trabajos?

f) Proyectos como Foresite³ o SCOPE, que ya experimentan con OAI-ORE, ¿pasarán infravalorados o desapercibidos para el 80% de la profesión, mientras el 20% restante se lamenta?

g) ¿Quién fijará las condiciones de reutilización de las agregaciones?

No obstante, el manejo de agregados en la Web (bajo estas especificaciones u otras que puedan surgir), son asuntos que deberán ser tratados en los futuros planes de estudio si deseamos que, en el día de mañana, los futuros documentalistas salgan preparados para enfrentarse a la realidad de su profesión, pues la documentación compleja en Web es la realidad del resto de profesiones.

Enrique Orduña-Malea

Miembro del Grupo ThinkEPI