Using Dublin Core™ - Dublin Core™ Qualifiers

Date Issued:	2003-08-26
Identifier:	http://dublincore.org/specifications/dublin-core/usageguide/2003-08-26/qualifiers/
Replaces:	Not Applicable
Is Replaced By:	http://dublincore.org/specifications/dublin-core/usageguide/2005-05-26/qualifiers/
Latest version:	http://dublincore.org/specifications/dublin-core/usageguide/
Translations:	http://dublincore.org/resources/translations/
Status of document:	DCMI Recommended Resource
Description of document:	This document describes the principles governing Dublin Core™ qualifiers, the two categories of qualifiers, and lists instances of qualifiers approved by the Dublin Core™ Usage Committee as well as guidance for their use.

## 5. Dublin Core™ Qualifiers

This document presents in part the results of an ongoing process to develop exemplary terms extending or refining the original 15 elements of the Dublin Core™ Metadata Element Set ( DCMES). The terms or "qualifiers" listed here were identified, generally in working groups of the Dublin Core™ Metadata Initiative, ( DCMI) and judged by the DCMI Usage Board to be in conformance with principles of good practice for the qualification of Dublin Core™ metadata elements.

In determining the makeup of these qualifiers, preference was given to vocabularies, notations, and terms already maintained by established agencies. It should be emphasized that the list of externally-maintained vocabularies identified here is a preliminary list. There are many more controlled vocabularies or classification systems that are not on this preliminary list. The DCMI has initiated a registration process, intended to be available in 2003, which will begin by registering subject vocabularies and from there extend to encoding and vocabulary schemes relevant to other elements. Until that registry is available, detail on currently recommended schemes are listed at: DCMI Encoding Schemes - a current list

Inevitably, there will be situations where an agent or client will encounter DCMES descriptions that use unfamiliar qualifiers developed by implementors for specialized local or domain-specific needs. The useful interpretation of such a DCMES description will depend on the ability of an application to ignore the unknown qualifiers and fall back on the broader meaning of the element in its unqualified form. The guiding principle for the qualification of Dublin Core™ elements, colloquially known as the "Dumb-Down Principle," is that a client should be able to ignore any qualifier and use the information as if it were unqualified. While this may result in some loss of specificity, the remaining element value (without the qualifier) should continue to be generally correct and useful for discovery.

It is expected that implementors will develop additional qualifiers for use within local applications or specific domains. Such qualifiers may not be understood by other applications. However, qualifiers that conform to the principles of qualification defined here are more likely to be reusable by other communities within the broader context of cross-domain discovery.

At the time of the ratification of this document, the DCMI recognizes two broad classes of qualifiers:

Element Refinement. These qualifiers make the meaning of an element narrower or more specific. A refined element shares the meaning of the unqualified element, but with a more restricted scope. A client that does not understand a specific element refinement term should be able to ignore the qualifier and treat the metadata value as if it were an unqualified (broader) element. The definitions of element refinement terms for qualifiers must be publicly available.
Encoding Scheme. These qualifiers identify schemes that aid in the interpretation of an element value. These schemes include controlled vocabularies and formal notations or parsing rules. A value expressed using an encoding scheme will thus be a token selected from a controlled vocabulary (e.g., a term from a classification system or set of subject headings) or a string formatted in accordance with a formal notation (e.g., "2000-01-01" as the standard expression of a date). If an encoding scheme is not understood by a client or agent, the value may still be useful to a human reader. The definitive description of an encoding scheme for qualifiers must be clearly identified and available for public use.

All of the qualifiers listed in this document fall into one of these two categories. Specific guidance is given below for element refinements. If a particular encoding scheme is available for the element and or/element refinement, its application is generally described either in this document or in documentation available with the encoding scheme itself. Audience, which is at the element level but not one of the original 15 elements, is described along with the other elements.

Additional qualifier categories may evolve over time and with implementation experience. The qualifiers listed here do not constitute a closed set, designed to meet all of the descriptive needs of implementors. Rather, they form the foundation for a larger body of qualifiers that will evolve as additional qualifiers are developed by various communities, some of which may eventually be submitted to the DCMI Usage Board for review and approval. Implementors may deploy the qualifiers on these lists with confidence that they conform to the Dumb-Down Principle, and are encouraged to use these qualifiers as examples to guide development of local qualifiers for Dublin Core™ metadata elements.

Summary Refinement and Scheme Table

This summary of the element refinements and schemes is provided for the convenience of users. Terms in this summary may have the status of "recommended" or "conforming." The reference definitions and status indications may be found in DCMI Terms. Click on the term to go directly to the reference definition for that term.

DCMES Element	Element Refinement(s)	Element Encoding Scheme(s)
Title	Alternative	-
Creator	-	-
Subject	-	LCSH MeSH DDC LCC UDC
Description	Table Of Contents Abstract	-
Publisher	-	-
Contributor	-	-
Date	Created Valid Available Issued Modified Date Copyrighted Date Submitted	DCMI Period W3C-DTF
Type	-	DCMI Type Vocabulary
Format	-	IMT
	Extent	-
	Medium	-
Identifier	-	URI
Identifier	Bibliographic Citation	-
Source	-	URI
Language	-	ISO 639-2 RFC 3066
Relation	Is Version Of Has Version Is Replaced By Replaces Is Required By Requires Is Part Of Has Part Is Referenced By References Is Format Of Has Format Conforms To	URI
Coverage	Spatial	DCMI Point ISO 3166 DCMI Box TGN
Coverage	Temporal	DCMI Period W3C-DTF
Rights	Access Rights	-
Audience	Mediator Education Level	-

Properties of Dublin Core™ Qualifiers

Dublin Core™ qualifiers have the following properties:

Name: The unique token assigned to the qualifier.
Label: The human-readable label assigned to the qualifier.
Definition: A statement that represents the concept and essential nature of the qualifier.
Comment: Additional information associated with the qualifier (if available).
See Also: A link to more information about the qualifier (if available).

For the up-to-date specification of all metadata terms maintained by the Dublin Core™ Metadata Initiative, including elements, element refinements, encoding schemes, and vocabulary terms (the DCMI Type Vocabulary), see http://dublincore.org/specifications/dublin-core/dcmi-terms/. In the listing below, the Name and Label attributes are the same as in the specification, but the Definition and Comment appear together as "Term Description", and guidance and examples are added.

Multiple Language Encodings of Dublin Core™ Entities

Dublin Core™ qualifiers will be expressed in languages other than English. A single invariant token assigned to each qualifier -- the Name property -- stands for a given qualifier concept irrespective of the language in which it is defined. This token can be incorporated into a URI to form a unique identifier for the qualifier. All other properties of a qualifier (Label, Definition, Comment, and aspects of See Also as appropriate) can be translated from English into any other language.

All other properties of Dublin Core™ entities (Label, Definition, Comment, and aspects of See Also as appropriate) will be expressed in the language and character set of the translation.

These element refinement terms are extensions to the "Simple Dublin Core™" 15 elements or to the additional element term Audience.

Alternative

Label: Alternative

Term description: Any form of the title used as a substitute or alternative to the formal title of the resource. This qualifier can include Title abbreviations as well as translations.

Guidelines for creation of content:

An alternative title can be used to provide access to secondary titles, but should only be used when a value is present in the Title element.

Examples:

Alternative="AMA newsletter" (Title="American Meteorological Association newsletter")
Alternative="Ocho semanas" (Title="Eight weeks")

tableOfContents

Label: Table of Contents

Term description: A list of subunits of the content of the resource.

Guidelines for creation of content:

When a description of a resource consists of a list of the contents, whether from a menu or other mechanism, tableOfContents can be used to differentiate this list from descriptive text that is written in sentence form. This allows more options for display and indexing.

Examples:

tableOfContents="Introduction; Vertebrates; Invertebrates; Molluscs"

Abstract

Label: Abstract

Term description: A summary of the content of the resource.

Guidelines for creation of content:

Used when a description of a resource consists of a formal abstract. For implementations where formal abstracts are preferred, using the specific term allows the label to better reflect the level of the description.

Examples:

Abstract="This article describes the work of the IFB Chaos Committee, including a summary of its major findings."

Date refinements are generally useful in situations where more than one date is needed, and the difference between the dates may be important to users. Note that the first five Date refinement terms were among the earlier ones approved by DCMI, and the naming convention of the time was not to include "date" as part of the refined term. The most recent ones reflect changes in the naming convention used, in which the name of the refined term expresses more clearly the relationship to the parent element.

Created

Label: Created

Term description: Date of creation of the resource.

Guidelines for creation of content:

If the date of creation of the resource is known, and that date is important to note specifically (e.g., there are other relevant dates to record), use the term Created for the creation date of the resource. Note that the "one-to-one" rule requires that the creation date be that of the resource being described, not any early version from which the current resource is derived.

Valid

Label: Valid

Term description: Date (often a range) of validity of a resource.

Guidelines for creation of content:

If the resource is only valid or relevant for a particular date or range of dates, the term Valid may be used to express those dates. This may be particularly important if the resource will be retained over time but its use is valid only during a particular period or until a particular date.

Available

Label: Available

Term description: Date (often a range) that the resource will become or did become available.

Guidelines for creation of content:

In general, the term Available should be used in the case of a resource for which the date of availability may be distinct from the date of creation, and the date of availability is relevant to the use of the resource.

Issued

Label: Issued

Term description: Date of formal issuance (e.g., publication) of the resource.

Guidelines for creation of content:

The term Issued should be applied when a formal date of issuance or publication is relevant to the resource, and is distinct from other dates that may be used with the resource.

Modified

Label: Modified

Term description: Date on which the resource was changed.

Guidelines for creation of content:

Modified dates may be used to record either all instances of modification or only the latest. When only one modified date is recorded, it is assumed to be the latest.

dateAccepted

Label: Date Accepted

Term description: Date of acceptance of the resource (e.g. of thesis by university department, of article by journal, etc.).

Guidelines for creation of content:

If, in the lifecycle of a resource, the date of acceptance by a formal body or entity is relevant to the use of the resource, dateAccepted may be used.

dateSubmitted

Label: Date Submitted

Term description: Date of submission of the resource (e.g. thesis, articles, etc.).

Guidelines for creation of content:

If, in the lifecycle of a resource, the date of submission to a body or entity is relevant to the use of the resource, dateSubmitted may be used.

Extent

Label: Extent

Term description: The size or duration of the resource.

Guidelines for creation of content:

Because the refinement Extent is used in a variety of situations, it generally consists of both a numeric value and a caption that is needed to interpret the numeric value. Best practice is to separate the numeric value and the caption with a space, whether the caption appears before or after the value.

Examples:

Extent="folio"
Extent="899 Kb"
Extent="21 minutes"

Medium

Label: Medium

Term description: The material or physical carrier of the resource.

Guidelines for creation of content:

Medium is generally used when the resource is of a physical nature, for instance a painting or model, where the physical carrier or material used is relevant to the user. For instance, if the resource is a movie on DVD, and is only available as a physical object, it should be described as such. If it is available digitally, its format would be reflected in the Format element.

Examples:

Medium="cotton fabric with sequins"
Medium="bronze on wooden pedestal"
Medium="oil on wood"

Most of the refinements of Relation are expressed as "reciprocals" and may be used to link resources in two directions, though this is not required. Implementors need not describe both or all resources involved in a reciprocal relationship to express the relationship--in other words, they may describe a later version and relate it to the earlier without having the need or opportunity to describe the earlier, and vice versa. In some of the relationships below, maintaining reciprocality is more important. In others, one direction of the relationship is more relevant that the other. These differences will be mentioned in the guidelines for specific terms.

In All cases, either a string or a URI may be used as a value. If a URI is used, the scheme should be designated.

Examples for Relation refinements can be found with the Relation element. When using Relation refinements, do not use embedded text labels, as the examples illustrate.

isVersionOf

Label: Is Version Of

Term description: The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.

Guidelines for creation of content:

Use only in cases where the relationship expressed is at the content level. Relationships need not be close for the relationship to be relevant. "West Side Story" is a version of "Romeo and Juliet" and that may be important enough in the context of the resource description to be expressed using isVersionOf. The Broadway Show and the movie of "West Side Story" also relate at a similar level, but the video and DVD of the movie are more usefully expressed at the level of format, the content being essentially the same.

See also isVersionOf.

hasFormat

Label: Has Format

Term description: The described resource pre-existed the referenced resource, which is essentially the same intellectual content presented in another format.

Guidelines for creation of content:

See isFormatOf for basic guidelines.

conformsTo

Label: Conforms To

Term description: A reference to an established standard to which the resource conforms.

Guidelines for creation of content:

The standards referenced might be educational standards, accessibility standards, or any other established standard that is relevant to the use of the resource.

Spatial

Label: Spatial

Term description: Spatial characteristics of the intellectual content of the resource.

Guidelines for creation of content:

Spatial characteristics may include geographic names, latitude/longitude, or other established georeferenced values. Clearly, this refinement does not allow complex or sophisticated georeferencing, but attention to standard schemes and controlled vocabularies should provide useful results. Controlled vocabulary terms can be drawn from recommended vocabularies, or standard labelling within the value can provide useful assistance to users and applications. For additional information on encoding spatial information see the DCMI Box Encoding Scheme and the DCMI Point Encoding Scheme.

Examples:

Spatial="Chicago, Ill."
Spatial="Lat: 44 00 00 S Long: 068 00 00 W Name:Patagonia"
Spatial="Upstate New York"

Temporal

Label: Temporal

Term description: Temporal characteristics of the intellectual content of the resource.

Guidelines for creation of content:

Temporal characteristics include those aspects of time that relate to the intellectual content of a resource and not its lifecycle. Examples might include a resource describing some aspect of the 19th century but itself created this year. In that case, the Temporal Coverage would be the 19th century, and the Date (or Date Created) would be 2003. Values can be text strings or encoded values. Specific suggestions for encoding Temporal characteristics may be found in the DCMI Period Encoding Scheme.

Examples:

Temporal="Jurassic Period"
Temporal="1922-1978"
Temporal="Twentieth Century"

Mediator

Label: Mediator

Term description: A class of entity that mediates access to the resource and for whom the resource is intended or useful. The audiences for a resource are of two basic classes: (1) an ultimate beneficiary of the resource, and (2) frequently, an entity that mediates access to the resource. The mediator element refinement represents the second of these two classes.

Guidelines for creation of content:

In an educational setting, a teacher might be designated the Mediator for a resource intended for use by a teacher in a classroom of students of a particular level or sharing other similar characteristics. Resources intended to be used directly by those same students would not include a Mediator. Mediators may be expressed in more or less specific terms, depending on the needs of the implementation. Controlled vocabularies can be useful in distinguishing Mediators.

Examples:

Mediator="Reading specialist"
Mediator="ESL teachers"

educationLevel

Label: Education Level

Term description: A general statement describing the education or training context. Alternatively, a more specific statement of the location of the audience in terms of its progression through an education or training context.

Guidelines for creation of content:

Commonly, this term would be used for a grade level for materials intended for an educational setting. Although no specific controlled vocabulary has been recommended for use with educationLevel, consistent use of terminology or reliance on an available controlled vocabulary enables more consistent results.

Examples:

educationLevel="elementary school students"
educationLevel="4th-5th grade"
educationLevel="secondary science"

accessRights

Label: Access Rights

Term description: Information about who can access the resource or an indication of its security status. Access Rights may include information regarding access or restrictions based on privacy, security or other regulations.

Guidelines for creation of content:

Access rights is intended to allow the characterization of restrictions to view, search or use resources, based on attributes of the resource itself or the class or category of user. An example would be a resource that was restricted to users holding a particular security clearance, or one that required login or authentication at a particular website.

Examples:

accessRights="Available to subscribers only."
accessRights="Viewable by Medium security cleared staff only."

bibliographicCitation

Label: Bibliographic Citation

Term description: A bibliographic reference for the resource. Recommended practice is to include sufficient bibliographic detail to identify the resource as unambiguously as possible, whether or not the citation is in a standard form.

Guidelines for creation of content:

Because this term is not describing a relationship to another resource, it should be limited to citations to the resource described in the remainder of the record. For instance, if the resource is an article for a journal, it is appropriate to include very specific information about the article, even page references, if such information is used to cite the article in a standard format for reference by other resources, even if the article being described is in a digital format.

Examples:

bibliographicCitation="ESOP, v.2, no. 1, Apr. 2003, p. 5-8"
bibliographicCitation="Nature, v.87, p. 200"

Using Dublin Core

Using Dublin Core™ - Dublin Core™ Qualifiers

Summary Refinement and Scheme Table

Properties of Dublin Core™ Qualifiers

Multiple Language Encodings of Dublin Core™ Entities

Element Refinements

Refinement(s) for element: Title

Refinement(s) for element: Description

Refinement(s) for element: Date

Refinement(s) for element: Format

Refinement(s) for element: Relation

Refinement(s) for element: Coverage

Refinement(s) for element: Audience

Refinement(s) for element: Rights

Refinement(s) for element: Identifier