3.9 Metadatos Descriptivos — Perfiles de Aplicación, Dublin Core (DC)

3.9.1. La mayor parte de los esfuerzos dedicados a los metadatos por parte del sector de la archivística se han concentrado en los metadatos descriptivos, como una rama natural de la catalogación tradicional. Sin embargo, parece claro que dedicar demasiada atención a esta área (desarrollando, por ejemplo, etiquetas descriptivas y vocabularios controlados hasta un nivel de refinamiento muy específico) a expensas de otras consideraciones ya descritas más arriba puede resultar en limitaciones o defectos del sistema en su conjunto. La figura 4 nos muestra las variadas interdependencias que deben establecerse, donde los metadatos descriptivos son solo una de las diversas subcategorías entre todos los elementos en juego.

Fig 4: Metadatos descriptivos simples (cortesía de Dempsey, libro elemental de CLIR/DLF, 2005)

3.9.2 La interoperatividad debe ser un componente clave en cualquier estrategia de metadatos: los sistemas complejos creados por cuenta propia por un equipo voluntarioso para un repositorio de archivo son la receta perfecta para una baja productividad, alto coste y mínimo impacto. El resultado será una industria artesanal de metadatos incapaz de crecer. El ámbito de los metadatos descriptivos es sin duda un ejemplo clásico de la máxima de Richard P. Gabriel «lo peor es mejor». Gabriel predijo correctamente que, de dos lenguajes de programación, uno elegante pero complejo y el otro torpe pero simple, el segundo se propagaría a mayor velocidad y en consecuencia, un mayor número de usuarios se interesaría en mejorar aspectos de este segundo lenguaje en detrimento del primero. Un ejemplo de ello lo constituye la rápida y exitosa adopción de Dublin Core (DC), inicialmente considerado una opción improbable por parte de los profesionales a causa de su palmaria simplicidad.

3.9.3 La misión de la DCMI (Dublin Core Metadata Initiative) ha sido facilitar el hallazgo de recursos a través de internet por medio del desarrollo de estándares de metadatos que permitan el descubrimiento entre diferentes dominios de conocimiento, definiendo marcos para la interoperatividad de conjuntos de metadatos y facilitando el desarrollo de metadatos específicos para una comunidad o disciplina concretas consistentes con esos propósitos. Se trata de un vocabulario de solamente quince elementos con los que describir recursos, y cubre con economía de medios las tres categorías de metadatos. Ninguno de estos elementos es obligatorio: todos ellos son repetibles, aunque quienes los implementen puedan aportar sus propias especificaciones en perfiles de aplicación (ver más adelante la sección 3.9.8). El nombre de «Dublin» se debe a su origen en el taller organizado en la ciudad de Dublin, Ohio (Estados Unidos) en 1995. El término «core», traducible como centro o núcleo, responde a que sus elementos son genéricos y de amplio alcance, utilizables para describir un gran abanico de recursos. El uso de Dublin Core ha gozado de un amplio respaldo durante más de una década y sus quince elementos descriptores han sido formalmente avalados en los siguientes estándares: ISO Standard 15836-2003 de febrero de 2003 [ISO15836 http://dublincore.org/documents/dces/#ISO15836] NISO Standard Z39.85-2007 de mayo de 2007 [NISO Z3985 http://dublincore.org/documents/dces/#NISO Z3985 ] e IETF RFC 5013 de agosto de 2007 [RFC 5013 http://dublincore.org/documents/dces/#RFC 5013].

A continuación, el cuadro 1 lista los quince elementos de DC con sus definiciones oficiales abreviadas y sus posibles interpretaciones en un contexto audiovisual.

Cuadro 1: Los 15 elementos DC

3.9.4     Los elementos de Dublin Core han sido expandidos para abarcar nuevas propiedades. Estas propiedades se conocen como términos DC. Un cierto número de estos elementos o «términos» adicionales resultan útiles para la descripción de medios basados en la reproducción temporal:

Cuadro 2: Términos DC (selección)

3.9.5     Los implementadores de DC pueden escoger entre los quince elementos en su versión original, dc:variant (como por ejemplo en http://purl.org/dc/elements/1.1/creator) o bien entre los términos de la variante extendida, dcterms:variant (por ejemplo en http://purl.org/dc/terms/creator) en función de los requisitos de cada aplicación. Con el tiempo se espera —y a ello anima DCM— un uso de los términos semánticamente más precisos dcterms:properties, más aún si el marco RDF es parte de la estrategia de metadatos, puesto que estos términos satisfacen mejor las recomendaciones profesionales para el procesado automatizado de metadatos.

3.9.6     Aun en su forma expandida, DC adolece del grado de detalle requerido en un archivo especializado en contenido audiovisual. El elemento Contribuyente, por ejemplo, deberá explicitar el papel desempeñado en el proceso concreto de grabación para evitar, por ejemplo, la habitual confusión entre intérpretes y compositores, o entre actores y dramaturgos.

<dcterms:contribuyente>
<marcrel:CMP>Beethoven, Ludwig van, 1770-1827</marcrel:CMP>
<marcrel:INT>Quatuor Pascal</marcrel:INT>
</dcterms:contribuyente>

<dcterms:contribuyente>
<marcrel:ORA>Greer, Germaine, 1939- (mujer)</marcrel:ORA>
<marcrel:ORA>McCulloch, Joseph, 1908-1990 (hombre)</marcrel:ORA>
</dcterms:contribuyente>

El primer ejemplo etiqueta «Beethoven» como compositor (CMP) y « Quatuor Pascal» como intérprete (INT). El segundo ejemplo etiqueta a ambos contribuyentes, Greer y McCulloch, como oradores o conferenciantes (ORA) aunque no aporta el detalle suficiente como para determinar quién es el entrevistador y quién el entrevistado. Esta información debería especificarse en algún otro campo de metadatos como la Descripción o el Título.

3.9.7     A este respecto podrían preferirse otros esquemas, o incluirlos como una extensión adicional de esquema (tal y como se vio en la figura 2). Por ejemplo MODS (Metadata Object Description Schema o esquema de descripción de objetos de metadatos, http://www.loc.gov/standards/mods) permite mayor detalle en los nombres y su vinculación con ficheros de autoridad, reflejo de su derivación del estándar MARC:

name
Subelements:
  namePart
    Attribute: type (date, family, given, termsOfAddress)
  displayForm
  affiliation
  role
    roleTerm
     Attributes: type (code, text); authority
     (see: www.loc.gov/marc/sourcecode/relator/relatorsource.html)
    description
  Attributes: ID; xlink; lang; xml:lang; script; transliteration
  type (enumerated: personal, corporate, conference)
authority (ver: www.loc.gov/marc/sourcecode/authorityfile/authorityfilesource.html)

3.9.8     En el marco de METS resulta admisible la inclusión de más de un conjunto de metadatos descriptivos en función del cumplimiento de diferentes propósitos. Tendríamos por ejemplo un conjunto que sigue DC (para el cumplimiento del protocolo OAI-MPH) además de un conjunto más sofisticado adscrito a MODS para el cumplimiento de otras iniciativas y en particular el intercambio de registros con sistemas codificados en MARC. La capacidad de incorporar diferentes estándares es una de las ventajas de METS.
    
3.9.9     DC sigue desarrollándose bajo el control del DCMI, Dublin Core Metadata Initiative. Por un lado, su capacidad para entrelazar recursos se ve reforzada mediante su interrelación más estrecha con herramientas semánticas en la red tales como RDF (ver Nilsson et al, DCMI 2008). Por otro lado, la asociación formal desde 2009 con RDA (Resource Description & Access http://www.collectionscanada.gc.ca/jsc/rda.html) incrementa su relevancia en el sector del patrimonio. Dado que RDA se considera el sucesor de las Anglo-American Cataloguing Rules, este particular desarrollo puede comportar sustanciales implicaciones estratégicas para los archivos audiovisuales que forman parte de bibliotecas nacionales y universitarias. Para los archivos de radiodifusión y televisión también son significativos otros desarrollos basados en DCMI. En el momento de la redacción de este documento, la EBU (Unión Europea de Radio y Televisión) completa el desarrollo de EBU CORE Metadata Set, basado en — y compatible con — Dublin Core.

3.9.10 Puede darse el caso de que el archivo desee modificar (expandir, adaptar) el conjunto nuclear de metadatos. Estos conjuntos modificados, basados en uno o más esquemas de elementos o identificadores (por ejemplo MODS y IEEE LOM así como también DC) se conocen como perfiles de aplicación. Todos los elementos en un perfil de aplicación se obtienen de recursos externos, de esquemas de elementos distintos. Si los implementadores desean crear «nuevos» elementos no categorizados en ningún otro esquema, como por ejemplo roles de contribuyente no disponibles en el grupo de relatores de MARC (agentes no humanos como por ejemplo especies, máquinas, entornos) deben entonces crear su propio esquema de elementos y asumir la responsabilidad de «declarar» y mantener dicho esquema.

3.9.11 Los perfiles de aplicación incluyen una lista de los identificadores directivos junto con sus localizadores uniformes (preferiblemente URLs permanentes, PURLs). Estos URLs se replican en cada instancia o entrada de metadatos. A estos URLs les siguen una lista de cada elemento de datos junto con sus valores admitidos y tipo de contenido. Esto puede referirse a reglas internas o adicionales y a vocabularios controlados, como tesauros o nombres y géneros de instrumentos, ficheros de autoridad de nombres de personas y materias. El perfil de aplicación deberá especificar también esquemas obligatorios para elementos específicos como fechas (año-mes-día) y coordenadas geográficas y estas representaciones estandarizadas de localización y tiempo serán capaces de mostrar mapas y líneas de tiempo como dispositivos de recuperación no textual.
 

Figura 5: Parte del perfil de aplicación de DC de la British Library para el sonido (BLAP-S)

Espacios de nombres usados en este perfil de aplicación:

Términos de metadatos
DCMI: http://dublincore.org/documents/dcmi-terms/
RDF (Resource Description Framework): http://www.w3.org/RDF/
Elementos MODS: http://www.loc.gov/mods
TérminosTEL: http://www.theeuropeanlibrary.org/metadatahandbook/telterms.html
Términos BL http://labs.bl.uk/metadata/blap/terms.html
MARCREL: http://www.loc.gov/loc.terms/relators/

3.9.12 El perfil de aplicación incorpora o toma por lo tanto elementos de un diccionario de datos (un fichero que define la organización básica de una base de datos hasta el nivel de campos individuales y tipos de campos) o hasta de diferentes diccionarios de datos que pueden ser mantenidos por un único archivo o compartidos por una comunidad de archivos. El diccionario de datos PREMIS (http://www.loc.gov/standards/premis/v2/premis-2-0.pdf, actualmente en su versión 2), referido exclusivamente a metadatos de preservación, es uno a los que más se acude. Sus numerosos elementos se conocen como «unidades semánticas». Los metadatos de preservación aportan explicaciones sobre la proveniencia, actividad de preservación y características técnicas de los datos, y ayuda en la verificación de la autenticidad de un objeto digital. El Grupo de Trabajo de PREMIS presentó su Diccionario de datos para metadatos de preservación en junio de 2005 y recomienda su uso en todos los repositorios de preservación sean cuales sean el tipo de material archivado y las estrategias de preservación desarrolladas.

3.9.13 Mediante la definición de perfiles de aplicación y, lo que es más importante, mediante su exposición pública, los implementadores pueden compartir información sobre sus esquemas con el fin de colaborar en tareas universales como la preservación a largo plazo.