Dspace Modulo 03 DublinCore

Capítulo 3: XML y la gestión de descripciones bibliográficas.
Dublin Core Ricardo Eito Brun
Lenguajes de marcas en bibliotecas y archivos: formatos

descriptivos y gestión de recursos digitales
Capítulo 3: XML y la gestión de descripciones

bibliográficas. Dublin Core
Ricardo Eíto Brun © 2017
Página 1 de 40
Capítulo 3: XML y la gestión de descripciones bibliográficas. Dublin Core Ricardo Eito Brun
Contenidos
1. Introducción ............................................................................................................................... 4
2. Metadatos y descripciones de recursos .................................................................................... 4
2.1. Estándares de estructura y de contenido ........................................................................... 5
2.2. Metadatos ........................................................................................................................... 5
2.3. Sistemas de metadatos....................................................................................................... 6
2.4. Metadatos y niveles de normalización ................................................................................ 8
2.4.1. Normalización terminológica y semántica .................................................................... 8
2.4.2. Normalización de las designaciones ............................................................................ 9
2.4.3. Normalización de pautas de contenido ...................................................................... 10
2.4.4. Normalización de los formatos de codificación y transferencia .................................. 10
2.4.5. Metadatos sobre las propias descripciones ............................................................... 11
2.5. Ventajas del uso de metadatos en la recuperación de información ................................. 11
2.6. Tipos de metadatos ........................................................................................................... 12
3. Dublin Core.............................................................................................................................. 12
3.1. La motivación de Dublin Core ........................................................................................... 13
3.2. Características de Dublin Core ......................................................................................... 14
3.2.1. Generalidad ................................................................................................................ 15
3.2.2. Independencia de sistemas de codificación ............................................................... 15
3.2.3. Extensibilidad .............................................................................................................. 15
3.2.4. Economía .................................................................................................................... 16
3.3. Los elementos Dublin Core – DCMES 1.1........................................................................ 16
3.3.1. Elemento title ......................................................................................................... 17
3.3.2. Elemento creator..................................................................................................... 17
3.3.3. Elemento subject..................................................................................................... 17
3.3.4. Elemento description ............................................................................................ 17
3.3.5. Elemento publisher ................................................................................................ 17
3.3.6. Elemento contributor ............................................................................................ 17
Página 2 de 40
3.3.7. Elemento date ........................................................................................................... 17
3.3.8. Elemento type ........................................................................................................... 18
3.3.9. Elemento format ....................................................................................................... 19
3.3.10. Elemento identifier ............................................................................................ 19
3.3.11. Elemento source ..................................................................................................... 19
3.3.12. Elemento language ................................................................................................ 19
3.3.13. Elemento relation ................................................................................................ 19
3.3.14. Elemento coverage ................................................................................................ 19
3.3.15. Elemento rights ..................................................................................................... 20
3.4. Dublin Core “simple” y “calificado” .................................................................................... 20
3.4.1. Calificadores Dublin Core ........................................................................................... 21
3.4.2. Esquemas de codificación en Dublin Core ................................................................. 24
3.4.3. Elementos adicionales ................................................................................................ 26
3.4.4. Términos y espacios de nombres ............................................................................... 26
3.5. Dublin Core para bibliotecas: el perfil DC-Lib ................................................................... 27
4. Dublin Core y XML .................................................................................................................. 29
4.1. Codificar metadatos Dublin Core en XHTML .................................................................... 30
4.1.1. Incluir metadatos Dublin Core en el documento XHTML ........................................... 30
4.1.2. Vincular metadatos Dublin Core a documentos XHTML ............................................ 32
4.2. Codificar metadatos Dublin Core Simple en XML ............................................................ 33
4.3. Codificar metadatos Dublin Core Calificado en XML ........................................................ 35
4.4. Codificar metadatos Dublin Core simple en RDF/XML ..................................................... 37
5. Conclusiones ........................................................................................................................... 39
Página 3 de 40
1. Introducción
Entre las aplicaciones del lenguaje XML en el ámbito de las bibliotecas, archivos y centros de
documentación, cobra especial importancia su utilización como formato para la gestión de
descripciones de recursos. En este sentido podemos identificar dos líneas de trabajo: a) la
utilización de XML como formato de intercambio de descripciones basadas en MARC (Machine
Readable Cataloging) y b) la utilización de XML como formato para codificar, almacenar y
difundir descripciones de recursos creadas con otros sistemas de metadatos, entre los que
cobra especial relevancia Dublín Core.
Este capítulo se centra en el uso de XML para la codificación e intercambio de metadatos y

descripciones de recursos. Se divide en los siguientes apartados:
a) Metadatos y descripciones de recursos: describe la función de los metadatos en el

marco de Internet y la World Wide Web, tipos y uso propuesto.
b) El sistema de metadatos Dublin Core: describe las características de este sistema de

metadatos, su origen y finalidad.
c) Dublín Core y XML: explica la forma de crear descripciones XML basadas en

metadatos Dublín Core.
d) Conclusiones: donde se resumen los principales puntos tratados en el capítulo.
2. Metadatos y descripciones de recursos

La descripción de recursos de información es una de las principales actividades desempeñadas
por los profesionales de la documentación. El control bibliográfico de la producción escrita
constituye la principal actividad en bibliotecas y centros de documentación, al hacer posible la
posterior difusión y acceso a los recursos de información.
La descripción de recursos consiste en la redacción de un asiento o registro en el que se

capturan las características de un recurso. En este registro se consignarán datos relevantes
para su identificación y localización, junto con otros que permitan al usuario evaluar la
relevancia del recurso.
Existen diferencias en el contenido de las descripciones dependiendo del tipo de recurso que
se describa. Por ejemplo, en la descripción de artículos académicos, noticias de prensa, etc.,
las descripciones suelen incorporar un resumen del que carecen las descripciones de
monografías o publicaciones seriadas; en el ámbito de los archivos se da una gran importancia
al contexto y los datos históricos y biográficos de la entidad, familia o persona que generó la
documentación que se describe, etc.
Página 4 de 40
Estas diferencias se plasman en la existencia de distintos sistemas para la descripción de

recursos. Así, en el ámbito de las bibliotecas contamos con normas como ISBD (Internacional
Standard Bibliographical Description), las Reglas de Catalogación españolas, etc., y con
formatos para el intercambio normalizado de descripciones como el formato MARC; en el
ámbito de los archivos la normalización internacional ha tardado más tiempo en alcanzarse con
la publicación de las normas ISAD(G) (Internacional Standard Archival Description – General) y
del lenguaje de marcas EAD (Encoded Archival Description). A estos sistemas debemos añadir
las alternativas diseñadas en respuesta a las nuevas necesidades planteadas por la red
Internet.
2.1. Estándares de estructura y de contenido

Suelen diferenciarse dos tipos de estándares: estándares de estructura y estándares de
contenido. Los estándares de estructura establecen los datos que deben consignarse en la
descripción. Por ejemplo, un estándar de estructura nos indicaría que un registro debe incluir
un encabezamiento principal, recoger el título del recurso, su fecha de publicación, editor, etc.
Por otra parte, los estándares de contenido pretenden fijar la forma en la que debe redactarse
el contenido de cada uno de esos datos para que se haga de forma coherente en distintas
descripciones.
No siempre es evidente la diferencia entre estándares de contenido y estructura, ya que en

muchos casos los estándares suelen tratar las dos partes. Por ejemplo, las Reglas de
catalogación españolas especifican aspectos relativos a la estructura de las descripciones (con
la división del asiento en áreas), y la forma de redactar su contenido. En otros casos sí
encontramos estándares y normas con características que nos permiten situarlos en uno u otro
grupo.
2.2. Metadatos
El término metadatos suele definirse como datos acerca de los datos. Metadatos sería
cualquier información que podemos dar sobre un recurso de información para facilitar su
posterior localización y gestión. Al redactar descripciones de recursos estamos consignando
metadatos sobre los mismos. Podemos hablar de metadatos con independencia del tipo de
recurso que se describa (monografías, artículos científicos, tesis, piezas de un museo, una
colección de manuscritos, etc.) y de su disponibilidad en formato electrónico 1.
1 . En la práctica, siempre que contemos con una descripción que facilite la identificación,
localización y acceso del recurso, podremos afirmar que estamos trabajando con metadatos.
Página 5 de 40
El hablar de metadatos se generalizó a raíz de la expansión de la World Wide Web, momento

desde el cual esta idea atrajo una gran atención por parte de la comunidad de profesionales de
la documentación. Gran parte de esta popularidad se debe al desarrollo de la iniciativa Dublín
Core. Sin embargo, la práctica de usar metadatos es intrínseca a las tareas propias de las
bibliotecas, centros de documentación y archivos, y difícilmente podríamos decir que este
concepto sea algo realmente nuevo. Fue la explosión informativa originada por el uso de
Internet la que llevó a un primer plano la necesidad de revisar estas prácticas y plantearse si
los sistemas utilizados hasta entonces para describir recursos eran adecuados en la nueva
situación.
2.3. Sistemas de metadatos

Los metadatos se caracterizan por tener un propósito y una estructura. Se han propuesto
distintos modelos o sistemas para organizar metadatos y estructurar las descripciones.
Constituyen distintos sistemas de metadatos. Normalmente, un sistema de metadatos
especificará:
 La finalidad que persigue con él, los recursos y contexto en los que son aplicables.
 Los datos o propiedades que constituirán la descripción.
 El tipo de información que pueden tomar como valor los datos anteriores, y si estos
valores se deben tomar de listas pre-establecidas.
 Mecanismos para establecer relaciones entre los recursos que se describen 2.
 La sintaxis o formato en el que deben codificarse las descripciones: XML, registros

basados en la norma ISO 2709, etc.
 Las políticas y prácticas que se seguirán para el mantenimiento y evolución del

sistema.
Sin embargo, una definición formal del término no aceptaría esta acepción, ya que el término
metadatos se refiere formalmente, a la información que se mantiene sobre los propios datos
descriptivos de algo. Así, sería correcto hablar de metadatos para referirnos a una descripción
detallada del contenido, tipo, restricciones aplicables, etc., de las propiedades que conforman
una descripción. En este caso sí estaríamos hablando realmente de “datos sobre los datos”.
2 Por ejemplo, para relacionar descripciones de recursos bibliográficos que se citan entre sí,
otros tipos de relaciones como versiones anteriores, previas, revisadas o no revisadas, etc., y
las relaciones entre descripciones de recursos bibliográficos y registros de autoridad.
Página 6 de 40
De esta forma, un sistema de metadatos abarcará distintos aspectos relacionados con la forma
de redactar, almacenar y difundir las descripciones, y cómo está previsto asegurar la evolución
del sistema en el futuro.
La aproximación más común a los metadatos consiste en entenderlos como una serie de
propiedades que caracterizan a los recursos de información. Estas propiedades se obtendrían
a partir de una abstracción de los recursos de información de un mismo tipo, de forma que
todas ellas serán aplicables a la mayoría de los recursos que se pretende describir.
Por ejemplo, en el caso de las tesis doctorales, podríamos afirmar que cualquier tesis puede
describirse mediante una serie de propiedades aplicables a la mayoría de ellas, y que son
datos que las caracterizan. Así, las tesis tendrán un título, una fecha de lectura, un doctorando,
un tribunal compuesto por una serie de miembros, un director, y estará vinculada a una
universidad, departamento y programa de doctorado. Las distintas propiedades sobre las que
podemos hacer una afirmación constituirán los metadatos aplicables a ese tipo de recurso.
Al redactar la descripción de una tesis en particular, asignaremos un valor a cada una de esas
propiedades; los valores corresponderán a la instancia en cuestión que estamos describiendo.
Por ejemplo, la descripción de una tesis disponible en formato electrónico podría incluir los
siguientes metadatos o propiedades: título, doctorando, director, fecha lectura, área de
conocimiento, universidad, departamento, programa, tribunal, palabras clave, resumen, etc.
La definición de metadatos como un conjunto de propiedades que permiten identificar y

describir los recursos resulta sumamente intuitiva. Pero además de establecer una serie de
propiedades e indicar qué tipo de restricciones deben cumplir sus valores (por ejemplo, su
carácter opcional u obligatorio, posibilidad de admitir valores repetibles, etc.) un sistema de
metadatos debe dar cabida a otras características que aseguren la coherencia en la creación
de descripciones y que potencien las opciones disponibles para el usuario en el momento de la
recuperación. Entre ellas se encontraría:
a) La posibilidad de establecer relaciones cruzadas entre recursos.
b) El control de autoridades, materias o vocabulario, de forma que algunas propiedades

tomen su valor de listas pre-definidas, con lo que se garantiza la consistencia en la
indización y se facilita la recuperación de información.
Continuando con nuestro ejemplo anterior, en las descripciones que hacemos de las tesis
podríamos incorporar elementos adicionales, como un listado predefinido de áreas de
conocimiento (con lo que aseguraremos que todas las personas que describen recursos utilizan
los mismos términos en la codificación de los temas), o referencias cruzadas a registros que
describen con mayor detalle las características de los departamentos, directores, etc. De esta
forma, nuestro sistema incorporaría descripciones de otros recursos que podríamos enlazar
Página 7 de 40
entre sí para constituir un sistema de información más sofisticado y con mayores opciones de
explotación3.
2.4. Metadatos y niveles de normalización

Uno de los problemas en el diseño de sistemas de metadatos es la normalización. La
necesidad de normalizar se hace más evidente cuando pensamos en sistemas de información
conectados, capaces de intercambiar información de forma económica y fácil. La normalización
hace posible que un usuario interactúe con distintos sistemas de recuperación de forma
homogénea, sin necesidad de aprender nuevos lenguajes de consulta o interfaces de usuario;
de forma similar, una persona encargada de crear y mantener descripciones de recursos será
más productiva si trabaja con esquemas normalizados; la existencia de normas también
permite racionalizar los planes docentes y formativos.
En la definición de un sistema de metadatos encontramos distintos niveles donde se debe

realizar un esfuerzo de normalización.
2.4.1. Normalización terminológica y semántica

En primer lugar se debe alcanzar un acuerdo sobre la terminología y los conceptos en los que
se fundamentará el sistema de metadatos, establecer con claridad a qué se hace referencia al
hablar de recurso, propiedad, registro, etc., y la finalidad del sistema. Por ejemplo, algunos
sistemas de metadatos estarán ideados para facilitar la recuperación por parte de usuarios
finales; otros estarán orientados a la preservación de recursos o a hacer posible el intercambio
de datos entre agentes y aplicaciones informáticas.
La normalización afecta al contenido de las descripciones, es decir, al conjunto de propiedades

que constituirán la descripción de los recursos y los datos que debemos recopilar como parte
de la catalogación. Se debe fijar el significado de cada una de estas propiedades y elegir una
designación para ellas. La definición detallada del significado de cada una de estas
propiedades, evitando cualquier ambigüedad, es un requisito indispensable para asegurar la
creación de descripciones coherentes.
3 Como conclusión, diremos que las características de un sistema de metadatos, junto a la

estructura de las descripciones con su listado de propiedades, deben incluir – como requisitos
deseables – el incorporar mecanismos de control (autoridades, materias o de descriptores), y
permitir codificar como parte del registro las relaciones que existen entre el recurso que se
describe y otros recursos descritos en el sistema de información, del mismo o de diferente tipo.
Página 8 de 40
Dentro de este apartado debemos mencionar las opciones orientadas a la identificación de los
recursos. Esta información formará parte habitualmente de la descripción. En el caso de
recursos electrónicos, contamos con distintos sistemas de identificación: URL (Uniform
Resource Locator), DOI (Digital Object Identifiers), etc. Es aconsejable que el sistema de
metadatos especifique qué mecanismos de identificación se aplicarán y cómo diferenciar el uso
de unos u otros.
2.4.2. Normalización de las designaciones

En relación a las designaciones de cada propiedad, es importante no sólo fijar la forma en la
que vamos a hacer referencia a dicha propiedad – su nombre – sino también especificar la
posibilidad de usar designaciones alternativas (por ejemplo, formas de referirse a esa misma
propiedad usando distintos idiomas). También es necesario distinguir esa propiedad de otras
propiedades homónimas usadas en otros sistemas de metadatos.
Por ejemplo, la propiedad título puede usarse en un sistema para recoger el título asignado a
un recurso por su autor, y en otro sistema podría recoger el tratamiento que se asigna a una
persona, o el título que asigna el centro catalogador en un segundo idioma.
Si pensamos en el intercambio de datos entre sistemas, debemos contar con algún mecanismo
que nos permita diferenciar de forma inequívoca los metadatos de distintos sistemas de
descripción que tengan una designación común.
En el ámbito de Internet y la World Wide Web, esta problemática se resuelve mediante los
llamados espacios de nombres XML. Cada espacio de nombres estará identificado de forma
única mediante un URI (Uniform Resource Identifier) y agrupará un conjunto de designaciones
o nombres de elementos y atributos4.
4 El concepto de URI es similar al de URL (Uniform Resource Locutor). De hecho las URL son
un caso particular de URI. Podríamos definirlo como un nombre único en la web. Por ejemplo,
en un sistema ficticio de metadatos para la descripción de tesis, podríamos establecer un
espacio de nombres asociado al URI http://www.tesisMetadatos.com/tesis. Otro sistema de
metadatos podría así utilizar propiedades homónimas; éstas estarán vinculadas a otro espacio
de nombres, por ejemplo http://www.catalog.es/informes.academicos/, por lo que no habría
posibilidad de malentendidos o conflictos, y sería posible diferenciar de qué sistema proceden
las propiedades que se usen en las descripciones. El nombre completo de cada propiedad
sería diferente. El título para las tesis del primer espacio de nombres quedaría identificado por
el nombre:
http://www.tesisMetadatos.com/tesis#titulo
Página 9 de 40
2.4.3. Normalización de pautas de contenido

Además de establecer el significado y la designación de las distintas propiedades que
conformarán la descripción de un recurso, la normalización también afecta a las pautas que
deben seguirse para escribir su valor. A modo de ejemplo, es importante establecer la forma en
la que deben redactarse nombres de persona: ¿por qué parte del nombre comenzamos
dependiendo de la nacionalidad de la persona? ¿debemos incluir u omitir títulos y términos que
indiquen tratamiento? ¿debemos incluir a continuación del nombre las fechas de nacimiento y
defunción? En el caso de las fechas, ¿en qué formato debemos indicarlas? ¿día-mes-año?
¿año-mes-día?
Distintos sistemas de metadatos pueden optar por aplicar pautas diferentes para completar los
valores de cada propiedad, por lo que establecer unos criterios comunes u optar formalmente
por una u otra forma sería otra de las áreas donde se hace necesaria la normalización.
Si recordamos la definición dada anteriormente sobre estándares de estructura y de contenido,

estas pautas corresponderían a los estándares de contenido. El trabajo realizado en la
elaboración de pautas para la catalogación son un excelente ejemplo de este nivel de
normalización.
2.4.4. Normalización de los formatos de codificación y transferencia

La necesidad de normalizar también se hace manifiesta en los formatos físicos para codificar,
almacenar y transferir las descripciones de recursos. No basta únicamente con establecer las
propiedades, fijar su designación, significado, y la forma en la que debe redactarse su
contenido; también es preciso fijar como se deben codificar y almacenar las descripciones
físicamente. Caben aquí múltiples opciones: bases de datos relacionales, datos XML, etc. La
posibilidad de que distintos sistemas de metadatos utilicen mecanismos de codificación
diferentes supone un reto adicional para los esfuerzos dirigidos a la normalización.
A priori la normalización de los formatos de codificación y transferencia es independiente de la

semántica del sistema de metadatos. Pero un sistema completo debería incluir – como parte de
mientras que el título para los informes de investigación utilizado en el segundo sistema de
metadatos tendría como nombre:
http://www.catalog.es/informes.academicos#titulo
El uso de espacios de nombres garantiza, de hecho, que no haya designaciones homónimas

para propiedades de distintos sistemas, con independencia de que su semántica sea
equivalente o no.
Página 10 de 40
sus especificaciones –información sobre cómo se deben editar, almacenar e intercambiar las
descripciones de los recursos. Por ejemplo, el sistema Dublin Core, por ejemplo, no propone un
único sistema de codificación de las descripciones, sino que permite distintas alternativas y nos
da recomendaciones para el uso de distintos formatos: HTML, XML, RDF, etc.
2.4.5. Metadatos sobre las propias descripciones

Algunos sistemas de metadatos también reservan propiedades para recoger información sobre
las propias descripciones: fecha en la que se creó, quién la hizo, cuando fue modificada y por
quién, el idioma en el que está escrita, etc.
Podríamos hablar así de metadatos sobre los propios metadatos. Este punto constituye otro de
los apartados que debe tratarse y para facilitar el intercambio de metadatos de forma
consistente.
2.5. Ventajas del uso de metadatos en la recuperación de

información
La aplicación de los metadatos tiene distintas aplicaciones. La más importante es la
recuperación de información. La utilización de metadatos – combinados con lenguajes
controlados – en las descripciones de recursos permite suplir las deficiencias de la
recuperación basada en el texto completo.
En los sistemas basados en texto completo, las aplicaciones informáticas generan índices con
todos los términos que aparecen en los documentos. El usuario busca los documentos que
contienen una combinación de términos determinada. Este modelo dista de ser óptimo. Los
problemas se deben a la falta de estructura del texto completo y a la dificultad de que coincidan
los términos usados en la redacción de los documentos con los usados por el usuario al
formular su búsquedas. Si no existe dicha correspondencia, el sistema no podrá identificar
documentos relevantes.
Por otra parte, la búsqueda texto completo está restringida a recursos disponibles en formato
electrónico, con contenido textual, y no permite acotar el contexto en el que debe aparecer un
término. A modo de ejemplo, en un sistema texto completo ¿podríamos diferenciar los
documentos que tratan sobre la Universidad de Santiago de los que están publicados por esta
institución?
Disponer de descripciones basados en metadatos permite acotar con precisión las búsquedas
y restringirlas a propiedades específicas, con lo que se obtiene más precisión y menos ruido.
Otra ventaja del uso de metadatos es que el sistema podrá mostrar al usuario un perfil de los
documentos recuperados como un paso previo a la visualización de su texto completo o a la
Página 11 de 40
solicitud del recurso. Este perfil estará formado por los metadatos que se hayan asignado al
recurso durante su descripción. Con él, el usuario podrá juzgar la utilidad potencial del recurso
sin tener que acceder al mismo.
2.6. Tipos de metadatos

Los metadatos no tienen como única finalidad la descripción y recuperación de recursos de
información. Así, suele establecerse una distinción entre distintos tipos de metadatos
dependiendo de su función. Se distingue entre:
 Metadatos descriptivos, para la recuperación: describen las características del

recurso, orientadas a su recuperación. Por ejemplo, los datos relativos a cuando y por
quién fue publicado, sus características físicas, el formato en el que se encuentra
(PDF, HTML, XML, etc.), el título que aparece en su portada, etc. Suelen incluirse en
este grupo las propiedades que permiten identificarlo, como la URL, DOI, ISBN, etc.
 Metadatos administrativos, para la gestión: facilitan el tratamiento y el

procesamiento del recurso. Por ejemplo, información sobre su fecha de creación,
restricciones en el acceso, derechos sobre el mismo, fecha de modificación y motivo de
los cambios, datos para la localización del recurso en un depósito, etc.
 Metadatos para la preservación: tienen como finalidad facilitar el uso del recurso en
el futuro, especificando los requisitos técnicos para su acceso y lectura, las
operaciones realizadas para asegurar su conservación, etc.
 Metadatos estructurales: permiten identificar las distintas partes o componentes que

configuran un recurso de información, la estructura lógica de la información y los
distintos archivos que conforman la publicación.
No siempre es posible clasificar un sistema de metadatos en uno de estos tipos de forma

tajante. De hecho, un sistema de metadatos contendrá normalmente propiedades que podrían
adscribirse a estos tipos. En los siguientes apartados incluimos la descripción de un sistema de
metadatos para la recuperación de información, el popular Dublin Core. Consideramos que es
necesario incluir una información de referencia previa sobre este sistema, antes de describir las
características de su codificación en XML.
3. El sistema de metadatos Dublin Core

Este sistema de metadatos se ha convertido en la propuesta más popular, y es el que más
atención ha recibido por parte de la comunidad de usuarios. Dublin Core establece un conjunto
de propiedades para la descripción de recursos de información. Se trata de un sistema de
Página 12 de 40
propósito general, para describir cualquier tipo de recurso, si bien su objetivo inicial se centró
en la catalogación de páginas web.
El nombre correcto para hacer referencia a este conjunto de metadatos es Dublin Core
Metadata Element Set o DCMES. La primera versión – con el nombre de DC1 – se publicó en
en 1998 en el documento IETF (Internet Engineering Task Force) RFC 24135.
La versión actual del DCMES es la 1.1, y se convirtió en norma internacional, ISO 15836:2003
“Information and documentation—The Dublin Core metadata element set, en febrero del 2003.
También es norma norteamericana ANSI Z39.85 desde septiembre del 2001.
Del mantenimiento de este sistema se encarga la Dublin Core Metadata Initiative – en adelante
DCMI –, que se auto-describe como una organización independiente e internacional dedicada a
la promoción y desarrollo de estándares sobre metadatos, y que estuvo vinculada inicialmente
a la OCLC (Online Computer Library Center) norteamericana. Algunos autores han señalado un
interés comercial por parte de la OCLC en el diseño de Dublin Core, para establecer una nueva
línea de negocio dedicada a la venta de registros catalográficos de recursos web [CITA].
3.1. La motivación de Dublin Core

Dublin Core se planteó como una posible solución al incremento exponencial de recursos de
información disponibles en la Web. En 1995, la web se encontraba en plena expansión, y
comenzaba a instituirse como un sistema idóneo para publicar con costes mínimos, y una
biblioteca virtual donde podían proliferar con facilidad recursos de información de todo tipo.
Ante este incremento en el número de materiales publicados, y ante la imposibilidad de que las
bibliotecas y los centros de documentación tradicionales afrontasen el reto de catalogar lo que
se publica en la web, se planteó la necesidad de contar con un sistema de descripción de
recursos fácil de usar, que no exigiese complejos conocimientos previos. El nuevo sistema para
la descripción de recursos debería permitir crear registros con facilitad, de forma intuitiva, para
que fuesen los mismos creadores de la documentación los que pudiesen catalogarla.
Dublin Core también se planteó como una respuesta ante la ineficacia de los sistemas de
indexación y recuperación en texto completo característicos de los motores de búsqueda en
Internet. Estos sistemas – basados normalmente en la ponderación de los términos a partir de
la frecuencia con la que aparecen en los documentos – no ofrecen una precisión similar al que
puede obtenerse en los sistemas de recuperación bibliográficos basados en registros
estructurados y lenguajes controlados. Así, podemos decir que Dublin Core pretendía ofrecer
5 http://www.ietf.org/rfc/rfc2413.txt
Página 13 de 40
un sistema para la descripción de recursos de información en la Web similar al utilizado en los

catálogos de bibliotecas, basado en la catalogación previa de los recursos de información 6.
3.2. Características de Dublin Core

Dublin Core se caracteriza por un modelo simple, donde un recurso se define como “algo que
tiene una identidad, por ejemplo documentos electrónicos, imágenes, servicios (por ejemplo un
informe sobre el clima en una ciudad) y una colección formada por otros recursos [...] No todos
los recursos son accesibles a través de una red: por ejemplo, las organizaciones, personas o
los libros impresos de una biblioteca también pueden considerarse recursos”7.
Uno de los principios de Dublin Core es el principio 1-1 o one-to-one en inglés. Según este
principio, las distintas representaciones de un mismo objeto constituyen recursos
independientes, que contarán con descripciones separadas.
Los recursos contarán con unas propiedades, que se definen formalmente como “aspectos,
características, atributos o relaciones que se usan para describir un recurso”. Vemos que el
sistema otorga importancia a las relaciones entre el recurso que se describe y otros, como
medio para facilitar su recuperación.
La asignación de valores a las distintas propiedades dará lugar a un registro: “conjunto de

metadatos estructurados relativos a un recurso, que comprende una o más propiedades y su
valor asociado”.
6 El origen de Dublin Core ha sido documentado en numerosas contribuciones [Ortiz-Repiso

Jiménez, 1999; Senso, 2002]. A modo de resumen, señalaremos que en la segunda
Conferencia Internacional del World Wide Web de 1994, celebrada en Chicago, Stuart Weibel
de OCLC (Online Computer Library Center), Yuri Rubinski de Softquad y Joseph Hardin del
NCSA (National Cener for Supercomputing Application), decidieron que era necesario abrir una
línea de trabajo para ver mecanismos que facilitasen la identificación de recursos de
información en la Web. El encuentro para discutir las distintas opciones se celebró un año más
tarde – en marzo de 1995 en la sede de la OCLC en Dublin, Ohio, de allí el nombre dado a esta
iniciativa. A partir de esa reunión inicial, la DCMI mantiene reuniones anuales.
Un resumen de las principales conclusiones y de las decisiones adoptadas desde la primera

reunión de 1995 hasta el 8th International Dublin Core Metadata Workshop celebrado en
Ottawa el año 2000 lo podemos encontrar en [Senso, 2002].
7 DCMI Glossary. Otras definiciones que se dan en este apartado se han tomado de este
documento disponible en:
http://dublincore.org/documents/2001/04/12/usageguide/glossary.shtml
Página 14 de 40
Las principales características de Dublin Core son: a) generalidad, b) independencia, c)

extensibilidad y d) economía.
3.2.1. Generalidad
Dublin Core establece un conjunto de propiedades o metadatos aplicables a cualquier tipo de
recurso, con independencia de su tipo o formato. Los metadatos Dublin Core podrían utilizarse
para describir cualquier material: páginas web, artículos o contribuciones a un congreso,
monografías, piezas de un museo, grabaciones, etc. Como consecuencia de esta
aproximación se identificaron quince elementos que constituyen el llamado núcleo del DCMES.
Son elementos genéricos que pueden usarse en la descripción de cualquier recurso.
3.2.2. Independencia de sistemas de codificación

Los registros Dublin Core pueden crearse en distintos formatos: HTML, XML, etc. Se dan
recomendaciones sobre cómo codificar descripciones Dublin Core en HTML, XML, RDF, etc.
Esta independencia permite optar por codificar los metadatos como parte integrante del recurso
de información o fuera de él. Por ejemplo, en una página HTML podríamos codificar metadatos
Dublin Core como parte de la propia página, aunque también podríamos incluir un enlace en la
página HTML que nos llevase a un documento con sus metadatos.
3.2.3. Extensibilidad
Se refiere a la capacidad de ampliar los metadatos iniciales para dar cabida a nuevas
aplicaciones. La extensibilidad también permite combinar metadatos Dublin Core con otros
procedentes de otros sistemas8. Se obliga a mantener la singularidad de los quince elementos
que conforman el núcleo para así garantizar un nivel de compatibilidad mínimo entre las
distintas implementaciones y usos que se haga de Dublin Core.
8 Este principio está relacionado con las conclusiones del segundo encuentro celebrado por la
OCLC y UKOLN (UK Office for Library & Information Networking) en Warwick (Reino Unido) en
abril de 1996. Entre las conclusiones de este encuentro se encontraba que Dublin Core fuese
compatible con otros sistemas de metadatos. Este planteamiento se plasmó en el llamado
Warwick Framework, que planteaba un modelo en el que un contenedor pudiese agrupar
distintos conjuntos de metadatos. El planteamiento surge ante la necesidad de dar cabida a
distintos sistemas de metadatos que describan un mismo recurso pero con propósito diferente.
Véase [DEMPSEY, 1996]: http://www.dlib.org/dlib/july96/07weibel.html.
Página 15 de 40
3.2.4. Economía
Hace referencia al bajo coste que tiene la creación de descripciones usando este sistema. La
sencillez de Dublin Core y la posibilidad de que cualquier persona pueda crear descripciones
sin una costosa formación previa. Esta característica permitiría catalogar recursos con rapidez
y dar respuesta al crecimiento exponencial de los recursos disponibles en la web 9.
La economía es consecuencia de esa simplicidad, que también se manifiesta en la falta de

restricciones a la hora de combinar las propiedades: todos los elementos serán opcionales y
repetibles, podrán codificarse en cualquier orden, y no se organizan jerárquicamente.
3.3. Los elementos Dublin Core – DCMES 1.1

El núcleo de los elementos Dublin Core está formado por quince elementos, que se clasifican
en tres grupos10, y suelen representarse en la siguiente tabla:
Descripción del recurso Propiedad intellectual Instancia

Title Creator Date
Subject Publisher Type
Description Contributor Format
Source Rights Identifier
Language
Relation
9 [SENSO/AJENSO, 2003] recogía las conclusiones de un estudio de Bernhard Eversberg

publicado en el MARC Forum y señalaba que la principal ventaja de este sistema de metadatos
– su simplicidad – puede constituir también el principal obstáculo para su adopción. En el
referido estudio de Eversberg se comparaban los elementos Dublin Core con los campos más
usados en la creación de registros MARC, concluyendo la falta de precisión y expresividad de
los primeros.
10 Inicialmente se definieron 13 elementos – identificados como versión 0.1 -, cuyos nombres

cambiaban ligeramente a los que tienen en la actualidad. Estos trece elementos incluían: title,
author, subject, publisher, OtherAgent, Date, ObjectType, Form, Identifier, Relation, Source,
Language y Coverage. En la actualidad, Author ha sido renombrado como Creator, otherAgent
ha pasado a llamarse Contributor, ObjectType Type y Form ha pasado a ser Format.
El documento IETF RFC 2413 se identifica con la versión 1.0 de Dublin Core. La versión actual
del DCMES, la 1.1, se publicó el 2 de julio de 1999. Desde entonces se han publicado distintas
revisiones de esta versión, sin cambios sustanciales.
Página 16 de 40
Coverage
Todos estos elementos se consideran opcionales y repetibles en la descripción. Normalmente,

su nombre se escribirá precedido por los caracteres “DC:”. Los elementos del describen en los
siguientes apartados.
3.3.1. Elemento title
Título o nombre dado al recurso que se describe. Normalmente, éste título lo asignará al autor
y será explícito en el documento.
3.3.2. Elemento creator
Persona u organización principal responsable de la creación del contenido intelectual del

recurso.
3.3.3. Elemento subject
Tema del que trata el recurso. Equivaldría a la materia. Se recomienda que el valor de este
elemento proceda de una lista de encabezamientos de materia, sistema de clasificación o
vocabulario controlado.
3.3.4. Elemento description
Resumen del contenido del recurso. Puede recoger también una tabla de contenidos o
sumario.
3.3.5. Elemento publisher
Organización responsable de la publicación del recurso. En el caso de recursos electrónicos

publicados en la web, DC:Publisher recogerá el nombre de la institución que ha publicado y
mantiene el recurso en Internet.
3.3.6. Elemento contributor
Persona u organización que ha tenido una contribución intelectual significativa en la creación

del recurso pero cuyas contribuciones son secundarias en comparación a la de las personas u
organizaciones especificadas en el elemento creator.
3.3.7. Elemento date
Fecha de un evento en el ciclo de vida del recurso. Este evento puede ser la publicación (sería
su uso más habitual), aprobación formal, creación, etc. Se recomienda codificar el valor de este
Página 17 de 40
campo según especifica la norma ISO 8061, es decir, AAAA-MM-DD (año, mes, día), por
ejemplo, 2006-03-02 sería el dos de marzo del 2006.
3.3.8. Elemento type
Tipo de recurso que se describe. Se ha propuesto un listado de valores recomendados para

esta propiedad11, entre ellos:
Los valores de esta lista son los siguientes:
 Collection: se define como una agregación de items. El recurso se describe como un

grupo, formado por una serie de partes que podrían describirse de forma
independiente.
 Dataset: se define como información codificada de forma estructurada, que podría ser
procesada directamente por un ordenador (por ejemplo, una base de datos quedaría
incluida en este grupo)
 Event: se refiere a un evento que sucede en un instante o periodo de tiempo y que se

caracteriza por tener un propósito, ubicación, duración, etc.
 Image: se refiere a cualquier tipo de imagen o representación visual no textual:

fotografías, dibujos, pinturas, diagramas, mapas, música impresa, películas, etc.
 InteractiveResource: recurso que exige la interacción del usuario para poder ser
comprendido y utilizado, como puede ser un sitio web, un componente multimedia, etc.
 MovingImage: imágenes en movimiento, películas, animaciones, videos, etc.
 PhysicalObject: objeto inanimado y tridimensional, como por ejemplo una escultura.
 Service: Se define como un sistema que ofrece funciones a unos usuarios. Se citan
como ejemplos un sistema de préstamo interbibliotecario, un servidor web, un Z39.50,
etc.
 Software: Programa de ordenador (compilado o no).
 Sound: recurso de información audio.
 StillImage: imágenes estáticas (pinturas, planos, mapas, dibujos...
 Text: recurso de información cuyo contenido principal es texto.
11 http://www.dublincore.org/documents/dcmi-type-vocabulary
Página 18 de 40
3.3.9. Elemento format
Formato físico en el que se encuentra el documento o recurso que se describe. Por ejemplo,
HTML, PDF, Word, etc. Se recomienda codificarlo usando los tipos MIME 12.
3.3.10. Elemento identifier
Identificador asignado al recurso. Lo identificará de forma inequívoca: por ejemplo, una URL,
un DOI, el ISBN para libros impresos, etc.
3.3.11. Elemento source
Hace referencia al recurso del cual procede el recurso que se está describiendo. Se usará
normalmente cuando el recurso que se describe es un resumen de otro documento, una
traducción o el resultado de la digitalización.
3.3.12. Elemento language
Idioma del recurso. Para indicarlo se utilizará el método y los códigos definidos en el
documento RFC 3066 y en la norma ISO 639-2:1998 Codes for the representation of names of
languages. Alpha-3 code 13.
3.3.13. Elemento relation
Recoge un recurso relacionado con el recurso que se está describiendo. Cada ocurrencia del
elemento relation establece una relación entre dos recursos. Las relaciones pueden ser de
distinto tipo: versiones, traducciones, relaciones parte-todo, cambios en formatos, etc.
3.3.14. Elemento coverage
Cobertura geográfica o temporal recurso, respecto al tema que trata. Indica de qué área
geográfica o periodo de tiempo trata el contenido del recurso. Por ejemplo, un documento
12 Los tipos MIME pueden consultarse en:
http://www.iana.org/assignments/media-types/
13 Disponibles, respectivamente, en:
http://www.ietf.org/rfc/rfc3066.txt
http://www.loc.gov/standards/iso639-2/langhome.html
Página 19 de 40
titulado El desempleo en España 1970-1975 tendría como cobertura geográfica España y como
cobertura temporal el periodo comprendido entre 1970 y 1975.
Se recomienda utilizar vocabularios controlados para recoger los nombres de lugares y

periodos de tiempo de forma normalizada14.
3.3.15. Elemento rights
Nota relativa a los derechos sobre el recurso, términos y condiciones de acceso, reproducción,
etc. Puede tomar como valor una URL que apuntase a un documento externo con esa
información.
3.4. Dublin Core “simple” y “calificado”

Una de las críticas más frecuentes al sistema Dublin Core es su generalidad. Para paliar los
problemas derivados de esto, la DCMI incorporó un mecanismo para precisar el significado de
sus elementos: los calificadores. Cumplen dos funciones: a) precisar el significado de los
elementos y b) indicar si el valor de un elemento se ha tomado de una lista controlada, o si se
ha redactado siguiendo una pauta.
Como ejemplo del primer uso de los calificadores, hemos señalado que el elemento date
recoge una fecha relacionada con un evento. Esto puede hacer referencia a distintas fechas:
creación, aprobación, publicación, etc. Los calificadores permiten expresar con más detalle a
qué tipo de fecha nos referimos. Los calificadores que cumplen esta función reciben el nombre
refinements en inglés.
La segunda función de los calificadores es indicar de dónde se toma el valor asignado a un

elemento Dublin Core. Los calificadores que cumplen esta función reciben el nombre de
esquemas de codificación, traducción de encoding schemes en inglés. Como ejemplos,
señalaremos que el valor del elemento subject puede tomarse de un sistema de clasificación
bibliográfica como la CDU (Clasificación Decimal Universal), la DDC (Dewey Decimal
Classification), o de una lista de encabezamientos de materia como la LCSH (Library of
Congress Subject Headings) entre otras. La descripción de un recurso podría recoger también
esta información mediante calificadores.
14 Entre los medios recomendados en el documento de Dublin Core se citan la norma ISO 3166
– Codes for the representation of names of countries, y el Thesaurus Getty de Nombres
Geográficos, disponible en:
http://www.getty.edu/research/conducting_research/vocabularies/tgn/
Página 20 de 40
Debemos señalar que la documentación de Dublin Core habla de términos Dublin Core (Dublin
Core terms en inglés) para hacer referencia tanto a los elementos como a los calificadores,
cualquiera que sea su tipo.
En la creación de descripciones basadas en Dublin Core se puede optar por usar o no los
calificadores definidos por la DCMI. Cuando se utilicen diremos que se está usando el Dublin
Core calificado (qualified Dublin Core). Cuando no se apliquen y sólo se usen los quince
elementos del núcleo, diremos que se está utilizando el Dublin Core simple15.
3.4.1. Calificadores Dublin Core

La DCMI publicó una lista inicial de calificadores en julio del año 2000 16. El listado completo de
calificadores disponibles en Dublin Core se puede obtener en el documento DMCI Metadata
Terms17.
La siguiente tabla recoge – en orden alfabético - los calificadores definidos en el citado

documento. La primera columna recoge su nombre; la segunda la del elemento al que
complementa, y la tercera una breve descripción de su significado. Todos ellos fueron añadidos
a la especificación el once de julio del 2000 (en aquellos casos donde no es así, se ha indicado
la fecha en la que se añadieron)
Calificador Califica al Descripción

elemento
abstract description Resumen del contenido del recurso.
accessRights rights Información sobre restricciones de
acceso relativas a la privacidad o
seguridad de la información. Fue
declarado el 15 de febrero de 2003.
alternative title Título alternativo para el recurso, a parte
del título principal.
available date Fecha o rango de fechas durante el cual
el recurso está disponible.
bibliographicCitation identifier Referencia bibliográfica recomendada
para citar al recurso. Declarado el 15 de
febrero de 2003. DCMI ha redactado
unas recomendaciones sobre cómo
15 El uso de calificadores está vinculado al llamado principio dumb-down. Este indica que una
descripción de un recurso en Dublin Core calificado, podría omitir todos los calificadores y
seguir siendo comprensible y procesable.
16 http://www.dublincore.org/documents/2000/07/11/dcmes-qualifiers/
17 Disponible en: http://dublincore.org/documents/dcmi-terms/
Página 21 de 40

elemento
codificar el valor de este metadato,
titulada Guidelines for Encoding
Bibliographic Citation Information in
Dublin Core Metadata18.
En ambos casos es posible codificar las
citas bibliográficas de dos formas: a) en
un formato no legible por ordenador,
orientado a un lector, y b) en un formato
procesable por un programa informático.
Para esto último se aconseja utilizar el
formato establecido en la norma Z39.88-
2004 OpenURL Framework for Context-
Sensitive Services.
Codificar referencias bibliográficas
usando esta norma como parte de los
registros Dublin Core ofrecería la
posibilidad de automatizar su tratamiento
y estructurar sistemas de recuperación
más sofisticados, capaces de explotar
también las referencias disponibles en el
registro.
conformsTo relation Establece una relación entre el recurso
que se describe y un estándar o norma
que el recurso cumple. Fue declarado el
21 de mayo de 2001.
created date Fecha de creación del recurso.
dateAccepted date Fecha en la que se aceptó el recurso
(por ejemplo, la fecha de aceptación de
una tesis, la de un artículo en una
publicación científica, etc.) . Fue
declarado el 13 de julio de 2002.
dateCopyrighted date Fecha del copyright. Declarado el 13 de
julio de 2002.
dateSubmitted date Fecha en la que se presentó el recurso
para su ser aprobado. Se puede usar con
tesis, artículos científicos, etc. Declarado
el 13 de julio de 2002.
extent format Duración o extensión física del recurso.
hasFormat relation Se usa cuando el recurso que se
describe existía anteriormente en otro
formato, pero con el mismo contenido
que el recurso al cual se hace referencia
desde esta propiedad.
18 La recomendación se publicó el 13 de junio del 2005, y puede consultarse desde la URL:
http://dublincore.org/documents/dc-citation-guidelines/
Página 22 de 40

elemento
hasPart relation El recurso que se describe incluye al
recurso al que se hace referencia.
hasVersion relation El recurso que se describe tiene una
versión, edición o adaptación a la que se
hace referencia desde esta propiedad.
isFormatOf relation El recurso que se describe contiene la
misma información que el registro al que
se hace referencia con la relación, pero
se encuentra en otro formato.
isPartOf relation El recurso que se describe es una parte
del registro al que se hace referencia con
la relación.
isReferencedBy relation El recurso que se describe es citado o
referenciado de alguna forma por el
recurso al que apunta la relación.
isReplacedBy relation El recurso que se describe es
reemplazado por el recurso al que
apunta la relación.
isRequiredBy Relation El recurso que se describe es requerido
por el recurso al que apunta la relación,
por ejemplo, para poder comprender su
información.
issued date Fecha en la que se publicó el recurso.
isVersionOf relation El recurso que se describe es una
versión, edición o adaptación del recurso
al cual apunta la relación. Implica
cambios en el contenido del recurso, y no
sólo cambios en el formato.
license rights Información sobre la licencia para usar el
recurso. Fue declarado el 14de junio de
2004
mediator audience Indica una entidad que media en el
acceso al recurso. Fue declarado el 2 de
mayo de 2001.
medium format Recoge el formato físico o medio sobre el
que se encuentra el recurso.
modified date Fecha de actualización del recurso.
references relation El recurso que se describe hace
referencia o cita al recurso al cual apunta
la relación.
replaces relation El recurso que se describe reemplaza al
recurso al cual apunta la relación.
requires relation El recurso que se describe requiere al
recurso al cual apunta la relación por
distintos motivos: coherencia de
contenido, información de soporte, etc.
spatial coverage Zona geográfica a la cual se refiere el
Página 23 de 40

elemento
contenido informativo del recurso que se
describe.
tableOfContents description Sumario o listado de las secciones que
contiene el recurso que se describe.
temporal coverage Tiempo o época a la que se refiere el
contenido informativo del recurso que se
describe.
valid Date Fecha – o rango de fechas – que
determina la validez de un recurso.
3.4.2. Esquemas de codificación en Dublin Core

Como hemos señalado, los calificadores no sólo permiten precisar el significado de un
elemento. También pueden usarse para indicar de dónde se toman los valores asignados a
éstos. Las especificaciones Dublin Core recomiendan el uso de las siguientes listas controladas
(todas se añadieron el 11 de julio del 2000, excepto aquellas en las que se ha indicado su
fecha explícitamente).
Sistema Usado con el Descripción

elemento
DCMIType Type Para codificar el tipo de contenido del recurso19.
DDC Subject Para codificar materias según la Dewey Decimal
Classification.
IMT Format Para codificar el formato del recurso20.

ISO3166 Coverage Para codificar países como valor del calificador spatial21.
spatial
ISO639-2 Language Para codificar idiomas22.
LCC Subject La materia se codifica según la Library of Congress
19 La lista de valores para type está disponible en: http://dublincore.org/documents/dcmi-type-

vocabulary/
20 La lista de formatos IMT se puede obtener en: http://www.iana.org/assignments/media-types/

21 La lista de códigos de país puede consultarse en:
http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
22 La lista de idiomas puede consultarse en:
http://lcweb.loc.gov/standards/iso639-2/langhome.html
Página 24 de 40
Sistema Usado con el Descripción

elemento
Classification.
LCSH Subject La materia se codifica según la Library of Congress Subject
Headings.
MESH Subject La materia se codifica según la Medical Subject Headings.
NLM Subject La material se codifica según la clasificación de la National

Library of Medicine. Se añadió el 13 de junio del 2005.
Period Date Se utiliza para indicar que el valor de los elementos /
coverage calificadores a los que acompaña recogen un periodo de
temporal tiempo.
Point Coverage Se usa para codificar un lugar mediante sus coordenadas
spatial geográficas.
TGN Coverage Indica que el valor del calificador se toma del Getty
spatial Thesaurus of Geographic Names.
UDC Subject La materia se codifica mediante códigos CDU (Clasificación

Decimal Universal).
URI Identifier Dependiendo del elemento con el cual se utilice, recogerá la

Source URI o URL en Internet de: a) el recurso que se describe; b) el
recurso en el que se basa el recurso que se describe, o c) el
Relation
recurso relacionado con el recurso que se describe.
W3CDTF Date Permite codificar fechas y horas. Se basa en la ISO 8601 23.
Coverage
temporal
Es posible utilizar otros vocabularios controlados o esquemas de codificación a parte de los

citados en la tabla anterior. En la documentación de la DCMI (Frequently Asked Questions), se
señala como “la lista recoge únicamente los vocabularios controlados que han sido
presentados a la DCMI” y se invita a registrar listas adicionales. La ventaja de registrarlas es
que – una vez se les asigne un identificador, otras instituciones podrán utilizarlo referenciando
ese mismo código, lo que asegura un mayor nivel de compatibilidad. La DCMI también señala
que en ningún momento se realiza ningún tipo de aprobación o validación del contenido de las
listas cuyo registro se solicita24.
23 Se describe en el documento: http://www.w3.org/TR/NOTE-datetime
24 Véase http://dublincore.org/resources/faq/
Página 25 de 40
3.4.3. Elementos adicionales

Dentro del Dublin Core calificado, también se incluyen unos elementos adicionales a los quince
que forman el núcleo propiamente dicho. Algunos de estos elementos tienen utilidad en
contextos determinados, y no se considerarían de utilidad general. La lista incluye:
 accrualMethod –método por el cual se ha añadido un recurso a la colección.

Podríamos traducirlo como método de ingreso. Se añadió el 13 de junio del 2005.
 accrualPeriodicity – relacionado con el anterior, indica con qué periodicidad se

unen o añaden recursos a la colección. Se añadió el 13 de junio del 2005.
 audience – audiencia a la cual se dirige el recurso. Se añadió el 21 de mayo del

2001. Este elemento cuenta con un calificador asociado, mediator, que recogería la
entidad que actúa como mediador entre el recurso y sus usuarios finales.
 educationLevel –nivel de estudios de la audiencia para la cual se recomienda el

recurso. Se añádió el 13 de julio del 2005 y resulta útil en la descripción de recursos
formativos o en el contexto de una centro educativo.
 instructionalMethod –método de instrucción al cual da soporte el recurso que se

describe. Se añadió el 13 de junio del 2005.
 provenance – recoge cambios en la propiedad y custodia del recurso producidos

desde el momento de su creación, y que pueden resultar relevantes para evaluar su
autenticidad, integridad e interpretación. Se añadió el 20 de septiembre del 2004.
 rightsHolder – organización o persona que posee los derechos de un recurso. Se

recomienda asignar a este elemento el nombre o una URI que apunte al poseedor de
dichos derechos. Se añadió el 14 de junio del 2004.
En cuanto se utilice en una descripción cualquiera de los elementos citados en este apartado,
debemos decir que se está usando el Dublin Core calificado. De esta forma, el sistema de
metadatos Dublin Core incorpora más de quince elementos – en total contaríamos veintidós –
si bien únicamente quince de ellos forman parte del llamado núcleo.
3.4.4. Términos y espacios de nombres

Si consultamos la documentación de la DCMI encontramos que se usa también la palabra
términos para hacer referencia tanto a los elementos del núcleo, como a los de los calificadores
descritos en el apartado anterior y a los elementos adicionales.
Para indicar que estos términos pertenecen a Dublin Core se han definido tres espacios de
nombres reservados. Recordamos que la función de los espacios de nombres es indicar de qué
Página 26 de 40
sistema de marcas o vocabulario procede un elemento, y evitar así confusiones en el caso de

que dos sistemas de metadatos contengan elementos con idéntico nombre.
 El primer espacio de nombres está identificado por el URI:
http://purl.org/dc/elements/1.1/
En él se agruparían los nombres de los elementos que forman el núcleo. Esto quiere
decir que el identificador completo del elemento subject, por ejemplo, sería:
http://purl.org/dc/elements/1.1/subject
De esta forma podríamos diferenciarlo de otros elementos con idéntico nombre que se
hayan definido en otros sistemas de metadatos
 El segundo espacio de nombres se identifica por el URI:
http://purl.org/dc/terms/
Engloba los nombres del resto de elementos (es decir, los que no forman parte de los
quince del núcleo) y los calificadores.
 El tercer espacio de nombres está identificado por el URI:
http://purl.org/dc/dcmitype/
y recoge los valores o términos que se pueden utilizar para indicar el tipo de un recurso
(es decir, los valores que se asignarán al elemento type)
No parece existir ningún motivo, al margen de la progresiva evolución de las especificaciones

por el que se hayan mantenido estos tres espacios de nombres. Cuando revisemos en un
apartado posterior la codificación de metadatos Dublin Core en XML, XHTML y RDF/XML,
deberemos recordar la necesidad de incluir referencias a estos espacios de nombres.
3.5. Dublin Core para bibliotecas: el perfil DC-Lib

Dublin Core se define como un sistema de metadatos de propósito general. Para satisfacer los
requerimientos de áreas más especializadas se ha establecido el concepto de perfil. Un perfil
podría definirse como una adaptación que se hace para facilitar su adopción en una comunidad
de usuarios con necesidades particulares. Los perfiles establecen recomendaciones o
restricciones sobre la forma en la que deben usarse algunos elementos y calificadores y la
posibilidad de combinarlos con otros sistemas de metadatos 25.
Página 27 de 40
En el área de las bibliotecas se ha desarrollado el perfil DC-Lib por el grupo de trabajo DCMI-
Libraries Working Group; su última versión está disponible desde el 10 de septiembre del
200426.
Entre las recomendaciones que se dan en este documento destacaremos:
 Obligatoriedad de incluir en las descripciones el elemento title o identifier.
 Se recomienda indicar el idioma en el que está escrito el valor de los metadatos mediante
atributos xml:lang.
 Un título paralelo, resultado de la traducción o transliteración del título propiamente dicho

se codificará en un elemento title aparte.
 El calificador alternative se usará para codificar títulos uniformes o cualquier otro título
alternativo.
 Para los elementos contributor y publisher se han definido una serie de

calificadores, que son un subconjunto de los disponibles en la lista:
http://www.loc.gov/marc/sourcecode/relator/relatorlist.html
 Se han registrado las listas de materias y sistemas de clasificación LCSH, MeSH, DDC,
LCC y UDC para el elemento subject.
 En el elemento description y en sus calificadores abstract y tableOfContents -

se recomienda incluir el texto de la descripción del recurso para facilitar la búsqueda por
palabras clave.
 En el elemento date, se recomienda el uso de los calificadores establecidos para este

elemento para evitar posibles ambigüedades. Los formatos recomendados para la
codificación de fechas son el W3C-DTF e ISO 8601 sin guiones para diferenciar año, mes y
día.
En relación a las fechas, se recomienda utilizar el calificador issued para la fecha de

publicación de la edición o reimpresión que se está describiendo (la fecha de publicación
de la instancia particular sería diferente de la de creación del recurso; por ejemplo, una
reimpresión de 1999 de un libro publicado por primera vez en 1996 tendría como fecha de
creación (created) 1996 y como fecha de publicación (issued) 1999.
26 Puede consultarse en la URL: http://dublincore.org/documents/library-application-profile/
Página 28 de 40
El calificador dateCopyrighted se usará únicamente si recoge un valor distinto al de

issued o created, o si éstas dos se desconocen y sólo figura la fecha del copyright.
Los calificadores dateSubmitted y dateAccepted se recomiendan en descripciones

de tesis académicas.
 En el caso del elemento type, se señala la posibilidad de registrar la lista de tipos

definidas en el formato MARC para codificar tipos de materiales.
 Se recomienda usar el elemento format para indicar el formato de los recursos

disponibles en formato electrónico. El calificador medium se usará para indicar el
dispositivo físico en el que se almacena el recurso (CD-ROM, DVD, cinta magnética, etc.)
 Se aconseja usar el elemento source cuando el recurso que se describe procede de la

digitalización de un documento, y sólo en este caso.
 El idioma se codificará preferiblemente mediante códigos tomados de la ISO 639-2..
 El elemento relation se podrá matizar con los siguientes calificadores: references,

isReferencedBy, hasPart, Requires, IsPartOf, Replaces,
isReplacedBy, hasFormat, isFormatOf, isVersionOf.
En el caso anterior el calificador isVersionOf se utilizará para diferenciar versiones,
ediciones o adaptaciones que afectan al contenido de la obra. Por otra parte isFormatOf
se utilizará para relacionar el recurso con otro de idéntico contenido pero en distinto
formato.
 El perfil DC-Lib aconseja el uso conjunto de los elementos Dublin Core con los de otro
sistema de metadatos: MODS. Se incorporan los siguientes metadatos de MODS:
 DateCaptured – para recoger la fecha de captura de un recurso.
 Edition – para indicar la edición o versión del recurso que se describe; la edición se
refiere al concepto de edición tradicional.
 Location: indica la organización que custodia un recurso y puede dar acceso al

mismo.
4. Dublin Core y XML

Dublin Core no obliga a utilizar un sistema de codificación determinado. las descripciones de
recursos pueden codificarse como documentos HTML, XHTML, XML, en una base de datos
relacional, o de cualquier otra forma. Para facilitar el uso de las distintas alternativas
disponibles, la DCMI ha publicado recomendaciones sobre cómo codificar los metadatos Dublin
Página 29 de 40
Core utilizando estos formatos. Únicamente trataremos la forma de crearlas en XHTML y en

XML. En este caso disponemos de dos opciones, dependiendo de si se usa o no RDF
(Resource Description Framework).
4.1. Codificar metadatos Dublin Core en XHTML

Hay dos formas de crear descripciones Dublin Core para documentos XHTML. La primera
consiste en escribir los metadatos en la cabecera del documento XHTML; la segunda en añadir
un enlace desde documento XHTML que apunte a un archivo RDF/XML externo con su
descripción.
4.1.1. Incluir metadatos Dublin Core en el documento XHTML

Para codificar metadatos Dublin Core como parte de un documento XHTML se usarán
etiquetas <meta> en la cabecera (elemento <head>) de los documentos27. Cada elemento
Dublin Core se recogerá en una etiqueta <meta> aparte. Si un elemento se repite en más de
una ocasión, contará con una etiqueta <meta> para cada una de sus ocurrencias. El atributo
name de la etiqueta <meta> recogerá el nombre del elemento y el atributo content su valor.
Las etiquetas <meta> no deben seguir un orden particular, ya que los elementos y
calificadores Dublin Core pueden aparecer en cualquier orden.
Otra convención que debemos seguir es incluir, en el elemento <head> de la página XHTML,
un atributo profile con la siguiente forma:
<head profile=”http://dublincore.org/documents/dcq-html/”>
27 Este apartado se basa en la última versión consultada de las recomendaciones de la DCMI

Expressing Dublin Core in HTML/XHTML meta and link elements, preparadas por Andy Powell
de la UKOLN y publicadas el 30 de noviembre del 2003. Están disponibles en la URL
http://dublincore.org/documents/2003/11/30/dcq-html/.
En la literatura sobre Dublin Core es posible encontrar referencias a otras formas ya obsoletas
de incluir metadatos Dublin Core en páginas HTML. Por ejemplo, escribir la letra inicial de los
metadatos Dublin Core en mayúscula, obviar el uso de elemento <link> para recoger
metadatos cuyo valor es una URI de otro recurso o escribir el nombre de los cualificadotes
precedidos del nombre del elemento al que cualifican. Destacamos este punto porque es
posible encontrar estas aproximaciones, como decimos ya obsoletas, en artículos dedicados a
este tema.
Página 30 de 40
Además de esto, dentro de la cabecera de la página HTML se añadirán elementos <link>

para hacer referencia a los espacios de nombres de Dublin Core:
http://purl.org/dc/elements/1.1/
http://purl.org/dc/terms/
Si en la descripción se usa el Dublin Core simple, únicamente se tendrá que incluir la referencia
al primero. Si se usa el calificado, será preciso incluir las referencias a los dos espacios de
nombres. La forma que tendrán los elementos <link> será ésta:
<link rel="schema.DC” href="http://purl.org/dc/elements/1.0/">
<link rel="schema.DCTERMS” href="http://purl.org/dc/terms/">
Por convención, los alias que se asignan a estos espacios de nombres, y que precederán a los
nombres de elementos y calificadores, son DC (para los quince elementos del núcleo) y
DCTERMS (para los calificadores, esquemas de codificación y elementos que no forman parte
del núcleo).
De esta forma, una descripción Dublin Core incrustada en una página XHTML tendría el
siguiente aspecto:
<head profile=”http://dublincore.org/documents/dcq-html/”>
<link rel="schema.DC” href="http://purl.org/dc/elements/1.0/">
<link rel="schema.DCTERMS” href="http://purl.org/dc/terms/">
<meta name="DC.creator“ content = "Marx, Karl" />
<meta name="DC.title“ content="El Capital“ />
<meta name = "DC.format" content = "text/html" />
<meta name = "DC.language" content = "en" />
<meta name="DCTERMS.modified" content="2001-07-18" />
</head>
Vemos que los nombres de los elementos del núcleo se escriben precedidos por el prefijo DC, y
los de calificadores por DCTERMS.
Para indicar que el valor de un elemento Dublin Core se toma de un vocabulario controlado o
que se codifica siguiendo una pauta particular, se debe añadir al elemento <meta>
correspondiente un atributo scheme que tomará como valor el nombre del esquema de
codificación que se aplique. Por ejemplo, para indicar el formato de la fecha que se usa, o que
la materia se toma de la Library of Congress Subject Headings, se usaría el atributo scheme
de la siguiente forma:
Página 31 de 40
<meta name="DC.date" scheme="DCTERMS.W3CDTF" content="2006-01-23" />
<meta name="DC.subject" scheme="DCTERMS.LCSH" content="History" />
Nótese que el valor asignado al atributo scheme, al tratarse de términos registrados como parte
del Dublin Core calificado, también se escribe precedido por el prefijo DCTERMS.
Para concluir este apartado, señalaremos una excepción a las reglas anteriores; en aquellos
casos en los cuales un elemento o calificador vaya a recoger una URI de un recurso en lugar
de un valor textual, en lugar del elemento <meta> se recomienda usar el elemento <link>.
Esta situación se puede dar en el caso del metadato relation y sus calificadores. El
elemento <link> irá acompañado por un atributo rel que recogería el nombre del elemento
o calificador (precedido por los prefijos DC o DCTERMS) y por un atributo href con la URL
del recurso al que se hace referencia.
Por ejemplo, si queremos indicar una relación entre el recurso que describimos y otro recurso
identificado por una URL, lo haríamos de la siguiente forma:
<link rel="DC.relation" href="http://www.example.org/" />
<link rel="DCTERMS.references"
href="http://www.example.org/publications/2002/176459.pdf" />
La recomendación también nos permite indicar el idioma en el que está escrito el valor
asignado a un metadato mediante los atributos:
 xml:lang – que acompañará a las etiquetas <meta>
 hreflang – que acompañará a las etiquetas <link>
4.1.2. Vincular metadatos Dublin Core a documentos XHTML

A parte de incluir los metadatos Dublin Core como parte de la cabecera de un documento
XHTML, es posible incluir un enlace en las páginas XHTML que apunten a un documento
RDF/XML externo con los metadatos del documento XHTML.
Para incluir este vínculo se recomienda usar la etiqueta <link>, asignando como valor de su
atributo href la URL del archivo RDF/XML con los metadatos. Este vínculo sería similar al
siguiente:
<link rel="meta" href="http://www.metadatos.org/recurso001.xml" />
Página 32 de 40
4.2. Codificar metadatos Dublin Core Simple en XML

DCMI publicó en abril del 2003 una recomendación para la codificación de metadatos en forma
de documentos XML: Guidelines for implementing Dubin Core in XML. Este documento
describe tanto la codificación de metadatos Dublin Core simple como calificado28.
La recomendación aconseja utilizar esquemas en lugar de DTD, y especifica que los metadatos
Dublin Core se deben agrupar en un elemento contenedor, si bien no se obliga a usar uno en
concreto (en los ejemplos que se dan se usa el elemento <metadata>, aunque podría usarse
cualquier otro). Dentro de este elemento contenedor se situarán los metadatos Dublin Core
propiamente dichos, todos en el mismo nivel jerárquico.
Cada metadato Dublin Core se codificará mediante elementos XML independientes. Sus
nombres se escribirán en minúsculas e irán precedidos por el alias del espacio de nombres
reservado para Dublin Core, que deberá haberse declarado previamente. Los elementos XML
contendrán el valor asignado al metadato. Por ejemplo, para codificar el título de un recurso
con el metadato title, se usaría un elemento como el siguiente:
<dc:title>Dublin Core in XML</dc:title>
Si un elemento Dublin Core recogiese más un más de un valor, se repetirá el elemento XML.
Así, un documento con dos materias incluiría dos elementos <dc:subject>:
<dc:subject>Bibliotecas</dc:subject>
<dc:subject>Archivos</dc:subject>
La recomendación no establece un mecanismo para vincular el registro Dublin Core con el

recurso que se describe, si bien señala la posibilidad de relacionarlo mediante el metadato
identifier, que tomaría como valor la URL o el identificador del recurso que se describe.
Un registro Dublin Core de ejemplo codificado en XML podría tener el siguiente aspecto (el
ejemplo se ha tomado de la citada recomendación). En el ejemplo podemos ver cómo se ha
declarado el espacio de nombres reservado para Dublin Core simple –
http://purl.org/cd/elements/1.1/ - asignándole el alias dc:
<?xml version="1.0"?>
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:title>UKOLN</dc:title>
<dc:description>
UKOLN is a national focus of expertise in digital information
28 Escrito por Andy Powell de UKOLN, está disponible en la URL:
http://dublincore.org/documents/2003/04/02/dc-xml-guidelines/
Página 33 de 40
management. It provides policy, research and awareness services

to the UK library, information and cultural heritage communities.
UKOLN is based at the University of Bath.
</dc:description>
<dc:publisher>UKOLN, University of Bath</dc:publisher>
<dc:identifier>http://www.ukoln.ac.uk/</dc:identifier>
</metadata>
El esquema recomendado por la DCMI para metadatos Dublin Core simple en XML puede
descargarse del sitio web Dublin Core29. Su representación gráfica es la siguiente:
Vemos que se para cada metadato Dublin Core se declara un elemento de tipo texto, que
puede ir acompañado opcionalmente por un atributo xml:lang. Este esquema no podría
usarse directamente. Para poder utilizarlo, tenemos que crear un nuevo esquema XSD e
importar el esquema simpledc20021212.xsd. El esquema desde el cual importamos
declarará el elemento contenedor de los metadatos Dublin Core. En la declaración del
elemento contenedor se indicará que su modelo de contenido es el grupo dcElementsGroup.
A continuación recogemos un ejemplo de esquema XML que hace uso del esquema para
Dublin Core simple:
29 http://dublincore.org/schemas/xmls/simpledc20021212.xsd
Página 34 de 40
<?xml version="1.0" encoding="UTF-8"?>

<xsi:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<xsi:import namespace="ttp://purl.org/dc/elements/1.1/"
schemaLocation="simpledc20021212.xsd"/>
<xsi:element name="metadata">
<xsi:complexType>
<xsi:group ref="dc:elementsGroup"/>
</xsi:complexType>
</xsi:element>
</xsi:schema>
4.3. Codificar metadatos Dublin Core Calificado en XML

El documento Guidelines for implementing Dubin Core in XML también incluye
recomendaciones para la codificación en XML de metadatos Dublin Core calificado.
Los calificadores se codificarán mediante elementos XML independientes. El nombre del

elemento XML coincidirá con el del calificador e irá precedido por el alias dcterms, que también
se debe declarar previamente y asociar al espacio de nombres http://purl.org/dc/terms/.
A modo de ejemplo, para indicar la fecha de modificación de un recurso con el calificador

modified se usaría un elemento XML independiente llamado <dcterms:modified>:
<dcterms:modified>2006-11-20</dcterms:modified>
Los elementos XML correspondientes a calificadores no deben estar anidados ni vinculados de

ninguna forma a los elementos Dublin Core a los que califican 30.
En el caso de los calificadores que indican la procedencia del valor asignado a un metadato, se
usará el atributo xsi:type. Por ejemplo, para indicar que la materia se toma de la CDU, se
haría lo siguiente:
<dc:subject xsi:type="dcterms:UDC">062</dc:subject>
El valor del atributo xsi:type se escribe precedido del alias dcterms.
30 En la recomendación se hace referencia a formas no recomendadas que han sido

propuestas anteriormente para vincular calificadores con elementos. Entre las propuestas que
se dieron, y que están obsoletas, se encuentra el uso del atributo refines y el anidamiento
de los calificadores dentro de los elementos.
Página 35 de 40
A continuación recogemos un ejemplo de registro XML Dublin Core calificado, procedente de la

mencionada recomendación. Los metadatos se agrupan en un elemento contenedor
<metadata>, en cuya etiqueta de inicio se declaran los espacios de nombres:
 http://purl.org/dc/elements/1.1/ - para los elementos que constituyen el núcleo, y
 http://purl.org/dc/terms/ - para los calificadores y el resto de elementos que no forman

parte del núcleo.
También se declara el espacio de nombres http://www.w3.org/2001/XMLSchema-instance

correspondiente a los esquemas XML, y que nos permitirá usar el atributo xsi:type.
<?xml version="1.0"?>
<metadata
xmlns="http://example.org/myapp/"
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:dcterms="http://purl.org/dc/terms/">
<dc:title>UKOLN</dc:title>
<dcterms:alternative>UK Office for Library and Information
Networking</dcterms:alternative>
<dc:subject xsi:type="dcterms:DDC">062</dc:subject>
<dc:subject xsi:type="dcterms:UDC">061(410)</dc:subject>
<dc:description xml:lang="fr">
UKOLN est un centre national d'expertise dans la gestion de
l'information digitale.
</dc:description>
<dc:publisher>UKOLN, University of Bath</dc:publisher>
<dcterms:isPartOf xsi:type="dcterms:URI">
http://www.bath.ac.uk/</dcterms:isPartOf>
<dc:identifier xsi:type="dcterms:URI">http://www.ukoln.ac.uk/
</dc:identifier>
<dcterms:modified>2001-07-18</dcterms:modified>
<dc:format>text/html</dc:format>
<dcterms:extent>14 Kbytes</dcterms:extent>
</metadata>
Página 36 de 40
El esquema propuesto para Dublin Core calificado en XML consta de tres archivos xsd:
dc.xsd, dcterms.xsd y dcmitype.xsd31. Para usarlos debemos crear un nuevo
esquema donde se declarará el elemento contenedor de los metadatos Dublin Core. Desde
este nuevo esquema se importará el esquema dcterms.xsd, se declararán los espacios de
nombres para Dublin Core y se indicará que el elemento contenedor tiene como tipo uno de los
grupos definidos en el esquema dcterms.xsd.
4.4. Codificar metadatos Dublin Core simple en RDF/XML

La codificación de metadatos Dublin Core en XML acepta dos sistemas: a) el descrito en los
apartados anteriores, basado en el uso de un elemento contenedor genérico, y b) el basado en
el uso de RDF (Resource Description Framework). Este último se describe en el documento
Expressing Simple Dublin Core in RDF/XML32.
RDF en un vocabulario XML ideado por el W3C para el intercambio de metadatos de cualquier
tipo. Está estrechamente ligado a la llamada web semántica. RDF establece un tipo de
documento XML que actúa como un sobre o contenedor que puede recoger descripciones
creadas con distintos sistemas de metadatos. El documento RDF recogerá elementos propios
del vocabulario RDF junto con los elementos correspondientes a metadatos Dublin Core. Para
diferenciar unos de otros se usarán los espacios de nombres.
El elemento raíz del documento RDF/XML será <rdf:RDF>, y contendrá uno o más elementos
<rdf:description> para cada recurso que se describa. Los elementos
<rdf:description> contarán con un atributo about que tomará como valor la URL o el
identificador del recurso.
A su vez, <rdf:description> contendrá los elementos correspondientes a los metadatos

Dublin Core. Los metadatos Dublin Core que tengan como valor la URI de otro recurso se
31 Pueden descargarse de la URL: http://dublincore.org/schemas/xmls/
32 Escrito por Dave Beckett, Eric Millar y Dan Brickley el 31 de julio del 2002, está disponible
en: http://dublincore.org/documents/dcmes-xml/.
Este documento se refiere únicamente a la codificación de metadatos Dublin Core simple. Hay
otro documento Expressing Qualified Dublin Core in RDF / XML que describe la codificación
RDF/XML de metadatos calificados, pero que no ha alcanzado el estado de Recomendación en
el momento de redactar este capítulo.
Página 37 de 40
codificarán mediante elementos vacíos acompañados por un atributo rdf:resource; éste

tomará como valor la URL del recurso al que se hace referencia.
La recomendación incluye una DTD y los esquemas con los que se pueden validar las
descripciones33:
El siguiente ejemplo tomado del sitio web de la DCMI muestra cómo codificar metadatos Dublin
Core en un RDF/XML. En el ejemplo, el recurso que se describe es la página web ficticia
http://purl.org/DC/docs/notes-cox-816.htm.
<?xml version="1.0" ?>

<!DOCTYPE rdf:RDF PUBLIC”-//DUBLIN CORE//DCMES DTD 2002/07/31//EN”
“http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-
dtd.dtd”
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description about="http://purl.org/DC/docs/notes-cox-816.htm">
<dc:title>Recording qualified Dublin Core metadata in
HTML</dc:title>
<dc:title xml:lang=”de”>der DC Metadata-Diskussionen</dc:title>
<dc:description> We describe a notation for recording qualified
Dublin Core metadata in HTML meta elements. The syntax includes
recommended usage of the standard HTML syntax to record the
different classes of qualification needed to represent the
model.</dc:description>
<dc:date>1999-08-18</dc:date>
<dc:format>text/html</dc:format>
<dc:language>en</dc:language>
33 La DTD está disponible en la URL:
http://dublincore.org/docuemnts/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd
Debemos señalar que estas DTD y esquemas se incluyen a título informativo, y se señala que
no forman parte del estándar propiamente dicho.
Página 38 de 40
<dc:publisher>Dublin Core Metadata Initiative</dc:publisher>

<dc:relacion rdf:resource=”http://dublincore.org/docs/01.htm” />
</rdf:Description>
</rdf:RDF>
En primer lugar podemos ver el uso de una declaración de tipo de documento que contiene una
referencia a la URL donde se encuentra la DTD (se trata de la segunda línea del documento,
que comienza por la palabra <!DOCTYPE...). Se puede apreciar también el uso del elemento
contenedor <rdf:Description> y su atributo about para recoger la URL del recurso.
Al igual que sucedía con la codificación de metadatos Dublin Core en XML sin usar RDF, en
este modelo también podemos utilizar el atributo xml:lang con cualquier elemento para
indicar en qué idioma está escrito su valor.
5. Conclusiones
Dublin Core constituye la alternativa más popular dentro de los sistemas de metadatos surgidos
como consecuencia de la generalización de la Web. En este capítulo se han descrito las
características de los metadatos, su finalidad, ventajas, y las características de Dublin Core. Si
bien Dublin Core no obliga a utilizar un formato de codificación y transferencia de registros
determinado, sí se permite el uso de XML y se han publicado recomendaciones para la
codificación de metadatos Dublin Core en este formato.
En el capítulo se han comentado los medios recomendados para codificar descripciones Dublin
Core simple y calificado en formato XML, y también el uso de RDF/XML, si bien éste último
cuenta con aspectos que aún no han sido publicados en forma de recomendación. Podemos
concluir señalando que la DCMI ha puesto a disposición de la comunidad unas pautas para la
codificación de descripciones Dublin Core en XML. Estas descripciones podría crearse con
herramientas de edición XML especializadas o con utilidades similares a la propuesta por la UK
Office for Library and Information Networking (UKOLN) de la Universidad de Bath en
Inglaterra34, y que permiten generar un documento XML a partir de un formulario web.
En la actualidad, las principales aplicaciones de Dublin Core son la creación de descripciones

de recursos en los llamados repositorios institucionales, y las iniciativas de archivos abiertos
(open archives).
Los repositorios institucionales consiste en colecciones de documentos que recogen la

producción intelectual de una institución. Han tenido una gran acogida en el entorno académico
34 Puede accederse a ella desde la URL: http://www.ukoln.ac.uk/metadata/dcdot
Página 39 de 40
y universitario. En estos repositorios, Dublin Core constituye una pieza clave ya que se quiere
que sean los autores de los documentos quienes completen una descripción básica de los
recursos, y no el personal especializado de las bibliotecas. De esta forma se agiliza el proceso
de descripción y se asegura la pronta disponibilidad de los materiales. Dublin Core ofrece un
sistema rápido, fácil e intuitivo para que los autores puedan completar esa descripción de sus
documentos antes de añadirlos al repositorio institucional.
La segunda aplicación significativa de Dublin Core – como sistema de descripción en los

llamados archivos abiertos -, se describe en un capítulo posterior del libro. Está relacionada
con la agregación de descripciones de recursos en bases de datos centralizadas, donde se
podrá acceder a los registros catalogados por una red de centros participantes. En este
escenario, Dublin Core y XML ofrecen un mecanismo para transferir a través de la Red los
registros de metadatos y optimizar la recolección de los contenidos.
No son estas las dos únicas aplicaciones de Dublin Core, si bien son las más significativas y
las que han situado a Dublin Core en un lugar prioritario en la práctica profesional.
Página 40 de 40

Dspace Modulo 03 DublinCore

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Dspace Modulo 03 DublinCore

Cargado por

Copyright:

Formatos disponibles

Capítulo 3: XML y la gestión de descripciones bibliográficas.

Dublin Core Ricardo Eito Brun

Lenguajes de marcas en bibliotecas y archivos: formatos

Capítulo 3: XML y la gestión de descripciones

Ricardo Eíto Brun © 2017

2. Metadatos y descripciones de recursos .................................................................................... 4

2.1. Estándares de estructura y de contenido ........................................................................... 5

2.2. Metadatos ........................................................................................................................... 5

2.3. Sistemas de metadatos....................................................................................................... 6

2.4. Metadatos y niveles de normalización ................................................................................ 8

2.4.1. Normalización terminológica y semántica .................................................................... 8

2.4.2. Normalización de las designaciones ............................................................................ 9

2.4.3. Normalización de pautas de contenido ...................................................................... 10

2.4.4. Normalización de los formatos de codificación y transferencia .................................. 10

2.4.5. Metadatos sobre las propias descripciones ............................................................... 11

2.5. Ventajas del uso de metadatos en la recuperación de información ................................. 11

2.6. Tipos de metadatos ........................................................................................................... 12

3.1. La motivación de Dublin Core ........................................................................................... 13

3.2. Características de Dublin Core ......................................................................................... 14

3.2.1. Generalidad ................................................................................................................ 15

3.2.2. Independencia de sistemas de codificación ............................................................... 15

3.2.3. Extensibilidad .............................................................................................................. 15

3.2.4. Economía .................................................................................................................... 16

3.3. Los elementos Dublin Core – DCMES 1.1........................................................................ 16

3.3.1. Elemento title ......................................................................................................... 17

3.3.2. Elemento creator..................................................................................................... 17

3.3.3. Elemento subject..................................................................................................... 17

3.3.4. Elemento description ............................................................................................ 17

3.3.5. Elemento publisher ................................................................................................ 17

3.3.6. Elemento contributor ............................................................................................ 17

3.3.7. Elemento date ........................................................................................................... 17

3.3.8. Elemento type ........................................................................................................... 18

3.3.9. Elemento format ....................................................................................................... 19

3.3.10. Elemento identifier ............................................................................................ 19

3.3.11. Elemento source ..................................................................................................... 19

3.3.12. Elemento language ................................................................................................ 19

3.3.13. Elemento relation ................................................................................................ 19

3.3.14. Elemento coverage ................................................................................................ 19

3.3.15. Elemento rights ..................................................................................................... 20

3.4. Dublin Core “simple” y “calificado” .................................................................................... 20

3.4.1. Calificadores Dublin Core ........................................................................................... 21

3.4.2. Esquemas de codificación en Dublin Core ................................................................. 24

3.4.3. Elementos adicionales ................................................................................................ 26

3.4.4. Términos y espacios de nombres ............................................................................... 26

3.5. Dublin Core para bibliotecas: el perfil DC-Lib ................................................................... 27

4. Dublin Core y XML .................................................................................................................. 29

4.1. Codificar metadatos Dublin Core en XHTML .................................................................... 30

4.1.1. Incluir metadatos Dublin Core en el documento XHTML ........................................... 30

4.1.2. Vincular metadatos Dublin Core a documentos XHTML ............................................ 32

4.2. Codificar metadatos Dublin Core Simple en XML ............................................................ 33

4.3. Codificar metadatos Dublin Core Calificado en XML ........................................................ 35

4.4. Codificar metadatos Dublin Core simple en RDF/XML ..................................................... 37

Este capítulo se centra en el uso de XML para la codificación e intercambio de metadatos y

a) Metadatos y descripciones de recursos: describe la función de los metadatos en el

b) El sistema de metadatos Dublin Core: describe las características de este sistema de

c) Dublín Core y XML: explica la forma de crear descripciones XML basadas en

d) Conclusiones: donde se resumen los principales puntos tratados en el capítulo.

2. Metadatos y descripciones de recursos

La descripción de recursos consiste en la redacción de un asiento o registro en el que se

Estas diferencias se plasman en la existencia de distintos sistemas para la descripción de

2.1. Estándares de estructura y de contenido

No siempre es evidente la diferencia entre estándares de contenido y estructura, ya que en

El hablar de metadatos se generalizó a raíz de la expansión de la World Wide Web, momento

2.3. Sistemas de metadatos