Western States Dublin Core Metadata Best Practices Version 1.2

The Western States Digital Standards Group (WSDSG) Metadata Working Group developed this best practices standard. Mountain West Digital Library (MWDL) used this standards document to guide digital collections metadata creation from approximately 2003-2006.

Utah State University DigitalCommons@USU Library Faculty & Staff Publications Libraries January 2003 Western States Dublin Core Metadata Best Practices, version 1.2 Cheryl D. Walters Utah State University Western States Digital Standards Group Follow this and additional works at: https://digitalcommons.usu.edu/lib_pubs Part of the Library and Information Science Commons Recommended Citation Walters, Cheryl D. and Western States Digital Standards Group, "Western States Dublin Core Metadata Best Practices, version 1.2" (2003). Library Faculty & Staff Publications. Paper 78. https://digitalcommons.usu.edu/lib_pubs/78 This Unpublished Paper is brought to you for free and open access by the Libraries at DigitalCommons@USU. It has been accepted for inclusion in Library Faculty & Staff Publications by an authorized administrator of DigitalCommons@USU. For more information, please contact [e-mail]. Western States Digital Standards Group Metadata Working Group Western States Dublin Core Metadata Best Practices Version 1.2 January 2003 ! " # $ ! % & !""# $ INTRODUCTION .......................................................................................................................................................3 UPDATING THE WSDSG DUBLIN CORE METADATA ELEMENT SET & BEST PRACTICES ...........................................3 PURPOSE AND SCOPE.............................................................................................................................................4 BACKGROUND..........................................................................................................................................................5 WHAT IS METADATA?............................................................................................................................................6 WHAT IS DUBLIN CORE AND WHY USE IT? ....................................................................................................8 DUBLIN CORE AND THE WESTERN STATES DIGITAL STANDARDS GROUP (WSDSG) ......................9 ADDITIONAL ELEMENTS NEEDED FOR DIGITAL RESOURCES .....................................................................................10 CREATING A NEW RECORD VS. USING AN EXISTING RECORD ....................................................................................11 CONTROLLED VOCABULARY ...........................................................................................................................11 GENERAL INPUT GUIDELINES ..........................................................................................................................11 PUNCTUATION .........................................................................................................................................................11 ABBREVIATIONS ......................................................................................................................................................11 CAPITALIZATION .....................................................................................................................................................12 INITIAL ARTICLES ....................................................................................................................................................12 KEYWORDS VS. SUBJECT TERMS ..............................................................................................................................12 CROSSWALKS .........................................................................................................................................................12 INTEROPERABILITY.............................................................................................................................................13 MANDATORY ELEMENTS ...................................................................................................................................13 QUALIFIERS .............................................................................................................................................................14 REFINEMENTS:.........................................................................................................................................................14 SCHEMES: ................................................................................................................................................................14 EMERGING TRENDS .............................................................................................................................................15 METADATA ENCODING AND TRANSMISSION STANDARD (METS)...........................................................................15 PRESERVATION METADATA.....................................................................................................................................15 DUBLIN CORE METADATA ELEMENT SET....................................................................................................17 TITLE .....................................................................................................................................................................18 CREATOR..............................................................................................................................................................20 SUBJECT ...............................................................................................................................................................22 !+ #, ' -. ....................................................................................................................................................26 PUBLISHER...........................................................................................................................................................28 CONTRIBUTOR ....................................................................................................................................................30 DATE.ORIGINAL .....................................................................................................................................................32 DATE.DIGITAL.....................................................................................................................................................34 TYPE ......................................................................................................................................................................36 FORMAT.USE .......................................................................................................................................................37 FORMAT.CREATION...........................................................................................................................................39 * '" '" # $ ! ! % ( ) 1 of 57 * !""# IDENTIFIER ..........................................................................................................................................................42 SOURCE.................................................................................................................................................................44 LANGUAGE ..........................................................................................................................................................46 RELATION ............................................................................................................................................................48 COVERAGE...........................................................................................................................................................51 RIGHTS MANAGEMENT ....................................................................................................................................54 HOLDING.INSTITUTION ....................................................................................................................................56 * '" '" # $ ! ! % ( ) 2 of 57 * !""# % Funded by a grant awarded by the Institute for Museum and Library Services (IMLS) in the fall of 2001, the University of Denver (Denver, Colorado) spearheaded a multi-state collaborative initiative to create a virtual collection of widely dispersed digital resources on the topic, Western trails. As part of this initiative, 23 institutions in four Western states were awarded mini-grants to create digital content and metadata for resources related to Western trails. In addition to creation of a virtual collection of digital resources, another significant component of this multistate initiative was development of a set of Dublin-Core based best practices by representatives from cultural heritage institutions beyond the original four participating states. Accordingly, in March 2002, 18 representatives from eight Western states met in Denver, Colorado to begin exploring issues associated with application of Dublin Core to digital objects by cultural heritage institutions. This group, the Western States Digital Standards Group (WSDSG) Metadata Working Group, formed two task forces to develop guidelines for the Dublin Core metadata. The WSDSG Metadata Working Group met again in Topeka, Kansas in July 2002 to finalize the guidelines and determine the remaining components of a best practices document. In November 2002 the resultant WSDSG Guidelines for the Dublin Core Elements were posted on the Colorado Digitization Program (CDP) and the Western Trails project website. In January 2003, the WSDSG Best Practices document will be released. This Best Practices document is based upon and supercedes the CDP’s General Guidelines for Descriptive Metadata Creation and Metadata. Updating the WSDSG Dublin Core Metadata Element Set & Best Practices The Dublin Core Metadata Initiative (DCMI)1 maintains the Dublin Core metadata format upon which the WSDSG metadata is based. Since the Colorado Digitization Program actively monitors the DCMI activities for changes to the Dublin Core standard, it will assume responsibility for maintaining this document, working in concert with the WSDSG Metadata Working Group to update its metadata element set and best practices document as needed in response to DCMI modifications. The following individuals participated in the meetings and discussions, making significant contributions in the development of this best practice document: Cheryl Walters, Utah State University, Descriptive Working Group Chair; Chuck Thomas, University of Minnesota, Technical Working Group Chair; Kenning Arlitsch, University of Utah; Kathlene Ferris, University of New Mexico; Mark Shelstad, American Heritage Center, University of Wyoming; 1 Dublin Core Metadata Initiative (DCMI) is the group responsible for the maintenance of the Dublin Core standard. Information on the Dublin Core can be found at http://dublincore.org. * '" '" # $ ! ! % ( ) 3 of 57 * !""# Erin Kinney, Wyoming State Library; Martha Hanscom, University of Wyoming; William Garrison, University of Colorado; Elizabeth Meagher, University of Denver; Nancy Chaffin, Colorado State University; Matt Veatch, Kansas State Historical Society; Michael Kelly, Wichita State University; Eric Hansen, Kansas Library Network Board; Melanie Sturgeon, Arizona State Archives; Richard Pearse Moses, Arizona State Archives; Devra Dragos, Nebraska Library Commission; Margaret Mering, University of Nebraska Lincoln; George Machovec, Colorado Alliance of Research Libraries; Kayla Willey, Brigham Young University; Mary McCarthy, Colorado State Library; Richard Urban, Colorado Digitization Program; and Liz Bishoff, Colorado Digitization Program. Liz Bishoff, Executive Director Colorado Digitization Program January 2003 Comments and questions regarding these guidelines can be sent to: [e-mail] These best practices offer assistance in creating metadata records for digitized resources, both those that are born digital as well as those that are reformatted from an existing physical resource (photographs, text, audio, video, three-dimensional artifacts, etc.). Creators of these records may include catalogers, curators, archivists, librarians, web site developers, database administrators, volunteers, authors, editors and other persons interested in creating digital libraries. Application of these best practices in the creation of metadata records will result in standardized records that: Enhance online search and retrieval accuracy in local databases and shared databases (e.g. union catalogs) Improve resource discovery capabilities Improve quality control of metadata records Facilitate inter-institutional interoperability This document uses the Dublin Core element data set as defined by the Dublin Core Metadata Initiative (DCMI), 2 http://www.dublincore.org. Because it addresses a very diverse audience of cultural heritage institutions comprised of museums, libraries, historical societies, archives, etc., this document seeks to accommodate different backgrounds and metadata skill levels by explaining terms and concepts as needed, and providing many examples describing diverse resources. Some terms may be used interchangeably such as catalog or online catalog versus database; digital resource versus digital object; and controlled vocabulary versus thesaurus or subject heading list. 2 The Audience element is still to be defined by the WSDSG. Once it is defined it will be added to the document. * '" '" # $ ! ! % ( ) 4 of 57 * !""# This document encompasses: A brief introduction to metadata and the Dublin Core standard A definition of each element, input guidelines, information about special requirements for entering each data element, and examples Interoperability, information on crosswalks supporting interoperability Recommended lists of Controlled Vocabulary, Subject Heading Lists and Thesauri Emerging trends in metadata Selected links to metadata resources & To help ensure libraries, museums, archives, and historical societies create metadata at a sufficient level and consistency to support identification and access needs in a shared environment, the WSDSG has established guidelines and standards for the creation of metadata for digital resources. These guidelines and standards take into account different standards and practices used at the local level while simultaneously meeting needs at the collaborative level. Adoption of standards is key to effective sharing of resources and inter-institutional interoperability. Over the last decade new approaches and standards for the description of digital resources have emerged. At the same time, established library and museum cataloging standards, including Machine Readable Cataloging (MARC) format and the Anglo-American Cataloging Rules, second edition (AACR2); Visual Resources Association Core Schemas (VRA); and Categories for the Descriptions of Works of Art (CDWA), are being applied to digital resources. The primary objective of the Western States Digital Standards Group is improved access to the unique resources and special collections that have been converted into digital format in cultural heritage institutions throughout the U.S. West. The standards followed to accomplish this objective depend of a variety of factors: Type of materials that are being digitized Purpose of the digitizing project Potential users Knowledge and expertise of the staff Technical infrastructure available to the institution or the collaborative Funding Collaborative databases providing access to collections from multiple cultural heritage institutions should be prepared to support metadata from a variety of standards including MARC, Dublin Core, Encoded Archival Description (EAD), VRA, Government Information Locator Service (GILS), and CDWA through the development of crosswalks or implementation of OAI * '" '" # $ ! ! % ( ) 5 of 57 * !""# harvesting and OAI repository. The WSDSG standards take into account a variety of different standards that might be used at the local level while simultaneously meeting needs at the collaborative level. In addition to collaborative databases handling the multiple standards used by their constituent institutions, they also need to take into account that the nature of details provided in metadata records varies from institution to institution. Some information is proprietary or confidential, such as provenance, location, or donor information and should not be distributed on systems open to the general public. When participating in a collaborative endeavor, agreeing on what information should be made publicly available by all participants is both difficult and critical. Best practice is to eliminate proprietary or confidential information in a shared catalog. To respond to the need of improved access within this diverse evolving environment, the WSDSG Metadata Working Group is recommending adoption of Dublin Core as the standard to support interoperability among cultural heritage institutions, as it provides for the broadest level of commonality of elements, flexibility and application among the institutions. Furthermore, Dublin Core is used in the Open Archives Harvest Protocol (http://www.openarchives.org) which is supported by the Institute of Museum and Library Services OAI Repository in order to create a single repository of all digital collections created through IMLS funding since 1998. ' ( Metadata is usually defined as ‘information about the data’ or any data associated with a resource that describes that particular resource. Until the mid-1990s, "metadata" was a term most prevalently used by communities involved with the management and interoperability of geospatial data, and with data management and systems design and maintenance in general. For these communities, "metadata" referred to a suite of industry or disciplinary standards as well as additional internal and external documentation and other data necessary for the identification, representation, interoperability, technical management, performance, and use of data contained in an information system. Perhaps a more useful "big picture" way of thinking about metadata is as "the sum total of what one can say about any information object at any level of aggregation." In this context, an information object is anything that can be addressed and manipulated by a human or a system as a discrete entity.3 3 Anne J. Gilliland-Swetland. Introduction to Metadata. http://www.getty.edu/research/institute/standards/intrometadata/2_articles/index.html * '" '" # $ ! ! % ( ) 6 of 57 * !""# It is essentially, a modern term for the bibliographic information that libraries traditionally entered into their catalogs or databases or registry information on collections that museums have entered into their systems; however the term metadata is most commonly used to refer to descriptive information about World Wide Web resources. The creation of metadata for digital resources is an important part of a digitization project, and must be incorporated into a projects workflow. Metadata should be created and associated with the digital resource to support the discovery, use, management, reusability, and sustainability of the resource. Metadata is most often divided into three conceptual types (with some overlap between the three): Descriptive metadata: used for the indexing, discovery, and identification of a digital resource Structural metadata: information used to display and navigate digital resources; also includes information on internal organization of the digital resource. Structural metadata might include information such as the structural divisions of a resource (i.e. chapters in a book) or sub-object relationships (such as individual diary entries in a diary section) Administrative metadata: represents the management information for the digital object, which may include information needed to access and display the resource, as well as rights management information. Administrative metadata might include the resolution at which the images were scanned, the hardware/software used to produce the image, compression information, pixel dimensions, etc. Recognizing that today’s user is coming to the digital resource from their home, work, school, etc., at any time of the day, and often without the assistance of a librarian, archivist, curator or museum educator, metadata needs to provide information that: Certifies the authenticity and degree of completeness of the content Establishes and documents the context of the content Identifies and exploits the structural relationships that exist between and within information objects Provides a range of intellectual access points for an increasingly diverse range of users Provides some of the information that an information professional might have provided in a physical reference or research setting 4 4 ibid. * '" '" # $ ! ! % ( ) 7 of 57 * !""# ' )' ( The Dublin Core metadata standard is a set of elements used to describe a variety of networked resources. The semantics of these elements have been established through consensus by an international, cross-disciplinary group of professionals from the library, museum, publishing, computer science, and text encoding communities, as well as from other related fields of scholarship. The Dublin Core Metadata Initiative (DCMI) Element Set has been approved by ANSI and assigned the number Z39.85. The Dublin Core metadata standard embodies the following characteristics: Simplicity of creation and maintenance The intention of the Dublin Core element set is to remain as simple and accessible as possible, in order to allow a non-specialist to create descriptive records for online resources both easily and efficiently, while providing for optimum retrieval of those resources in an online environment. Commonly understood terminology The Dublin Core was developed with the "non-specialist searcher" in mind. By supporting a common set of elements, the semantics of which are universally understood and supported, resource discovery across different descriptive practices from one field of knowledge to another will increase. By using terminology that is generic yet applicable to a variety of disciplines, the visibility and accessibility of resources across these disciplines is enhanced. International in scope The involvement of representatives from almost every continent in establishing Dublin Core specifications has ensured that the standard will address the multicultural and multilingual nature of networked resources. Extensibility Although the Dublin Core element set was developed with simplicity in mind, the need for precise retrieval of resources has also been recognized. As the standard develops, the Dublin Core element set could serve as the core descriptive information that will be usable across the Internet, while also allowing other, additional elements to be added that make sense within a specific discipline. These additional element sets can be linked with the Dublin Core to meet the need for extensibility, to aid in additional resource discovery, and to accommodate the precision and granularity needed for access. * '" '" # $ ! ! % ( ) 8 of 57 * !""# The WSDGS has adopted the Dublin Core because it adequately describes resources found in the library, archival, and museum communities. The standard is open and amenable to involving all of these communities, without excluding groups of users. Other standards, such as MARC have historically been difficult to adopt by other communities, such as the museum or historical societies for their non-library collections. However, for institutions committed to the MARC format, crosswalks can be developed (see Crosswalks) to map data (i.e. move or translate data from one format to the other) between Dublin Core and MARC, allowing participation in collaborative projects by those institutions. The Dublin Core and its crosswalks pave the way for interoperability between institutions. The Dublin Core element set is the “umbrella” of metadata standards that allows access for resource discovery. In addition, while the Dublin Core is relatively simple to learn and easy to use, particularly for those institutions that might not have a professional cataloger on staff to create descriptive data about their digitized resources, its elements include cover the most essential information about a resource. ' * + These best practices have been developed for use within an individual institution as well as a collaborative environment, be that collaboration among organizations on a college or university campus; a library or historical society within a county; or, a statewide initiative or a multi-state initiative. The Western States Digital Standard Group (WSDSG) Metadata Working Group has taken into consideration the needs of a broad range of cultural heritage institutions of varying size—archives, historical societies, libraries and museums. Institutions large and small can use these guidelines to describe a wide range of digital resources, including websites, individual digital objects5, and collections of digital objects. The Dublin Core record developed by the WSDSG Metadata Working Group includes 16 elements, each of which is repeatable and optional. To increase success in a collaborative environment where consistent description of digital resources is critical, the WSDSG Metadata Working Group has identified some of these elements as mandatory elements. The remaining elements are optional, but recommended. Richer, more complete records increase the likelihood of database users locating the digital resource. 5 Digital object may be an item that is born digital or object that has been reformatted from the original. It can be a digital photograph, manuscript, diary, digital audio, three- dimensional artifacts, digital video or other digital object. * '" '" # $ ! ! % ( ) 9 of 57 * !""# Additional elements needed for digital resources To effectively use the Dublin Core standard for digital resources, the WSDSG Metadata Working Group developed several additional elements so that a WSDSG Dublin Core-based metadata record includes 13 elements from the basic Dublin Core set and 3 additional elements created by WSDSG. The first of these additional elements is Date.Original. The publication or creation date of the original object, from which the digital resource is derived, may be a critical component in the description of the digital resource. However, the Dublin Core Date element is limited to the date a resource was digitized. The Working Group decided to develop an additional Date element, the Date.Original element, to contain the date of the original work; this new element can be qualified by a selected set of refinements. It is best practice to use this element when the institution wishes to use the date of the original object to qualify a search in their database. The date of the original can also be included in the Source element, along with other descriptive information about the original. The second element that the Working Group added is the Format.Creation element. This element provides information related to the creation of the digital object. The best practice is to include information that supports the migration of the digital object over time, as well as supporting the quality control of the digital resource. The type of information specified in this element includes the hardware and software used to create the digital object, resolution, and possibly the name or initials of the person performing the scanning. A third element, the Holding.Institution element, records information on ownership of the digital object. This element is particularly important for collaborative projects where records from multiple institutions are combined in a shared database. In addition to these elements, the database that will support your Dublin Core system will have to provide information on the date and time of record creation and record modification, and a unique record number. The following guidelines offer assistance on how to use the Dublin Core elements. Each entry provides the Dublin Core definition for the element, along with a description and whether the element is mandatory. Input guidelines and examples provide some application suggestions. It should be noted that many decisions on how the record will appear to the user or how the searches and indexes will work are dependent on the functionality of the library or museum system or database where the Dublin Core record is entered. We have not made any assumptions regarding the functionality that specific systems provide for data entry, retrieval or display of the Dublin Core records. * '" '" # $ ! ! % ( ) 10 of 57 * !""# Creating a new record vs. using an existing record The best practice is to create a new record for digital resources. However, some institutions are adding the information about the digital resource to the existing record for the original resource; many are just adding the URL. Use or augmentation of existing records without the addition of information pertaining to the creation of the digital object are inadequate for supporting quality control of the digital resource and its migration over time. This information would be included in the Format.Creation element. See the Western States Digital Standards Group Digital Imaging Best Practices document. The best practice is to select terms from controlled vocabularies, thesauri and subject heading lists for completion of the subject elements, rather than just using keywords. Employing terminology from controlled vocabularies ensures consistency and can improve the quality of search results, while reducing the likelihood of spelling errors when inputting metadata records. Recognizing the diverse nature of the statewide initiatives and the involvement of a broad range of cultural heritage institutions, controlled vocabularies have been expanded to include subject discipline taxonomies and thesauri. Several states are developing geographic based lists of terms that are available on each state’s website. These lists can be helpful in achieving a level of consistency in terminology. Many of the thesauri, subject heading lists and taxonomies are currently available via the web and online links are provided wherever possible. See the Subject element in this document for the current list. % It is best practice that participants follow the general grammatical rules of the language involved when entering descriptive information about resources. In addition, it may be useful to consult the Anglo-American Cataloging Rules for more information and details on general rules and guidelines for data entry. Following are a few brief comments: Punctuation Avoid ending punctuation unless it is part of the content of the resource. Abbreviations In general, the following abbreviations are allowed: common or accepted abbreviations (such as "St." for "Saint"); designations of function (such as "ed." for "Editor"); terms used with dates (b. or fl.); and distinguishing terms added to names of persons, if they are abbreviated on the item * '" '" # $ ! ! % ( ) 11 of 57 * !""# (such as "Mrs."). We suggest that abbreviations not be used if they would make the record unclear. In case of doubt, spell out the abbreviation. Capitalization In general, capitalize the first word (of a title, for example) and proper names (place, personal and organization names). Capitalize content in the description element according to normal rules of writing. Enter content in lower case except for acronyms, which should be entered in capital letters. Initial Articles Omit initial articles at the beginning of the title such as: the, a, an, le, la, los, el, der, die, das, etc. Keywords vs. Subject terms Best practice recommends that subject terms be taken from a controlled vocabulary whenever possible for more accurate retrieval of resources. However, other non-controlled terms or keywords that identify the resource with some precision can be added to a record to enhance resource retrieval and discovery, especially in cases where such terms are too new to be included in controlled vocabularies. Entry of Creator or Contributor Enter a personal name in the Creator or Contributor element as last name first, separated by a comma, then first name, then middle name or initial. If birth and death year is known, enter them following the first name followed by a comma. Separate the birth year from the death year with a hyphen. Smith, John, 1895-1964. Smith, John James, 1914-2002. ) & A crosswalk is defined as a set of transformations applied to the content of elements in a source metadata standard that results in the storage of appropriately modified content in the analogous elements of a target metadata standard: (NISO White Page, October 1998). A fully specified crosswalk contains a semantic mapping as well as a conversion specification. See the NISO White paper, “Issues in Crosswalking content Metadata Standards” for further information. Crosswalks provide the ability to create and maintain a set of metadata and to map that metadata into any number of related content metadata standards. In order to build successful crosswalks and mapping schemes, it is important to maintain consistency across metadata standards. Dublin Core to USMARC:GILS: http://lcweb.loc.gov/marc/dccross.html * '" '" # $ ! ! % ( ) 12 of 57 * !""# Dublin Core to UNIMARC: http://www.ukoln.ac.uk/metadata/interoperability/dc_unimarc.html TEI header to USMARC: http://etext.lib.virginia.edu/tei/tei-marc.html/ GILS to USMARC: http://www.gils.net/prof_v2.html#annex_b FDGC to USMARC: http://www.alexandria.ucsb.edu/publicdocuments/metadata/fgdc2marc.html MARC to Dublin Core: http://loc.gov/marc/marc2dc.html % As cultural heritage institutions have automated collections information each sector developed unique practices, procedures and semantics for describing items. Interoperability is a set of hardware, software, policies and procedures that allows for the exchange and re-use of information across a collaborative network. This network may encompass a particular field, such as natural history, internal institutional departments, or a broader cultural heritage initiative. Beyond the technical requirements (such Z39.50 library system queries or Open Archives Initiative protocols) for sharing data, institutions need to be aware of impact that semantic choices create (particularly for describing similar concepts such as “author,” “creator,” artist”). By adopting a common set of best practices, controlled vocabularies, and by participating in interoperable networks, institutions can increase their visibility and provide opportunities to create new connections with other cultural heritage institutions that better serves the needs of constituent communities. Z39.50 Protocol. http://lcweb.loc.gov/z3950/agency/ Open Archives Initiative. http://www.openarchives.org/ , The WSDSG has identified 11 mandatory elements that are most important in describing the digital resource and are critical in supporting interoperability in a collaborative initiative. These are: Title Creator (if available) Subject Description Date. Digital Date. Original (if applicable) Format. Use Format. Creation Identifier Rights * '" '" # $ ! ! % ( ) 13 of 57 * !""# Holding. Institution The WSDSG Dublin Core elements separate into three categories: Descriptive, Structural and Administrative metadata. The descriptive elements of the record consist of elements necessary for describing the resource and facilitating access to the digital resource and include Title, Creator, Contributor, Subject, Date: Original, Date: Digital, Description, Source, Publisher, Relation, Identifier, Language, and Coverage. The Structural Metadata includes Type, Format: Use, and Relation. The Administrative Metadata elements include Rights Management, Publisher, Format: Creation, and Date: Digital. Qualifiers The basic elements described above are intended to cover most of the information needed to give an adequate description of the digital resource. However there is often a need to further refine information about a resource than can be expressed using the basic elements. To help remedy this, the WSDSG has developed a ‘Qualified’ Dublin Core that consists of the element and its qualifiers. These qualifiers are defined as refinements and schemes. Refinements: These refine or specify the meaning of the content of an element. Example: Relation.IsPartOf: Library Journal v. 127, no. 9 (May 15, 2002) p. 32-4 The Relation element can be refined to show the nature of the relationship between the resource described in the Relation element and the resource described by the metadata record. To show that the full-text article described by the metadata record is an article that is part of the May 15, 2002 issue of Library Journal, the Relation element can be “refined” by adding “IsPartOf”: Schemes: These define rules for constructing a term, date, or other type of data in accordance with a controlled list of terms or a specific format of representing data (e.g.. dates, geographic coordinates, etc.). Schemes are usually a recognized coding system used in the description of resources. The purpose of the scheme qualifier is to introduce a degree of consistency and standardization into the Dublin Core record. Example: Date.Original: 1997-07-16. * '" '" # $ ! ! % ( ) 14 of 57 * !""# The scheme ISO 8601 for the date element allows formatting of the date in a specific way for consistency. Using this scheme, dates follow the format YYYY-MM-DD so that July 16, 1997 would be stated as 1997-07-16. The refinements and schemes that apply to each element are discussed in the guidelines for each element. ,- $ Metadata Encoding and Transmission Standard (METS) The Metadata Encoding and Transmission Standard (METS) is an XML-based encoding standard for digital library metadata. It is both powerful and inclusive, making provision for encoding structural, descriptive and administrative metadata. It is designed not to supercede existing metadata structures such as Dublin Core or Text Encoding Initiative (TEI) headers, but rather to provide a means of including them in the METS document. It is a way of bringing together a wide range of metadata about a digital object. Through its structural metadata section, it allows the user to express relationships between multiple representations or manifestations of the digital object, for example, encoded TEI files, the scanned page image, and audio recordings. It also allows one to express the relationship between multiple parts of a single digital representation, such as the chapters of a book. The administrative metadata section supports the encoding of the kinds of information required to manage and track digital objects and the delivery -- technical information such as file format and creation; digital rights management information including copyright and licensing information; and information on the provenance and revision history of the digital object, including migration data and transformations that have been performed over time. METS is in its earliest stages of development and in fall 2002 is just being implemented in a few research libraries. Preservation Metadata Preservation metadata is the information needed to execute, document and evaluate the processes that support and facilitate the long-term retention of digital content. Digital resources require detailed metadata to ensure accessibility for future generations. Digital objects are subject to change so the change history of the object must be maintained over time to ensure its authenticity and integrity. At this time we are recording technical information on preservation decisions in the Format.Creation element. With the adoption of the METS other options become available. It is important to record this information as access technologies for digital objects become obsolete. the equipment or software is no longer available. The best practice is to capture the information hardware, operating system, and software use to create the digital object. This information, as well as other forms of description and documentation, can be detailed in the metadata associated * '" '" # $ ! ! % ( ) 15 of 57 * !""# with a digital object. Preservation metadata is extremely important to provide future digital archives managers with sufficient information to maintain the digital object. Standards and best practices for its use and implementation are still being developed. In particular, preservation metadata maybe used to: store technical information supporting preservation decisions and actions document preservation actions taken, such as migration or emulation policies record the effects of preservation strategies ensure the authenticity of digital resources over time note information about collection management and the management of rights The types of information enumerated above address two functional objectives: 1) providing preservation managers with sufficient knowledge to take appropriate actions in order to maintain a digital object’s bit stream over the long-term, and 2) ensuring that the content of an archived object can be rendered and interpreted, in spite of future changes in access technologies. An early effort to develop preservation metadata for digital objects was conducted by the Research Libraries Group’s (RLG) Working Group on Preservation Issue of Metadata, which in May 1998 released a set of 16 recommended metadata elements considered essential for preserving a digital master file over the long-term.6 The National Information Standards Institute has also released a draft Data Dictionary: Technical Metadata for Still Images (Z39.87) with the purpose of supporting image quality assessment and data processing needs through an images life cycle7 6 RLG Working Group on Preservation Metadata. Final Report [online] RLG DigiNews. May 1998. http://www.rlg.org/preserv/presmeta.html 7 National Information Standards Organization. Data Dictionary: Technical Metadata for Still Images. http://www.niso.org/standards/resources/Z39_87_trial_use.pdf * '" '" # $ ! ! % ( ) 16 of 57 * !""# , - * '" '" # $ ! ! % ( ) 17 of 57 * , !""# TITLE Label: Title Dublin Core Definition: A name given to the resource. Description: Name given to the resource by the creator or publisher; may also be identifying phrase or name of the object supplied by the holding institution. Mandatory: Yes. Repeatable: Yes. Refinements: Title.Alternative Schemes: None defined. Input Guidelines: 1. Enter one Title per element. Use separate elements,to enter more than one title if necessary for access (i.e., caption title, former title, spine title, collection title, series title, artist’s title, object name, etc.) or if in doubt about what constitutes the title. 2. Transcribe title, if there is one, from the resource itself, such as a book title from the title page or a caption from a photograph. 3. When no title is found on the resource itself, use a title assigned by the holding institution or found in reference sources 4. Make the title as descriptive as possible, avoiding simple generic titles such as Papers or Annual report. 5. File names, accession numbers, call numbers, or other identification schemes should be entered in the Identifier element. 6. When possible, exclude initial articles from title. Exceptions might include when the article is an essential part of the title or when local practice requires use of initial articles. 7. Capitalize only the first letter of the first word of the title or of any proper names contained within the title. 8. In general, transcribe titles and subtitles from the source using the same punctuation that appears on the source. If the holding institution has created the title, then use punctuation that would be appropriate for English writing. 9. For more guidance in constructing titles, consult established cataloging rules such as Anglo-American Cataloging Rules (AACR2), Archives, Personal Papers, and Manuscripts. 10. Collections: a) If multiple items are being described as a collection by one record and no collection title already exists, create a collective title that is as descriptive as possible of the contents. b) If each item in such a collection is itself worthy of being described by its own record (i.e. item-level record), refer back to the collection-level title in the Relation element. Likewise, list any titles for subordinate item-level records in the Relation element of the collectionlevel record. Notes: None * '" '" # $ ! ! % ( ) 18 of 57 * , !""# Examples: Titles created by creator/publisher: Great Gatsby HAL’s legacy: 2001’s computer as dream and reality Music man Optional additional element: Title.Alternative: The music man Important farmlands, Arapahoe County (this is a map, but not obvious from title) Optional additional element: Title.Alternative: Arapahoe County map Symphony no. 3, A major, opus 56 12 ways to get to 11 Optional additional element: Title.Alternative: Twelve ways to get to eleven L’opera completa di Watteau Titles supplied by holding institution: Letter petitioning for White Sulphur Springs, N.M. Post Office Jack London papers (correspondence, papers, etc. of Jack London) United States Pueblo Lands Board report regarding Pueblo of Laguna View of the Brooklyn Bridge (photograph of the Brooklyn Bridge) Venus and Cupid sculpture (sculpture of Venus and Cupid) Walnut rolltop desk (a desk with a top that rolls up and down to cover it) Portrait of Thomas Jefferson (painting of Thomas Jefferson) Green and gold ceramic fruit bowl (a ceramic bowl used to hold fruit) Maps to: Dublin Core Title * '" '" # $ ! ! % ( ) 19 of 57 * , !""# CREATOR Label: Creator Dublin Core Definition: An entity primarily responsible for making the content of the resource. Description: Person or entity primarily responsible for creating the intellectual content of the resource. Examples of creators include authors of written documents; artists; illustrators; photographers; collectors of natural specimens or artifacts; organizations that generate archival collections; etc. Mandatory: Yes, if available. Repeatable: Yes. Refinements: None. Schemes: None Input Guidelines: 1. 2. 3. 4. 5. 6. 7. Enter multiple creators in the order in which they appear on the resource or in order of their importance. Use separate Creator elements to enter multiple creators or clearly separate each entry by a semi-colon, space within an element. Secondary authors, editors, etc. may be entered using the Contributor element. If using established cataloging rules to construct contributor elements, follow those rules. Some examples of established rules include: Anglo-American Cataloging Rules (AACR2); Archives, Personal Papers, and Manuscripts (APPM); Categories of Description for the Works of Art (CDWA); Visual Resources Association (VRA). If not using such rules, then use the following guidelines. Determine the correct form of the name when possible. The Library of Congress Authority File (http://authorities.loc.gov) or other locally specified bibliographic utilities (OCLC, RLIN, ULAN, etc.) should be consulted when possible. Enter personal names in inverted form in most cases: Last name, First name, Middle name or initial. If it is not obvious how to invert or structure the name, use the name form given in an authority list or enter it as it would be in the country of origin. Birth and/or death dates, if known, should be added, in accordance with authorized form of the name when possible. Enter group or organization names in full, direct form. In the case of a hierarchy, list the parts from the largest to smallest, separated by periods. In the case of a long group or organization name that includes subordinate units, sometimes the name can be shortened by eliminating some of the hierarchical parts not considered necessary for uniquely identifying the body in question. For example, to enter the CIA as a creator, use the form of the name as given in the Library of Congress Authority File (United States. Central Intelligence Agency) instead of the full hierarchical name (United States. National Security Council. Central Intelligence Agency). If there is doubt as to how to enter a name and the form of name cannot be verified in an authority list, enter it as it appears and do not invert (Example: Sitting Bull). * '" '" # $ ! ! % ( ) 20 of 57 * , !""# 8. Have a clear understanding of how the database handles non-standard characters such as diacritics and input them so that they display and retrieve effectively. 9. Optional: The function of a creator may be included in parentheses after the name. Example: Rackham, Arthur, 1867-1939 (illustrator). 10. If the creator is unknown, leave the element blank. Notes: 1. Entities responsible for digitizing an existing resource should be entered in the Publisher element. Examples: Personal names: Onassis, Jacqueline Kennedy, 1929Toulouse-Lautrec, Henri de, 1864-1901 Jeanne-Claude, 1935Duran y Gonzalez, Juan Maria, d 1899Chavez de Aguilar, Maria Alicia. Armijo Aguilar, Leopoldo Laozi (not Lao-Tzu or Po-yang Li or any of 34 other variants of this name given in the LCAF record) Webb, Wellington E. Pak, Sæong-t°aek (Caution: remember to check how the database handles non-standard characters such as diacritics before using them) Alexander, the Great, 356-323 B.C. Scroggins, C. H. Madonna, 1958- (meaning the entertainer; this is the form given in the LCAF; don’t use just “Madonna” which could be confused with another person) Smith, Adam, 1723-1790 (note that in the case of commonly encountered names, birth/death dates are very important to distinguish between otherwise identical names). Group or Organization names: Ty, Inc. International Business Machines Corporation (not IBM or I.B.M.) Denver Art Museum Unesco (not U.N.E.S.C.O. or United Nations Organisation for Education, Science, and Culture) Walt Disney Company H.W. Wilson Company Colorado. Dept. of Social Services. Massachusetts Institute of Technology. Migration and Development Study Group. Note that this shorter form of the name should be used as indicated by the LC NAF instead of the fullest form of the name, which would be: Massachusetts Institute of Technology. Center for International Studies. Migration and Development Study Group. Maps to: Dublin Core Creator * '" '" # $ ! ! % ( ) 21 of 57 * , !""# SUBJECT Label: Subject Dublin Core Definition: The topic of the content of the resource. Description: What the content of the resource is about or what it is, expressed by headings, keywords, phrases, or names; or terms for significantly associated people, places, and events, etc. Mandatory: Yes Repeatable: Yes. Refinements: None. Schemes: It is strongly recommended that subject words and phrases come from established thesauri or discipline-related word lists. Established recommended schemes given in the DCMES Dublin Core Qualifiers memo (07/11/2000) consist of: Code Name of thesauri LCSH MeSH DDC LCC UDC Library of Congress Subject Headings Medical Subject Headings http://www.nlm.nih.gov/mesh/meshhome.html Dewey Decimal Classification http://www.oclc.org/dewey/ Library of Congress Classification http://lcweb.loc.gov/catdir/cpso/lcco/lcco.html Universal Decimal Classification http://www.udcc.org Other established thesauri or word lists include, but are not limited to: AAT Art and Architecture Thesaurus AASL Asian American Studies Library subject headings AMG Audiovisual Materials Glossary (AMG) CHT Chicano Thesaurus for Indexing Chicano Materials FAST Faceted Application of Subject Terminology GEOREFT GEORef Thesaurus RBGENR Genre Terms: A Thesaurus for Use in Rare Books and Special Collections TGN Getty Thesaurus of Geographic Names GSAFD Guidelines on Subject Access to Individual Works of Fiction, Drama, etc. LCAF LC Authorities File ( http://authorities.loc.gov) LCSHAC LC Subject Headings: Annotated Card Program (Children’s headings) Local Locally controlled list of terms * '" '" # $ ! ! % ( ) 22 of 57 * , !""# MIM NASAT NALAT NICEM NIMACSC NTISSC ATLA NMC Sears LCTGM GMGPC TEST ERICD: WATREST Moving Image Materials: Genre terms NASA Thesaurus http://www.sti.nasa.gov/thesfrm1.htm NAL Agricultural Thesaurus http://agclass.nal.usda.gov/agt/agt.htm NICEM (National Information Center for Educational Media) Thesaurus For order info, see http://www.nicem.com/thes.htm NIMA Cartographic Subject Categories NTIS Subject Categories Religion Indexes Thesaurus Revised Nomenclature for Museum Cataloging: a revised and expanded version of Robert C. Chenhall’s system for classifying man-made objects Sears Subject Headings Thesaurus for Graphic Materials: TGM I, Subject Termshttp://lcweb.loc.gov/rr/print/tgm1/ Thesaurus for Graphic Materials: TGM II, Genre and Physical Characteristic Terms http://lcweb.loc.gov/rr/print/tgm2/ Thesaurus of Engineering and Scientific Terms Thesaurus of ERIC Descriptors http://ericae.net/scripts/ewiz/swiz4.htm Thesaurus of Water Resources Terms This list includes most of the major thesauri, but more exist. Caution: Before opting to use terms from a thesaurus other than ones listed above, carefully consider if this thesaurus will be acceptable to any potential partners with whom you may share your records. Input Guidelines: 1. 2. 3. 4. 5. 6. 7. 8. 9. Enter multiple subjects in the order of their importance (often based upon how much of the entire content is devoted to a particular subject). Use separate Subject elements to enter multiple subjects or clearly separate each entry by a semi-colon, space within an element. Use subject terms from established thesauri from the list(s) above. To determine subject, use the title, description, and resource itself. Enter multiple subjects in the order of their importance (often based upon how much of the entire content is devoted to a particular subject). Depending on your local system, use multiple subject elements (one element per subject is strongly recommended) or enter multiple subjects within the same element, clearly separating each entry by a semicolon and space. Enter subjects taken from different schemes or thesauri in separate subject elements. Identify applicable scheme or thesauri in the subject element or label using standardized abbreviations such as those from the MARC Code List for Term, Name, Title Sources ( http://www.loc.gov/marc/relators/relasour.html#rela600b ) Use specific or unique words rather than more general words (example: if object is a picture of lilies, use the term Lilies instead of Flowers; if object is a field of wild flowers, use the term Wild flowers, instead of Flowers. Subjects may be personal or organization names as well as topics, places, genres, forms, and events. * '" '" # $ ! ! % ( ) 23 of 57 * , !""# 10. Subject elements may describe not only what an object is about, but also what it is. A poem about coal miners might have a heading for Coal miners – Poetry to show the subject of the poem, and then another heading for Poem to show what the object is. Subject elements in this Dublin-core based metadata format may contain different types of headings that in other formats are differentiated into separate elements. 11. Have a clear understanding of how database handles non-standard characters such as diacritics and input them so that they display and retrieve effectively. Notes: 1. Subjects are different from the very the broad types found in the Type element. A digital image that is a photograph could be given the subject term photograph, but its genre type listed in the Type element would be “image”. An artist’s book might be given the subject genre term artist’s book while the genre type listed in Type element would be“text”. 2. Enter the names of creators of the object in the creator element. Only repeat these names in the subject element if object is also about the creator in some way. (Example: A record for The autobiography of Benjamin Franklin would list Franklin, Benjamin, 1706-1790 in both the creator and the subject elements; a record for an exhibition of Picasso’s works probably would list Picasso as both a creator and a subject since the exhibition is about him while a record of a single work by Picasso probably would list Picasso only in the creator element) Examples: Subject Terms Animal parasites and pests Territorial style Beanie babies (Stuffed animals) Deer -- Florida Indians of North America Indians of North America -- Religion Coal miners -- West Virginia -- Jackson County Arapahoe County (Colo.) -- Map Northwind, Chief Villa, Pancho, 1878-1923 Polastron, Marie-Louise d'Esparbáes de Lussan, vicomtesse de, 1764-1804 Missionaries-- Biographies Bookmarks Camera obscura works Camera obscuras Metalpoint drawings Protest posters Vocal music Student protesters -- Posters Peace movements -- Posters Islamic revival Saddlery Saddles Rocky Mountain states Atomic bomb Soil erosion Bibionidae -- Southern States. (a.k.a. Lovebugs) Lovebugs -- Southern States Source of term (i.e. scheme) NALAT ATT LCSH LCSH, LCTGM LCSH ATLA, LCSH LCSH, LCTGM LCSH LCAF LCAF LCAF ATLA LCSH, GMGPC GMGPC LCSH, AAT GMGPC GMGPC NICEM LCSH LCSH ATLA LCSH Local NICEM LCSH NICEM LCSH Local * '" '" # $ ! ! % ( ) 24 of 57 * , !""# Heaven’s Gate (Sect) Breast -- Cancer Breast Neoplasms Leptocoris trivittatus (a.k.a. Box-elder bug) Box-elder bug Horse & buggy 9-11 ATLA LCSH MeSH LCSH Local Local Local Maps to: Dublin Core Subject * '" '" # $ ! ! % ( ) 25 of 57 * , !""# Label: Description Dublin Core Definition: An account of the content of the resource. Description: A textual description of the content of the resource such as an abstract, table of contents, full-text, or free text account of the object. Mandatory: Yes. Repeatable: Yes. Refinements: May clarify nature of a given description element by adding one of the following terms to its label name: Term New Label Abstract Table of Contents Description. Abstract Description. Table of Contents Schemes: None. Input Guidelines: 1. 2. Enter descriptive text, remarks, and comments about the object. This information can be taken from the object or provided by the record creator. Enter here specialized information not included in other elements, e.g., measurements of a depicted object, description, provenance, technique, distinguishing features, inscriptions, condition, and history of the work. Examples: Description: Black and white photograph of horse and buggy, in front of the J.C. Penney store, Longmont, Colorado, ca. 1901. Print, photographic, black and white; subject, a woman and a child in a horse-drawn buggy, identified on back as Mrs. Merrick and Charlotte, on Garden of the Gods Road, by White House Ranch. Red Cross nurse beckoning woman to assist wounded solider [From University of Minnesota’s war posters collection] 17th to 18th century Chinese chair. Round-back chair [quanyi, yuanyi] 41 in. (h) x 24.5 in. (w) x 19.24 in. (d). Made of zitan (type of wood) * '" '" # $ ! ! % ( ) 26 of 57 * , !""# Digital version of sheet music originally published by Head Music, New York, 1911. 6 digital images [From University of Colorado, Boulder’s sheet music project] 1867; ink, wash and tempera on card, 19 x 35. Watercolor of Jackson and friend waving jackets at longhorn cattle by roadside. Includes holographic inscription by Jackson. Illustration in Picture Maker of the Old West, p. 35. [From Brigham Young University’s William Henry Jackson Collection] Label of an olive can for Monte Vista Brand Standard Ripe Olives packed by A. Adams, Jr. (F-599). 8.5” x 5.5” multi-colored label. [From San Fernando Valley History Digital Library] Description.Abstract: A collection of 225 posters from the 9th Colorado International Invitational Poster Exhibition, held 1995 in Fort Collins, Colorado. Description.Table of Contents: Opening hymn: To the poem (F. O'Hara) -- Three solos: The penny candy store beyond the El (L. Ferlinghetti). A Julia de Burgos (J. de Burgos). To what you said ... (W. Whitman).-- Three ensembles: Duet: Too, sing America (L. Hughes). Okay "Negroes" (J. Jordan). Trio: To my dear and loving husband (A. Bradstreet). Duet: Storyette H. M. (G. Stein). -- Sextet: If you can't eat you got to (E. E. Cummings). -Three solos: Music I heard with you (C. Aikin). Zizi's lament (G. Corso). Sonnet: What lips my lips have kissed ... (E. St. Vincent Milay). -- Closing hymn: Israfel (E. A. Poe) Maps to: Dublin Core Description * '" '" # $ ! ! % ( ) 27 of 57 * , !""# PUBLISHER Label: Publisher Dublin Core Definition: An entity responsible for making the resource available. Description: Entity that made the resource available. For digital objects, publisher is the entity that created the digital resource. Publishers can be a corporate body, publishing house, museum, historical society, university, a project, a repository, etc. Mandatory: No Repeatable: Yes, a resource may have a publisher and distributor or more than one entity responsible for making the resource available. . Refinements: None. Schemes: None Input guidelines: 1. 2. 3. 4. 5. 6. 7. 8. Use separate Publisher elements to enter multiple publishers or clearly separate each entry by a semicolon, space within an element. In the case of an object that existed in another form before being digitized, the publisher of this earlier form may be given in the Source element or, if a publisher of an earlier form is considered important to users and therefore for resource discovery, then include it in a Contributor element. When in doubt about whether an entity is a publisher or a creator, enter an organization as publisher and a personal name as creator. Use of authority files, such as Library of Congress Authories File (LCAF) is encouraged. This file is available via OCLC, RLIN, and the LC Web Authorities website ( http://authorities.loc.gov ). Omit initial articles in publisher names. Enter group or organization names in full, direct form. In the case of a hierarchy, list the parts from the largest to smallest, separated by periods. In the case of a long group or organization name that includes subordinate units, sometimes the name can be shortened by eliminating some of the hierarchical parts not considered necessary for uniquely identifying the body in question. For example, to enter the CIA as a contributor, use the form of the name as given in LCAF (United States. Central Intelligence Agency) instead of the full hierarchical name (United States. National Security Council. Central Intelligence Agency). If the publisher is the same as the creator, enter the name or entity in both the Publisher and Creator elements. Notes: 1. The Publisher element contains information about the digital publisher. Publisher information from earlier stages in an object’s publishing history may be listed in elements such as Source and Contributor. * '" '" # $ ! ! % ( ) 28 of 57 * , !""# Examples Publisher element These are publishers of the digital object University of Virginia Press National Academy of Science Denver Art Museum Brooklyn Historical Society Tennessee Valley Authority. Division of Natural Resources Colorado. Division of Social Services Keystone View Company Microsoft Corporation National Academy of Science United States. Government Printing Office Contributor element This is the publisher of a print book that was later digitized by another entity. Caxton Printers is an important small publisher anticipated to be of interest to users and needed for resource discovery. Caxton Printers Source element Describes publication information of original source from which digital object was derived. Excerpt from the book Cavalry Wife: the diary of Eveline M. Alexander, 1866-1867, Texas A&M University Press, 1977, ISBN 0890960259 Maps to: Dublin Core Publisher * '" '" # $ ! ! % ( ) 29 of 57 * , !""# CONTRIBUTOR Label: Contributor Dublin Core Definition: An entity responsible for making contributions to the content of the resource. Description: Person(s) or organization(s) who made significant intellectual contributions to the resource but whose contribution is secondary to any person(s) or organization(s) already specified in a Creator element. Examples: editor, transcriber, illustrator, etc. Mandatory: No. Repeatable: Yes. Refinements: None Schemes: None. Input Guidelines: 1. Enter multiple contributors in the order in which they appear on the resource or in order of their importance. Use separate Contributor elements to enter multiple contributors or clearly separate each entry by a semi-colon, space within an element. 2. If using established cataloging rules to construct contributor elements, follow those rules. Some examples of established rules include: Anglo-American Cataloging Rules (AACR2); Archives, Personal Papers, and Manuscripts (APPM); Categories of Description for the Works of Art (CDWA); Visual Resources Association (VRA). If not using such rules, then use the following guidelines. 3. Determine the correct form of the name when possible. The Library of Congress Authority File (http://authorities.loc.gov) or other locally specified bibliographic utilities (OCLC, RLIN, ULAN. etc.) should be consulted when possible. 4. Enter personal names in inverted form in most cases: Last name, First name, Middle name or initial. If it is not obvious how to invert or structure the name, use the name form given in an authority list or enter it, as it would be in the country of origin. Birth and/or death dates, if known, should be added, in accordance with authorized form of the name when possible. 5. Enter group or organization names in full, direct form. In the case of a hierarchy, list the parts from the largest to smallest, separated by periods. 6. In the case of a long group or organization name that includes subordinate units, sometimes the name can be shortened by eliminating some of the hierarchical parts not considered necessary for uniquely identifying the body in question. For example, to enter the CIA as a contributor, use the form of the name as given in Library of Congress Authorities File (United States. Central Intelligence Agency) instead of the full hierarchical name (United States. National Security Council. Central Intelligence Agency). 7. If there is doubt as to how to enter a name and the form of name cannot be verified in an authority list, enter it as it appears and do not invert (Example: Sitting Bull). 8. Have a clear understanding of how database handles non-standard characters such as diacritics and input them so that they display and retrieve effectively. * '" '" # $ ! ! % ( ) 30 of 57 * , !""# 9. Optional: The function of a contributor may be included in parentheses after the name. Example: Rockwell, Norman, 1894-1978 (illustrator). Notes: 1. Input entities responsible for digitizing an existing resource in the Publisher element. Examples: Personal names: Onassis, Jacqueline Kennedy, 1929Toulouse-Lautrec, Henri de, 1864-1901 Jeanne-Claude, 1935Duran y Gonzalez, Juan Maria, d 1899Chavez de Aguilar, Maria Alicia. Armijo Aguilar, Leopoldo Laozi (not Lao-Tzu or Po-yang Li or any of 34 other variants of this name given in the LCAF record) Webb, Wellington E. Pak, Sæong-t°aek Alexander, the Great, 356-323 B.C. Scroggins, C. H. Madonna, 1958- (meaning the entertainer; this is the form given in the Library of Congress Name Authority File do not just use “Madonna” which could be confused with another person) Smith, Adam, 1723-1790 (note that in the case of commonly encountered names, birth/death dates are very important to distinguish between otherwise identical names). Group or organization names: Ty, Inc. International Business Machines Corporation (not IBM or I.B.M.) Denver Art Museum Unesco (not U.N.E.S.C.O. or United Nations Organization for Education, Science, and Culture) Walt Disney Company H.W. Wilson Company Colorado. Dept. of Social Services. Massachusetts Institute of Technology. Migration and Development Study Group. Note that this shorter form of the name should be used as indicated by the LCAF and not the fullest form of the name which would be: Massachusetts Institute of Technology. Center for International Studies. Migration and Development Study Group. Maps to: Dublin Core Contributor * '" '" # $ ! ! % ( ) 31 of 57 * , !""# DATE.Original Label: Date.Original Dublin Core Definition: A date associated with an event in the life cycle of the resource. Description: Creation or modification dates for the original resource from which the digital object was derived or created. Mandatory: Yes, if applicable. Repeatable: Yes. Refinements: The five established refinements are: Refinement Label Definition Created Date of creation of the resource Valid Date of validity of the resource; this is often a range of dates Available Date that resource will become or did become available Issued Date of formal issuance (e.g. publication) of the resource Modified Date on which the resource was changed Schemes: ISO 8601 http://www.w3.org/TR/NOTE-datetime.html and DCMI Period http://dublincore.org/documents/dcmi-period/ Input guidelines: 1. 2. 3. 4. A resource may have several dates associated with it, including: creation date, copyright date, revision date, edition date, modification date, etc. Use separate Date.Original elements to enter multiple dates or clearly separate each entry by a semi-colon, space within an element. Enter dates in the form YYYY-MM-DD in accordance with the date/time standard ISO 8601 defined in http://www.w3.org/TR/NOTE-datetime.html. Use a single hyphen to separate the year, month, and date components: a. Year: YYYY (1997 for the year 1997)) b. Year and month: YYYY-MM (1997-07 for July 1997)) c. Complete date: YYYY-MM-DD (1997-07-16 for July 16, 1997) For a range of dates, enter the dates on the same line, separating them with a space, hyphen, space as in 1910 - 1920. To show a date is approximate, follow it with a question mark as in 1890? . Notes: 1. Enter dates pertaining to the digitized version of the resource under the Date.Digital element. * '" '" # $ ! ! % ( ) 32 of 57 * , !""# 2. Other date information can be described in the description element. Examples: Element Value 1950-06 1950-07 1948 2000 – 2002 1880? – 1915? 1998-06-15 1925? 2000-06-15 Definition Creation date for report issued in June, 1950 Modification date for above report that was subsequently revised in July, 1950 Date for digitized article reprint: reprinted, 1948; digitized 2002 Range of years during which collection of posters was created Approximate date range for set of stereographs with no known copyright date Creation date for letter written on June 15, 1998) Approximate year photograph taken or circa date Creation date for clay pot depicted in digitized slide Note: further date information pertaining to the creation of the slide can be included in the Description element. Maps to: Dublin Core Date * '" '" # $ ! ! % ( ) 33 of 57 * , !""# DATE.DIGITAL Label: Date.Digital Dublin Core Definition: A date associated with an event in the life cycle of the resource. Definition: Date of creation or availability of the digital resource; may be approximated by agency creating the record. Mandatory: Yes Repeatable: Yes Refinements: Refinement Label Created Modified Valid Issued Definition Date on which the resource was first created Date on which resource was last modified or changed Date of validity of the resource Date of formal issuance (e.g. publication) of the resource Schemes: ISO8601 Input Guidelines: 1. A resource may have several dates associated with it, including: creation date, copyright date, revision date, edition date, modification date, etc. Use separate Date.Digital elements to enter multiple dates or clearly separate each entry by a semi-colon, space within an element. 2. Enter eight digit numbers in the form YYYY-MM-DD as defined in http://www.w3.org/TR/NOTEdatetime.html, a profile of ISO 8601. In this scheme the date element 1994-11-05 corresponds to November 5, 1994. 3. If only the year is known, enter only the four-digit year. 4. Enter ranges of dates on the same line and use a dash ( - ) with a space on each side to separate dates. 5. Enter dates for different purposes on separate lines; i.e. date resource brought into being and date first collected. 6. If date is approximate use question mark (?) to indicate holding institution is approximating the date. NOTES: Local systems or databases may utilize other date formats and conventions for date entry. Also, some databases distinguish between free text "display" date values, and normalized date values for more efficient backend sorting * '" '" # $ ! ! % ( ) 34 of 57 * , !""# EXAMPLES: Element Value 1996-04-05 1996 1996-04 1996-04-01 - 1996-04-30 MAPS TO: Definition Standard entry for April 5, 1996 Date with only year known Date with only month and year known Date span Dublin Core Date * '" '" # $ ! ! % ( ) 35 of 57 * , !""# TYPE Label: Type Dublin Core Definition: The nature or genre of the content of the resource. Definition: A broad term drawn from a controlled vocabulary that describes the genre or nature of the resource. Mandatory: No Repeatable: Yes Refinements: None Schemes: Dublin Core Types Vocabulary http://www.dublincore.org/documents/dcmi-typevocabulary/ Input Guidelines: 1. Some digital objects may involve more than one TYPE, i.e. a manuscript collection may have text, image, sound and interactive components. Use separate Type elements to enter multiple types or clearly separate each entry by a semi-colon, space within an element. 2. For more information, see the Colorado Digitization Program's explanation at http://www.cdpheritage.org or the Library of Congress reference guide on this element at http://lcweb.loc.gov/marc/dc/typequalif19991210.html Notes: None Examples: Collection (Group of things, could be a mixture of these examples) Dataset (Statistical data file, CD-ROM of data, database) Event (Gallery opening, symposium, parade) Image (Map, stereograph, photograph, painting, engraving) Interactive Resource (video game, virtual exhibit) Service (System that provides function for the end-user, such as e-commerce order fulfillment) Software (Application software such as presentation viewer, word processor) Sound (Sound recording) Text (Scrapbook, diary, poem, home page, manuscripts, music score. Note that page images are text) Physical Object (Museum piece, architectural structure, monument) MAPS TO: Dublin Core Type * '" '" # $ ! ! % ( ) 36 of 57 * , !""# FORMAT.USE Label: Format.Use Dublin Core Definition: The physical or digital manifestation of the resource. Definition: Electronic format of the resource being described. Format.Use may include the electronic media-type or extent of the digital resource, such as file format, file size, or playtime. This element is used to help identify the software and hardware needed to load and use the digital resource. Mandatory: Yes Repeatable: Yes Refinements: None Schemes: Internet Media Types Input Guidelines: 1. Recommended best practice is to select electronic format terms from the Internet Media Types standardized list at http://www.isi.edu/in-notes/iana/assignments/media-types/media-types also known as MIME types. 2. Recommended bet practice is to include file size for large media files that have high bandwidth requirements, such as digital audio and video. Record the file size as bytes (i.e. 3,000,000 bytes) and not as kilobytes (Kb), megabytes (Mb), etc. 3. For large media files, such as digital audio and video, best practice is to include the playtime of the resource. 4. New media types and applications are always emerging. If the resource format being described is not yet part of the MIME type list, follow the MIME convention by selecting a broad category of object format (audio, video, application, etc.) for the first part of the MIME type, then use as a brief identifier for the second half of the MIME type the file name suffix usually attached to files of this format. See "xip" example below. Notes: Many local systems may not be used to capturing such information. If not, this metadata may be able to be inserted automatically by technical staff at the time of metadata sharing, if the same digital formats were created consistently throughout digitization projects. * '" '" # $ ! ! % ( ) 37 of 57 * , !""# Examples: Element Value image/jpeg text/html text/sgml application/sgml video/mpeg audio/mp3 audio/xip 3,000,000 bytes 1 minute Maps To: Definition visual file in JPEG format text file in HTML format text file in SGML-encoded format interactive application based upon SGML encoding video file in MPEG format sound file in MP3 format hypothetical audio file in which the file name ends with ".xip" file size for a 3 megabyte file playtime for a digital audio file Dublin Core Format * '" '" # $ ! ! % ( ) 38 of 57 * , !""# FORMAT.CREATION Label: Format.Creation Dublin Core Definition: None Definition: Technical information about the hardware, software and processes used to create a digital resource, including specifics such as scanner model, scan resolution, color profiles, compression schemes, file sizes, etc. Primary intended use is at local level, though FILE SIZE should be contributed in a shared metadata environment. Mandatory: Yes Repeatable: Yes Refinements: None Schemes: None Input Guidelines: 1. A resource may have multiple creation formats, such as Master, Access or Thumbnail. Use separate Format.Creation elements to enter multiple formats or clearly separate each entry by a semi-colon, space within an element. 2. This element is free text, and not based upon any Dublin Core recommendations. However, as a general guideline, information that describes technical aspects of the digital object's creation is beneficial for longterm administration, technical support and maintenance of digital objects. 3. Refer to NISO document Z39.87-2002, TECHNICAL METADATA FOR DIGITAL STILL IMAGES (http://www.niso.org/standards/resources/Z39_87_trial_use.pdf) for an excellent element-by-element example of the types of technical metadata that should be recorded about every digital object. This document is focused upon visual resources, but many of the technical metadata elements would apply to any digital file. 4. See also the Colorado Digitization Program's Draft Digital Audio Standards (http://www.cdpheritage.org/resource/audio/std_audio.htm). 5. An excellent print resource for more information is Maggie Jones and Neal Beagrie's Preservation Management of Digital Materials: A Handbook (British Library, 2001). 6. Some important technical details of digital file creation that are worth recording, but not included in other elements of this document: a. File Size - The number of bytes as provided by the computer system. Best practice is to record the file size as bytes (i.e. 3,000,000 bytes) and not as kilobytes (Kb), megabytes (Mb), etc. b. Quality - For visual resources, characteristics such as bit depth, resolution (not spatial resolution); for multimedia resources, other indicators of quality, such as 16-bit audio file. * '" '" # $ ! ! % ( ) 39 of 57 * , !""# c. Extent - Pixel dimensions, pagination, spatial resolution, playtime, or other measurements of the physical or temporal extent of the digital object. d. Compression - Electronic format or compression scheme used for optimized storage and delivery of digital object. This information often supplements the Format.Use element. e. Checksum Value - A numeric value used to detect errors in file recording or file transfer, checksum helps ensure the integrity of digital files against loss of data. f. Preferred Presentation - Designation of the device, application, medium, or environment recommended for optimal presentation of the digital object. g. Object Producer - Name of scanning technician, digitization vendor, or other entity responsible for the digital object's creation. Distinguishable from the descriptive Creator element, this element is mainly useful when different persons generated multiple versions of the object’s content. h. Operating System - Computer operating system used on the computer with which the digital object was created. (Examples: Windows, Mac, UNIX, Linux). Also include version of operating system. i. Creation Hardware - If a hardware device was used to create, derive or generate the digital object, indicate from a controlled list of terms the particular hardware device. (Examples: flatbed reflective scanner, digital camera, etc.) Include manufacturer, model name, and model number. j. Creation Software - Name and version number of the software used to create the digital object. k. Creation Methodology - If creation process used a standard series of steps, derivations or techniques, either state or refer to a URL describing the creation process. 7. The owning institution of the digital object may create and manage each of these elements as separate database fields. 8. Much of this information is only of value at the local level. In a shared metadata environment, it would be of little value for resource discovery or access, with the exception of the FILE SIZE refinement. Notes: Other useful creation information, such as the name of technicians, text encoders, digitization vendor, may also be beneficial for long-term administration of digital collections. It is recognized that many partners may split these discrete pieces of information (resolution, bit depth, hardware, etc.) into separate fields in their local databases or management systems. * '" '" # $ ! ! % ( ) 40 of 57 * , !""# Examples: Example 1: This 300,000,000 byte file is derived from a high-resolution (300 ppi, 24-bit) uncompressed TIFF image that was scanned from the original using an Epson 836 XL scanner, default color configuration. Example 2 (XML representation): <Format.Creation compression="lzw" quality="24-bit color, 300 ppi" filesize="300,000,000" checksum="D455 AD5F 66EF F100 B2BA 15F9" extent="9000h x 20,000w pixels" preferredpresentation="Sony Trinitron monitor using embedded color profile" operatingsystem="Mac OS X" creationhardware="PhaseOne PowerPhase FX Digital Camera attached to Mac G-4" methodology="Scanned files created using color profile found at http://url.address.edu"/> Maps To: N/A * '" '" # $ ! ! % ( ) 41 of 57 * , !""# IDENTIFIER Label: Identifier Dublin Core Definition: An unambiguous reference to the resource within a given context. Definition: A character string or record number that clearly and uniquely identifies a digital object or resource. The Identifier element ensures that individual digital objects can be managed, stored, recalled and used reliably. Mandatory: Yes Repeatable: Yes Refinements: Type Schemes: URL, ISBN, ISSN, local naming conventions. Input Guidelines: 1. Use separate Identifier elements to enter multiple identifiers or clearly separate each entry by a semi-colon, space within an element. Recommended best practice is to include Identifiers from different Schemes in separate elements. 2. Recommended best practice is to identify the resource by means of a string or number conforming to a formal identification system. Example formal identification systems include the Uniform Resource Identifier (URI), the Digital Object Identifier (DOI) and the International Standard Book Number (ISBN). 3. In addition to any formal or local identifying numbers, the Uniform Resource Locator (URL) should be included as an identifier for any Internet-accessible resource. 4. In a shared metadata environment, numbers unique within an institution's digital collection (e.g., accession numbers) should also include the name or a code for the institution along with the number, in case another participating institution also uses the same “unique” identifier. 5. Input ISSN, ISBN or other international standard numbers without hyphens or spaces. 6. If possible, use the identifier as the file naming basis for the digital object. 7. For multi-piece, multi-part digital objects such as each individual page image of a scanned text, best practice is to identify each page image with a predictable naming scheme locally, but to share one metadata record for the text as a single, whole resource. Notes: It is recognized that each participating partner will maintain its own local database or management system. Many databases and systems require a unique record number for each record. Such unique identifiers are ideal entries for the Identifier element. * '" '" # $ ! ! % ( ) 42 of 57 * , !""# Examples: Element Value ISSN10945234 http://jsr.lib.virginia.edu/ DeWaalC23655 KSHS//MSP01101 CSPM//S2001.32.35289.34 Definition ISSN for online JOURNAL OF SOUTHERN RELIGION URL for JOURNAL OF SOUTHERN RELIGION Identifier for a rare book from a standard bibliography Local record number for a digital object belonging to KSHS Museum accession number for a work of art For further examples, see the Library of Congress Naming Conventions For Digital Resources at http://lcweb.loc.gov/marc/naming.html and Northwestern University's Standards for Long-Term Storage and File Naming Conventions at http://staffweb.library.northwestern.edu/dl/adhocdigitization/storage/ Maps To: Dublin Core Identifier * '" '" # $ ! ! % ( ) 43 of 57 * , !""# SOURCE Label: Source Dublin Core Definition: A reference to a resource from which the present resource is derived. Comments: The present resource may be derived from the Source resource in whole or in part. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system. Description: When applicable, use the Source element to cite any other resource from which the digital resource was derived, either in whole or in part. Some digital resources are “born digital” and derive from no pre-existing resource; in these cases, the Source element is not used. Mandatory: No. Repeatable: Yes Refinements: None Schemes: None Input guidelines: 1. Use separate Source elements to enter multiple sources or clearly separate each entry by a semi-colon, space within an element. Usually there will only be once source from which the present digital resource has been derived. 2. If, as in most cases, the Source element describes an originating resource upon which the digital resource is somehow based, then also include a Relation element such as Relation.IsBasedOn – see Relation element for more information. Such Relation elements often duplicate information given in the Source element, but in shorter form and often with a hyperlink added. 3. The Source element may consist of a combination of elements such as free text combined with an ISBN to describe a book. 4. Whenever possible, include a unique standard identifier such as an ISBN, ISSN, LC call number, Dewey call number, NTIS report number. If no standard identifier exists, use a local call number, control number, accession number, or barcode. Identify the institution associated with such locally derived numbers. 5. Clarify the nature of the relationship between the two resources by using an initial phrase such as Originally published as:, Excerpted from:, Original book:, Original format:, or Reproduction of: etc. * '" '" # $ ! ! % ( ) 44 of 57 * , !""# Notes: 1. The Source element usually is used in conjunction with a corresponding Relation element. Because Source elements show a derivative relationship with another resource, they generally have a corresponding Relation element to show that relationship. Not all Relation elements, however, conversely require a corresponding Source element because not all related resources are derivative. For example, a resource might require another resource to support it or it might be referenced by another resource. In both these cases, a Relation element might be required (i.e. Relation.Requires and Relation:IsReferencedBy), but a Source element would not. See Relation for more information. Examples: Source Element Value Originally published as: Geek Love (New York: Warner Books, 1990), ISBN: 0446391301, 355 p. Definition Digitized version of a published book described in Source element Original version: 35 mm slide of a Van Briggle dark blue vase, slide no. 101 in the Modern Pottery Slide Collection, San Francisco Institute of Art. Digitized image from an original slide described in Source element Excerpted from: 30 minute audio cassette recording of Galway Kinnell, reading from his poems, at Southern Connecticut State University, April 6, 1987 Digitized audio clip taken from a audio cassette recording described in Source element Original book: Fisher, Vardis. God or Caesar? : the Writing of Fiction for Beginners (Caldwell, Idaho Caxton Printers, 1953), 271 p Digitized version of a published book described in Source element; a Contributer element also separately gives the print publisher, Caxton Printers, so that it is searchable Original letter: Letter from R.C. Smith to J.L. Fisher, Dec. 24, 1892, K.C. Fisher Papers, Calhoun State University, Special Collections, Accession No. 5346-9, box 2, folder 8 Digitized reproduction of a handwritten letter described in Source element Original artifact: Red Raku Ware Tea Bowl, 3 3/8 x 5 ½ inches, Metropolitan Museum of Art, New York Textual description Original format: VHS Videotape of “Star Wars,” directed by George Lucas Reproduction of: Red Cross Emblem poster, University of Winchester, War World II Poster Collection. Textual description Textual description Maps to: Dublin Core Source * '" '" # $ ! ! % ( ) 45 of 57 * , !""# LANGUAGE Label: Language Dublin Core Definition: A language of the intellectual content of the resource. Definition: Indicates the language(s)of the intellectual content of the resource. This implies the language(s) in which a text is written or the spoken language(s) of an audio or video resource. Visual images do not usually have a language unless there is significant text in a caption or in the image itself. Mandatory: No, but recommend entering the language element if it applies. Repeatable: Yes. Refinements: None Schemes: Adhere to the ISO 639 standard for languages (a two-letter code). RFC 1766 offers an option for adding a 2-letter country code taken from ISO 3166 (see note 1 below). Input Guidelines: 1. 2. 3. 4. A resource may include multiple languages. Use separate Language elements to enter multiple languages or clearly separate each entry by a semi-colon, space within an element. Indicate language using two-letter language codes defined by ISO 639. For a list of these codes, see http://www.loc.gov/standards/iso639-2/englangn.html In addition to using language codes, if needed, a textual description of the nature of the language may be included in the Description element. Example: In German and English, in parallel columns. Enter only one language per element; use multiple elements if needed. Notes: 1. These guidelines deliberately omit the option authorized by the Dublin Core Metadata Initiative to add country codes in combination with the language codes as in “en-UK” for English, United Kingdom or “enUS” for English, United States. Country codes are defined in ISO3166 standard at http://www.iso.org/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html * '" '" # $ ! ! % ( ) 46 of 57 * , !""# Examples: Language code fr en cs so Equivalent French English Czech Somali Maps to: Dublin Core Language * '" '" # $ ! ! % ( ) 47 of 57 * , !""# RELATION Label: Relation Dublin Core Definition: A reference to a related resource Description: Related resource. Element contains information necessary to find or link to a related resource. Element may consist of an identifier such as an URL, URI, etc.; the physical location of the related resource, if applicable; information about the nature of the relationship between the two resources, etc. Mandatory: No. Repeatable: Yes. A resource may relate to other resources in a variety of relationships that requires more than one Relation element to describe. The same resource can be a part of a larger resource while simultaneously containing a smaller resource than itself; it can be a more recent version of one resource and be superceded by another. A resource can be a different version of another resource, or contain the same intellectual content as another resource, but in a different format. Use one of the following refinements to explain the nature of the relationship between the described resource (i.e. resource described by the metadata record) and the related resource described in the Relation element. Include the refinement in the label name, not the element text. Refinements: Refinement Label Relation.IsPartOf Relation.HasPart Relation.IsVersionOf Relation.HasVersion Relation.IsFormatOf Relation.HasFormat Relation.References Relationship between the two resources: The described resource is a physical or logical part of the related resource The described resource includes the related resource either physically or logically The described resource is a version, edition, or adaptation of the related resource The described resource has a version, edition, or adaptation of the related resource The described resource has the same intellectual content of the related resource, but is presented in another format The described resource pre-existed the related resource, which is essentially the same intellectual content presented in another format The described resource references, cites, or otherwise points to the related resource. * '" '" # $ ! ! % ( ) 48 of 57 * , !""# Relation.IsReferencedBy The described resource is referenced, cited, or otherwise pointed to by the related resource. Relation.IsReplacedBy The described resource is supplanted, displaced or superceded by the related resource. Relation.Replaces The described resource supplants, displaces or supercedes the Relation.Requires Relation.IsRequiredBy related resource The described resource requires the related resource to support its function, delivery or coherence of content. The described resource is required by the related resource either physically or logically. Schemes: URI (Uniform Resource Identifier) Input guidelines: 1. 2. 3. Use separate Relation elements to enter multiple relations or clearly separate each entry by a semicolon, space within an element. As appropriate, select refinement from the above list of qualifiers recommended by the Dublin Core Metadata Initiative (DCMI) at http://dublincore.org/documents/dcmes-qualifiers/ Include sufficient information in the Relation element to enable users to identify, cite, and either locate or link to the related resource. Notes: None Examples: Label Relation.IsVersionOf Relation.IsBasedOn Relation.IsPartOf Relation.HasPart Relation.IsPartOf Relation.IsPartOf Relation.IsVersionOf Relation:HasVersion: Relation.IsPartOf Relation.IsFormatOf What Relation Element Contains Second ed. (another edition of same work) I am a Sorcerer is the English translation of Yo Soy Hechicero Library Journal v. 127, no. 9 (May 15, 2002) p. 32-4 (The described resource is the article and nothing else) Library Journal v. 127, no. 9 (May 15, 2002) p. 32-4 (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) Jack and Charmian London correspondence and papers, 1894-1953. Utah State University Special Collections & Archives, MSS COLL 10 Frank Waters Papers, University of New Mexico General Library Adaptation of the play Death of a Salesman by Arthur Miller Collection of recorded fairy tales read from various sources including: Babar the King (New York: Random House, 1935) E-journal article from Library Hi-Tech v. 20, no. 2 (2002) p. 137-140 http://lucia.emeraldinsight.com/vl=6724010/cl=22/nw=1/rpsv/cw/mcb/ 07378831/v20n2/s2/p137.idx Digital reproduction of the poster Wildflowers Amuk, City Museum of Wildflowers, New York. * '" '" # $ ! ! % ( ) 49 of 57 * , !""# Relation.IsFormatOf Relation.References Relation.IsReferencedBy Relation.Replaces Relation.IsReplacedBy Relation.Requires Relation.IsRequiredBy Relation.IsPartOf Digital reproduction of Diary of a Physician in California from microfilm version by University Microfilms, 1971 as part of American Culture Series II, reel 450, pt. 19. American Culture Series, II (Described source is an index to the series) The New Sabin, v. 1, no. 333. ISBN 0878750495 1040 Tax Form, 2000 (Related title is earlier version of described source, 1040 Tax Form 2001) 1040 Tax Form, 2002 (Related title is later version of described source, 1040 Tax Form 2001) NTIS Digest (Described resource is the NTIS Index, which requires the Digest to provide the corresponding abstracts & order information). NTIS Index (Index cannot stand alone; requires the Digest to supply the abstracts) Mesa Verde Black-on-white kiva jar (Vessel 25) (Record for an image of the jar’s lid, the lid is part of the overall pottery piece). Maps to: Dublin Core Relation * '" '" # $ ! ! % ( ) 50 of 57 * , !""# COVERAGE Label: Coverage Dublin Core Definition: The extent or scope of the content of the resource. Comment: Coverage will typically include spatial location (a place name or geographic coordinates), 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 [TGN]) and that, where appropriate, use named places or time periods in preference to numeric identifiers such as sets of coordinates or date ranges. Description: Describes the spatial or temporal characteristics of the intellectual content of the resource. Spatial refers to the location(s) covered by the intellectual content of the resource (i.e. place names; longitude and latitude; celestial sector; etc.) not the place of publication. Temporal coverage refers to the time period covered by the intellectual content of the resource (e.g. Jurassic; 1900-1920), not the publication date. 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. Mandatory: No. Currently recommended only for use in describing maps, globes, and cartographic resources or when place or time period cannot be adequately expressed using the Subject element. Repeatable: Yes. Refinements: Coverage.Spatial: describes geographical/place information using controlled vocabularies or conventions such as coordinates in a defined grid system. Coverage.Temporal: describes a date/time period according to accepted standards and controlled vocabularies. Schemes: Spatial schemes recommended by DCMES are: TGN (Getty Thesaurus of Geographic Names ) uses place names http://www.getty.edu/research/tools/vocabulary/tgn/ * '" '" # $ ! ! % ( ) 51 of 57 * , !""# DCMI Point uses geographic coordinates to locate a point in space ISO 3166 uses 3-letter codes to represent names of countries DCMI Box uses geographic limits to identify a region of space http://dublincore.org/documents/dcmi-point/ http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1 /index.html http://dublincore.org/documents/dcmi-box/ Other schemes available, but not in the DCMES list: http://geonames.usgs.gov/index.html Latitude/longitude coordinates following GNIS practice Ordnance Survey National Grid Reference such as the one for the United Kingdom. http://www.sewhgpgc.co.uk/os.html Temporal schemes recommended by DCMES are: DCMI Period W3-DTF, a profile based on ISO 8601 In this scheme, dates are indicated using the numeric form YYYY-MM-DD. (Example: enter November 5, 1994 as 1994-11-05). http://dublincore.org/documents/dcmi-period/ http://www.w3.org/TR/NOTE-datetime. Other schemes available, but not on the DCMES list: Terms from controlled vocabularies such as Library of Congress Subject Headings for recording time periods (Example: Middle Ages). Input Guidelines: 1. 2. 3. Multiple places, physical regions, dates, and time periods may be associated with the intellectual content of the resource. No hierarchy is implied. Use separate Coverage elements to enter multiple spatial and temporal values or clearly separate each entry by a semi-colon, space within an element. If using place names, select terms from a controlled vocabulary to identify place names (e.g. Geographic Names Information System (GNIS) at http://geonames.usgs.gov/index.html; Getty Thesaurus of Geographical Names, Library of Congress Subject Headings, etc.). If using latitude/longitude, enter according to GNIS standards: “A variable-length alphanumeric field that contains geographic coordinate pairs locating the feature. Each coordinate pair is compressed into and fixed at 15 characters. Latitude and longitude values are in degrees, minutes, and seconds followed by a one-character directional indicator. If the degrees of longitude are less than 100, a leading zero is present. The first coordinate pair listed in this element is termed the primary coordinates. In the case of a real feature [i.e. covering a * '" '" # $ ! ! % ( ) 52 of 57 * , !""# broad area, such as a mountain range], they represent the location of the approximate geographic center of the feature, whereas the primary coordinates of linear features [i.e. long & narrow as in a river] represent the location of the mouth of the feature.”—GNIS website. Enter coordinates as DDMMSSXDDDMMSSX with D=degrees, M=minutes; S=seconds, X=Directional indicator (N, S, E, or W); citing the latitude first, following by the longitude. Note that 3 spaces are provided for Longitude degrees and only 2 for Latitude. Use leading zeros if needed to fill up allotted spaces. Example: To represent coordinates for Washington Monument in Washington D.C., cite as 385322N0770208W which translates as latitude 38 degrees, 53 minutes, 22 seconds north and longitude of 77 degrees, 2 minutes, 8 seconds West. 4. Use free text to input B.C.E dates as in 200 B.C.E. 5. For a range of dates, enter the dates on the same line, separating them with a space, hyphen, and space as in 1900 – 1950. 6. To show a date is approximate, follow it with a question mark as in 1997? Notes: None Examples: Label Coverage.Temporal Coverage.Temporal Coverage.Temporal Coverage.Spatial Contents of Element 1776-07-04 Colonial America Ming 394916N0771325W Coverage.Spatial Coverage.Spatial 390254N0954040W 290903N0891512W Coverage.Spatial Coverage.Spatial 442830N084430W SN 045 055 Coverage.Temporal Coverage.Temporal Coverage.Temporal Coverage.Spatial Coverage.Spatial Coverage.Spatial Coverage.Temporal 1840? 1900-1901 15th century North America Paris Rocky Mountains 96 B.C.E. Type of Data Date for July 4, 1776 Time Period Time Period Latitude/Longitude for Gettysburg National Military Park Latitude/Longitude for Topeka, Kansas Latitude/Longitude for Mississippi River, at its mouth (end) in Pilottown, Louisiana Latitude/Longitude, Higgins Lake in Mich. A place in Wales, using the UK Ordnance Survey Grid System Approximate date or circa date Date range Time period Place name Place name Place name Free text B.C.E. date Maps to: Dublin Core Coverage * '" '" # $ ! ! % ( ) 53 of 57 * , !""# RIGHTS MANAGEMENT Label: Rights Dublin Core Definition: Information about rights held in and over the resource. Definition: The content of this element is intended to be a rights management or usage statement, a URL that links to a rights management statement, or a URL that links to a service providing information on rights management for the resource. A rights management statement may contain information concerning accessibility, reproduction of images, copyright holder, restrictions, securing permissions for use of text or images, etc. Mandatory: Yes, if Available Repeatable: Yes Refinements: None Schemes: None Input Guidelines: 1. Enter either a textual statement or a URL pointing to a use and access rights statement for digital resources on the Internet. 2. This statement can be a general copyright statement for the institution, for the whole collection, or a specific statement for each resource. 3. The statement may be general, providing contact information, or specific, including the name of the copyright holder. 4. Make sure that the rights statement corresponds to the digital resource; for example, link to a copyright statement for the digital resource instead of the original resource. Notes: None Examples: Example 1: http://www.college.edu/copyright.html [URL for a complete copyright statement] Example 2: U.S. and international copyright laws protect this digital image. Commercial use or distribution of the image is not permitted without prior permission of the copyright holder. Please contact XXX for permission to use the digital image. Example 3: This audio file may be freely used for educational uses, as long as it is not altered in any way. No commercial reproduction or distribution of this audio file is permitted without written permission of XXX. A high-quality version of this file may be obtained for a fee for personal use by contacting XXX. * '" '" # $ ! ! % ( ) 54 of 57 * , !""# Example 4: Copyright to this resource is held by XXX and is provided here for educational purposes only. It may not be downloaded, reproduced, or distributed in any format without written permission of XXX. Any attempt to circumvent the access controls placed on this file is a violation of United States and international copyright laws, and is subject to criminal prosecution. Maps To: Dublin Core Rights * '" '" # $ ! ! % ( ) 55 of 57 * , !""# HOLDING.INSTITUTION Label: Holding.Institution Dublin Core Definition: None Definition: A consistent reference to the institution or administrative unit that owns the digital resource for which metadata was created. Mandatory: Yes Repeatable: Yes Refinements: (optional) Geographic Location, which may include postal or general address information. Schemes: None Input Guidelines: 1. Use separate Holding.Institution elements to enter multiple institutions or clearly separate each entry by a semi-colon, space within an element. 2. Institution names should be entered exactly the same way for every record contributed, to permit reliable sorting by owning institution. 3. Institutional names may be entered either in direct order (as the name generally appears), or may be entered hierarchically subdivided according to Anglo-American Cataloging Rules (AACR2). Notes: Such information may not need to be stored locally, and can usually be inserted automatically into every metadata record at the time when metadata is shared. Examples: Element Value Wyoming State Historical Society Nebraska. Dept. of Administrative Services Holding Institution ="Kansas State Historical Society"Geog. Location="6425 SW 6th Avenue, Topeka, KS, 66615" Definition name entered in direct order name entered hierarchically by org. and sub-org., as opposed to just "Dept. of Administrative Services" entry including optional Geographic Location refinement Maps To: N/A * '" '" # $ ! ! % ( ) 56 of 57 *