UKOLN, University of Bath
This discussion paper considers some of the issues related to bringing together the use of DC metadata and ODRL. It takes a DCMI-centric view, since, of the two standards, DC is the one with which the author has most familiarity. It starts with a summary of the capabilities of DC metadata and then presents some potential use cases that describe how the combined use of DC and ODRL may benefit the end-user.
Finally, it outlines some of the issues that the ODRL-DCMI working group will have to address.
DCMI provides a growing set of metadata terms (elements, element refinements, encoding schemes and controlled vocabularies) and three encoding syntaxes (XHTML, XML and RDF) that allow those terms to be used in a wide variety of resource discovery applications. These are underpinned by the DCMI Abstract Model, which provides a description of the key entities that make up DC metadata records.
A number of DCMIs terms are valid in the context of encoding rights-related information. These are summarised here:
URI: http://purl.org/dc/elements/1.1/contributor Label: Contributor Definition: An entity responsible for making contributions to the content of the resource. Comment: Examples of a Contributor include a person, an organisation, or a service. Typically, the name of a Contributor should be used to indicate the entity. Type of Term: element Status: recommended Date Issued: 1999-07-02
URI: http://purl.org/dc/elements/1.1/creator Label: Creator Definition: An entity primarily responsible for making the content of the resource. Comment: Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity. Type of Term: element Status: recommended Date Issued: 1999-07-02
URI: http://purl.org/dc/elements/1.1/publisher Label: Publisher Definition: An entity responsible for making the resource available Comment: Examples of a Publisher include a person, an organisation, or a service. Typically, the name of a Publisher should be used to indicate the entity. Type of Term: element Status: recommended Date Issued: 1999-07-02
URI: http://purl.org/dc/elements/1.1/rights Label: Rights Management Definition: Information about rights held in and over the resource. Comment: Typically, a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the Rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource. Type of Term: element Status: recommended Date Issued: 1999-07-02
URI: http://purl.org/dc/terms/accessRights Label: Access Rights Definition: Information about who can access the resource or an indication of its security status. Comment: Access Rights may include information regarding access or restrictions based on privacy, security or other regulations. Type of Term: element-refinement Refines: http://purl.org/dc/elements/1.1/rights Status: conforming Date Issued: 2003-02-15
URI: http://purl.org/dc/terms/dateCopyrighted Label: Date Copyrighted Definition: Date of a statement of copyright. Type of Term: element-refinement Refines: http://purl.org/dc/elements/1.1/date Status: conforming Date Issued: 2002-07-13
URI: http://purl.org/dc/terms/license Label: License Definition: A legal document giving official permission to do something with the resource. Comment: Recommended best practice is to identify the license using a URI. Examples of such licenses can be found at http://creativecommons.org/licenses/. Type of Term: element-refinement Refines: http://purl.org/dc/elements/1.1/rights Status: conforming Date Issued: 2004-06-14
URI: http://purl.org/dc/terms/provenance Label: Provenance Definition: A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity and interpretation. Comment: The statement may include a description of any changes successive custodians made to the resource. Type of Term: element Status: conforming Date Issued: 2004-09-20
URI: http://purl.org/dc/terms/rightsHolder Label: Rights Holder Definition: A person or organization owning or managing rights over the resource. Comment: Recommended best practice is to use the URI or name of the Rights Holder to indicate the entity. Type of Term: element Status: conforming Date Issued: 2004-06-14
Of these, it is worth noting that Creator, Contributor and Publisher are used to indicate an entity (an ‘agent’ in DCMI terminology) that is or was responsible for creating the resource or making it available. However, there are no guarantees about what rights any of these entities hold over the resource, since any rights once held by any of these entities may have been sold or given away or simply revoked.
It is also worth noting that Date is defined very broadly and may not indicate a date that is relevant in the context of the ‘rights’ associated with the resource.
Similarly, the Rights element is also defined very broadly and might be used to provide a variety of rights related information, for example a simple copyright statement such as “(c) University of Bath, 2005” or a link to a complex ODRL rights statement.
Provenance will typically be used to hold a human-readable description of the custodial history of the resource. This may be useful information to end-users wishing to trace the right-holding agents associated with a resource, but is unlikely to be structured sufficiently well in order that it may be usefully parsed by software applications.
In recognition of these kinds of problems, DCMI created some additional rights-related terms that are more specific in nature - Rights Holder, Date Copyrighted and Licence. For example, by combining use of the Rights Holder, Date Copyrighted, Rights and Licence it is possible to encode (in a machine-readable way) information about who holds rights over as resource, when it was copyrighted and which licence it is made available under, as follows:
<dc:rights>(c) University of Bath, 2005</dc:rights>
The fragment of XML shown here is based on the DCMI guidelines for encoding DC in XML.
Note that there is some replication of information in the metadata above between the Rights and Rights Holder elements. This is because the Rights Holder element does not specifically indicate the copyright holder and therefore the Rights element has been used to provide a more ‘traditional’ copyright statement.
Finally, it is worth noting that although the Creative Commons URI used above identifies a particular CC license, there are no guarantees about what will be made available at such a URI – there may be a machine-readable version of the licence (encoded using ODRL, XrML or some other markup language), there may be a human-readable statement about the licence, there may be the full legal text of the licence or there may be nothing. In the context of a DC metadata description, a machine-readable description about the licence under which the resource is made available is known as a ‘related description’.
This section outlines some possible use cases where the combined use of DC metadata and ODRL might be used to provide an enhanced service to the end-user. Note that these use cases are somewhat aspirational and therefore may not reflect what is currently possible in the real-world!
The encoding guidelines currently endorsed by the DCMI currently have different capabilities with respect to the DCMI Abstract Model, i.e. not all features of the model can be encoded in all the syntaxes. The RDF encoding can encode almost all aspects of the model and is therefore the richest. The XML and XHTML guidelines do not support all parts of the model. It is therefore the case that, currently, descriptions that can be encoded in one syntax may not be able to be encoded in the other syntaxes.
A very simple model of the key entities related to the combined use of DCMI metadata and ODRL may be represented as follows:
It is important to remember that the ‘value URI’ (the URI that identifies the value of a DCMI property) associated with the DC Licence property is the URI of the licence under which the resource is made available. This may or may not be the same URI as the URI of the ODRL encoding of that licence.
Finally it should be noted that these has been a recent thread on the dc-architecture mailing list about whether it is possible and/or sensible to simply merge together fragments of XML from non-DC XML applications such as ODRL with DC XML metadata records. The author is firmly of the view that it is not sensible to do this, unless the two XML fragments conform to the same underlying ‘model’, such as that provided by RDF.
Therefore, with the exception of those cases where both DC metadata and ODRL are encoded using RDF/XML, it seems more sensible consider how to link together, rather than merge, DC metadata description and ODRL documents.