Using Dublin Core in Semantic MediaWiki

From Metadata-Registry
Revision as of 12:39, 6 September 2007 by Diane (Talk | contribs)

Jump to: navigation, search

Using Dublin Core

Creator:

Diane Hillmann

Date Issued: 2005-11-07
Identifier:

[/documents/2005/11/07/usageguide/ http://dublincore.org/documents/2005/11/07/usageguide/]

Replaces:

[/documents/2005/08/15/usageguide/ http://dublincore.org/documents/2005/08/15/usageguide/]

Is Replaced By: Not applicable
Latest Version:

[/documents/usageguide/ http://dublincore.org/documents/usageguide/]

Translations:

[/resources/translations/ http://dublincore.org/resources/translations/]

Status of Document:

[/documents/#recommendedresources DCMI Recommended Resource]

Description of Document: This document is intended as an entry point for users of Dublin Core. For non-specialists, it will assist them in creating simple descriptive records for information resources (for example, electronic documents). Specialists may find the document a useful point of reference to the documentation of Dublin Core, as it changes and grows.

Table of Contents

[/documents/usageguide/#introduction 1. Introduction]

  • [/documents/usageguide/#whatismetadata 1.1. What is Metadata?]
  • [/documents/usageguide/#whatis 1.2. What is the Dublin Core?]
  • [/documents/usageguide/#purpose 1.3. The Purpose and Scope of This Guide]

[/documents/usageguide/#whichsyntax 2. Syntax, Storage and Maintenance Issues]

  • [/documents/usageguide/#html 2.1. HTML]
  • [/documents/usageguide/#rdfxml 2.2. RDF/XML]
  • [/documents/usageguide/#metadatacontained 2.3. Metadata Storage and Maintenance]

[/documents/usageguide/#basicprinciples 3. Element Content and Controlled Vocabularies]
[/documents/usageguide/elements.shtml 4. The Elements]
[/documents/usageguide/qualifiers.shtml 5. Dublin Core Qualifiers]
[/documents/usageguide/appendix_roles.shtml 6. Appendix, Roles]
[/documents/usageguide/glossary.shtml 7. Glossary]
[/documents/usageguide/bibliography.shtml 8. Bibliography]

1. Introduction

1.1. What is Metadata?

Metadata has been with us since the first librarian made a list of the items on a shelf of handwritten scrolls. The term "meta" comes from a Greek word that denotes "alongside, with, after, next." More recent Latin and English usage would employ "meta" to denote something transcendental, or beyond nature. Metadata, then, can be thought of as 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.

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 in any venue where information retrieval is critical. As noted by Weibel and Lagoze, two leaders in the fields of metadata development and digital libraries:

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

In the last years we have also seen an increase in the application of Dublin Core metadata in more closed environments. There are implementations where Dublin Core metadata is used to describe resources held, owned or produced by companies, governments and international organisations to supporting portal services or internal knowledge management. There are also implementations where Dublin Core metadata is used as a common exchange format supporting the aggregation of collections of metadata, such as the case of the Open Archive Initiative. In these cases, like in the open environment of the Web, the concept of standardized descriptive metadata provides a powerful mechanism to improve retrieval for specific applications and specific user communities. 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 includes two levels: Simple and Qualified. Simple Dublin Core comprises fifteen elements; Qualified Dublin Core includes three additional elements (Audience, Provenance and RightsHolder), as well as a group of element refinements (also called qualifiers) that refine the semantics of the elements in ways that may be useful in resource discovery. The semantics of Dublin Core have been established by an international, cross-disciplinary group of professionals from librarianship, computer science, text encoding, the museum community, and other related fields of scholarship and practice.

Another way to look at Dublin Core is as a "small language for making a particular class of statements about resources". In this language, there are two classes of terms -- elements (nouns) and qualifiers (adjectives) -- which can be arranged into a simple pattern of statements. The resources themselves are the implied subjects in this language. (For additional discussion of Dublin Core Grammar, see [/usage/documents/principles/ "DCMI Grammatical Principles"]) In the diverse world of the Internet, Dublin Core can be seen as a "metadata pidgin for digital tourists": easily grasped, but not necessarily up to the task of expressing complex relationships or concepts.

The Dublin Core basic element set is outlined in [/documents/usageguide/elements.shtml Section 4]. Each element is optional and may be repeated. Most elements also have a limited set of qualifiers or refinements, attributes that may be used to further refine (not extend) the meaning of the element. The Dublin Core Metadata Initiative (DCMI) has established standard ways to refine elements and encourage the use of encoding and vocabulary schemes. The full set of [/documents/dcmi-terms/ elements and element refinements] conforming to DCMI "best practice" is available, with a [/dcregistry/ formal registry] available as well.

Three other Dublin Core principles bear mentioning here, as they are critical to understanding how to think about the relationship of metadata to the underlying resources they describe.

1. The One-to-One Principle. In general Dublin Core metadata describes one manifestation or version of a resource, rather than assuming that manifestations stand in for one another. For instance, a jpeg image of the Mona Lisa has much in common with the original painting, but it is not the same as the painting. As such the digital image should be described as itself, most likely with the creator of the digital image included as a Creator or Contributor, rather than just the painter of the original Mona Lisa. The relationship between the metadata for the original and the reproduction is part of the metadata description, and assists the user in determining whether he or she needs to go to the Louvre for the original, or whether his/her need can be met by a reproduction.

2. The Dumb-down Principle. The qualification of Dublin Core properties is guided by a rule known colloquially as the Dumb-Down Principle. According to this rule, a client should be able to ignore any qualifier and use the value as if it were unqualified. While this may result in some loss of specificity, the remaining element value (minus the qualifier) must continue to be generally correct and useful for discovery. Qualification is therefore supposed only to refine, not extend the semantic scope of a property.

3. Appropriate values. Best practice for a particular element or qualifier may vary by context, but in general an implementor cannot predict that the interpreter of the metadata will always be a machine. This may impose certain constraints on how metadata is constructed, but the requirement of usefulness for discovery should be kept in mind.

Although the Dublin Core was originally developed with an eye to describing document-like objects (because traditional text resources are fairly well understood), DC metadata can be applied 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. (Implementors interested in using Dublin Core for diverse resources are encouraged to browse the [/projects/ Dublin Core Projects pages] for ideas on using Dublin Core metadata for their resources.)

Dublin Core has as its goals:

Simplicity of creation and maintenance

The Dublin Core 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.

Commonly understood semantics

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

International scope

The Dublin Core Element Set was originally developed in English, but versions are being created in [/resources/translations/ many other languages], including Finnish, Norwegian, Thai, Japanese, French, Portuguese, German, Greek, Indonesian, and Spanish. [/groups/languages/ The DCMI Localization and Internationalization Special Interest Group] is coordinating efforts to link these versions in a distributed registry.

Although the technical challenges of internationalization on the World Wide Web have not been directly addressed by the Dublin Core development community, the involvement of representatives from virtually every continent has ensured that the development of the standard considers the multilingual and multicultural nature of the electronic information universe.

Extensibility

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, specialized to the needs of their communities. Metadata elements from these sets could be used in conjunction with Dublin Core metadata to meet the need for interoperabilbility. The DCMI Usage Board is presently working on a model for accomplishing this in the context of "application profiles."

Rachel Heery and Manjula Patel, in their article "Application profiles: mixing and matching metadata schemas" define an application profile as:

" ... schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application."

This model allows different communities to use the DC elements for core descriptive information, and allowing domain specific extensions which make sense within a more limited arena.

1.3. The Purpose and Scope of This Guide

This document is intended to be an entry point for users of Dublin Core. For non-specialists, it will assist in creating simple descriptive records for information resources (for example, electronic documents, JPEG images, video clips). Specialists may find the document a useful point of reference to the documentation of Dublin Core, as it changes and grows.

"Using Dublin Core" will show in a non-technical fashion how Dublin Core metadata may be used by anyone to make their material more accessible. It discusses the principles, structure and content of Dublin Core metadata elements, how to use them in composing a complete Dublin Core metadata record, as well as how to qualify elements to support use by a wide variety of communities.

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 optimal retrieval and intelligible display across disparate sources of descriptive records. Inconsistent metadata effectively hides desired records, resulting in uneven, unpredictable or incomplete search results.

As a general introduction, this document is necessarily brief, and cannot address all the issues implementors may encounter while planning their use of metadata. Several avenues remain for those who have additional questions beyond those addressed in this guide.

  1. 1. Appended to this guide are references to relevant articles and other resources, including those with more technical guidance for implementors
  2. The Dublin Core Website contains references to additional documents and resources of the DCMI community and ways for implementors to become involved in the DCMI
  3. Specific questions can be addressed to AskDCMI. In addition to fielding questions, the AskDCMI service maintains a searchable archive of already answered questions and links to additional resources.

2. Syntax Issues

[/documents/abstract-model/ The Dublin Core Abstract Model] provides a reference model against which particular DC encoding guidelines can be compared, independent of any particular encoding syntax. Such a reference model allows implementors to gain a better understanding of the kinds of descriptions they are trying to encode and facilitates the development of better mappings and translations between different syntaxes. Although the document is primarily aimed at the developers of software applications that support Dublin Core metadata, anyone who is considering implementing Dublin Core -- particularly those contemplating extending DC in any way -- could usefully review the document. Those involved in developing new syntax encoding guidelines for Dublin Core metadata or developing metadata application profiles based on the Dublin Core should also become familiar with the DC Abstract Model.

In this guide, we have chosen to represent Dublin Core examples in a "generic" form (Element="value"). Examples of other syntaxes, including: HTML or XHTML (the Web's Hypertext Markup Language format), RDF/XML (the Resource Description Framework using eXtensable Markup Language) and in plain XML can be found in syntax-specific [/resources/expressions/ documents available on the DCMI Website]. Some are also referenced within this document and in the [/documents/usageguide/bibliography.shtml Bibliography Section] of this guide.

Syntax choices depend on a number of variables, and "one size fits all" prescriptions rarely apply. When considering an appropriate syntax, it is important to note that Dublin Core concepts and semantics are designed to be syntax independent, are equally applicable in a variety of contexts, as long as the metadata is in a form suitable for interpretation both by search engines and by human beings.

2.1. HTML and XHTML

HTML or XHTML can be used to express either simple or qualified Dublin Core, although there are limitations inherent in representing refinements in HTML. Specific instructions for expressing Dublin Core in HTML can be found in the following DCMI document:

  1. [/documents/dcq-html/ Expressing Qualified Dublin Core in HTML/XHTML meta and link elements]

2.2. RDF/XML

RDF (Resource Description Framework) allows multiple metadata schemes to be read by humans as well as parsed by machines. It uses XML (EXtensible Markup Language) to express structure thereby allowing metadata communities to define the actual semantics. This decentralized approach recognizes that no one scheme is appropriate for all situations, and further that schemes need a linking mechanism independent of a central authority to aid description, identification, understanding, usability, and/or exchange.

RDF allows multiple objects to be described without specifying the detail required. The underlying glue, XML, simply requires that all namespaces be defined and once defined, they can be used to the extent needed by the provider of the metadata.

For example:

<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">

   <rdf:Description rdf:about="http://media.example.com/audio/guide.ra">

      <dc:creator>Rose Bush</dc:creator>

      <dc:title>A Guide to Growing Roses</dc:title>
      <dc:description>Describes process for planting and nurturing different kinds of rose bushes.</dc:description> 
      <dc:date>2001-01-20</dc:date>

   </rdf:Description> 

</rdf:RDF>

This simple example uses Dublin Core by itself to describe an audio recording of a guide to growing rose bushes. With XML or RDF/XML, Dublin Core can potentially be mixed with other metadata vocabularies. For example, the simple Dublin Core description above might be used alongside other vocabularies such as vCard that can describe the author's affiliation and contact information, or a more specialized "rose description" vocabulary that described the rose bushes in greater detail.

DCMI has made available several recommendations specifically about using these syntaxes:

  1. [/documents/dc-xml-guidelines/ Guidelines for Implementing Dublin Core in XML]
  2. [/documents/dcmes-xml/ Expressing Simple Dublin Core in RDF/XML]
  3. [/documents/dcq-rdf-xml/ Expressing Qualified Dublin Core in RDF/XML] (Proposed Recommendation)

2.3. Metadata Storage and Maintenance Issues

Some implementations using Dublin Core have chosen to embed their metadata within the resource itself. This approach is taken most often with documents encoded using HTML, but is also sometimes possible with other kinds of documents. Simple tools have been developed to make provision of Dublin Core metadata within HTML encoded pages fairly easy. One such tool, DC.dot, extracts metadata information from an HTML document, and formats it so that it can be edited, then cut and pasted back into the HTML header of the original document.

On the other hand, metadata can be stored in any kind of database, and provide a link to the described resource rather than be embedded within it. This approach is likely to be most practical for many non-textual resources, and is increasingly used for text as well, primarily to support easier maintenance and sharing of metadata.

Each of these approaches have their advantages and disadvantages, and the balance point changes as implementations become larger and more diverse, and also as the metadata ages over time.

3. Element Content and Controlled Vocabularies

Each Dublin Core element is optional and repeatable, and there is no defined order of elements. 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. Ordering or sequencing may be syntax dependent; for instance, RDF/XML supports ordering, but HTML does not.

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 the necessity for 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." More sophisticated implementations can make such tasks much easier, but the controlled vocabulary terms must be available for them to apply.

Using controlled vocabularies can be done most effectively using [/documents/dcmi-terms/#H4 encoding schemes]. Without an encoding scheme specifically designated, a subject which might very well be carefully selected from a particular controlled vocabulary cannot be distinguished from a simple keyword.

4. [/documents/usageguide/elements.shtml The Elements]

Using Dublin Core - The Elements

4. The Elements

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

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.

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. Typically, a Title will be a name by which the resource is formally known.

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 (if any) is also included as a Title.

Examples:

Title="A Pilot's Guide to Aircraft Insurance"
Title="The Sound of Music"
Title="Green on Greens"
Title="AOPA's Tips on Buying Used Aircraft"

4.2. Subject

Label: Subject and Keywords

Element Description: The topic of the content of the resource. Typically, a Subject will be expressed as keywords or key phrases or classification codes that describe the topic of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.

Guidelines for creation of content:

Select subject keywords from the Title or Description information, or from within a text resource. 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 or Contributor.

In general, choose the most significant and unique words for keywords, avoiding those too general to describe a particular item. Subject might include classification data if it is available (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 as keywords.

When including terms from multiple vocabularies, use separate element iterations. If multiple vocabulary terms or keywords are used, either separate terms with semi-colons or use separate iterations of the Subject element.

Examples:

Subject="Aircraft leasing and renting"
Subject="Dogs"
Subject="Olympic skiing"
Subject="Street, Picabo"

4.3. Description

Label: Description

Element Description: An account of the content of the resource. Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.

Guidelines for creation of content:

Since the Description field is a potentially rich source of indexable terms, care should be taken to provide this element when possible. Best practice recommendation for this element is to use full sentences, as description is often used to present information to users to assist in their selection of appropriate resources from a set of search results.

Descriptive information can be copied or automatically extracted from the item if there is no abstract or other structured description available. Although the source of the description may be a web page or other structured text with presentation tags, it is generally not good practice to include HTML or other structural tags within the Description element. Applications vary considerably in their ability to interpret such tags, and their inclusion may negatively affect the interoperability of the metadata.

Examples:

Description="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."

Description="Teachers Domain is a multimedia library for K-12 science educators, developed by WGBH through funding from the National Science Foundation as part of its National Science Digital Library initiative. The site offers a wealth of classroom-ready instructional resources, as well as online professional development materials and a set of tools which allows teachers to manage, annotate, and share the materials they use in classroom teaching."

4.4. Type

Label: Resource Type

Element Description: The nature or genre of the content of the resource. Type includes terms describing general categories, functions, genres, or aggregation levels for content. Recommended best practice is to select a value from a controlled vocabulary (for example, the DCMIType vocabulary ). To describe the physical or digital manifestation of the resource, use the FORMAT element.

Guidelines for content creation:

If the resource is composed of multiple mixed types then multiple or repeated Type elements should be used to describe the main components.

Because different communities or domains are expected to use a variety of type vocabularies, best practice to ensure interoperability is to include at least one general type term from the DCMIType vocabulary in addition to the domain specific type term(s), in separate Type element iterations.

Examples:

Type="Image"
Type="Sound"
Type="Text"
Type="simulation"

Note: The first three values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.

The item described is an Electronic art exhibition catalog:

Type="Image"
Type="Text"
Type="Exhibition catalog"

Note: The first two values are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary. The last value is a term from an unspecified source.

The item described is a Multimedia educational program with interactive assignments:

Type="Image"
Type="Text"
Type="Software"
Type="InteractiveResource"

Note: All values in this example are taken from the DCMI Type Vocabulary, and follow the capitalization conventions for that vocabulary.

4.5. Source

Label: Source

Element Description: A Reference to a resource from which the present resource is derived. The present resource may be derived from the Source resource in whole or part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

Guidelines for content creation:

In general, include in this area information about a resource that is related intellectually to the described resource but does not fit easily into a Relation element.

Examples:

Source="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]

Source="Image from page 54 of the 1922 edition of Romeo and Juliet"

4.6. Relation

Label: Relation

Element Description: A reference to a related resource. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

Guidelines for content creation:

Relationships may be expressed reciprocally (if the resources on both ends of the relationship are being described) or in one direction only, even when there is a refinement available to allow reciprocity. If text strings are used instead of identifying numbers, the reference should be appropriately specific. For instance, a formal bibliographic citation might be used to point users to a particular resource.

Because the refined terms used with Relation provide significantly more information to a user than the unqualified use of Relation, implementers who are describing heavily interrelated resources might choose to use qualified Dublin Core.

Examples:

Title="Reading Turgenev"
Relation="Two Lives" [Resource is a collection of two novellas, one of which is "Reading Turgenev"]
[Relationship described is IsPartOf.

[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="Elton John's 1976 song Candle in the Wind"
[Relationship described is IsVersionOf.

[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="Anglo-American Cataloging Rules, 2nd edition"
[Relationship described is IsFormatOf]
Title="Landsat TM dataset of Arnhemland, NT, Australia"
Relation="arnhem.gif"
[Relationship described is HasFormat]

[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="Engels' Origin of the Family, Private Property and the State"
[Relationship described is IsReferencedBy]
Title="Nymphet Mania"
Relation="References Adrian Lyne's 'Lolita'"
[Relationship described is References]

[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="1998 movie Oscar and Lucinda"
[Relationship described is IsBasisFor]
Title="The movie My Fair Lady"
Relation="Shaw's play Pygmalion"
[Relationship described is IsBasedOn]

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

Title="Dead Ringer"
Relation="Gemstar e-book"
[Relationship described is Requires]

[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.7. Coverage

Label: Coverage

Element Description: The extent or scope of the content of the resource. Coverage will typically include spatial location (a place name or geographic co-ordinates), temporal period (a period label, date, or date range) or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [Getty Thesaurus of Geographic Names, http://www. getty.edu/research/tools/vocabulary/tgn/]). Where appropriate, named places or time periods should be used in preference to numeric identifiers such as sets of co-ordinates or date ranges.

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 human users, particularly in order to provide interoperability in situations where sophisticated geographic or time-specific searching is not supported. For most simple applications, place names or coverage dates might be most useful. For more complex applications, consideration should be given to using an encoding scheme that supports appropriate specification of information, such as DCMI Period, DCMI Box or DCMI Point.

Examples:

Coverage="1995-1996"
Coverage="Boston, MA"
Coverage="17th century"
Coverage="Upstate New York"

4.8. Creator

Label: Creator

Element Description: An entity primarily responsible for making the content of the resource. Examples of a Creator include a person, an organization, or a service. Typically the name of the Creator should be used to indicate the entity.

Guidelines for creation of content:

Creators should be listed separately, preferably 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.

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 and a space. 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.

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 or ambiguous responsibility, other than creation, use Contributor.

Examples:

Creator="Shakespeare, William"
Creator="Wen Lee"
Creator="Hubble Telescope"
Creator="Internal Revenue Service. Customer Complaints Unit"

4.9. Publisher

Label: Publisher

Element Description: The entity responsible for making the resource available. Examples of a Publisher include a person, an organization, or a service. Typically, the name of a Publisher should be used to indicate the 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 ambiguous responsibility, use Contributor.

Examples:

Publisher="University of South Where"
Publisher="Funky Websites, Inc."
Publisher="Carmen Miranda"

4.10. Contributor

Label: Contributor

Element Description: An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person, an organization or a service. Typically, the name of a Contributor should be used to indicate the entity.

Guideline for content creation:

The same general guidelines for using names of persons or organizations as Creators apply here. Contributor is the most general of the elements used for "agents" responsible for the resource, so should be used when primary responsibility is unknown or irrelevant.

4.11. Rights

Label: Rights Management

Element Description: Information about rights held in and over the resource. Typically a Rights element will contain a rights management statement for the resource, or reference a service providing such information. Rights information often encompasses Intellectual Property Rights (IPR), Copyright, and various Property Rights. If the rights element is absent, no assumptions can be made about the status of these and other rights with respect to the resource.

Guidelines for content creation:

The Rights element may be used for either a textual statement or a URL pointing to a rights statement, or a combination, when a brief statement and a more lengthy one are available.

Examples:

Rights="Access limited to members"
Rights="http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Terms& quot;

4.12. Date

Label: Date

Element Description: A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [Date and Time Formats, W3C Note, http://www.w3.org/TR/NOTE- datetime] and follows the YYYY-MM-DD format.

Guidelines for content creation:

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

Examples:

Date="1998-02-16"
Date="1998-02"
Date="1998"

4.13. Format

Label: Format

Element Description: The physical or digital manifestation of the resource. Typically, Format may include the media-type or dimensions of the resource. Examples of dimensions include size and duration. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource.

Recommended best practice is to select a value from a controlled vocabulary (for example, the list of Internet Media Types [http://www.iana.org/ assignments/media-types/] defining computer media formats).

Guidelines for content creation:

In addition to the specific physical or electronic media format, information concerning the size of a resource may be included in the content of the Format element if available. In resource discovery size, extent or medium of the resource 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.

When more than one category of format information is included in a single record, they should go in separate iterations of the element.

Examples:

Title="Dublin Core icon"
Identifier="http://purl.org/metadata/dublin_core/images/dc2.gif& quot;
Type="Image"
Format="image/gif"
Format="4 kB"
Subject="Saturn"
Type="Image"
Format="image/gif 6"
Format="40 x 512 pixels"
Identifier="http://www.not.iac.es/newwww/photos/images/satnot.gif "
Title="The Bronco Buster"
Creator="Frederic Remington"
Type="Physical object"
Format="bronze"
Format="22 in."

4.14. Identifier

Label: Resource Identifier

Element Description: An unambiguous reference to the resource within a given context. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Examples of formal identification systems include the Uniform Resource Identifier (URI) (including the Uniform Resource Locator (URL), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN).

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. It should not be used for identification of the metadata record itself.

Examples:

Identifier="http://purl.oclc.org/metadata/dublin_core/& quot;
Identifier="ISBN:0385424728"
Identifier="H-A-X 5690B" [publisher number]

4.15. Language

Label: Language

Element Description: A language of the intellectual content of the resource. Recommended best practice for the values of the Language element is defined by RFC 3066 [RFC 3066, http://www.ietf.org/rfc/ rfc3066.txt] which, in conjunction with ISO 639 [ISO 639, http://www.oasis- open.org/cover/iso639a.html]), defines two- and three-letter primary language tags with optional subtags. Examples include "en" or "eng" for English, "akk" for Akkadian, and "en-GB" for English used in the United Kingdom.

Guidelines for content creation:

Either a coded value or text string can be represented here. If the content is in more than one language, the element may be repeated.

Examples:

Language="en"
Language="fr"
Language="Primarily English, with some abstracts also in French."
Language="en-US"

NOTE: Audience, Provenance and RightsHolder are elements, but not part of the Simple Dublin Core fifteen elements. Use Audience, Provenance and RightsHolder only when using Qualified Dublin Core.

4.16. Audience

Label: Audience

Element Description: A class of entity for whom the resource is intended or useful. A class of entity may be determined by the creator or the publisher or by a third party.

Guidelines for content creation:

Audience terms are best utilized in the context of formal or informal controlled vocabularies. None are presently recommended or registered by DCMI, but several communities of interest are engaged in setting up audience vocabularies. In the absence of recommended controlled vocabularies, implementors are encouraged to develop local lists of values, and to use them consistently.

Examples:

Audience="elementary school students"
Audience="ESL teachers"
Audience="deaf adults"

4.17. Provenance

Label: Provenance

Element Description: A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity and interpretation. The statement may include a description of any changes successive custodians made to the resource.

Guidelines for content creation:

Examples:

Provenance="This copy once owned by Benjamin Spock."
Provenance="Estate of Hunter Thompson."
Provenance="Stolen in 1999; recovered by the Museum in 2003."

4.18. RightsHolder

Label: Rights Holder

Element Description: A person or organization owning or managing rights over the resource. Recommended best practice is to use the URI or name of the Rights Holder to indicate the entity.

Guidelines for content creation:

Since, for the most part, people and organizations are not typically assigned URIs, a person or organization holding rights over a resource would be named using a text string. People and organizations sometimes have websites, but URLs for these are not generally appropriate for use in this context, since they are not clearly identifying the person or organization, but rather the location of a website about them.

Examples:

RightsHolder="Stuart Weibel"
RightsHolder="University of Bath"

4.19. InstructionalMethod

Label: Instructional Method

Element Description: A process, used to engender knowledge, attitudes and skills, that the resource is designed to support. Instructional Method will typically include ways of presenting instructional materials or conducting instructional activities, patterns of learner-to-learner and learner-to-instructor interactions, and mechanisms by which group and individual levels of learning are measured. Instructional methods include all aspects of the instruction and learning processes from planning and implementation through evaluation and feedback.

Guidelines for content creation:

Best practice is to use terms from controlled vocabularies, whether developed for the use of a particular project or in general use in an educational context.

Examples:

InstructionalMethod="Experiential learning"
InstructionalMethod="Observation"
InstructionalMethod="Large Group instruction"

4.20. AccrualMethod

Label: Accrual Method

Element Description: The method by which items are added to a collection. Recommended best practice is to use a value from a controlled vocabulary.

Guidelines for content creation:

Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.

Examples:

AccrualMethod="Deposit"
AccrualMethod="Purchase"

4.21. AccrualPeriodicity

Label: Accrual Periodicity

Element Description: The frequency with which items are added to a collection. Recommended best practice is to use a value from a controlled vocabulary.

Guidelines for content creation:

Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.

Examples:

AccrualPeriodicity="Annual"
AccrualPeriodicity="Irregular"

4.22. AccrualPolicy

Label: Accrual Policy

Element Description: The policy governing the addition of items to a collection. Recommended best practice is to use a value from a controlled vocabulary.

Guidelines for content creation:

Terms from controlled vocabularies may be developed for the use of a particular project or in general use in a cultural materials context.

Examples:

AccrualPolicy="Active"
AccrualPolicy="Closed"


Errata

2006-02-07: Corrected spelling (s/Languge/Language/)
2006-08-28, Errata: 'Type="Interactive Resource"' changed to 'Type="InteractiveResource"' in Section 4.4.