Global navigation options:	Home	Metadata Basics	DCMI Specifications	Community and Events	Join/Support	About Us

Search:

Revisions to DCMI Metadata Terms

Table of contents

1. About the proposed revisions
2. Types of revisions
3. Revisions, term by term
References

1. About the proposed revisions

The document proposes a set of editorial revisions to terms in the set of DCMI Metadata Terms [DCTERMS]. The proposed changes are summarized in Section 2 and detailed, term by term, in Section 3. This proposal should be considered in conjunction with a separate but related proposal, "Domains and Ranges for DCMI Properties", which proposes a set of classes for assignment as domains and ranges of DCMI properties [DOMAINS].

This document follows on an earlier revision of terms in the Dublin Core Metadata Element Set (DCMES) [DCMES-CHANGES], which was undertaken in order to clarify intended semantics and bring the wording of definitions and usage comments into line with the language of the DCMI Abstract Model [DCAM].

After a Public Comment period, the changes described here will be finalized by the DCMI Usage Board, then published in revised versions of the Web documents "DCMI Metadata Terms" [DCTERMS] and "DCMI Metadata Terms: A complete historical record" [DCTERMS-HISTORY].

All of the changes proposed here have been evaluated by the DCMI Usage Board in light of the DCMI Namespace Policy [NAMESPACE]. The namespace policy says that DCMI terms are identified using Uniform Resource Identifiers (URIs). In accordance with the principle that distinct URIs should be assigned to distinct resources, the policy sets limits on the range of editorial changes that may allowably be made to the official labels, definitions, and usage comments associated with DCMI terms. By policy, any changes of meaning judged "likely to have a substantial impact on either machine processing of DCMI terms or the functional semantics of the terms" must trigger the creation of a new, distinct term with a new, distinct URI.

In the opinion of the Usage Board, the changes described in this document are unlikely to have a substantial impact on either machine processing of DCMI terms or the functional semantics of the terms -- i.e., they fall within the allowable range of editorial change. The changes constitute clarifications of term semantics in light of improved theoretical understanding, user feedback, and implementation experience. They are intended to provide the final twist of the lens that brings intended meanings more sharply into focus.

2. Types of revisions

Free-standing descriptive labels

When terms such as dcterms:available were first coined as "Dublin Core qualifiers" in 2000 [QUALIFIERS], it was not yet entirely clear whether qualifiers were intended to be used like adjectives -- i.e., in conjunction with the Dublin Core elements they modified -- or as elements in their own right. The labels assigned at the time, such as "Available", suggest the former, but DCMI grammatical principles, and later the Abstract Model, clearly evolved to the latter. The terms dcterms:alternative, dcterms:available, dcterms:created, dcterms:issued, dcterms:modified, dcterms:valid, dcterms:spatial, and dcterms:temporal have been re-named with free-standing names such as "Date created" (instead of just "Created") and "Alternative Title" instead of just "Alternative").

The phrase "content of the resource"

As described in [DCMES-CHANGES], wordings which distinguish the "content of" a resource have been revised to refer directly to a resource. In the current batch, this change is relevant to the definitions of: dcterms:abstract, dcterms:tableOfContents, dcterms:isFormatOf, dcterms:hasFormat, dcterms:spatial, dcterms:temporal, dcterms:DCMIType, and dcterms:requires.

The phrase "reference to a resource"

Definitions which specify encoding practice with phrases such as "reference to a resource" have been revised as described in [DCMES-CHANGES]. This change is relevant to the definition of dcterms:conformsTo. Note, however, that the definition of dcterms:bibliographicCitation remains "A bibliographic reference for the resource".

The phrase "use a controlled vocabulary"

It is now generally recommended that controlled vocabularies be used in metadata, so specific usage advice along these lines has been removed from the comments dcterms:accrualMethod, dcterms:accrualPeriodicity, and dcterms:accrualPolicy.

Types of "encoding schemes"

The revised DCMI Abstract Model [DCAM] draws a clear distinction between Vocabulary Encoding Schemes and Syntax Encoding Schemes. Existing terms hitherto classified as "encoding schemes" have been designated in this batch of revisions, more specifically, as Vocabulary Encoding Schemes (dcterms:DCMIType, dcterms:DDC, dcterms:IMT, dcterms:LCC, dcterms:LCSH, dcterms:MESH, dcterms:NLM, dcterms:RFC4646, dcterms:TGN, and dcterms:UDC) or Syntax Encoding Schemes (dcterms:Box, dcterms:ISO3166, dcterms:ISO639-2, dcterms:Period, dcterms:Point, dcterms:RFC1766, dcterms:RFC3066, dcterms:URI, and dcterms:W3CDTF).

Encoding scheme definitions

In accordance with the differentiation of encoding schemes into Vocabulary Encoding Schemes and Syntax Encoding Schemes, the Usage Board has revised their definitions to make clear how the encoding schemes are being seen and interpreted from a modeling point of view:

• as a set of concepts: dcterms:IMT, dcterms:LCSH, dcterms:MESH, dcterms:DDC, dcterms:LCC, dcterms:UDC, dcterms:DCMIType, dcterms:NLM
• as a set of codes: dcterms:ISO639-2, dcterms:ISO3166
• as a set of tags: dcterms:RFC1766
• as a set of identifiers: dcterms:URI
• as a set of regions in space: dcterms:Box
• as a set of places: dcterms:TGN
• as a set of time intervals: dcterms:Period
• as a set of dates and times: dcterms:W3CDTF

A thorough discussion of these interpretations is beyond the scope of this document and will be undertaken by the Usage Board in a separate note.

Definitions versus Comments

Parts of some term Definitions have been moved into Comments, as with dcterms:isVersionOf, dcterms:dateAccepted, and dcterms:dateSubmitted.

Relation of a property to a "described resource"

Some definitions have revised to make clear how a property relates to the "described resource" (dcterms:instructionalMethod, dcterms:isVersionOf, dcterms:isReplacedBy, dcterms:replaces, dcterms:isRequiredBy, dcterms:requires, dcterms:isPartOf, dcterms:hasPart, dcterms:isReferencedBy, dcterms:references, dcterms:isFormatOf, and dcterms:hasFormat).

References to IETF Requests for Comment (RFCs)

Some term declarations make reference to "Request for Comment" (RFC) standards maintained by The Internet Engineering Task Force (IETF). When RFC standards are updated, their numbers change, and the newer standard (with a higher number) obsoletes the older standard. In this batch of revisions, references to RFCs have been updated:

• for dcterms:URI, RFC 3986 has obsoleted RFC 2396
• for dcterms:language, RFC 4646 has obsoleted RFC 3066

DCMI encoding schemes that designate RFCs

Existing encoding schemes declared by DCMI in reference to specific RFCs -- dcterms:RFC1766 and dcterms:RFC3066 -- are interpreted in this batch of proposed changes as Syntax Encoding Schemes. Since RFC 3066 has been obsoleted by RFC 4646, however, this batch of revisions includes the proposal for a new DCMI encoding scheme, dcterms:RFC4646, which is interpreted to be a Vocabulary Encoding Scheme.

Revisions in response to the five-year review for NISO Z39.85-2007

A five-year review of ANSI/NISO Z39.85 (The Dublin Core Metadata Element Set) was held, resulting in the revised standard ANSI/NISO Z39.85-2007 in May 2007 [NISOZ39-85]. This batch of revisions includes minor changes of wording undertaken in response to comments (dcterms:source, dcterms:subject, dcterms:language, and dcterms:coverage). In response to the comment that the Comment for dcterms:title was potentially misleading, the Usage Board decided to delete the comment altogether.

The statement "qualifies:"

When "Dublin Core qualifiers" were first published in 2000 [QUALIFIERS], encoding schemes were associated with specific elements -- e.g., dcterms:LCSH with dc:subject. In light of subsequent work on the DCMI model, however, the association between a property and a Vocabulary Encoding Scheme or Syntax Encoding Scheme is seen as something more appropriately declared in an application profile than in the formal declaration of a vocabulary. "Qualifies:" statements have therefore been removed from the term descriptions for dcterms:DDC, dcterms:LCC, dcterms:UDC, dcterms:DCMIType, dcterms:IMT, dcterms:ISO639-2, dcterms:RFC1766, dcterms:URI, dcterms:Point, dcterms:ISO3166, dcterms:Box, dcterms:TGN, dcterms:Period, dcterms:W3CDTF, dcterms:RFC3066, dcterms:NLM, dcterms:LCSH, and dcterms:MESH. Methods for the formal expression of such an association in the RDF schemas published by DCMI were never finalized as a DCMI Recommendation [DCQ-RDF] and have since been superseded by new guidelines for expressing Dublin Core metadata in RDF [DC-RDF], as discussed in [DC-RDF-NOTES].

SubjectScheme and other "undeclared" members of the TERMS namespace

It is worth noting that since March 2000, seven classes with URIs based on http://purl.org/dc/terms/ (the "TERMS" namespace) have been used in RDF schemas published by DCMI. These classes were dcterms:DateScheme, dcterms:FormatScheme, dcterms:IdentifierScheme, dcterms:LanguageScheme, dcterms:SpatialScheme, dcterms:SubjectScheme, and dcterms:TypeScheme. These classes were added to the RDF expressions on the basis of "qualfies:" statements (see above) as part of an automatic routine for generating updated documentation for DCMI terms. At the time, the classes served to associate a set of encoding schemes with a particular property (e.g., to associate dcterms:LCSH with dc:subject). Since the terms were never officially declared (outside of their undocumented use in the RDF schemas), DCMI does not consider them to fall under the DCMI Namespace Policy [NAMESPACE]. With the removal of the "qualifies:" statements and the revision of guidelines for expressing Dublin Core metadata in RDF (see above), these undeclared classes will cease to be used in DCMI term declarations.

New terms related to the DCMI Abstract Model

Addition of domains and ranges for existing properties and creation of new properties

A separate document, "Domains and ranges for DCMI properties" [DOMAINS], proposes a vocabulary of classes for use as formal domains and ranges of DCMI properties. Domains and ranges specify -- in a form usable for inferencing -- what kind of described resources and value resources are associated with a given property. The assignment of formal domains and ranges makes the meanings implicit in natural-language definitions available for machine processing. So as not to affect the conformance of existing implementations of Simple Dublin Core in RDF, domains and ranges will not be specified for the fifteen properties of the Dublin Core Metadata Element Set (DCMES), Version 1.1, which are identified by URIs in the DCMI namespace http://purl.org/dc/elements/1.1/ . Rather, the document proposes to define fifteen new properties, which will be identified by URIs in the DCMI namespace http://purl.org/dc/terms/ . Each of the fifteen new properties is to be a subproperty of the corresponding property of the DCMES, and is to be assigned domain and range as outlined in the proposal.

Subproperty relations between terms in "the Dublin Core"

The original thirteen (later fifteen) elements of "the Dublin Core" were originally intended to serve as a self-contained template for simple descriptions. It was soon noticed that some of the fifteen elements semantically fit within the scope of others, but a typological distinction between "elements" and "qualifiers" made it seem confusing to declare some elements to be subproperties of others. The DCMI Abstract Model no longer makes such a typological distinction, so the current batch of revisions includes assertions of dcterms:creator as a sub-property of dcterms:contributor and of dcterms:source as a sub-property of dcterms:relation. As with the assignment of domains and ranges, so as not to affect the conformance of existing implementations, these assertions are made only for the newly created properties, identified by URIs in the DCMI namespace http://purl.org/dc/terms/ . No such assertions are made for the existing properties of the DCMES.

Comments deleted

In addition to the Comment for dcterms:title, other Comments were found to be no longer useful and simply deleted (dcterms:audience, dcterms:license dcterms:rightsHolder, dcterms:accrualMethod, dcterms:accrualPeriodicity, dcterms:accrualPolicy).

Special cases

Editorial revision has sometimes involved deciding among different possible interpretations (e.g., dcterms:educationLevel) and minor clarifications of wording too subtle to merit separate explanations (e.g., dcterms:accessRights). Section 3 lists old and new versions side-by-side so that readers may judge for themselves.

3. Revisions, term by term

References

[DCAM]
Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston and Thomas Baker. DCMI Abstract Model. DCMI Proposed Recommendation. February 2007.
<http://dublincore.org/documents/2007/02/05/abstract-model/>

http://dublincore.org/documents/dc-rdf/

http://dublincore.org/documents/dc-rdf-notes/

http://dublincore.org/usage/decisions/2006/2006-03.dcmes-changes.shtml

http://dublincore.org/documents/dcmi-terms/

http://dublincore.org/usage/terms/history/

http://dublincore.org/documents/2002/05/15/dcq-rdf-xml/

http://dublincore.org/documents/2007/07/02/domain-range/

http://dublincore.org/documents/dcmi-namespace/

http://www.niso.org/standards/resources/Z39-85-2007.pdf

Errata 2007-11-20: corrected URI displayed as Identifier (was incorrectly shown as http://dublincore.org/usage/public-comment/documents/2007/07/dcterms-changes/; URI for href was already correct). Corrected broken "li" tags in section "Encoding scheme definitions".