Dublin Core
Dublin Core
About DCMI Themes Members Governing Board Usage Board Directorate
Bluesky Twitter YouTube GitHub RSS Feed

User Guide Working Draft

Title:

User Guide Working Draft
Creator:
Date Issued:
1998-07-31
Identifier:
Replaces:
Is Replaced By:
Latest Version:
Status of Document:
This is a DCMI Working Draft.
Description of Document: A user guide for simple Dublin Core™.

A USER GUIDE FOR SIMPLE DUBLIN CORE

DRAFT VERSION 5.1

1. INTRODUCTION

1.1. What is metadata?

Metadata describes an information resource. The term "meta" comes from a Greek word that denotes something of a higher or more fundamental nature. Metadata, then, is data about other data. It is the Internet-age term for information that librarians traditionally have put into catalogs, and it most commonly refers to descriptive information about Web resources. However, metadata can serve a variety of purposes, from identifying a resource that meets a particular information need, to evaluating their suitability for use, to tracking the characteristics of resources for maintenance or usage over time. Different communities of users meet such needs today with a wide variety of metadata standards.

A metadata record consists of a set of attributes, or elements, necessary to describe the resource in question. For example, a metadata system common in libraries -- the library catalog -- contains a set of metadata records with elements that describe a book or other library item: author, title, date of creation or publication, subject coverage, and the call number specifying location of the item on the shelf.

The linkage between a metadata record and the resource it describes may take one of two forms:

  1. elements may be contained in a record separate from the item, as in the case of the library's catalog record; or
  2. the metadata may be embedded in the resource itself.

Examples of embedded metadata that is carried along with the resource itself include the Cataloging In Publication (CIP) data printed on the verso of a book's title page; or the TEI header in an electronic text. Many metadata standards in use today, including the Dublin Core™ standard, do not prescribe either type of linkage, leaving the decision to each particular implementation.

Although the concept of metadata predates the Internet and the Web, worldwide interest in metadata standards and practices has exploded with the increase in electronic publishing and digital libraries, and the concomitant "information overload" resulting from vast quantities of undifferentiated digital data available online. Anyone who has attempted to find information online using one of today's popular Web search services has likely experienced the frustration of retrieving hundreds, if not thousands, of "hits" with limited ability to refine or make a more precise search. The wide scale adoption of descriptive standards and practices for electronic resources will improve retrieval of relevant resources from the "Internet commons." As noted by Weibel and Lagoze, two leaders in the field of metadata development:

The association of standardized descriptive metadata with networked objects has the potential for substantially improving resource discovery capabilities by enabling field-based (e.g., author, title) searches, permitting indexing of non-textual objects, and allowing access to the surrogate content that is distinct from access to the content of the resource itself." (Weibel and Lagoze, 1997)

It is this need for "standardized descriptive metadata" that the Dublin Core™ addresses.

1.2. What is the Dublin Core?

The Dublin Core™ metadata standard is a simple yet effective element set for describing a wide range of networked resources. The Dublin Core™ standard comprises fifteen elements, the semantics of which have been established through consensus by an international, cross-disciplinary group of professionals from librarianship, computer science, text encoding, the museum community, and other related fields of scholarship.

The Dublin Core™ element set is outlined in Section 4. Each element is optional and may be repeated. Each element also has a limited set of qualifiers, attributes that may be used to further refine (not extend) the meaning of the element. The present guide explores "simple" Dublin Core, that is, Dublin Core™ without qualifiers. More information on qualifiers and their use will be covered in A User Guide for Qualified
Dublin Core [not yet available]

Although the Dublin Core™ favors document-like objects (because traditional text resources are fairly well understood), it can apply to other resources as well. Its suitability for use with particular non-document resources will depend to some extent on how closely their metadata resembles typical document metadata and also what purpose the metadata is intended to serve.

Dublin Core™ has as its goals the following characteristics:

Simplicity of creation and maintenance
  <dd>The Dublin Core&#8482; element set has been kept as small and
  simple as possible to allow a non-specialist to create simple
  descriptive records for information resources easily and
  inexpensively, while providing for effective retrieval of
  those resources in the networked environment.</dd>

  <dt>Commonly understood semantics</dt>

  <dd>Discovery of information across the vast commons of the
  Internet is hindered by differences in terminology and
  descriptive practices from one field of knowledge to the
  next. The Dublin Core&#8482; can help the 'digital tourist' -- a
  non-specialist searcher -- find his or her way by supporting
  a common set of elements, the semantics of which are
  universally understood and supported. For example, scientists
  concerned with locating articles by a particular author, and
  art scholars interested in works by a particular artist, can
  agree on the importance of a "creator" element. Such
  convergence on a common, if slightly more generic, element
  set increases the visibility and accessibility of all
  resources, both within a given discipline and beyond.</dd>

  <dt>International scope</dt>

  <dd>The Dublin Core&#8482; Element Set was originally developed in
  English, but versions are being created in many other
  languages. As of June 1998, there were versions in Finnish,
  Norwegian, Thai, Japanese, French, Portuguese, German, Greek,
  Indonesian, and Spanish. The Working Group on Dublin Core&#8482; in
  Multiple Languages is coordinating efforts to link these
  versions in a distributed registry using the <a href="http://www.w3.org/RDF/"><strong>Resource Description
  Framework</strong></a> technology being developed by the
  World Wide Web Consortium (W3C).</dd>

  <dd>Although the technical challenges of internationalization
  on the World Wide Web have not been directly addressed by the
  Dublin Core&#8482; development community, the involvement of
  representatives from almost every continent has ensured that
  the development of the standard considers the multilingual
  and multicultural nature of the electronic information
  universe.</dd>

  <dt>Extensibility</dt>

  <dd>While balancing the needs for simplicity in describing
  digital resources with the need for precise retrieval, Dublin
  Core developers have recognized the importance of providing a
  mechanism for extending the DC element set for additional
  resource discovery needs. It is expected that other
  communities of metadata experts will create and administer
  additional metadata sets. Metadata elements from these sets
  could be linked with Dublin Core&#8482; metadata to meet the need
  for extensibility. This model allows different communities to
  use the DC elements for core descriptive information which
  will be usable across the Internet, while allowing domain
  specific additions which make sense within a more limited
  arena.</dd>
</dl>

1.3. The purpose and scope of this guide

This document is intended to help non-specialists create simple descriptive records for information resources (for example, electronic documents). Creators of these records include authors, editors, and World-Wide Web (WWW) site administrators.

The guide will show in a non-technical fashion how Dublin Core™ metadata may be used by anyone to make their material more accessible. This guide discusses the layout and content of Dublin Core™ metadata elements, and how to use them in composing a complete Dublin Core™ metadata record.

Another important goal of this document is to promote "best practices" for describing resources using the Dublin Core™ element set. The Dublin Core™ community recognizes that consistency in creating metadata is an important key to achieving complete retrieval and intelligible display across disparate sources of descriptive records. Inconsistent metadata effectively hides desired records, resulting in uneven, unpredictable or incomplete search results.

2. Why HTML?

In this guide, we have chosen to represent Dublin Core™ examples in HTML, the Web's Hypertext Markup Language format and in a generic form (Element="value"). HTML provides an easily understood format for demonstrating Dublin Core's underlying concepts. It is important to note, however, that Dublin Core™ concepts are equally applicable to virtually any file format, as long as the metadata is in a form suitable for interpretation both by search engines and by human beings.

HTML has two tags that can be used to capture metadata. These are the "" and "" tags. If creating metadata that will be embedded, or appear alongside, an actual document these tags must appear within the HEAD section of the HTML document. For example:

<HTML>
<HEAD>
<TITLE>Mating Habits of the Northern Hairy Nosed Wombat</TITLE>
<META NAME= "DC.Creator" CONTENT="Smythe, Pearl">
</HEAD>
<BODY>
<H1>Northern Hairy Nosed Wombats</H1>
<P>
The Northern Hairy Nosed Wombat is an animal native to Australia....</P>
</BODY>
</HTML>

Indexing programs understand that the metadata record starts after the "" line and ends before the "" line, and are thus able to extract metadata automatically. The metadata does not appear during normal document formatting or printing, and metadata-aware Web browsers may even be able to exploit it. A number of the current search engines have begun to include the ability to make use of the HTML tag in Web documents.

In HTML, each record element definition begins with "<META'' and ends with ">". Within the META tag, two attribute/value pairs (as found in other HTML tags) are used to define the metadata. The first is NAME, the second, CONTENT. These two work together to define the metadata within the META tag.

This document will not cover the use of the LINK tags.

Below are some examples of how the META tag might be used in stand-alone and embedded metadata. Note that each metadata definition happens to fit on one line, but in general a definition can span several lines.

2.1. Stand-Alone Metadata

Stand-alone metadata can exist in any kind of database. This example describes a photograph in another file that has a location given by a Uniform Resource Locator (URL). The entire record file looks like this:

<META NAME="DC.Title" CONTENT="Kita Yama (Japan)">
<META NAME="DC.Creator" CONTENT="Kertesz, Andre">
<META NAME="DC.Date" CONTENT="1968">
<META NAME="DC.Type" CONTENT="image">
<META NAME="DC.Format" CONTENT="image/gif">
<META NAME="DC.Identifier" CONTENT="http://foo.bar.zaf/kertesz/kyama">

2.2. Metadata Contained in a Resource

The next example is of a metadata record contained in a file alongside the document that it describes. The document is a short poem expressed in HTML, the Web's Hypertext Markup Language [3].

<HTML>
<HEAD>
<TITLE>Song of the Open Road</TITLE>
<META NAME="DC.Title" CONTENT="Song of the Open Road">
<META NAME="DC.Creator" CONTENT="Nash, Ogden">
<META NAME="DC.Type" CONTENT="text">
<META NAME="DC.Date" CONTENT="1939">
<META NAME="DC.Format" CONTENT="text/html">
<META NAME="DC.Identifier" CONTENT="http://www.poetry.com/nash/open.html">
</HEAD>
<BODY><PRE>
I think that I shall never see
A billboard lovely as a tree.
Indeed, unless the billboards fall
I'll never see a tree at all.
</PRE></BODY>
</HTML>

3. Basic Principles of Descriptive Elements

The notation (one of several) described in this guide is based on the HTML META tag. If non-ASCII characters are required, use the same conventions as in the body of the document. For example:

<META NAME="DC.Title" CONTENT="Les biscuits &agrave; la banane">

Each element is optional and repeatable. Metadata elements may appear in any order. The ordering of multiple occurrences of the same element (e.g., Creator) may have a significance intended by the provider, but ordering is not guaranteed to be preserved in every user environment.

3.1. Element Parts and Syntax

As demonstrated in Section 2, each descriptive element definition has a NAME attribute and a CONTENT attribute, as in:

<META NAME="DC.Creator" CONTENT="Browning, Elizabeth">

Any metadata element may be omitted or repeated. When repeating elements, it is recommended best practice to list each element definition separately, as in:

<META NAME="DC.Creator" CONTENT="Marx, Karl"> <META NAME="DC.Creator" CONTENT="Engels, Friedrich">

However, it is also valid to express repeated elements using a single NAME attribute with multiple semi-colon delimited values for the CONTENT attribute, as in:

<META NAME="DC.Creator" CONTENT="Marx, Karl ; Engels, Friedrich">

A Proposed Convention for Embedding Metadata in HTML agreed upon a convention for identifying and grouping metadata schemes in HTML. This convention relies on the use of a prefix to indicate that the elements used are from Dublin Core™ or another metadata scheme. For increased readability the prefix "DC" should be written in upper case letters and element names should be capitalized. For example:

META NAME="DC.Title" META NAME="DC.Creator"

NOT

DC.CREATOR or dc.CREATOR or DC.creator

3.2. Element Content and Controlled Vocabularies

Content data for some elements may be selected from a "controlled vocabulary," which is a limited set of consistently used and carefully defined terms. This can dramatically improve search results because computers are good at matching words character by character but weak at understanding the way people refer to one concept using different words, i.e. synonyms. Without basic terminology control, inconsistent or incorrect metadata can profoundly degrade the quality of search results. For example, without a controlled vocabulary, "candy" and "sweet" might be used to refer to the same concept. Controlled vocabularies may also reduce the likelihood of spelling errors when recording metadata.

One cost of a controlled vocabulary is in needing an administrative body to review, update and disseminate the vocabulary. For example, the US Library of Congress Subject Headings (LCSH) and the US National Library of Medicine Medical Subject Headings (MeSH) are formal vocabularies, indispensable for searching rigorously cataloged collections. However, both require significant support organizations. Another cost is having to train searchers and creators of metadata so that they know when using MeSH, for example, to enter "myocardial infarction"' instead of the more colloquial "heart attack."

4. The Core Elements

This section lists each Core element by its full name and label. For each element there is a reference description (taken from the RFC) and there are guidelines to assist in creating metadata content, whether it is done "from scratch" or by converting an existing record in another format.

The elements are listed in the order they were developed, but there are other useful ways to group them. In the following table, you can see that some elements relate to the content of the item, some to the item as intellectual property, still others to the particular instantiation, or version, of the item.

Content

Intellectual Property

Instantiation

Coverage

Contributor

Date

Description

Creator

Format

Type

Publisher

Identifier

Relation

Rights

Language

Source

    

Subject

    

Title

    

In the element descriptions below, a formal single-word label is specified to make the syntactic specification of elements simpler for encoding schemes. Although some environments, such as HTML, are not case-sensitive, it is recommended best practice always to adhere to the case conventions in the element names given below to avoid conflicts in the event that the metadata is subsequently converted to a case-sensitive environment, such as XML/RDF.

Some information may appear to belong in more than one metadata element. While there will normally be a clear preferred choice, there is potential semantic overlap between some elements. Consequently, there will occasionally be some judgment required from the person assigning the metadata.

4.1. Title

Label: Title

Element Description: The name given to the resource by the Creator or Publisher.

Guidelines for creation of content:

If in doubt about what constitutes the title, repeat the Title element and include the variants in second and subsequent Title iterations. If the item is in HTML, view the source document and make sure that the title identified in the title header is also include as a meta title (unless the DC metadata element is to be embedded in the document itself).

Examples:

<META NAME="DC.Title" CONTENT="A Pilot's Guide to Aircraft Insurance">

<META NAME="DC.Title" CONTENT="The Sound of Music">

<META NAME="DC.Title" CONTENT="Green on Greens">

<META NAME="DC.Title" CONTENT="AOPA's Tips on Buying Used Aircraft">

4.2. Author or Creator

Label: Creator

Element Description: The person or organization primarily responsible for creating 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.

Guidelines for creation of content:

Creators should be listed separately in the same order that they appear in the publication. Personal names should be listed surname or family name first, followed by forename or given name. When in doubt, give the name as it appears, and do not invert.

Examples:

<META NAME="DC.Creator" CONTENT="Duncan, Phyllis-Anne">

Creator="Melendez Santiago, Maria Luz"

Creator="Maimonides"

BUT:

<META NAME="DC.Creator" CONTENT="Park Sung Hee">

In the case of organizations where there is clearly a hierarchy present, list the parts of the hierarchy from largest to smallest, separated by full stops.

Examples:

Creator="United States. Internal Revenue Service"

Creator="Elvis Presley Fan Club"

<META NAME="DC.Creator" CONTENT="Federal Aviation Administration. Aviation Safety Program.">

NOT:

<META NAME="DC.Creator" CONTENT="Aviation Safety Program of the Federal Aviation Administration">

If it is not clear whether there is a hierarchy present, or unclear which is the larger or smaller portion of the body, give the name as it appears in the item.

<META NAME="DC.Creator" CONTENT="Art Institute of Chicago">

Creator="Association of the Bar of the City of New York"

Creator="Baltimore County Medical Society"

If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser responsibility, other than creation, use Contributor.

4.3. Subject and Keywords

Label: Subject

Element Description: 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 schemes is encouraged.

Guidelines for creation of content:

Select subject keywords from either the Title or Description information. If the subject of the item is a person or an organization, use the same form of the name as you would if the person or organization were a Creator, but do not repeat the name in the Creator element.

In general, choose the most significant and unique words for keywords, avoiding those too general to describe a particular item. This element might well include classification data (for example, Library of Congress Classification Numbers or Dewey Decimal numbers) or controlled vocabularies (such as Medical Subject Headings or Art and Architecture Thesaurus descriptors) as well.

Examples:

<META NAME="DC.Subject" CONTENT="Aircraft leasing and renting">

Subject="Dogs"

Subject="Olympic skiing" Subject="Street, Picabo"

4.4. Description

Label: Description

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

Guidelines for creation of content:

Since the description field is a potentially rich source of indexable vocabulary, care should be taken to provide this element when possible. Some metadata collections could include 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.

Descriptive information can be taken from the item itself, if there is no abstract or other structured description available. Normally, if a Description cannot be found either in the introductory or front matter, or the first few paragraphs, it should be set up "on the fly" by the metadata provider. Normally, Description should be limited to a few brief sentences.

Example:

<META NAME="DC.Description" CONTENT="Illustrated guide to airport markings and lighting signals, with particular reference to SMGCS (Surface Movement Guidance and Control System) for airports with low visibility conditions">

4.5. Publisher

Label: Publisher

Element Description: The entity responsible for making the resource available in its present form, such as a publishing house, a university department, or a corporate entity.

Guidelines for content creation:

The intent of specifying this field is to identify the entity that provides access to the resource. If the Creator and Publisher are the same, do not repeat the name in the Publisher area. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator for individuals. In cases of lesser responsibility, other than creation, use Contributor.

Examples:

<META NAME="DC.Publisher" CONTENT="Moguls Anonymous">

Publisher="University of Miami. Dept. of Economics"

Publisher="Microsoft Corporation"

4.6. Other Contributor

Label: Contributor

Element Description: 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 the Creator element (for example, editor, transcriber, and illustrator).

Guideline for content creation:

The same general guidelines for using names of persons or organizations as Creators apply here.

4. 7. Date

Label: Date

Element Description: A date associated with the creation or availability of the resource. Such a date is not to be confused with one belonging to the Coverage element, which would be associated with the resource only insofar as the intellectual content is somehow about that date. Recommended best practice is defined in a profile of ISO 8601 [Date and Time Formats (based on ISO8601), W3C Technical Note http://www.w3.org/TR/NOTE-datetime] that includes (among others) dates of the forms YYYY and YYYY-MM-DD. In this scheme, the date 1994-11-05 corresponds to November 5, 1994.

Guidelines for content creation:

If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) may be used. Many other schema are possible, but if used, they may not be easily interpreted by users or software.

<META NAME="DC.Date" CONTENT="1998-02-16"> <META NAME="DC.Date" CONTENT="1998-02"> <META NAME="DC.Date" CONTENT="1998">

4.8. Resource Type

Label: Type

Element Description: 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.

Guidelines for content creation:

This element should describe the genre of the content of the resource. See http://sunsite.Berkeley.edu/Metadata/minimalist.html for current thinking on the application of this element. A minimal default list recommended for DC is:

  • text
  • image
  • sound
  • data
  • software
  • interactive
  • physical object

which are used as follows:

text
  <dd>resources in which the content is mainly words for
  reading: for example - books, letters, dissertations, poems,
  newspapers, archives of mailing lists</dd>

  <dt>image</dt>

  <dd>the content is primarily visual in two dimensions and is
  not text: for example - images, paintings, animations,
  diagrams</dd>

  <dt>sound</dt>

  <dd>the content is primarily audio: for example - music,
  speech, recorded sounds</dd>

  <dt>data</dt>

  <dd>information encoded in lists, tables, databases, etc.,
  which will often be in a format ready for direct machine
  processing: for example - spreadsheets, databases, GIS
  data</dd>

  <dt>software</dt>

  <dd>computer programs in source or compiled form which may be
  available for installation non-transiently on another
  machine</dd>

  <dt>interactive</dt>

  <dd>resources which require interaction from the user to be
  understood, executed, or experienced: for example - forms on
  web pages, applets, multimedial learning objects</dd>

  <dt>physical object</dt>

  <dd>three dimensional objects or substances which are not
  primarily text or image: for example - a person, a computer,
  the great pyramid, a sculpture, etc.</dd>
</dl>

Examples:

<META NAME="DC.Type" CONTENT="image">

Type="sound"

Type="text"

Note that if the resource has content of multiple mixed types then multiple or repeated Type elements should be used to describe the main components.

Examples:

Electronic art exhibition catalog:
Type="image" Type="text"

Multimedia educational program with interactive assignments:
Type="text" Type="image" Type="software" Type="interactive"

4.9. Format

Label: Format

Element Description: 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 currently under development in the workshop series.

Guidelines for content creation:

Electronic formats, such as text/html, ASCII, Postscript file, executable application, or JPEG image may be included in this area. In these cases, assign a Format from Internet Media Types (MIME types). In principle, formats can include physical media such as books, serials, or other non-electronic media.

Information concerning the size of a resource may be included in the content of the Format element. In resource discovery this might be used as a criterion to select resources of interest, since a user may need to evaluate whether they can make use of the resource within the infrastructure available to them.

Examples:

<META NAME="DC.Format" CONTENT="image/gif">

Title="Dublin Core&#8482; icon" Identifier="http://purl.org/metadata/dublin_core/images/dc2.gif" Type="image" Format="image/gif 4kB"

<META NAME="DC.Subject" CONTENT="Saturn"> <META NAME="DC.Type" CONTENT="image"> <META NAME="DC.Format" CONTENT="image/gif 640 x 512 pixels"> <META NAME="DC.Identifier" CONTENT="http://www.not.iac.es/newwww/photos/images/satnot.gif">

Title="The Bronco Buster" Creator="Frederic Remington" Type="physical object" Format="bronze 22 in."

4.10. Resource Identifier

Label: Identifier

Element Description: A 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 are also candidates for this element.

Guidelines for content creation:

This element can also be used for local identifiers (e.g. ID numbers or call numbers) assigned by the Creator of the resource to apply to a particular item.

Examples:

<META NAME="DC.Identifier" CONTENT="http://purl.oclc.org/metadata/dublin_core/">

Identifier="0385424728" [ISBN]

Identifier="H-A-X 5690B" [publisher number]

4.11. Source

Label: Source

Element Description: Information about a second resource from which the present resource is derived. While it is generally recommended that elements contain information about the present resource only, this element may contain a date, creator, format, identifier, or other metadata for the second resource when it is considered important for the discovery of the present resource: recommended best practice is to use the Relation element instead. For example, it is possible to use a Source date of 1603 in a description of a 1996 film adaptation of a Shakespeare play, but it is preferred instead to use Relation "IsBasedOn" with a reference to a separate resource whose description contains a Date of 1603. Source is not applicable if the present resource is in its original form.

Guidelines for content creation:

In general, include in this area information which does not fit easily into Relation.

Example:

<META NAME="DC.Source" CONTENT="RC607.A26W574 1996"> [where "RC607.A26W574 1996" is the call number of the print version of the resource, from which the present version was scanned]

4.12. Language

Label: Language

Element Description: The language of the intellectual content of the resource. Where practical, the content of this field should coincide with RFC 1766 [Tags for the Identification of Languages, http://ds.internic.net/rfc/rfc1766.txt]; examples include en, de, es, fi, fr, ja, th, and zh.

Guidelines for content creation:

Coded or textual information can be represented here. If the content is in more than one language, the element may be repeated.

Examples:

Language=en Language=fr

OR,

<META NAME="DC.Language" CONTENT="en;fr">

OR,

<META NAME="DC.Language" CONTENT="Primarily English, with some abstracts also in French.">

<META NAME="DC.Language" CONTENT="en-US">

4.13. Relation

Label: Relation

Element Description: An identifier of a second resource and its relationship to the present resource. This element permits links between related resources and resource descriptions to be indicated. Examples include an edition of a work (IsVersionOf), a translation of a work (IsBasedOn), a chapter of a book (IsPartOf), and a mechanical transformation of a dataset into an image (IsFormatOf). For the sake of interoperability, relationships should be selected from an enumerated list that is currently under development in the workshop series.

A list of types which accomodates most expected relationships is:

  • IsPartOf
  • HasPart
  • IsVersionOf
  • HasVersion
  • IsFormatOf
  • HasFormat
  • References
  • IsReferencedBy
  • IsBasedOn
  • IsBasisFor
  • Requires
  • IsRequiredBy

Guidelines for content creation:

The recommended method for expressing a relationship in unqualified DC is:

Title="the present resource" Relation="relationship-type [space] unique identifer for the related resource"

where "relationship-type" is a token drawn from the list above.

Note: In the case where the DC metadata is embedded in the present resource, the value for Identifier is implied (i.e. the present resource). In qualified DC the two components given in Relation here will be structured using sub-elements for easier automated processing.

Examples:

Title="Reading Turgenev" Relation ="IsPartOf Two Lives"[collection of two novellas, one of which is "Reading Turgenev"]

[Part/Whole relations are those in which one resource is a physical or logical part of another]

Title="Candle in the Wind" Subject="Diana, Princess of Wales" Date="1997" Creator="John, Elton" Type="sound" Description="Tribute to a dead princess" Relation="IsVersionOf Elton John's 1976 song Candle in the Wind"

Title="Gombrich's Story of Art" Relation="HasVersion 13th Edition, 1972"

[Version relations are those in which one resource is an historical state or edition, of another resource by the same creator]

Title="Electronic AACR2" Relation="IsFormatOf Anglo-American Cataloging Rules, 2nd edition"

Title="Landsat TM dataset of Arnhemland, NT, Australia" Relation="HasFormat arnhem.gif"

[Format transformation relations are those in which one resource has been derived from another by a reproduction or reformatting technology which is not fundamentally an interpretation but intended to be a representation.]

Title="Morgan's Ancient Society" Relation="IsReferencedBy Engels' Origin of the Family, Private Property and the State"

Title="Nymphet Mania" Relation="References Adrian Lyne's 'Lolita'"

[Reference relations are those in which the author of one resource cites, acknowledges, disputes or otherwise make claims about another resource.]

Title="Peter Carey's novel Oscar and Lucinda" Relation="IsBasisFor 1998 movie Oscar and Lucinda"

Title="The movie My Fair Lady" Relation="IsBasedOn Shaw's play Pygmalion"

[Creative relations are those in which one resource is a performance, production, derivation, adaptation or interpretation of another resource.]

Title="program.c" Relation= Requires stdio.h"

Title="List of Internet Media Types" Relation="IsRequiredBy Dublin Core&#8482; Format element"

[Dependency relations are those in which one resource requires another resource for its functioning, delivery, or content and cannot be used without the related resource being present.]

4.14. Coverage

Label: Coverage

Element Description: The spatial or temporal characteristics of the intellectual content of the resource. Spatial coverage refers to a physical region (e.g., celestial sector); use coordinates (e.g. longitude and latitude) or place names that are from a controlled list or are fully spelled out. Temporal coverage refers to what the resource is about rather than when it was created or made available (the latter belonging in the Date element); use the same date/time format (often a range) [Date and Time Formats (based on ISO8601), W3C Technical Note, http://www.w3.org/TR/NOTE-datetime] as recommended for the Date element or time periods that are from a controlled list or are fully spelled out.

Guidelines for content creation:

Whether this element is used for spatial or temporal information, care should be taken to provide consistent information that can be interpreted by users. For most simple applications, where place names or coverage dates might be useful, whether the information is numeric or alphabetical may be enough to differentiate. For more complex applications, consideration should be given to additional qualification.

Examples:

Coverage=1995-1996

Coverage=Boston, MA

OR,

<META NAME="DC.Coverage" CONTENT="17th century">

<META NAME="DC.Coverage" CONTENT="Upstate New York">

4.15. Rights Management

Label: Rights

Element Description: A rights-management statement, an identifier that links to a rights management statement, or an identifier that links to a service providing information about rights management for the resource.

Guidelines for content creation:

At present, used for either a textual statement or a URL.

Examples:

Access limited to members.

<META NAME="DC.Rights" CONTENT="http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Terms">

5. Glossary

6. Background Reading and References

rev. 31july98 dih