3.3 Infraestructura
3.3.1 No necesitamos un estándar de metadatos «discográficos»: aspirar a una solución específica para determinado ámbito es una limitación poco práctica. Necesitamos una infraestructura de metadatos que disponga de un núcleo de componentes compartido con otros ámbitos, cada uno de los cuales pueda a su vez acoger variaciones locales (mediante extensiones de esquema, por ejemplo) aplicables a las tareas de cualquier archivo audiovisual en concreto. Algunas de las cualidades esenciales para definir los requisitos estructurales y funcionales de los metadatos son las siguientes:
3.3.1.1 Versatilidad. En relación a los metadatos, el sistema debe ser capaz de incorporar, fusionar, indexar, resaltar y presentar al usuario metadatos provenientes de una variedad de fuentes descriptoras de una variedad de objetos. Debe ser también capaz de definir estructuras físicas y lógicas, donde la estructura lógica representa entidades intelectuales —como colecciones u obras— y la estructura física representa los medios o soportes físicos que constituyen la fuente de los objetos digitalizados. El sistema no debe estar sometido a un único esquema de metadatos: deben poderse mezclar esquemas con perfiles de aplicación (ver 3.9.8) adecuados a las demandas de cada archivo en particular, sin comprometer por ello la interoperatividad. El reto está en construir un sistema que admita la mayor diversidad sin complicaciones innecesarias para el usuario de bajo perfil, a la vez que permita acciones complejas a aquellos usuarios que requieran un mayor campo de maniobra.
3.3.1.2 Extensibilidad. Habilidad para admitir un amplio abanico de materias, tipos de documento (como imágenes y archivos de texto) y entidades de negocio (identificación de usuarios, licencias de uso, políticas de adquisición, etc.). Deben poderse aplicar, desarrollar o ignorar extensiones de metadatos sin arruinar el conjunto del sistema. En otras palabras, dado que la implementación de metadatos continúa siendo una ciencia inmadura, la experimentación debe ser posible.
3.3.1.3 Sostenibilidad. Capacidad de migración, mantenimiento asequible, usabilidad, relevancia y disponibilidad en el tiempo.
3.3.1.4 Modularidad. Los sistemas usados para crear, incorporar, fusionar, indexar o exportar metadatos deben ser modulares a fin de facilitar el reemplazo de componentes que realizan funciones concretas por otros, sin arruinar por ello el conjunto del sistema.
3.3.1.5 Granularidad o nivel de detalle. Los metadatos deben presentar el suficiente detalle como para permitir cualquier uso previsto. Es habitual que los metadatos no alcancen el suficiente nivel de detalle, y por contra es raro que un excesivo nivel de detalle impida alcanzar un objetivo determinado.
3.3.1.6 Liquidez. Escritura única, pero uso múltiple.12 La liquidez permitirá a los objetos digitales y a sus representaciones auto-documentarse a través del tiempo, de forma que los metadatos rendirán más al archivo en numerosos entornos en red y proporcionarán considerables ingresos para compensar la inversión inicial en tiempo y dinero.
3.3.1.7 Apertura y transparencia. El sistema de metadatos debe admitir la interoperatividad con otros sistemas. Para facilitar la extensibilidad, los estándares, protocolos y software incorporados deberán ser tan abiertos y transparentes como sea posible.
3.3.1.8 Estructura relacional (jerarquía / secuencia / proveniencia). El sistema debe expresar las relaciones de dependencia jerárquica relevantes (por ejemplo, en las escenas de una representación teatral y otras derivadas). En el caso de objetos digitales, debe permitir instanciaciones13 y mapeos precisos de los soportes originales de datos y sus contenidos intelectuales en relación con los archivos digitales. Todo ello permite asegurar la autenticidad del objeto archivado (Tennant: 2004).
3.3.2 Esta receta basada en la diversidad es a su vezen sí misma una forma de apertura. Si se apuesta opta por un estándar abierto propuesto por el W3C (World Wide Web Consortium) como XML (eXtensible Markup Language), un lenguaje de marcas ampliamente adoptado, ello no debe ser óbice para implementaciones particulares que incluyan una mezcla de estándares de intercambio como MXF (Material eXchange Format) y AAF (Microsoft’s Advanced Authoring Format)
3.3.3 Aun siendo un estándar abierto, la inclusión práctica de metadatos en el formato MXF se realiza habitualmente de un modo propietario.14 MXF aporta ventajas para la industria de la radiodifusión audiovisual (broadcasting) porque puede usarse para la transmisión profesional de contenido a tiempo real (streaming), mientras que otros contenedores permiten únicamente la descarga completa del archivo. El uso de MXF como contenedor de datos y metadatos es aceptable como medio de almacenamiento solo tras la sustitución de aquellos metadatos descritos mediante formatos propietarios por otros descritos en estándares abiertos.
3.3.4 Se ha escrito tanto sobre el formato XML que podría resultar fácil considerarlo una panacea. XML no es una solución «per se» aunque sí un excelente método de aproximación a la organización y re-utilización de contenidos, dada su enorme capacidad junto con una inagotable lista de herramientas y tecnologías aportadas por terceros en beneficio del reciclaje y la reutilización de datos. Como tal, XML se ha convertido en el estándar de facto para la representación de metadatos asociados a recursos disponibles en internet. Una década de euforia alrededor de XML viene hoy en día acompañada por el continuo desarrollo de instrumentos abiertos y también comerciales de edición del contenido generado en XML (ver 3.6.2).
3.3.5 Aunque el presente capítulo incluya referencias a formatos específicos de metadatos de uso común o que prometen serlo en el futuro, no pretenden ser en ningún caso prescriptivas. La observancia de las cualidades clave enumeradas en la sección 3.3.1 y el mantenimiento de información explícita, comprehensiva y puntual de todos los detalles técnicos, creación de datos y política de cambios, incluyendo fechas y responsables asociados, deberá permitir futuras migraciones y traslaciones sin cambios substanciales en la infraestructura de base. Una infraestructura de metadatos robusta deberá ser capaz de admitir nuevos formatos de metadatos mediante la creación o aplicación de instrumentos específicos de dicho formato, tales como tablas de equivalencia o crosswalks,15 o bien algoritmos para la traducción de metadatos de un esquema de codificación a otro de manera efectiva y precisa. Existe un buen número de tablas de equivalencia entre formatos como MARC, MODS, MPEG-7 Path, SMPTE y Dublin Core. El uso de tablas de equivalencia va más allá de la traslación de metadatos de uno a otro formato. Pueden ser usadas también para fusionar dos o más formatos de metadatos en un tercero, o en un conjunto de índices de búsqueda. Con un formato contenedor o de transferencia apropiado, como es METS, puede acomodarse casi cualquier formato de metadatos como MARC-XML, Dublin Core, MODS, SMPTE, etc. Además, esta infraestructura abierta permitirá a los archivos absorber, total o parcialmente, fichas de sus catálogos procedentes de sistemas informáticos heredados (anticuados pero todavía en uso) a la vez que ofrecer nuevos servicios basados en estos, como por ejemplo la recopilación y explotación de metadatos heredados (ver OAI-PMH, Open Archives Initiative Protocol for Metadata Harvesting).
12 «Usos» o «lecturas», a partir del inglés WORM – Write Once, Read Many (n. de los t.).
13 Anglicismo del ámbito informático que refiere a la creación de un objeto, «caso» o «ejemplo» concreto derivado de una clase o mode¬lo general de datos (n. de los t.).
14 Expresión del ámbito informático que se refiere a soluciones no abiertas, esto es, soluciones desarrolladas por compañías privadas cuyo uso se rige bajo licencia y con cierto coste económico (n. de los t.).
15 Aplicado a metadatos, el concepto de schema crosswalk se refiere a una tabla de equivalencias entre elementos o campos propios de esquemas de bases de datos distintos (n. de los t.).
