Dublin Core Qualifiers/Substructure

Rebecca Guenther

Last updated: 15 October 1997

Introduction.


The following proposes a core set of qualifiers for the Dublin Core element set. It attempts to find a middle ground between the "minimalists" (those wanting a minimum of DC qualifiers and substructure if any) and the "structuralists" (those wanting more precision in refinement of the elements for searching).

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.

Proposed Dublin Core Qualifiers/Subelements


1. Title
The name given to the resource by the CREATOR or PUBLISHER.

SCHEME: not necessary

TYPE:


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.

SCHEME:


TYPE: Note that qualifiers listed in the Knight/Hamilton document extend the element rather than refine it (e.g., postal, phone, fax, affiliation, etc.). Only address is included here because it has been used frequently in current metadata projects. Email may be considered an alternative way of specifying the author. If other qualifiers are needed (e.g. affiliation), they should be used as local extensions.

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.

SCHEME:


The above are the most frequently used. The scheme could point to the controlled list maintained by the Library of Congress in the USMARC Code List for Relators, Sources, Description Conventions, which includes many others (Part III: Classification Sources and Part IV: Subject/Index Term Sources; these documents are currently under revision for a new edition). Many locally defined thesauri or classification schemes are possible.

TYPE: not necessary

4. Description
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.

SCHEME:


TYPE: not necessary

5. Publisher
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
TYPE:


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).

SCHEME:


TYPE:
At DC4 it was decided that role was not needed. It has thus not been included here. If needed, it could be included as a local extension. (At the Library of Congress, we have found that names are all searched in the same index and there is no need to further specify role in the work. We ceased to indicate this in bibliographic records a long time ago.)

7. Date
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.

SCHEME:


TYPE: Note that the names of the subelements have not been agreed upon. The Date Working Group continues to work on these. There was some controversy at the end of DC5 as to whether the first two type subelements should be combined. It was also uncertain whether to include the last three subelements.

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.

9. Format
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.

SCHEME:


TYPE: not necessary

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.

SCHEME:


TYPE: Not necessary

11. Source
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.

SCHEME:


TYPE: not necessary

12. Language
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

SCHEME:


TYPE: Not necessary
Note that the current ISO 639 (to become ISO 639-1 when ISO 639-2 3-character code is approved), which is used in RFC 1766, covers only about 140 languages as compared with the newly developed standard ISO 639-2, which includes about 400 languages. (For instance, ISO 639-1 does not distinguish ancient languages from modern languages.) Many agencies will need the larger more extensive list that ISO 639-2 provides. ISO 639-2 was approved in 1997; approval of the Final Draft International Standard is forthcoming followed by publication by ISO. Note that ISO 639-2 includes a bibliographic set (ISO 639-2/B) and a terminologic set (ISO 639-2/T); the bibliographic set is preferred for metadata because of its widespread use in bibliographic agencies. The new standard is closer to Z39.53 than to ISO 639-1.

13. Relation
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.

SCHEME:


TYPE: This element is considered to be developing rapidly within the context of collection-level descriptions. Subelements may be defined at a later date. The following Relation categories were enumerated at DC5; these should not be considered formal subelement names:

14. Coverage
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.
SCHEME:


TYPE: Not necessary; subelements are implementation specific.