Comentario sobre esquemas de metadatos

Todos estos esquemas de metadatos presentados en el capítulo anterior hacen especial énfasis en la cuestión que nos ocupa, la interoperabilidad. En todos los documentos que han emitido los organismos o colectivos que hay detrás de cada uno, se remarca de alguna forma u otra que tienen un especial interés en garantizar la interoperabilidad entre sistemas. O que su objetivo primordial es proporcionar esta interoperabilidad allá donde no la haya.

Pero esto tiene su sentido en un entorno homogéneo. Es decir, si todo el mundo usase Dublin Core para etiquetar todos sus recursos disponibles, entonces es lógico pensar que todo sería interoperable. O si todo fuese MPEG. O si todo estuviese referenciado con LOM. La realidad, no obstante, es muy distinta.

Los esquemas de metadatos que hemos presentado nacieron para entornos concretos. No nacieron con una visión global. Su posterior desarrollo los ha convertido en referentes en muchos ámbitos, pero lo cierto es que ninguno ha conseguido imponerse, al menos de momento, sobre los demás más allá de sus entornos naturales. Así, la mayor parte de repositorios de recursos educativos usan LOM, o Dublin Core en menor medida, mientras que las bibliotecas digitales están usando Dublin Core extensivamente, y los generadores, productores y distribuidores de material audiovisual usan o se plantean usar MPEG-7.

Mención aparte merece el caso de los perfiles de aplicación que se están definiendo en Dublin Core. Es una muestra clara del intento, legítimo por supuesto, de llegar a todas partes con Dublin Core. Pero esta generalización va a ir claramente en detrimento de la interoperabilidad. Porque en el fondo, un perfil de aplicación es una personalización, recogiendo elementos concretos de diversos esquemas para poder buscar los más adecuados. Y esto es el sentido contrario de lo que se podría interpretar como interoperabilidad.

El problema será el mismo entre perfiles de aplicación que entre DC y MPEG y LOM, tal como ya se ha comentado. Porque en algunos casos son esquemas bastante diferentes entre sí, aunque partan del mismo núcleo. El hecho de que estén definidos para un entorno concreto obviamente tiene que ir en detrimento de una visión global, y, por tanto, de la interoperabilidad.

Otro aspecto a destacar de los esquemas de metadatos descritos es su granularidad. Algunos, como Dublin Core, podríamos decir que son de grano grueso porque definen pocos atributos con un significado muy amplio mientras que otros especifican una cantidad bastante grande de atributos, normalmente organizados jerárquicamente, con un contenido semántico mucho más específico, los cuales e podrían llamar de grano fino. Los otros dos esquemas analizados, MPEG y IEEE LOM, son dos claros ejemplos de estos esquemas más completos. Esta diferencia en la granularidad va a condicionar los mapeos que se puedan hacer entre ellos .

En el capítulo anterior hemos expuesto también las tres propuestas de interoperabilidad más divulgadas. Z39.50 es claramente una propuesta en el plano sintáctico. Especifica perfectamente un mecanismo de intercambio de información y metainformación, en un modelo cliente/servidor. Cada entidad que quiera establecer un contacto con Z39.50 necesita implementar un módulo que adapte su funcionalidad interna a dicho protocolo, ya sea para enviar peticiones o para interpretar las respuestas recibidas. De esta manera, un cliente y un servidor de recursos que a priori no podrían comunicarse, sí podrían conseguirlo incorporando cada uno un módulo Z39.50. Pero en todo el estándar no hay ninguna referencia al contenido, al tipo de información que se puede intercambiar, a los esquemas de metadatos que se pueden usar. Es, como se ha dicho, interoperabilidad funcional, no de significados.

El proyecto Harmony nació como un intento de armonizar (de ahí su nombre) las semánticas asociadas a los diversos esquemas de metadatos, pero evolucionó hacía la creación de un modelo, el llamado modelo ABC, que pretende ser una especie de ontología de muy alto nivel. Intenta modelar todo lo que puede acontecer a un recurso, sea cual sea su naturaleza o el ámbito de aplicación. Se trata de un modelo que se ha alejado de los esquemas tradicionales hacia niveles de abstracción muy superiores. Puede ser útil como marco de desarrollo de aplicaciones, pero no para crear pasarelas entre esquemas más básicos.

Por otro lado, el entorno MPEG, después de emitir los estándares dedicados a la codificación de datos audiovisuales (1, 2, y 4) y el estándar dedicado a la descripción de los datos (7), está planteando el marco global donde se puedan crear, transmitir y consumir digital items. Está claro que cualquiera que quiera estar dentro del marco, tendrá que conocer muy bien MPEG-21.

A la vista de los análisis realizados, establecemos una distinción clara entre:

· sistemas o aplicaciones o entornos homogéneos, diseñados de forma global, y dónde todos sus actores hablan el mismo idioma, tanto en el sentido sintáctico (cómo se dicen las cosas) como en el sentido semántico (qué significado tienen las cosas que se dicen), y

· sistemas heterogéneos, como reunión de actores que ya han sido desarrollados y que pretenden cooperar para proporcionar o recibir servicios de forma global. Para los primeros, la interoperabilidad se consigue aplicando el mismo esquema de metadatos, con las mismas reglas de funcionamiento para todos los actores. Para ello, proyectos como Harmony, o una combinación de Z39.50 y Dublin Core, o un entorno MPEG son perfectamente válidos.

Para los segundos, necesitamos un modelo diferente, que mantenga la heterogeneidad no imponiendo ningún comportamiento ni significado.