This document has been replaced by http://dublincore.org/documents/2002/12/02/dc-xml-guidelines/.

Guidelines for implementing Dublin Core in XML

Andy Powell
Pete Johnston
UKOLN, University of Bath

10th draft

1. Introduction

This document provides guidelines for people implementing Dublin Core [DCMI] metadata applications using XML [XML]. It considers both simple (unqualified) DC [DCMES] and qualified DC [DCQ]. In each case, the underlying metadata model is described (in a syntax neutral way), followed by some specific guidelines for XML implementations. Guidance on the use of non-DC metadata is also provided. Finally, a mechanism for linking multiple XML metadata records is suggested.

This document does not provide guidelines for encoding Dublin Core in RDF/XML [RDF]. Nor does it take a position on the relative merits of encoding metadata in 'plain' XML rather than RDF/XML. This document provides guidelines in those cases where RDF/XML is not considered appropriate. Mechanisms for encoding Dublin Core metadata in RDF/XML are being developed elsewhere [DCARCH].

2. Definitions

First, some terminology:

Resource
a resource is anything that has identity. Familiar examples include an electronic document, an image, a service (e.g., "today's weather report for Los Angeles"), and a collection of other resources. Not all resources are network "retrievable"; e.g., human beings, corporations, and bound books in a library can also be considered resources.
Property
a property is a specific aspect, characteristic, attribute, or relation used to describe a resource.
Record
a record is some structured metadata about a resource, comprising one or more properties and their associated values.

Note that Dublin Core metadata elements are properties (as defined above). Note also that there is potential confusion between the XML usage of the terms 'element' and 'attribute' and the usage of those terms in a more general metadata context.

3. General implementation guidelines

Recommendation 1. Implementors should base their XML applications on XML Schemas [XMLSCHEMA] rather than XML DTDs. Approaches based on XML Schemas are more flexible and are more easily re-used within other XML applications. In some cases it may be sensible to provide both an XML Schema and a DTD for the application. Where XML Schemas are not used, a DTD should be provided instead.

Recommendation 2. Implementors should use XML Namespaces [XMLNS] to uniquely identify DC properties. DC namespaces are defined in the DCMI Namespace Recommendation [DCMINS].

Note: It is anticipated that records will be encoded within one or more container XML element(s) of some kind. This document makes no recommendations for the name of any container element, nor for the namespace that the element should be taken from. Candidate container element names include <dc>, <dublinCore>, <resource>, <record> and <metadata>.

4. Simple Dublin Core

4.1 Abstract model

Note: There is no formal linkage between a simple DC record and the resource being described. Such a linkage may be made by encoding the URI of the resource as the value of the DC Identifier element, however this is not mandatory.

Note: While the value of a property may be a URI, there is nothing in the simple DC model that indicates this is the case. At their own risk, implementations may choose to guess which values are URIs and which are not.

4.2 Implementation guidelines

(Implementors should follow the general guidelines.)

Recommendation 3. Implementors should encode properties as XML elements and values as the content of those elements. For example, use

<dc:title>Dublin Core in XML</dc:title>
rather than
<dc:title value="Dublin Core in XML" />

Recommendation 4. The property names for the 15 DC elements should be all lower-case. For example, use

<dc:title>Dublin Core in XML</dc:title>
rather than
<dc:Title>Dublin Core in XML</dc:Title>

Recommendation 5. Multiple property values should be encoded by repeating the XML element for that property. For example:

<dc:title>First title</dc:title>
<dc:title>Second title</dc:title>

4.3 Example - a simple DC record

<?xml version="1.0"?>

<metadata
  xmlns="http://myorg.org/myapp/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://myorg.org/myapp/ http://myorg.org/myapp/schema.xsd"
  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
    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>

Note that the http://myorg.org/myapp/schema.xsd XML schema does not exist. This is a ficticious example!

5. Qualified Dublin Core

5.1 Abstract model

Note: for schemes that are currently recommended by the DCMI, the name is specified in the DC Qualifiers recommendation (listed as the name, not the label) [DCQ]. It is anticipated that the DCMI will develop other mechanisms for registering agreed names for schemes in the future.

5.2 Implementation guidelines

(Implementors should follow the general guidelines and the guidelines for simple Dublin Core.)

Recommendation 6. Element refinements should be treated in the same way as other properties. For example, use

<dcterms:available>2002-06</dcterms:available>
rather than
<dc:date refinement="available">2002-06</dc:date>
or
<dc:date type="available">2002-06</dc:date>
or
<dc:date>
  <dcterms:available>
    2002-06
  </dcterms:available>
</dc:date>

Element refinements are elements in their own right and are therefore best encoded in a similar way to other DC elements. In particular, it should be noted that element refinements may have further refinements of their own (e.g. 'format' is refined by 'extent' which might be further refined by 'duration').

Recommendation 7. Encoding schemes should be implemented using a 'dcxml:scheme' attribute of the XML element for the property. The encoding scheme name (as listed in the DC Qualifiers recommendation [DCQ]) should be given as the attribute value. For example:

<dc:identifier dcxml:scheme="URI">http://www.ukoln.ac.uk/</dc:identifier>

The namespace URI for the 'dcxml' namespace is http://purl.org/dc/dcxml/.

Recommendation 8. Element refinement names may be mixed-case but should always have a lower-case first letter. Encoding scheme names may be mixed-case but should always start with an upper-case letter. For example:

<dcterms:isPartOf dcxml:scheme="URI">
  http://www.bbc.co.uk/
</dcterms:isPartOf>
<dcterms:temporal dcxml:scheme="Period">
  name=The Great Depression; start=1929; end=1939;
</dcterms:temporal>

Note: Encoding scheme names are often all upper-case.

Recommendation 9. Where the language of the value is indicated, it should be encoded using the 'xml:lang' attribute. For example:

<dc:subject xml:lang="en">seafood</dc:subject>
<dc:subject xml:lang="fr">fruits de mer</dc:subject>

5.3 Example - a qualified DC record

<?xml version="1.0"?>

<metadata
  xmlns="http://myorg.org/myapp/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://myorg.org/myapp/ http://myorg.org/myapp/schema.xsd"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:dcxml="http://purl.org/dc/xml/">

  <dc:title>
    UKOLN
  </dc:title>
  <dcterms:alternative>
    UK Office for Library and Information Networking
  </dcterms:alternative>
  <dc:subject>
    national centre, network information support, library
    community, awareness, research, information services,public
    library networking, bibliographic management, distributed
    library systems, metadata, resource discovery,
    conferences,lectures, workshops
  </dc:subject>
  <dc:subject dcxml:scheme="DDC">
    062
  </dc:subject>
  <dc:subject dcxml:scheme="UDC">
    061(410)
  </dc:subject>
  <dc:description>
    UKOLN is a national focus of expertise in digital information
    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: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 dcxml:scheme="URI">
    http://www.bath.ac.uk/
  </dcterms:isPartOf>
  <dc:identifier dcxml:scheme="URI">
    http://www.ukoln.ac.uk/
  </dc:identifier>
  <dcterms:modified dcxml:scheme="W3C-DTF">
    2001-07-18
  </dcterms:modified>
  <dcterms:medium dcxml:scheme="IMT">
    text/html
  </dcterms:medium>
  <dcterms:extent>
    14 Kbytes
  </dcterms:extent>

</metadata>

6. Mixing DC metadata with other metadata schemas

Many metadata applications will mix Dublin Core metadata with properties taken from other metadata schemas. There are several reasons for wanting to do this. Firstly, the need for DC-based metadata applications to incorporate semantics that are not available within the DCMES. Secondly, the desire to incorporate DCMES elements within other metadata applications.

Where possible, all use of DC metadata in XML should follow the guidelines above.

Non-DC properties can be encoded as XML elements alongside DC elements. Here are two simple examples:

6.1 Example - mixing DC and IMS metadata

This example adds an IMS (IEEE LOM) [IMS] TypicalLearningTime property to a simple DC record:

<?xml version="1.0"?>

<record
  xmlns="http://myorg.org/learningapp/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://myorg.org/learningapp/ http://myorg.org/learningapp/schema.xsd"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:ims="http://www.imsglobal.org/xsd/imsmd_v1p2">

  <dc:title>
    Frog maths
  </dc:title>
  <dc:identifier>
    http://somewhere.com/frogmaths/
  </dc:identifier>
  <dc:description>
    Simple maths games for 5-7 year olds.
  </dc:description>
  <ims:typicallearningtime>
    <ims:datetime>
      0000-00-00T00:15
    </ims:datetime>
  </ims:typicallearningtime>

</record>

Note that DC case conventions for element names may not apply to other metadata schemas.

6.2 Example - mixing DC and ODRL metadata

This example adds a machine-readable Open Digital Rights Language [ODRL] statement and a DC Rights element to the example above:

<?xml version="1.0"?>

<record
  xmlns="http://myorg.org/learningapp/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://myorg.org/learningapp/ http://myorg.org/learningapp/schema.xsd"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:dcterms="http://purl.org/dc/terms/"
  xmlns:dcxml="http://purl.org/dc/xml/"
  xmlns:oex="http://odrl.net/1.0/ODRL-EX"
  xmlns:odd="http://odrl.net/1.0/ODRL-DD"
  xmlns:ims="http://www.imsglobal.org/xsd/imsmd_v1p2">

  <dc:title>
    Frog maths
  </dc:title>
  <dc:identifier dcxml:scheme="URI">
    http://somewhere.com/frogmaths/
  </dc:identifier>
  <dc:description>
    Simple maths games for 5-7 year olds.
  </dc:description>
  <ims:typicallearningtime>
    <ims:datetime>
      0000-00-00T00:15
    </ims:datetime>
  </ims:typicallearningtime>
  <dc:rights>
    Permission is granted for anyone to display, copy, modify and annotate
    this software.
  </dc:rights>

  <oex:rights>
   <oex:asset>
     <oex:context>
        <odd:uid idscheme="URI">
          http://somewhere.com/frogmaths/
        </odd:uid>
     </oex:context>
   </oex:asset>
   <oex:permission>
     <odd:display/>
     <odd:modify/>
     <odd:annotate/>
   </oex:permission>
  </oex:rights>

</record>

Note that ODRL uses structural conventions (i.e. the nesting of XML elements) that are not used in the DC XML encoding proposed in this document. This may also be true for other metadata applications, such as IMS.

7. Linking between metadata records

In some cases (notably with the dc:creator, dc:contributor, dc:publisher, dc:source and dc:relation elements) it may be desirable to link between DC records or from one DC record to another metadata record. For example, when using dc:relation to indicate a relationship between the resource being described and another resource, it may be desirable to link to the metadata about the second resource. Similarly, when using dc:creator to indicate the name of the creator of a resource, it may be desirable to link to a metadata record that describes the creator more fully.

Recommendation 10. Link between related metadata records using the XML Linking Language (XLink) [XLINK]. For example:

<dc:relation xlink:type="simple"
  xlink:href="http://www.ukoln.ac.uk/intro.dc.xml" dcxml:scheme="URI">
  http://www.ukoln.ac.uk/
</dc:relation>
shows how to provide a link to an external DC record for the resource at http://www.ukoln.ac.uk/. However, links may also be internal:
<dc:creator xlink:type="simple" xlink:href="#andy">
  Andy Powell
</dc:creator>
shows how to link to a separate metadata record in the same XML document. The separate record would be named using the XML 'id' attribute, for example:
<vcard id="andy">
 ....
</vcard>

Here's a complete example from a slightly more complex metadata application:

<?xml version="1.0"?>

<metadata
  xmlns="http://myorg.org/learningapp/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://myorg.org/learningapp/ http://myorg.org/learningapp/schema.xsd"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:ims="http://www.imsglobal.org/xsd/imsmd_v1p2"
  xmlns:vcard="http://www.imc.org/vcard/3.0/">

  <resource>
    <dc:title>
      Frog maths
    </dc:title>
    <dc:creator xlink:type="simple" xlink:href="#andy">
      Andy Powell
    </dc:creator>
    <dc:identifier>
      http://somewhere.com/frogmaths/
    </dc:identifier>
    <dc:description>
      Simple maths games for 5-7 year olds.
    </dc:description>
    <ims:typicallearningtime>
      <ims:datetime>
        0000-00-00T00:15
      </ims:datetime>
    </ims:typicallearningtime>
  </resource>

  <person id="andy">
    <vcard:fn>
      Andy Powell
    </vcard:fn>
    <vcard:org>
      UKOLN, University of Bath
    </vcard:org>
    <vcard:email>
      a.powell@ukoln.ac.uk
    </vcard:email>
  </person>
</metadata>

Note that this example uses an outer <metadata> container and inner <resource> and <person> containers. The advantage of this approach is that it allows a single XML document to contain multiple metadata records.

8. Example XML schemas

A set of base XML schemas and example schemas that support the examples in this document are available separately [SCHEMAS]. It is hoped that the base XML schemas will be hosted on the DCMI Web site in order that they can be easily imported into application-specific schemas.

References

[DCMI] Dublin Core Metadata Initiative
http://dublincore.org/

[XML] Extensible Markup Language (XML)
http://www.w3.org/XML/

[DCMES] Dublin Core Metadata Element Set, Version 1.1: Reference Description
http://dublincore.org/documents/dces/

[DCQ] Dublin Core Qualifiers
http://dublincore.org/documents/dcmes-qualifiers/

[RDF] Resource Description Framework (RDF)
http://www.w3.org/RDF/

[DCARCH] DCMI Architecture Working Group
http://dublincore.org/groups/architecture/

[XMLSCHEMA] XML Schema
http://www.w3.org/XML/Schema

[XMLNS] Namespaces in XML
http://www.w3.org/TR/1999/REC-xml-names-19990114/

[DCMINS] Namespace Policy for the Dublin Core Metadata Initiative (DCMI)
http://dublincore.org/documents/dcmi-namespace/

[IMS] IMS Learning Resource Meta-data Information Model - Version 1.2 Final Specification
http://www.imsglobal.org/metadata/imsmdv1p2/imsmd_infov1p2.html

[ODRL] The Open Digital Rights Language Initiative
http://odrl.net/

[XLINK] XML Linking Language (XLink) Version 1.0
http://www.w3.org/TR/xlink/

[SCHEMAS] Example Dublin Core XML Schemas
http://www.ukoln.ac.uk/metadata/dcmi/dcxml/examples.html


Web page by: Andy Powell
Last updated: 05-Mar-2003