Skip to main content

Metadata Best Practices for DAMS Data Providers

This document provides best practice recommendations for creating metadata values that describe materials contributed to the UC San Diego Library's Digital Asset Management System (DAMS). It includes a high level overview of metadata elements, indication of what elements are required for submission to the DAMS, and recommendations for how the metadata values for some elements should be formatted.

This document is not restricted to a single encoding format, so it can be used with a variety of data encoding tools and methods (e.g. Excel, SharedShelf, MARC, XML, etc.). If you have questions regarding these recommendations or a specific encoding situation please contact us for assistance. For more information on rights and access metadata see the internal Rights Policy Group page or ask us.

These guidelines will evolve as new best practices are identified.

General Metadata Recommendations

  • The element list below is not exhaustive. There may be metadata elements that are necessary to describe your collection which are not listed below.
  • For guidance on elements not described below, contact us.
  • As a general rule it is better to provide granular descriptions. In other words, parse information into "small buckets" instead of large buckets.
  • For example, distinguishing different types of subjects (geographic, topical, etc.) rather than including all subjects under the less specific grouping of "subject".
  • If you do not see a metadata element with sufficient detail below, you can create your own element(s) for recording data.
  • For example, if cataloging maps, you may want to record information about what insets are available on a map. You could place this information in a "big bucket" like a generic "Notes" field, or a "small bucket" like a dedicated "Insets" field.
  • When your collection is ingested, your metadata analyst will map this to the DAMS metadata field which is the closest match.
  • You can also reference a content standard (e.g. DACS, RDA, CCO) for more detailed instructions and guidance about how to express and format descriptive data.
  • And don't forget the most important thing: Be consistent!

Metadata Element Overview

Metadata field Metadata Type Requirement
File name Administrative Required from data provider
Identifier Administrative Recommended when applicable
Date Descriptive Recommended when applicable
Language Descriptive Required from data provider
Names Descriptive Recommended when applicable
Publication information Descriptive Recommended when applicable
Subject Descriptive Recommended when applicable
Title Descriptive Required from data provider
Type of resource Descriptive Required from data provider

Metadata Element Details

Content file name

(required from data provider)

Best Practice:

  • Each file name must be unique within the collection.
  • Do not rely solely on your file names to encode descriptive metadata.
  • Use only alphanumeric characters a-z, 0-9, underscore “_” and hyphen “-“
  • Do not use spaces, use underscore “_”
  • Do not use characters such as: $ & [ ] “ \ / : * ? < > | , .
  • Only use period before file extension; using a period other than in this specific case can result in lost files or processing errors
  • Do not use more than 255 characters

Examples:

Simple object with unique filename

  • MouseBrainAtlas_v3.mov

Simple object with collection_creator_resource type-sequence of 1301 files

  • ccas_pickowicz_slide-0001.tif

Front and back of a postcard with a bib number  

  • b9281430_1.tif (front)
  • b9281430_2.tif  (back)

Manuscript with box and folder designators and sequence of 123 files.  These are the cropped files, the original scan files will not be ingested.

  • mss32_b049_f01_001-edited.tif
  • mss32_b049_f01_002-edited.tif
  • mss32_b049_f01_003-edited.tif
  • ...
  • mss32_b049_f01_123-edited.tif

Identifier

(recommended when applicable)

Best Practice:

  • Supply identifiers when available (e.g. accession numbers, barcodes, etc.).
  • Distinguish different types of identifiers by using a label or separating them into different metadata fields.
  • For a list of identifier types, see our GitHub Wiki.

Examples:

  • Resources which have both a bibliographic number identifier and a negative number associated with each item:
Item bib number negative number
1 b6885896 an3_a1096_1_1
2 b7862398 an3_a0084_1_1

Date

(recommended when applicable)

Best Practice:

  • The type of date(s) may vary depending on the material, but some commonly used date types include copyright date, creation date, date issued, date collected, and event date.
  • Be consistent in the format used for expressing dates.  For example, when expressing specific dates you could use a "Month DD, YYYY" format or a "YYYY-MM-DD" format. 
  • When a specific date is unknown, it is preferable to include an approximate date:
    • If an approximate single date is known, use the term 'circa', e.g. "circa 1975" (avoid the abbreviated forms of 'circa', e.g. c. or ca.).
    • For an approximate date within a known date range, use the expression "between YYYY and YYYY".  You can use the date range of the collection as an approximation of the date for an item within the collection. 
  • Use a date range when a work or collection was created over a known date span, e.g., 1937-1953.
  • If date is not known or cannot be approximated, do not include "unknown" as a value; instead leave the field blank.
  • Once again, you can reference a content standard for more detailed guidance on expressing dates.

Examples:

Date Format
For an item with no known date  
For an item created approximately in 1887 circa 1887
For an item created around 75,000 B.C. circa 75,000 B.C.
For an item or group of items created over the period of 1901-1909 1901-1909
For an item created between 1901 and 1909, but exact date unknown between 1901 and 1909
For an item created on a specific known date May 4, 2001
2001-05-04
For an item created on a less specific date July, 1978
For an item or group of items with no known date but which is part of a collection with the inclusive dates 1961-1976 between 1961 and 1976
  • Metadata for a collection of items with more than one type of associated dates:
Item Creation Date Performance Date
1 1967 2008-07-02
2 1972-05 1994-12-16

Language

(required from data provider)

Best Practice:

  • Record the language(s) represented in the resource.
    • For an item with a single language, record only that language.
    • For an item with multiple languages, record the predominant or most important language(s).
    • For an item with no linguistic content (e.g. instrumental music, images), record “No linguistic content” .
  • Optionally, add a language of material note describing the languages represented in the item.

Examples:

Item Language(s) Language Note
1 Spanish  
2 English, German, Polish The item is mostly in English but also contains German and Polish.
3 Korean, English Item is bilingual, Korean translated into English.

Names

(recommended when applicable)

Best Practice:

  • Record the name(s) of the person(s) or agency(ies) associated with the resource.
  • When providing names not from an authority file:
    • Format as family name, then first name (and any additional middle names and or intials), for example:
    • Pearce, Roy Harvey
    • For other naming practices, follow the appropriate convention:
    • Chen Cai
    • Supply vital dates if readily known:
    • Stevens, Wallace (1879-1955) Tarango, Adolfo R. (1957- )

Specify what role the person or corporate body has in relation to the resource.  Examples of roles include: creator, performer, photographer. For a full list of roles, see our GitHub Wiki.

Examples:

Item Composers Conductors Performers
1 Sessions, Roger (1896-1995) Szell, George (1897-1970) | Ormandy, Eugene (1899-1985) Zukofsky, Paul
2 Josquin, des Prez ( -1521) Nee, Thomas Ma, Yo-Yo (1955-    ) | Metropolitan Opera (New York, N.Y.) Orchestra
3 Mozart, Wolfgang Amadeus   Estey, Jackie | Doering, Michael | Doering, Mark | Morton, Clarke

Publication information

(recommended when applicable)

Best Practice:

  • Include place of publication, publisher name, and publication date in separate fields.

Examples:

Item Place of Publication Publisher Publication Date
1 Boston, Mass. Doubleday 1924
2 New York, New York Penguin Press circa 1938

Subject

(recommended when applicable)

Best Practice:

  • Include one or more subject(s) describing the resource.
  • If you need some suggestions on what subjects to apply, try browsing the “Topic” list at this link to get suggestions and enhance the potential for someone discovering your collections when searching collections similar to yours in the Digital Collections database.
  • Specify the type of subject; examples include genre/form, topical subjects, geographic subjects and name subjects. A full list of subject types can be found on the GitHub Wiki.
  • If using a controlled list of subjects, indicate the source (e.g. LCSH, MESH, AAT, TGM, etc.). 
  • Note: The UCSD Digital Collections will be changing its existing string-based, precoordinated LCSH subject terms into Linked Data-sourced URIs from, for example, FAST, VIAF, and GeoNames. We encourage data providers to seek out these or other Linked Data vocabularies for their subject terms. 

Examples:

Item Title Topical Subject Geographic Subject
1 Fiji, Terraces of Eua Dance | Kava Fiji
2 Fijian Natives Native dress | Rugby Football Fiji
3 Scenes in Polynesia Dance Polynesia

Title

(required from data provider)

Best Practice:

  • Transcribe the formal title of the resource if available.
  • If the resource does not have a formal title, use a title assigned by an authoritative source (e.g. Mona Lisa for the painting by Leonardo Da Vinci).
  • If there is no formal or assigned title, construct a title .
    • When constructing a title, provide enough detail so the title is not overly generic (e.g. "Speech to the House of Representatives" vs. “Speech”).
    • But avoid using the title to provide an extensive description of the content of a resource. Use an abstract or note instead.

Examples:

  • Anglican Church, Sulufou
  • UC President Clark Kerr speaking at Chancellor Galbraith's inauguration ceremony
  • View of Pacific Beach, San Diego
  • Mona Lisa
  • Codex Angelicus 123

Negative Examples of Constructed Titles: I’m

  • Too much information in the title:
    UC President Clark Kerr speaking at Chancellor Galbraith's inauguration ceremony, photo taken by Roger Kline on June 3, 1962. Includes students and Geisel Library in the background.
  • Too little detail:
    San Diego

Type of resource

(required from data provider)

Best Practice:

  • Use a value from the following list to indicate the type of resource:
    • cartographic
    • data
    • moving image
    • multimedia
    • notated movement
    • notated music
    • software
    • sound recording
    • sound recording-musical
    • sound recording-nonmusical
    • still image
    • text
    • three dimensional object
  • Value should be determined by the material's content and not the file format (e.g.  an image of a page of text should have the value "text" and not "still image").
  • Multiple values can be assigned.

Examples:

  • An image of a manuscript page may have the value of "text" and not "still image".
  • An audio recording of an oral history which has music in the background may have the value of "sound recording-nonmusical" rather than "sound recording-musical", assuming the oral history is the primary focus of the material, or could have both if the music is also important.
  • A poster may be an “image” if the content is primarily visual, or it may be “text” if the content is primarily text-based, or both.

Developed by the UC San Diego Library Metadata Policy Group, last updated November 16, 2016.