The document has been updated as a result of discussions at DC5 in Helsinki in October 1997. It may be replaced in the near future by the report of the DC5 Subelement Working Group, which discussed the type qualifier. This document also includes information on the scheme qualifier. The concept of a registry was discussed at DC4, which would need to be established and would maintain any qualifier list.
This document deals only with the qualifiers "scheme" and "type". A scheme qualifier is used to interpret the value in the content and is generally based on external standards. A type qualifier refines the definition of the data element itself.
Two principles were agreed upon at the DC4 meeting in Canberra relating to the type qualifier (also known as Dublin Core subelement):
If a Dublin Core subelement does not meet these principles, then an extensibility mechanism may be used (i.e., indicate the extensible element set from which the qualifier came). In this case the metadata would not be regarded as falling within the Dublin Core list of elements.
Further principles for subelements were established at DC5, which will be reported in the Subelement Working Group report. There was little discussion about scheme qualifiers, so that information in this document is preliminary.
Following is a list of qualifiers ("core qualifiers") which is an intermediate approach between the minimalist approach of using no or few qualifiers and the more complex approach in Dublin Core Qualifiers by Jon Knight and Martin Hamilton. The latter document has been heavily used, but the number of qualifiers is considerably lessened here.
Definitions are taken from the Weibel/Kunze/Lagoze RFC Dublin Core Metadata Element Set: Reference Description (as updated 2 October 1997). All qualifiers are optional. The default for "scheme" is nothing (it is not controlled by any standard). The default for "type" is the definition of the element iteself. If the default is used, no qualifier is given.
SCHEME: not necessary
2. Author or Creator
The person(s) or organization(s) primarily responsible for the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources.
3. Subject and Keywords
The topic of the resource. Typically, subject will be expressed as keywords or phrases that describe the subject or content of the resource. The use of controlled vocabularies and formal classification schemas is encouraged.
A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources.
The entity responsible for making the resource available in its present form, such as a publishing house, a university department, or a corporate entity.
SCHEME: not necessary
6. Other Contributor
A person or organization not specified in a creator element who has made significant intellectual contributions to the resource but whose contribution is secondary to any person or organization specified in a creator element (for example, editor, transcriber, and illustrator).
Date associated with the creation or availability of the resource.
NOTE that this definition was changed at DC5. The date can be a single date or a range of dates.
8. Resource Type
The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. For the sake of interoperability, type should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document. See http://sunsite.berkeley.edu/Metadata/types.h tml for current thinking on the application of this element.
SCHEME: not necessary, but an enumerated list of types is.
The data format of the resource, used to identify the software and possibly hardware that might be needed to display or operate the resource. For the sake of interoperability, format should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document.
10. Resource Identifier
String or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers,such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element in the case of off-line resources.
A string or number used to uniquely identify the work from which this resource was derived, if applicable. For example, a PDF version of a novel might have a source element containing an ISBN number for the physical book from which the PDF version was derived.
Language(s) of the intellectual content of the resource. Where practical, the content of this field should coincide with RFC 1766. See: http://ds.internic.net/rfc/rfc1766.txt
Relationship to other resources. The intent of specifying this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. A formal specification of RELATION is currently under development. Users and developers should understand that use of this element should be currently considered experimental.
The spatial and/or temporal characteristics of the resource. Formal specification of coverage is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
SCHEME: To be determined by Coverage Working Group
TYPE: The following were determined by the Coverage Working Group. More information is in http://www.sdc.ucsb.edu/~mary/coverage. htm
15. Rights Management
A link to a copyright notice, to a rights-management statement, or to a service that would provide information about terms of access to the resource. Formal specification of rights is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.