Best practices for creating sharable metadata

The translation on this website may be generated by machine translation. The quality and accuracy of machine translation can vary significantly from one text to another. Read the page in original English here.

Challenges

Essentially there are four types of problems that we see when metadata are viewed outside the context of the collection home. These were generally described in a 2006 article i published by First Monday.

Typical problems include:

• Lack of consistency within a single collection.
  • Example: The use of both the Dublin Core and elements to record some variant of the resource creation date.
  • Example: Inclusion of technical information such as date digitized and type of scanner used.
  • Example: Exclusion of a collection name that is essential to make sense of the record.
  • Example: Metadata encoded in XML with character encoding problems.

  Recommendations

  Likewise, Shreeves (2006) recommends several general practices which CONTENTdm collection administrators would do well to consider. They include:

  • We encourage institutions to think carefully about how they might generate multiple views of resources using the metadata already created rather than simply sharing a single record describing everything about a resource.
  • An institution should understand what an aggregator needs included in the metadata (learning standards? audience level?) to support its service and, when possible, work to meet those needs.
  • Metadata aggregators can more effectively normalize records from metadata providers if all records within a defined set are consistent both semantically and syntactically.
  • When multiple values are needed, the metadata element should be repeated.

  And from M .J. Han, et al, at the University of Illinois ii come these further recommendations. Since their research focused on sharing CONTENTdm collection metadata with OAI harvesters, these are especially relevant to our community:

  • Keep a balance between specificity and generality in defining local fields.
  • Decide at the outset which locally defined fields are intended only for the local environment and which should be made available to aggregators.
  • Be cognizant of how values will be created in the local environment.
  • Maximize use of Qualified Dublin Core elements for labeling in the local environment.
  • Consider taking field names and definitions, if possible, directly from other metadata standards such as EAD, VRA Core and CDWA when creating locally developed application profiles.
  • Share the logic of mapping decisions with aggregators.

  Opportunities

  In the current metadata aggregation landscape, it is safe to assume that users search and browse for resources at an aggregator’s site then follow a link back to the home institution for access to the resource itself and any additional metadata. Therefore, when creating metadata for the purposes of inclusion in these aggregations, one can afford to be selective about the data elements included, with the understanding that a user will find his way to the local records for full contextual information. (Shreeves, 2006 )

  On July 20, 2009, the OCLC Digital Collection Gateway became available to all CONTENTdm 5.1 users in the form of CONTENTdm WorldCat Sync. This integrated function enables a CONTENTdm collection administrator to map qualified and simple Dublin Core elements from digital items held in the CONTENTdm collection, to MARC fields, creating and modifying WorldCat records that are synchronized on a schedule set by the collection administrator. The Gateway thus represents a timely opportunity to provide specific Dublin Core metadata schemas for use in CONTENTdm and intended for OAI-PMH harvesting, and underscores a rather urgent need to provide advice to our community.

  Below are some notes on creating and configuring metadata for discovery of digital items in WorldCat.org:

  • For all fields that you want to display in WorldCat, configure the metadata fields in CONTENTdm so that those fields are mapped to an appropriate Dublin Core element . You can use any Simple Dublin Core and Qualified Dublin Core elements. We recommend using Qualified Dublin Core elements for the best mapping results.
  • Date fields should use consistent date formatting.
  • Metadata fields set to hidden in CONTENTdm are not available for use with the Digital Collection Gateway.
  • If you opt to make a field non-searchable in CONTENTdm and map that field into the Digital Collection Gateway, the field will be searchable in WorldCat.org.

  Core and recommended metadata elements

  An element is a descriptive category of information about the resource . All of the elements used to describe a resource together make up a record. (NCSU Libraries Core 1.0 Metadata Element Set Best Practices)

  The following is a set of guidelines for understanding using and mapping Dublin Core elements according to the Open Archives Initiative Protocol for Metadata Harvesting. It began as a guide for CONTENTdm collection administrators, and was expanded with the opening of the OCLC Digital Collection Gateway to WorldCat for all OAI-PMH compliant repositories. These guidelines promote the simplification of local information to enable better end-user discovery in an aggregated environment. As with any Best Practices Guide, it is recommended that catalogers follow basic rules of consistency with grammar and syntax (content standard) set forth in resources such as AACR2, DACS, CCO, etc., as well as incorporate the use of controlled vocabularies such as LCSH, AAT, MeSH, and authority lists such as LCNAF and ULAN or locally-grown thesauri as appropriate to the subject matter of a resource. For each digital collection, a collection -level record should be created along with item-level records. Metadata elements should contain labels most useful to the local environment, but should be mapped to standard Dublin Core elements .

  A note about repeating fields: A number of works have been published offering best practices for configuring OAI-harvestable metadata. Although these works recommend repeating fields versus multiple values, in some cases multiple values (separated by a semicolon) are preferred for accuracy depending upon the level of complexity in configuring a collection using your digital collections management software and the OAI harvesting tool. For example, semicolon-separated values can be easily accommodated in CONTENTdm as well as display accurately when synced to WorldCat.org via the Digital Collection Gateway. When in doubt, test your data sets against your chosen OAI harvester.

  Explanation of table components

  • Core, recommended: The main fields to be used to describe a resource, important for sharing outside of local context.
  • Recommended, as appropriate: The secondary fields which are helpful if available. To use or not depends on the circumstances and the collection manager.
  • Yes: A field may appear multiple times in a single record.
  • Not preferred: A field should occur only once in a single record.

  Core and recommended elements

  • Prefer literal and non-numeric description of resource, excluding material -type information if possible.
  • Prefer non -use of explanatory or qualifying symbols ( e.g., brackets to indicate cataloger-supplied title).
  • If the recourse has multiple titles ( e.g., translated titles, etc.), prefer to use Title-Alternative element.

  “Make the title descriptive yet brief. Use generic titles to bring together different images of the same subject, if possible (e.g., use Mayor Benjamin Bosse on all photos of him, so they display together by title).” – Metadata Guidelines, Evansville Photos Collection, Evansville Vanderburgh Public Library.

  Title-Alternative
  • Examples of a Creator include a person, an organization, etc.
  • “Prefer use of Name (personal or corporate) Authority Source to be used consistently throughout description of a resource and from one resource to another.” - Metadata Implementation Guidelines for North Carolina Digital State Documents
  • Prefer non-use of "junk value" (e.g., Unknown) however, it is appropriate to qualify named entities with [role].
  • WorldCat.org display mapping: dc:creator maps to MARC 720 by default in the Gateway. To enhance precision in fielded searching within WorldCat.org, map dc:creator to MARC 100 (for Personal Name) or 110 (For Corporate Name).

  “Do not use honorifics, titles, or nicknames unless it is necessary to disambiguate (e.g., the first name of the person is unknown). Otherwise, these alternate forms of names (such as “Buddy” Jones; Reverend Murrell; Dr. Reed) may be used in the Description field but not as the authoritative version. ” – Huntington Digital Library Guidelines, The Huntington Library

  Contributors
  • Examples of a Contributor include a person (e.g., additional writer, illustrator, editor, finding aid author, etc.), an organization, etc .
  • Contributors are named so because their responsibility for the creation of a work is not equal to that named as Creator.
  • Prefer use of Name (personal or corporate) Authority Source to be used consistently throughout description of a resource and from one resource to another.
  • Prefer non -use of "junk value" ( e.g., Unknown) however, it is appropriate to qualify named entities with [role].

  “Persons or organizations who made significant intellectual contributions to the resource, but whose contribution is usually secondary to the person or organization specified in the Creator element. Examples include co -author, editor, transcriber, translator, illustrator, etc.” – Metadata Implementation Guidelines for North Carolina Digital State Documents

  Description
  • Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.
  • Some digital collections management practitioners prefer the local practice of mapping separate Table of contents, abstract, and similar local elements, to description.
  • Prefer collection-based cataloger decision on enabling full-text searching for this field.
    • If data type Full Text Search, prefer no mapping to WorldCat. See Description-Abstract element.
    • If data type Text, prefer mapping wc.Summary (MARC 520 [8 ]) .

    “Also include any other information a searcher might need to find an image through a keyword search or to understand the context of the image: Is there a view of the Mississippi River? Was a photograph taken from the future site of a university library? Does a building no longer exist? What location was a photograph taken from? Is it an aerial view” – WAICU Metadata Guide

    Description-Abstract
    • With CONTENTdm, only one Full Text Search field per collection is allowed; therefore if Description field is of data type Full Text Search, Description-Abstract will be of Text data type.
    Description-Table Of Contents

    Chapter 1: Getting started. 1

    • Examples of a Publisher include a person, an organization, etc.
    • Prefer use of Name (personal or corporate) Authority Source to be used consistently throughout description of a resource and from one resource to another.
    • Prefer non-use of "junk value" ( e.g., Unknown).
    • Prefer “digitized by” or other text prefix to qualify value; Gateway allows both prefix and suffix text constants for each field in every profile.

    “The entity responsible for making the Resource available in its present form, such as a corporate publisher, a university department, or a cultural institution.” – University of Wisconsin Digital Library Data Dictionary

    • Typically, the subject will be represented using keywords, key phrases, or classification codes. Recommended best practice is to use a controlled vocabulary.
    • WorldCat.org display mapping: prefer map to MARC 650 if controlled, to MARC 653 if uncontrolled.
    • To describe the spatial or temporal topic of the resource, use the Coverage element.

    “Use subject terms that describe what an object is as well as what it is about. Example 1: Mural painting and decoration; Derry (Northern Ireland); Ireland— History — Easter Rising, 1916.” – Guidelines for Metadata Application in the Claremont Colleges Digital Library

    Identifier

    URL: Gateway selects the first Identifier that contains a URL and makes it the default value for the resolution URL in MARC 856 $u.

    Thumbnail display images:

    CONTENTdm supplies the Reference URL to Identifier. This not only provides the resolution URL but also automatically generates the thumbnail for WorldCat.org.

    *Repeatability: It will take all other URLs in repeating Identifier fields, and place them in repeating 856 fields but with no $3 text.

    • Non -URL: Examples include accession number, ISBN, photo negative job/roll/frame number, call number, etc.

    Digital Collection Gateway automatically populates a value for a non-URL Identifier (MARC 024).

    “If contributing a digital resource to a collaborative digital collection, consider prefixing the character string with an institutional code to keep your resources distinguishable from those owned by other institutions.” –Mountain West Digital Library Metadata Group Recommended best practice is to identify the resource by means of a string conforming to a formal identification system.

    “Separate terms by semi-colon (;) and a space. For example, for French and English: fre; eng” – Metadata Supplement for Fashion Plate Collection, Claremont Colleges Digital Library

    • Prefer free text statement of rights to a "lonely" URL.
    • Rights information includes a statement about various property rights associated with the resource, including intellectual property rights.
    • Rights statements should provide references or contact information. Additional clarification can be indicated via linking to an institutional policy statement or other web resource.

    “These statements should be given in the form: Rights status. Reproduction/use restrictions. Further information.” – Core 1.0 Metadata Element Set Best Practices, NCSU Libraries

    Rights-Access Rights

    Element name	Rights-Access Rights
    DC definition	Information about who can access the resource or an indication of its security status.
    Required	Recommended, as appropriate
    Controlled vocabulary
    Syntax scheme
    DC Element Map	Access Rights (dcterms:accessRights)
    MARC map in WorldCat	( 506##$a enhancement recommended )
    Repeatable	Yes
    Best practices	Access rights may include information regarding access or restrictions based on privacy, security, or other policies.

    Rights-Rights Holder
    • Moving images, three-dimensional objects and sound recordings are all examples of Resource Types.
    • Prefer DCMI Type Vocabulary for controlled list of authorized terms: http://dublincore.org/documents/dcmi -type -vocabulary/
    • To describe the file format, physical medium, or dimensions of the resource, use the Format element.

    “This element should be populated from the DCMI type vocabulary, a controlled listing of genre types. It may be automatically populated, based on characteristics of the repository.” – NCSU Libraries Core 1.0 Metadata Element Set Best Practices

    • Examples of dimensions include size and duration.
    • Prefer use of Internet Media Types [MIME] or two -part (type/subtype) identifier in a single string: http://www.iana.org/assignments/media -types/. E.g., audio/mp3; image/jpg; application/pdf; text/html.

    “New media types and applications are always emerging. If the resource format being described is not yet part of the MIME type list, select a broad category of object format for the first part of the MIME type, then use the file name suffix for the second half.” – University of Louisville CONTENTdm Cookbook

    Format-Extent
    • Examples include a number of pages, a specification of length, width, and breadth, or a period in hours, minutes, and seconds. E.g., 109,568 bytes; 00:16 minutes.
    Format-Medium
    • Date may be used to express temporal information at any level of granularity. Recommended best practice is to use an encoding scheme, such as the W3CDTF profile of ISO 8601 [W3CDTF]. See Appendix B: Dates
    • Prefer non-use of "junk value" ( e.g., Unknown).
    • If more than one date is going to be used to describe the resource, it is recommended to use the sub-elements of Date to clarify the type of date, such as Date-Accepted, Date-Issued, etc.
    • If only one Date value is present, users may choose to use the Gateway Prefix/Suffix feature to explain the context of the date given, e.g., a literal such as “Digitally published.” By default, Gateway maps dc:date to MARC 260 $6 (Date of publication, distribution).

    “Similarly, if you will describe both physical and digital manifestation properties in your local system using unique field names, consider whether you intend to follow the Dublin Core one-to-one principle, in which case only metadata about one manifestation will be mapped and made available to aggregators.” – Metadata for Special Collections in CONTENTdm: How to improve interoperability of Unique Fields through OAI-PMH

    Date-Accepted
    • Examples of resources to which a Date Accepted may be relevant are a thesis (accepted by a university department) or an article (accepted by a journal).
    • Prefer to use the “Prefix/Suffix” feature in Gateway with label "Date Accepted." E.g., Date Accepted 2010 - 03 - 17.
    Date-Submitted
    • Examples of resources to which a Date Submitted may be relevant are a thesis (submitted to a university department) or an article (submitted to a journal).
    • Prefer to use the “Prefix/Suffix” feature in Gateway with label "Date Submitted." E.g., Date Submitted 2010 - 03 - 15.
    Date-Created Date-Available Date-Copyrighted
    • Prefer to use the “Prefix/Suffix” feature in Gateway with label "Date Copyrighted ". E.g., Date Copyrighted 2010- 03.
    • • Both dcterms:dateCopyrighted and dcterms:issued are mapped to MARC 260 $c by default in Gateway.
    Date-Issued
    • Both dcterms:dateCopyrighted and dcterms:issued are mapped to MARC 260 $c by default in Gateway.
    • Prefer to use the “Prefix/Suffix” feature in Gateway with label "Date Issued."
    • Prefer use of free text description incl., Collection Name, Accession Number, Physical Dimensions for graphic materials and Repository information.
    • Prefer “Original Format” or other text prefix to qualify value.

    “Enter information about the original item before digitization as follows: genre of item: collection name, name of box, number of bin. Ex: 35 mm color slide: Larry Oglesby Collection, Morro Bay FT, bin #8” – Data Dictionary for Larry Oglesby Collection, LO C — Claremont Colleges Digital Library

    • Include sufficient information in the Relation element to enable users to identify, cite, and either locate or link to the related resource.
    • *Some communities of practice reference both the Physical Collection and the Digital Collection.
    • When applicable, use the more specific sub-elements.

    “The described resource is a physical or logical part of the referenced resource.” – University of Wisconsin Digital Library Data Dictionary

    Relation-Has Format Of
    • The described resource is treated as the primary/pre-existing resource. For example, the postcard, "See Seattle" postcard, Alaska Yukon Pacific Exposition, 1909, Has format of TIFF, scanned from original text, "See Seattle" postcard digital reproduction, Alaska Yukon Pacific Exposition, 1909, at 400 dpi. (See Relation - Is Format Of element).
    Relation-Is Format Of
    • The described resource is treated as the secondary/supplement recourse. For example, the TIFF image, "See Seattle" postcard digital reproduction, Alaska Yukon Pacific Exposition, 1909 , Is Format Of the original postcard, "See Seattle" postcard, Alaska Yukon Pacific Exposition, 1909 , in 7 x 5 1/2 inch. ( See Relation - Has Format Of element).
    Relation-Has Part

    Element name	Relation-Has Part
    DC definition	A related resource that is included either physically or logically in the described resource
    Required	Recommended, as appropriate
    Controlled vocabulary
    Syntax scheme
    DC Element Map	Has Part (dcterms:hasPart)
    MARC map in WorldCat	774 08 $n
    Repeatable	Yes
    Best practices	“(For example) The described resource is an anthology that includes this article as well as other articles, each of which is described in another Relation [HasPart] element.” - CDP Dublin Core Metadata Best Practices Version 2.1.

    Relation-Is Part Of
    • Used to state the collection to which this resource belongs. E.g., for Articles, this element indicates the host item (e.g., journal, series, etc.)

    “The described resource is a physical or logical part of the referenced resource.” – University of Wisconsin Digital Library Data Dictionary

    Relation-Has Version
    • For example, Microsoft Office software Has Version Microsoft Office 97, Microsoft Office 2003, Microsoft Office 2010, etc.
    Relation-Is Version Of
    • For example, The Lord of the rings published by London: HarperCollins, in 2009 Is Version OfThe Lord of the rings published by LONGMAN YORK PRESS in 1940s.

    “Changes in version imply substantive changes in content rather than differences in format. ” - CDP Dublin Core Metadata Best Practices Version 2.1

    Relation-Replaces
    • For example, Best Practices for CONTENTdm and other OAI -PMH compliant repositories 3.0ReplacesBest Practices for CONTENTdm and other OAI - PMH compliant repositories 1.0.
    Relation-Is Replaced By

    Element name	Relation-Is Replaced By
    DC definition	A related resource that supplants, displaces, or supersedes the described resource
    Required	Recommended, as appropriate
    Controlled vocabulary
    Syntax scheme
    DC Element Map	Is Replaced By (dcterms:isReplacedBy)
    MARC map in WorldCat	785 00 $n
    Repeatable	Yes
    Best practices	For example, Best Practices for CONTENTdm and other OAI -PMH compliant repositories 1.0 Is Replaced By Best Practices for CONTENTdm and other OAI - PMH compliant repositories 3.0.

    Relation-Requires
    • This could be the technical information about an item. For example, a downloadable article Requires Adobe Acrobat Reader, version 6.0.

    “When the resource being described requires the use of software, hardware, or other infrastructures that are external to the resource itself, record that information in the Relation [Requires] element. For example, if a Dublin Core record for the digitized version of a hand- written letter is delivered to the user as a PDF file, Adobe Acrobat Reader (which is external to the resource being described) is required to view that PDF file” – CDP Dublin Core Metadata Best Practices Version 2.1

    Relation-Is Required By
    • For example, the described resource is a life sciences dataset underline the scientific findings and Is Required By the paper, Making Logistic Regression A Core Data Mining Tool With TR-IRLS.
    • A location, period of time, or jurisdiction of described resources. Spatial topic and spatial applicability may be a named place or a location specified by its geographic coordinates. Temporal topic may be a named period, date, or date range. A jurisdiction may be a named administrative entity or a geographic place to which the resource applies.
    • For Spatial topic, prefer to use Coverage-Spatial element. For temporal topic, prefer to use Coverage-Temporal element.

    “For artifacts or art objects, the spatial characteristics usually refer to the place where the artifact/object originated while the temporal characteristics refer to the date or time period during which the artifact/object was made.“ - CDP Dublin Core Metadata Best Practices Version 2.1

    Coverage-Spatial
    • Prefer use of standard controlled vocabularies and name authority sources , such as Thesaurus of Geographic Names [TGN].
    • Some communities of practice reference geographic information system coordinates, such as those made available by Google Earth ®

    “Currently recommended by the “Collaborative Digitization Project Dublin Core Metadata Best Practices” guide for use only ‘in describing maps, globes, and cartographic resources or when place or time period cannot be adequately expressed using the Subject element.’ Coverage spatial refers to the extent or scope of the content of the resource ( e.g., place shown on a map or in a photograph, or geographic locations that are the topic of a manuscript), not the place of publication or digitization.” - Metadata Best Practices Guide, Western Michigan University Libraries

    Coverage-Temporal
    • Use to describe the time period covered or represented by the resource, not the date when the resource was published. Temporal topic may be a named period, date, or date range.
    • If using a named period, use a controlled vocabulary if possible such as Library of Congress Subjects (LCSH).
    • Where appropriate, time periods can be date ranges in ISO 8601 W3C Date/Time Format standard.

    “Usually a date or range of dates, but can be a named time period (e.g., Renaissance). Temporal coverage ‘refers to the time period covered by the intellectual content of the resource (CDP Dublin Core Metadata Best Practices (CDPDCMBP)),’ not the date of publication or digitization. It can refer to the time period shown in an image, the topic of a written manuscript, the time period covered in a series of diary entries, or, for art objects or artifacts, the date or time period of creation of the piece.” - Metadata Best Practices Guide, Western Michigan University Libraries

    Provenance
    • The statement may include a description of any changes successive custodians made to the resource.

    “Provenance, from the French provenir, "to come from," refers to the chronology of the ownership or location of an historical object.” - Oxford English Dictionary

    References

    i Moving towards shareable metadata by Sarah L. Shreeves, Jenn Riley, and Liz Milewicz
    First Monday, Volume 11, number 8 - 7 (August 2006),
    URL: https://firstmonday.org/ojs/index.php/fm/issue/view/202

    ii Han, Myung-Ja, Cho, Christine, Cole, Timothy W. and Jackson, Amy S. (2009) "Metadata for Special Collections in CONTENTdm: How to Improve Interoperability of Unique Fields Through OAI-PMH,"
    Journal of Library Metadata, 9: Issue 3 - 4 , 213 - 238.
    URL: http://dx.doi.org/10.1080/19386380903405124

    iii Members of the original CONTENTdm Metadata Working Group, Aug-Dec 2009

    Sheila Bair	Western Michigan University	bair@wmich.edu
    Dachun Bao	National Defense University	baod@ndu.edu
    Amalia (Molly) Beisler	University of Nevada Reno	abeisler@unr.edu
    Megan Bernal	Depaul University	MBERNAL2@depaul.edu
    Laura Capell	University of Southern Mississippi	laura.capell@usm.edu
    MingYu Chen	University of Houston	mchen15@uh.edu
    Mei Ling Chow	Montclair University	chowm@mail.montclair.edu
    Kevin Clair	Penn State University	kmc35@psulias.psu.edu
    Lee Dotson	University of Central Florida	ddotson@mail.ucf.edu
    Mario Einaudi	The Huntington Library	meinaudi@huntington.org
    Allegra Gonzalez	Claremont Colleges Digital Library	Allegra_Gonzalez@cuc.claremont.edu
    Deborah Green	University of Idaho	dgreen@uidaho.edu
    Myung-Ja (MJ) Han	University of Illinois U-C	mhan3@illinois.edu
    Rachel Howard	University of Louisville	rachel.howard@louisville.edu
    Amanda A Hurford	Ball State University	aahurford@bsu.edu
    Andrea Kappler	Evansville Vanderburgh Public Library	andreak@evpl.org
    Deborah Keller	US Army	deborah.eb.keller@us.army.mil
    Kate Kluttz	North Carolina State Library	kate.kluttz@ncdcr.gov
    Lyn MacCorkle	University of Miami	LMaccork@miami.edu
    Sandra McIntyre	Mountain West Digital Library	sandra.mcintyre@UTAH.EDU
    Gail McMillan	Virginia Tech	gailmac@vt.edu
    Ann Olszewski	Cleveland Public Library	ann.olszewski@cpl.org
    Jennifer Palmentiero	SE NY Library Resources Council	jennifer@senylrc.org
    Kitty Pittman	Oklahoma State Library	kpittman@oltn.odl.state.ok.us
    Gayle Porter	Chicago State University	gporter@csu.edu
    Gayle Spears	Atlanta University Center	gspears@auctr.edu
    Jill Strass	St. Olaf University	strass@stolaf.edu
    Glee M Willis	University of Nevada Reno	willis@unr.edu
    Ling Wang	University of Illinois Chicago	lwang@uic.edu
    Noelia Ramos	Map Library of Catalonia	noelia.ramos@icc.cat
    Shilpa Rele	University of Miami	s.rele@miami.edu
    Cheryl Walters	Utah State University	cheryl.walters@usu.edu
    Trashinda Wright	Atlanta University Center	twright@auctr.edu
    ZeeZee Zamin	Louisiana State University/LOUIS	zehra@lsu.edu
    Joined 2012: Natalie Bulick	Indiana State University	natalie.bulick@indstate.edu

    History and acknowledgements

    Throughout the digital repository landscape, it is increasingly accepted that metadata needs not only to serve the local community but also be suitable for harvesting externally. The challenge is to sustain useful local information while providing context and perspective to both the local and the remote user. Because each metadata standard and each collection management toolset may derive its own 'best practice,’ it is incumbent upon each community of practice to provide leadership from its constituents' particular points of view.

    Thus, in August 2009, OC  LC Digital Collection Services (DCS) convened the CONTENTdm Metadata Working Group (MWG) to create a 'best practices' guideline for our community. Discussions followed presentations given at regional and national CONTENTdm Users Groups, and collaborative work was undertaken using the tools familiar to the collective — CONTENTdm, WorldCat Digital Collection Gateway (Gateway) and various social networking environments. The discussion focused on members’ research and publications, and on their efforts to develop, optimize and standardize CONTENTdm metadata element sets such that materials are discoverable easily both in the local CONTENTdm environment as well as across repositories into which their metadata might be harvested according to the standard OAI protocols.

    OCLC DCS allocated CONTENTdm servers and trained the MWG members to use the Gateway to map qualified Dublin Core metadata and test them against WorldCat.org displays and WorldCat MARC fields. In the course of the work, the MWG untied several knotty issues and made suggestions resulting in significant improvements to the Gateway. In July, 2010, the Gateway was opened to any OAI -PMH compliant repository.

    OCLC Digital Collection Services would like to thank the participants in the CONTENTdm Metadata Working Group iii , and their colleagues, for their invaluable contribution to this guide, most recently editorial advice on version 3 from Natalie Bulick, Metadata Librarian at the Cunningham Memorial Library, Indiana State University.

    Special thanks to Yan Ren, Metadata Specialist and MSIM Candidate, University of Washington iSchool. Yan served as an OCLC Digital Collection Services Intern, Fall 2011, and edited version 3 for inclusion of the full complement of dcterms.

    Appendices

    Appendix A: Additional dcterms available
    • Used for Bibliographic Resource only.
    • Recommended practice is to include sufficient bibliographic detail to identify the resource as unambiguously as possible.
    • Prefer "Bibliographic citation" to qualify value.

    Element Name	Rights-License
    DC Definition	A legal document giving official permission to do something with the resource
    Required	As appropriate
    Controlled Vocabulary
    Syntax Scheme
    DC Element Map	License (dcterms:license)
    MARC MAP IN WWORLDCAT	( 540##$a enhancement recommended)
    REPEATABLE	Yes
    BEST PRACTICES

    Element Name	Date-Modified
    DC Definition	Date on which the resource was changed
    Required	As appropriate
    Controlled Vocabulary
    Syntax Scheme	W3CDTF
    DC Element Map	Date Modified (dcterms:modified)
    MARC MAP IN WORLDCAT	046 $j
    REPEATABLE	Not preferred
    BEST PRACTICES

    • The standard is a basis for comparison; a reference point against which other things can be evaluated.

    Element Name	Relation-References
    DC Definition	A related resource that is referenced, cited, or otherwise pointed to by the described resource
    Required	As appropriate
    Controlled Vocabulary
    Syntax Scheme
    DC Element Map	References (dcterms:references)
    MARC MAP IN WORLDCAT	787 08 $n
    REPEATABLE	Yes
    BEST PRACTICES

    Relation-Is Referenced By

    Element Name	Relation-Is Referenced By
    DC Definition	A related resource that is referenced, cited, or otherwise pointed to by the described resource
    Required	As appropriate
    Controlled Vocabulary
    Syntax Scheme
    DC Element Map	Is Referenced By (dcterms:isReferencedBy
    MARC MAP IN WORLDCAT	510 0#
    REPEATABLE	Yes
    BEST PRACTICES

    Element Name	Audience-Education Level
    DC Definition	A class of entity, defined in terms of progression through an educational or training context, for which the described resource is intended
    Required	As appropriate
    Controlled Vocabulary
    Syntax Scheme
    DC Element Map	Audience Education Level (dcterms:educationLevel)
    MARC MAP IN WORLDCAT	( 521##$a enhancement recommended
    REPEATABLE	Yes
    BEST PRACTICES

    • In an educational context, a mediator might be a parent, teacher, teaching assistant, or care-giver.
    • 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.
    • Used for Collection type of resource only.
    • A plan or course of action by an authority, intended to influence and determine decisions, actions, and other matters.

    Appendix B: Moving towards marketing with metadata We have long recognized the need for effective marketing to increase discovery and delivery of digital collections. Enhancing descriptive metadata can move us in the right direction. Websites such as Flickr have adopted Web 2.0 social metadata standards such as tagging, in order to improve searchability for digital image material, and can leverage existing metadata to augment the user experience. There exists opportunity to further optimize descriptive metadata in otherwise well -aggregated digital collections. For example, there are many archival collections of historical material related to topics such as gold mining, railroad production, and other industries. The metadata used to describe these types of images can be quite literal and catalogers sometimes ‘miss the point’ -- failing to apply such key, albeit at times colloquial, descriptors as “boomtowns,” “Gold Rush,” or “Wild West.” While many controlled vocabularies are limited in their ability to incorporate this type of higher-level description, catalogers are encouraged to develop their own local controlled vocabularies based upon a convergence of subject terms (nouns, adjectives and verbs describing main topics) technical and style-based terms (unique image attributes such as image orientation, lens perspectives, and photographic techniques) and concept terms (ideas portrayed in an image). In WorldCat.org, the ability to 32 create/name lists of items and apply social tags to items allows a high level of flexibility in accessing and managing content. Thus, the further integration of digital content into WorldCat.org represents a unique opportunity for the special collections community to begin experimenting with these types of terminologies -focused workflow tasks to increase discovery. Appendix C:Dates

    Date type	Date example
    Known year-month-day	2001-10-19
    Known year-month	2001-10
    Known year	2001
    One year or another	1892 or 1893
    Circa year-month	circa 1843-02
    Decade certain	1970s
    Before a time period	before 1867
    After a time period	after 1867

    -- Guidelines for Metadata Application in the Claremont Colleges Digital Library

    About Dates in CONTENTdm:

    • CONTENTdm supports the “date” data type and is consistent with the ISO standard yyyy-mm-dd, yyyy-mm and yyyy. You must use the date data type in order to provide searchable dates in CONTENTdm. However, many CONTENTdm users also provide a date field using the text data type. The fields shown in the latter five examples above would need to be configured as “text.”
    • To enter a range of years, use the following guidelines:
      • CONTENTdm Project Client - Use the yyyy-yyyy standard. Upon saving your metadata, the CONTENTdm Project Client will break out every date in the range.
      • CONTENTdm Web Add - Type every single year in the date range separated by semicolon-space.

      -Metadata Implementation Guidelines for North Carolina Digital State Document

      Appendix D: Metadata Schemas The following are examples of CONTENTdm metadata schemas that represent the vetted work of the CONTENTdm Metadata Working Group (MWG):

      

      For photographic collections
      

      

      For archival collections
      Appendix E: Compound Objects Addendum on the treatment of compound objects with respect to OAI harvesting Authors:

      Geri Bunker Ingram, MLIS OCLC Digital Collection Services

      Myung-Ja "MJ" Han Metadata Librarian Assistant Professor of Library Administration University of Illinois at Urbana - Champaign

      Sheila Bair, MLIS Metadata & Cataloging Librarian Western Michigan University

      Context:
      During the drafting of the Best Practices Guide version 1.7, discussion arose among the Metadata Working Group concerning the special case of sharing metadata from CONTENTdm Compound Objects. Users may employ diverse strategies for sharing metadata, regard less of the material type or formats that are assembled as compound objects, and regardless of the OAI-PMH harvester that will be employed. A request was made to attach a statement to the guide explaining the implications of metadata schema definition and CONTENTdm field configuration when a collection containing Compound Objects is destined to be harvested.

      CONTENTdm Definitions:

      • A metadata record describing the object itself, (known as object -level metadata ).
      • A metadata record (known as page-level metadata ) for each of the composite pages or items that make up the compound object.
      • Document —a series of related items
      • Monograph— a series of items related in hierarchical fashion
      • Post card —a series of exactly two items that may be displayed on one screen using the compound object viewer (by default labeled “front” and “back”);
      • Picture cube —a series of exactly six items (designed originally for scans of realia)

      DOCUMENT DESCRIPTION (VIEW): One of several views of the compound object available from the compound object viewer. The metadata that displays through this view is the object-level metadata.

      PAGE DESCRIPTION (VIEW): One of several views of the compound object available from the compound object viewer. The metadata that displays through this view is the page-level metadata.

      Sharing metadata
      With CONTENTdm, one can set a collection to be harvestable generally as long as the harvester is compliant, and one can also set a collection to be harvested by the Digital Collection Gateway specifically. With the former, CONTENTdm collection administrators can decide whether to enable the page-level metadata to be harvested. This is done in CONTENTdm Administration in the Server/Settings/OAI configuration function. With the Gateway, page-level metadata are never harvested, therefore the object-level metadata must be carefully considered. For other OAI harvesters, CONTENTdm collection administrators can decide whether and how fully to allow harvest of page-level metadata. Collection administrators should verify for every collection that the OAI configuration settings are correct for that particular collection. The implications for discovery and delivery vary depending upon the type of object at hand, and how well the Compound object-level (metadata of the object itself) is represented. Collection administrators must determine whether the document description (object-level metadata) is enough for resource discovery/retrieval outside of the context of the native CONTENTdm environment. If a harvester provides direct links back to the object in its repository environment, (as in worldcat.org), and if the object-level metadata is extensive enough to allow discovery of the object, then end-users can link directly to the original collection and re-issue the specific search criteria to retrieve relevant objects with ‘hits’ highlighted on each page of each compound object across the collections on the server.

      Example--Enhancing discovery of buried information
      One of the CONTENTdm collections at Western Michigan University is a collection of Civil War diaries and letters assembled as compound objects. They employ the Library of Congress’ “20 percent rule" ii for subject headings at the object level, except in cases of special information of interest to Civil War researchers. For instance, in all the diaries, subject headings at the object level contain the names of battles in which the diarist participated even though the description of the battle may comprise only a small percentage of the total text.

      Special considerations for textual transcripts
      The Document and Monograph classes of compound object in CONTENTdm are used mainly to handle text-rich objects. Searchable text transcripts are handled as metadata within a CONTENTdm schema. i.e., not only can every field of the metadata be made searchable, but above and beyond that, one field in each record may contain a searchable transcript of the text of the item. The Full text search field data type can be used for one field in each schema. In the case of a compound object, the object level metadata itself, and each of its item level metadata, may contain up to 128,000 characters in this Full text search field (often re-labeled “Transcript” in practice). CONTENTdm administrators decide whether to make this field harvestable or not, i.e., map the field to one of the DC elements. Appendix F: Consortium issues Addendum on considerations for consortia using OAI harvesting tools; adding value from the members’ point of view
      Authors :

      Jason B. Lee Metadata Coordinator, WorldCat Digital Content OCLC Digital Collection Services	Lyn MacCorkle Digital Project Development & Repositories Librarian, Digital Initiatives & Resources University of Miami Libraries	Sandra McIntyre Program Director, Mountain West Digital Library
      Gayle Porter Special Formats Catalog Librarian, University Library Chicago State University	Taylor Surface Senior Product Manager OCLC Digital Collection Services	Cheryl Walters Head of Digital Initiatives, Utah State University

      Context:
      A consortium is defined as an “agreement, combination, or group (as of companies) formed to undertake an enterprise beyond the resources of any one member.” During the drafting of the Best Practices Guide ver. 1.7, discussion arose among Metadata Working Group members concerning digital production & syndication challenges from a consortial viewpoint. A task group was formed in order to identify these [primarily workflow-oriented] issues in order to set forth an additional suite of recommended guidelines and to propose and communicate some specific resolutions in the WorldCat Digital Gateway environment.

      Considerations for Consortia:
      We have identified several overlapping core considerations for institutional members of a consortium using OAI harvesting tools in order to contribute digital content to a central server (outside of the institution). These core considerations, which may affect workflows at both the institution- and consortium-levels, include but are not limited to, metadata practices, communication strategy, and coordination of tasks.

      • One CONTENTdm license is owned by the Consortium and shared among institutions.
      • One CONTENTdm license is owned as above, plus one or more CONTENTdm licenses are owned by member institutions.
      1. Back to top
      2. • Jumpstart my website
         • Collection building overview

      Recommended articles

      1. Article type Topic Content type Product documentation Language English
      2. Tags This page has no tags.