Guidelines for Use of Dublin Core in University of Chicago Library Projects

Rev 3/18/99; 4/28/99

[Note: This is a copy of an internal document from the University of Chicago Library. It reflects the library's usage at the time at which the metadata records for First American West were created.]

The following guidelines are a work in progress. Additions and refinements may be made as types of material and various projects dictate.

I. General Principles
II. University of Chicago Interpretation and Use for Digitized Surrogates
III. Specific Dublin Core Elements
IV. University of Chicago Library Extensions to the Dublin Core
Appendix A: Authority List for DC.Type
Appendix B: Examples


1. The same general guidelines should apply regardless of project or intended audience.

2. Data elements should be omitted if their encoding would be misleading or irrelevant.

3. If supplying a data element would not be misleading or irrelevant, the data element should be supplied. For example, DC.Type should be supplied on all records, even if the value would be the same for all records in a project.

4. If a data element is supplied, the use of it should be consistent with MARC/AACR2 cataloging where applicable and reasonably easily ascertained. For example, if the library has cataloged an ejournal in Horizon, the same title should be used in DC.Title.

5. Either qualified or simple (unqualified) Dublin Core is allowable in library projects. However, the guidelines below pertain primarily to simple Dublin Core.

6. Local extensions to Dublin Core are allowed, although particular projects or situations (e.g. CORC participation) may not support them. Local extensions should be identified as belonging to the University of Chicago Library (UofCL) namespace.

7. Do not use ending punctuation except within elements such as DC.Description where the content is given in complete sentences.


1. Many projects are concerned with retrospectively digitizing source materials in other formats. The University of Chicago Library does not follow a strict interpretation of the principal of 1:1. DC.Creator, DC.Contributor, and DC.Date are used to describe the source material when applicable. DC.Publisher is used to describe the publisher of the digital surrogate.

2. When describing a digital surrogate, the DC.Relation element should always contain a complete citation to the original source object as the subelement IsFormatOf. E.g., DC.Relation.IsFormatOf "Women Drown; Booze-Driven Car Slays Girl", The Chicago Daily Tribune, October 18, 1919.


This section contains guidelines for using metadata elements defined in the DC namespace.

Guidelines taken directly from Diane Hillman's User Guide for Simple Dublin Core are given in italics below.

1. Title

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

1.1. If there are multiple titles you may use them all, but select one as DC.Title and call the rest DC.Title.Alternative.

1.2. If the source object is a newspaper article, use the headline as DC.Title.

1.3. If the source object is a captioned photograph or illustration from a newspaper or other publication, use the caption as DC.Title.

1.4. If the object is a document such as an article or paper, use the title of the document as DC.Title.

1.5. If the object is in HTML, derive title information from a variety of sources, such as a meaningful title in the H1, text imbedded in the <TITLE > tags, and/or title information represented in a prominent graphic image. Supply this as DC.Title or DC.Title.Alternative as appropriate.

1.6. If there is no relevant title information associated with the source object, a descriptive title can be made up. Do not put made-up titles in brackets.

1.7. Record the title as it appears, including the initial article, if any. However, for consistency with ISBD, change capital letters to lower case, except for the first letter of the first word, and proper names.

2. Creator

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.

2.1. Creators should be listed separately.

2.2. Names should be consistent with the LC Name Authority File (LCNAF), where the authorized form of the name can be reasonably easily ascertained.  The authoritative form of name should be determined by searching in the LCNAF.

2.3. Authorized forms of names should be noted by use of a SCHEME qualifier, e.g. SCHEME="LCSH".

2.3. If an authorized form of name cannot be found, 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.

2.4. Since this element refers to the intellectual content of the object, DC.Creator should always refer to the author or creator of the source object, not the digital surrogate (if any).

2.5. If the source object is a newspaper article, give the person(s) mentioned in the bi-line (if any) as DC.Creator. If there is no bi-line use the name of the newspaper.

2.6. If the source object is a photograph or slide, give the photographer as DC.Creator; if the photographer is unknown, omit DC.Creator.

2.7. If the source object is an original web page, DC.Creator may be included or omitted. Use judgement to decide whether the creator is likely to be significant (e.g., for a bibliography) or irrelevant (e.g. for a "portal page") from a user or searcher’s point of view. For LibInfo pages, it is not necessary to give the individual or department noted as responsible for maintaining the page as DC.Creator.

3. Contributor

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

3.1 Interpret this element to include any contributor apart from author or creator (i.e., the contribution need not be secondary).

3.2. Contributors should be listed separately in repeated iterations of DC.Contributor.

3.3. The form of name should follow the same rules as for DC.Creator above.

3.4. Contrary to the formal definition of this element, contributors do not need to have contributed to the intellectual content of a source object, but can be associated withthe source object in other roles. For example, the Chicago Metro History Fair can be given as DC.Contributor for an image collected and digitized by the History Fair.

3.5 In general, supply only prominently named contributors as DC.Contributor. When in doubt as to whether to include a name, leave it out.

4. Publisher

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.

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

4.2. If the nature of the responsibility is ambiguous, the recommended practice is to use Publisher for organizations, and Creator or Contributor for individuals.

4.3. Where the object being described is a digital surrogate of a source object, DC.Publisher refers to the surrogate. For example, the DC.Publisher of a newspaper article scanned from paper into a gif file is the entity which made the gif file available, not the publisher of the newspaper.

4.4. When an individual working for an organization is the publisher as part of his job, use the organization in DC.Publisher. For example, if John Smith in the Systems Office put something on the Web, the publisher is the Systems Office.

4.5. For objects published locally as part of projects, supply DC.Publisher with the most granularity as possible. For example, prefer "University of Chicago Library, Department of Special Collections" to "University of Chicago" or "University of Chicago Library".

4.6. For LibInfo portal pages, use "University of Chicago Library" in DC.Publisher.

4.7. For consistency with AACR2, for articles published in ejournals, use the name of the publisher of the ejournal, not the title of the ejournal, in DC.Publisher. For example, if the object being described is an article in PACS Review , the publisher is the University of Houston Libraries, not PACS Review .

4.8. The form of name in the publisher element does not need to be consistent with the form used as a name heading.

5. Date

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

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

5.2.When describing the digital surrogate of a source object, DC.Date should refer to the creation date of the source object.

5.3. For web pages and other frequently updated materials, use only the creation date, not the date of last update. If a web page indicates only the date of last update, omit this element.

5.4. Use of qualifiers is encouraged. Acceptable qualifiers include:


6. Source

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.

6.1. Following recommended best practice, do not use DC.Source; use DC.Relation instead.

7. Relation

Description: An identifier of a second resource and its relation 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:



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"


Creator="John, Elton"


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


Relation= Requires stdio.h"

Title="List of Internet Media Types" Relation="IsRequiredBy Dublin Core 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.]

7.2. When describing the digital surrogate of a published or unpublished document, use DC.Relation.IsFormatOf for a complete citation to the original. Follow standard citation format as found in the latest edition of the Chicago Manual of Style (14ed., 1993) where possible. For example,

Allen, G.M. 1939. Bats. Cambridge: Harvard University Press

Article in a serial:
Bennett, John W. 1946. The interpretation of Pueblo culture: A question of values. Southwestern Journal of Anthropology 2:361-74

7.3. When describing an article from an electronic journal, use DC.Relation.IsPartOf for a citation to the journal, including when available the title of the journal, enumeration and chronology, and the pagination of the article.

7.4. For the case of an article scanned from a paper journal (e.g. for ereserves), use DC.Relation.IsFormatOf for a complete citation to the paper article including article title, journal title, publisher, enumeration and chronology, and pagination.

7.5. When describing an original web page that is part of a larger, titled website, use DC.Relation.IsPartOf to identify the website. E.g. DC.Relation.IsPartOf eCUIP website.

7.6. If the object being described is listed in a bibliography, do not use DC.Relation.IsPartOf to cite the bibliography. Only use IsPartOf when the object itself is part of another object. In the case of the bibliography, a reference to the object (not the object itself) is actually part of the bibliography.

7.7. DC.Relation.IsProvidedFor can be used to indicate that a resource was acquired, assembled or otherwise made available for a particular person or purpose. For example, DC.Relation.IsProvidedFor Mrs. Gaal’s 5 th grade class at McCosh Elementary School.

8. Description

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.

8.1. Since the description field is a potentially rich source of indexable vocabulary, care should be taken to provide this element when possible.

8.2. Normally description should be limited to a few brief sentences.

8.3. DC.Description for textual objects should describe the content of the object (e.g. "Newspaper article about the possibility of life on Mars...") not the source or history of the object (e.g. "Article published in the Chicago Tribune , December 15, 1919").

9. Subject

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.

9.1. Select subject keywords from either the Title or Description information. However do not be limited by this -- feel free to assign any applicable words or phrases that would aid in retrieval.

9.2. If the subject of the item is a person or organization, use the same form of name you would for Creator.

9.3. In general, choose the most significant and unique words for keywords, avoiding those too general to describe a particular item.

9.4.. Use of LCSH or other authority is encouraged, although not required. If used, follow standard display punctuation (e.g. use dashes to separate subject subdivisions). Do not use ending punctuation. If LCSH is used, always supply the qualifier SCHEME="LCSH".

9.5. Subject terms should be as specific as possible.

9.6. Subjects should be listed separately in repeated iterations of the element.

10. Type

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

10.1. If applicable, take DC.Type from the authority list in Appendix A.

11. Format

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.

11.1 Electronic formats such as text/html, ASCII, Postcript, executable application, or JPEG may be included in this area. In these cases, assign a format from Internet Media Types. See

11.2. Information concerning the size of a resource may be included in the content of the Format element.

11.3. For electronic media, describe the digital format (e.g. text/html) in DC.Format. Describe the nature of the object (e.g. working paper) as the second DC.Type element.

12. Identifier

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 ISBNs or other formal names are candidates for this element.

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

12.2. One (and only one) occurrence of DC.Identifier.URI should always be used for the URN (e.g. handle) or URL of the object. If the object has both a handle and a URL, use the handle as DC.Identifier.URI.

13. Language

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, see; examples include en, de, es, fi, fr, ja, th, and zh. These codes are also available in ISO 639, see

13.1. Omit this element for non-textual objects; include it consistently for textual ones.

13.2. For English language materials, use "en".

13.3. If there is more than one language, use multiple occurrences of DC.Language.

14. Coverage

Description: The spatial or temporal characteristics of the intellectual content of the resource....

14.1. This element is under discussion at the DC workshops and may not have a stable definition. Omit this element for the time being. Where place or time is important information about the content of a resource, e.g. for a photograph of a building in Chicago in 1919, it can be indicated in DC.Subject and DC.Description.

15. Rights

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.

15.1. At present, this element can be used for either a textual statement or a URL.

15.2. If a statement of copyright applies to the object, include the copyright statement in DC.Rights.


This section defines and describes metadata elements in the University of Chicago Library namespace (UofCL).

1. Access

Description: A statement describing restrictions on access or other access policy.

1.1. Use UofCL.Access to note that a resource is restricted by IP filtering to members of the campus or some other community. For example, "Access to this resources is restricted by contract to computers on the Chicago Public Schools (CPS) network."

2. Icon

Description: An identifier that links to a displayable icon that can be used in association with the object.

3. Rating

Description: A term or code to indicate rating or ranking of the content of the resource.

3.1. The system used in rating should always be indicated in a SCHEME qualifier, e.g. SCHEME="Grade".


APPENDIX A. DC.Type Authority List for University of Chicago Libraries

Adapted from Dublin Core Resource Types, Structuralist DRAFT, July 24, 1997

APPENDIX B. Examples


Object: JPEG image of an untitled lantern slide.

DC.Title View of lake with mountains

(supplied by cataloger)

DC.Creator Fuller, George D.

(the photographer)

DC.Publisher University of Chicago Library, Department of Special Collections

(the unit responsible for the AEP project, making these photographs available on the web; note that since the publisher is not a name heading the form of name in the catalog is not followed ("University of Chicago. Library. Dept. of Special Collections")

DC.Date.Created 1897

DC.Relation.IsFormatOf Unpublished lantern slide taken by George D. Fuller, 7.1 x 5.4 cm.

DC.Description View of mountain lake with trees, rock and unidentified man in the foreground, mountains in the background. Taken in Loch Vale, Colorado.

DC.Subject Loch Vale, Colorado

DC.Type Image.Photographic (lantern slide)

DC.Format image/jpeg, 72 dpi

("image/jpeg" is from mime authority list, followed by additional relevant information)




Object: An html transcription of a newspaper article originally published in the Chicago Tribune in 1919. The transcription was created by the Metro History Fair and mastered onto an interactive CD called "Chicago in 1919" by a company in the UK, then taken from the CD and mounted on the eCUIP website by Library Systems on behalf of CUIP.

DC.Title Women drown; booze-driven car slays girl

DC. Title.Alternative joyriders kill 3; racer knocks auto into lake

DC.Creator Chicago Daily Tribune

DC.Contributor Chicago Metro History Fair

DC.Date.Created 1919-10-18

DC.Relation.IsFormatOf "Women Drown; Booze-Drive Car Slays Girl", Chicago Daily Tribune, October 18, 1919.

DC.Description Newspaper article describing three automobile-related fatalities.

DC.Subject automobile accidents

DC.Subject drunk driving

DC.Subject Chicago

DC.Type Text.Article

DC.Format Text/html

DC.Identifier.URI dline/d3/cardeth2.html

DC.Language en

DC.Rating Middle, High


Object: Article from published paper journal scanned locally.

DC.Creator Bohannan, Paul

DC.Creator Curtin, Philip

DC.Title African markets

DC.Date.Issued 1963

DC.Relation.IsFormatOf "African Markets" in Bohannon, Paul & Curtin, Phillip, eds. African and Africans. Garden City, New York: Natural history press, 1963. p 155-172

(IsPartOf relation is omitted as this would be entirely redundant with IsFormatOf)

DC.Subject African marketplaces

DC.Type Text.Mongraph.Chapter

DC.Format application/pdf


DC.Language en


Object: E-journal article.

DC.Title: Development of CONSER cataloging policies for remote access computer file serials

DC.Creator Anderson, Bill

DC.Creator Hawkins, Les

(there is no record for these authors in the PAC, so names are taken from piece as published)

DC.Publisher University Libraries, University of Houston

DC.Date.Issued 1996

DC.Relation.IsPartOf The Public-Access Computer Systems Review 7, no. 1 (1996): 6-25


DC.Subject Remote Access Computer File Serials

DC.Subject Resource description

DC.Subject Cataloging electronic journals

DC.Type Text.Article

DC.Format text/html


DC.Language en



Object: Web page created for LibInfo.

DC.Title The libraries and collections

DC.Publisher University of Chicago Library

DC.Date.Created 1998-09-15

DC.Relation.IsPartOf LibInfo website

DC.Description A portal page of links to a general introduction to the University Library; descriptions of the 8 individual libraries, Special Collections, and government documents; and the Working Plan for Digital Information.

DC.Subject University of Chicago Library

DC.Type Text.WebPage

DC.Format text/html


DC.Language en


Object: UMI ProQuest.

DC.Title ProQuest Direct

DC.Publisher University Microfilms International (UMI)

DC.Date.Issued 1994-

(this is the date from the copyright screen, which is also in the imprint of the cataloging record)

DC.Description ProQuest Direct is an online information service that provides summaries of articles from over 5,000 newspapers, journals and other publications. Particularly strong in business and economic information. Includes ABI/Inform. Many articles are available in full text and/or full image format.

DC.Subject Periodicals indexes

DC.Type ??? [we have a query out to the type subgroup on this]

DC.Format ???


DC.Language en

Return to top of page.

HTML created: 4/28/99
By Cameron J. Campbell

HTML revised by Merle Steeves: 4/16/02