[Mirrored from: http://www.loc.gov/marc/dcqualif.html]
The document should be considered a "strawman" proposal to engender discussion about Dublin Core qualifiers/substructure. Participants at DC4 touched on some of these issues, but not in great detail. The concept of a registry was also discussed, which would need to be established and would maintain any qualifier list. In addition, the document provides a starting point in scoping the problem and could provide guidance for people who need to implement immediately. It could serve as a framework for those considering the implications of using Dublin Core style records in various syntaxes.
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. The 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:
If a type qualifier 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 standard.
Following is a list of qualifiers ("core qualifiers") which may provide 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. In many cases I have given rationales for why some were left off. Note that I have used one of the two recommended HTML syntaxes (the "dot" approach), but the types could represented by the alternative syntax discussed at DC4.
Note that the Knight/Hamilton document defined a scheme=USMARC. I have left that off entirely, because it is inappropriate. USMARC is a record syntax, a communication mechanism, and is not a standard for content. One uses other standards for the content of MARC records. A mapping between the elements with and without qualifiers provides the field/subfield tag names and they are not necessary as a scheme subelement.
Definitions are taken from the Weibel/Kunze/Lagoze RFC Dublin Core Metadata Element Set: Reference Description. The default for "scheme" is nothing (it is not controlled by any standard) and the default for "type" is indicated below. If the default is used, no qualifier is given.
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:
3. Subject and Keywords
The topic of the resource, or keywords or phrases that
describe the subject or content of the resource. The intent
of the specification of this element is to promote the use
of controlled vocabularies and keywords. This element might
well include scheme-qualified classification data (for
example, Library of Congress Classification Numbers or Dewey
Decimal numbers) or scheme-qualified controlled vocabularies
(such as MEdical Subject Headings or Art and Architecture
Thesaurus descriptors) as well.
SCHEME:
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.
Future metadata collections might well include computational
content description (spectral analysis of a visual resource,
for example) that may not be embeddable in current network
systems. In such a case this field might contain a link to
such a description rather than the description itself.
SCHEME:
5. Publisher
The entity responsible for making the resource available in
its present form, such as a publisher, a university
department, or a corporate entity. The intent of
specifying this field is to identify the entity that
provides access to the resource.
SCHEME: not necessary
TYPE: Publisher.email
As with Author, the qualifiers listed in the Knight/Hamilton
document extend rather than refine this element. Email has been
included because of a demonstrated need. Use local qualifiers if
others are needed.
6. Other Contributor
Person(s) or organization(s) in addition to those specified
in the CREATOR element who have made significant
intellectual contributions to the resource but whose
contribution is secondary to the individuals or entities
specifed in the CREATOR element (for example, editors,
transcribers, illustrators, and convenors).
SCHEME:
7. Date
The date the resource was made available in its present
form. The recommended best practice is an 8 digit number in
the form YYYYMMDD as defined by ANSI X3.30-1985. In this
scheme, the date element for the day this is written would
be 19961203, or December 3, 1996. Many other schema are
possible, but if used, they should be identified in an
unambiguous manner.
NOTE that the DATE Subgroup of DC4 is working on changing this
definition so that it is general enough to allow for qualifiers
that refine rather than extend the definition. (Possible
definition suggested: A point in time related to the document.)
SCHEME:
8. Resource Type
The category of the resource, such as home page, novel,
poem, working paper, technical report, essay, dictionary.
It is expected that RESOURCE TYPE will be chosen from an
enumerated list of types.
SCHEME: not necessary (but an enumerated list of types
is)
TYPE: Type.Audience? (is this necessary?)
A controlled list of values is needed. Jon Knight's Dublin Core
Standard Resource Types is a start, but in many cases categories
are not mutually exclusive. In addition, in some cases it
combines notions of genre, publishing patterns (preprint,
unpublished), quality (referreed vs. non-referreed), and
relations (InBook, InCollection).
9. Format
The data representation of the resource, such as text/html,
ASCII, Postscript file, executable application, or JPEG
image. The intent of specifying this element is to provide
information necessary to allow people or machines to make
decisions about the usability of the encoded data (what
hardware and software might be required to display or
execute it, for example). As with RESOURCE TYPE, FORMAT
will be assigned from enumerated lists such as registered
Internet Media Types (MIME types). In principal, formats
can include physical media such as books, serials, or other
non-electronic media.
SCHEME:
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.
SCHEME:
11. Source
The work, either print or electronic, from which this
resource is derived, if applicable. For example, an html
encoding of a Shakespearean sonnet might identify the paper
version of the sonnet from which the electronic version was
transcribed.
SCHEME:
12. Language
Language(s) of the intellectual content of the resource.
Where practical, the content of this field should coincide
with the NISO Z39.53 three character codes for written
languages.
SCHEME:
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.
NOTE that a subgroup was formed at DC4 to deal with Relation.
SCHEME:
14. Coverage
The spatial locations and temporal durations characteristic
of the resource. Formal specification of COVERAGE is
currently under development. Users and developers should
understand that use of this element should be currently
considered experimental.
Note that this is preliminary pending the recommendations of the
Coverage working group.
SCHEME: To be determined by Coverage Working
Group
TYPE: Highly recommend that a type always be specified
(but if not, read as free text)
15. Rights Management
The content of this element is intended to be a link (a URL or
other suitable URI as appropriate) to a copyright notice, a
rights-management statement, or perhaps a server that would
provide such information in a dynamic way. The intent of
specifying this field is to allow providers a means to associate
terms and conditions or copyright statements with a resource or
collection of resources. No assumptions should be made by users
if such a field is empty or not present.
SCHEME: