Top Banner
Contributor Field Definitions (2006-09-16; rev. 2009-03-09 shoaf) Contributor is a Web application which, among other functions, provides a cataloging input form for creating/editing/deleting metadata records for assets in the USC Libraries Digital Archive. Contributor currently relies on the Documentum back end which, in turn, makes use of an Oracle database for metadata storage. Within Documentum, the custom metadata field set is called uscdoc and is based principally on the qualified Dublin Core element set. Table of Contents I. Field Labels..................................1 II. Field Names..................................2 III. Field Usage.................................5 IV. Field Fixed Values..........................52 V. Modifiers....................................53 VI. Node IDs....................................57 VII. Schemes....................................58 I. The field labels in Contributor are: Access Conditions Alternative Title [current label: Title alt] Bibliographic Citation Catalog Date Cataloger Cataloger Comments Contains Record ID [current label: Contains Record Id] Contents Contributor Coverage Dates Coverage Era Creator Date Created Date Issued Date Modified Description Digitize Date Filename (Repeatable) [current label: Filename] Contributor Field Definitions -- p.
93

Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Apr 20, 2018

Download

Documents

doananh
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Contributor Field Definitions(2006-09-16; rev. 2009-03-09 shoaf)

Contributor is a Web application which, among other functions, provides a cataloging input form for creating/editing/deleting metadata records for assets in the USC Libraries Digital Archive. Contributor currently relies on the Documentum back end which, in turn, makes use of an Oracle database for metadata storage. Within Documentum, the custom metadata field set is called uscdoc and is based principally on the qualified Dublin Core element set.

Table of Contents

I. Field Labels..............................................................................................1II. Field Names.............................................................................................2III. Field Usage............................................................................................5IV. Field Fixed Values...............................................................................52V. Modifiers...............................................................................................53VI. Node IDs..............................................................................................57VII. Schemes..............................................................................................58

I. The field labels in Contributor are:

Access Conditions Alternative Title

[current label: Title alt] Bibliographic Citation Catalog Date Cataloger Cataloger Comments Contains Record ID

[current label: Contains Record Id] Contents Contributor Coverage Dates Coverage Era Creator Date Created Date Issued Date Modified Description Digitize Date Filename (Repeatable)

[current label: Filename]

Format Geographic Coordinates Geographic Coverage Language Other Format Part of Part of Record ID

[current label: Part of Record Id] Previous Format Publisher Record ID [unlabelled] Record Type References Repository Address Repository Email Repository Name Rights Source Subject Title Type

Contributor Field Definitions -- p. 1

Page 2: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

II. The actual field names in Documentum as well as other field-specific parameters are given in the table below. Specifically:

Label -- what the field is called in Contributor Documentum name -- what the field is called in Documentum (and Oracle) XML element -- the XML specification used for importing metadata into

Documentum Other names -- previous field name(s) in use in other systems Length -- the number of characters defined for the field Modifier (_mod) length -- the number of characters for the field modifier tuple1,

if it exists (for instance, dc_title_alt_mod) Node ID (_nid) length -- the number of characters for the field node ID tuple, if

it exists (for instance, dc_contributor_nid) Scheme (_sch) length -- the number of characters for the field scheme tuple, if it

exists (for instance, dc_identifier_bib_cite_sch) Repeatable -- whether or not multiple instances of the field can exist in a single

record Required -- indication of whether use of the field is:

o not recommendedo optionalo recommendedo mandatoryo system supplied

In section -- the category or grouping in which the field is located in Contributor:o ACCESSo ADMIN DATAo ATTRIBUTESo CONTEXTo CREDITSo DESCRIPTIONo IDENTIFIERSo SUBJECT

1 A 'tuple' is a group of fields which are tightly linked with each other. For instance the creator tuple consists of dc_creator, dc_creator_mod, dc_creator_nid, dc_creator_sch. Not all fields are parts of tuples. Not all fields which are parts of tuples have all four possible parts of a tuple.

Contributor Field Definitions -- p. 2

Page 3: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO
Page 4: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

III. Field Usage

Field label: Access Conditionsrepeatable recommended length: 2000 in section: ACCESS

Definition: Information about conditions that affect the availability of the materials being described.

Usage: May indicate the need for an appointment to view physical materials which have been digitized, or the nature of restrictions imposed by the donor, legal statute, repository, or other agency. May also indicate the lack of restrictions.

This is an Encoded Archival Description (EAD) field. EAD description: Information about conditions that affect the availability of the materials being described. May indicate the need for an appointment or the nature of restrictions imposed by the donor, legal statute, repository, or other agency. May also indicate the lack of restrictions. Do not confuse with Conditions Governing Use <userestrict>, which designates information about limitations on the use of the described materials after access has been granted.

Examples: (213) 743-1672; http://www.usc.edu/isd/libraries/locations/grand/ Access to the original physical material is dictated by the individual institutions

contributing to the Internet Mission Photography Archive. Refer to individual items for specifics.

Contact rights owner at repository for access to physical images. Send requests to address or e-mail given. For permission to publish or republish material in any form -- print or electronic -- contact the Rights owner.

Researchers wishing to see any of the restricted materials should consult with the USC Libraries Special Collections staff.

Send requests to address or e-mail given. The collection may be viewed in the Virginia Steele Scott Gallery at the

Huntington Library, Art Galleries and Botanical Gardens. Consult visitor information at http://www.huntington.org/Information/HEHGeneral.html.

Documentum name (uscdoc): ead_access_conditions

XML expression: <accessConditions>

Other names: none

Related uscdoc fields: none

Page 5: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Definition: An alternative title by which an asset is known.

Usage: Some examples of alternative titles include translated, transliterated, transcribed, vernacular, shortened, abbreviated, former, or uniform titles. The alternative title may not be able to stand on its own and retain the same meaning or as full a meaning as it has in combination with Title. Do not capitalize every word. Normalize capitalization as if writing a sentence. Do not end the field with a punctuation unless such punctuation is part of a word or closes an abbreviation. Best practice is to not exceed the visible window for inputting the alternative title.

This field may be used with a modifier such as "romanization" or "short" from the dropdown box (dc_title_alt_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): Any form of the title used as a substitute or alternative to the formal title of the resource. This qualifier can include title abbreviations as well as translations for the name given to the resource.

Examples: [a subtitle] A ghoulish spoof in two acts [a translated title] The rite of spring [a transliterated title] Voĭna i mir [a vernacular title] Войнá и мир [a uniform title] Symphonies, no. 7, op. 92, A major ; arr.

Documentum name (uscdoc): dc_title_alt

XML expression: <title><alternative modifier="">

Other names: DC.Title.Alternative

Related uscdoc fields: dc_title_alt_mod

Field label: Alternative Title [current label: Title alt]repeatable optional length: 256 in section: DESCRIPTION

Page 6: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Bibliographic Citationrepeatable optional length: 1024 in section: CONTEXT

Definition: A bibliographic reference for an asset.

Usage: Use a standard citation standard such as Chicago Manual of Style, MLA or Turabian. Recommended practice is to include sufficient bibliographic detail to identify the asset as unambiguously as possible.

This field may be used with a scheme such as "Chicago" in the text box (dc_identifier_bib_cite_sch) adjacent to it. See full scheme list in Section VI. This field may be used with a modifier in the text box (dc_identifier_bib_cite_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage: An unambiguous reference to the resource within a given context. A bibliographic reference for the resource. Recommended best practice is to identify the resource by means of a string conforming to a formal identification system. Recommended practice is to include sufficient bibliographic detail to identify the resource as unambiguously as possible.

Examples: Okuda, Michael, and Denise Okuda. Star Trek Chronology: The History of the

Future. New York: Pocket, 1993. Wilcox, Rhonda V. 1991. Shifting roles and synthetic women in Star tred: The

next generation. Studies in Popular Culture 13 (June): 53-65. Mershon, D.H. (1998, November/December). Star trek on the brain: Alien minds,

human minds. American Scientist, 86(6), 585. Retrieved July 29, 1999, from Expanded Academic ASAP database.

Di Rado, Alicia. 1995. Trekking through college: Classes explore modern society using the world of Star trek. Los Angeles Times, March 15, sec. A.

James NE. Two sides of paradise: The Eden myth according to Kirk and Spock. In: Palumbo D, ed. Spectrum of the Fantastic. Westport, Conn: Greenwood; 1988:219-223.

Documentum name (uscdoc): dc_identifier_bib_cite

XML expression: <identifier><bibCitation modifier="" scheme="">

Other names: none

Related uscdoc fields: dc_identifier_bib_cite_mod; dc_identifier_bib_cite_sch

Page 7: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Catalog Daterepeatable recommended length: 32 in section: ADMIN DATA

Definition: A date on which the metadata record is created or modified.

Usage: In Contributor ver.1, this field is manually editable, however, the system will automatically generate a new instance of this field every time a record is edited and fill in that day's full date. Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). Normally times are not manually added to this field. As such, it is recommended, if a date must be input manually, that catalogers put the local date into this field rather than converting it to Universal Time before input. If a Universal Time must be expressed in this field, use the form yyyy-mm-dd hh:mm:ss. For each instance of Catalog Date, there must be a parallel instance of Cataloger.

In Contributor ver.2, this field is filled by the system and is not manually editable. The rules by which this field is filled follow. 1st instance: map data from dm_document attribute r_creation_date to uscdoc attribute catalog_date; 1st + n instance: map data from dm_document attribute r_modify_date to uscdoc attribute catalog_date. For each instance of Catalog Date, there must be a parallel instance of Cataloger. Note, n+1 equals the total number of times a record has been edited and includes its initial creation. Repeatable.

This is a non-Dublin Core field. Examples:

2006-09-16 1998-04-16 23:26:24

Documentum name (uscdoc): catalog_date (Contributor ver.1); r_creation_date & r_modify_date (Contributor ver.2)

XML expression: <catalogDate>

Other names: DC.Date.DataGathered; Catalog.Date

Related uscdoc fields: none

Page 8: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Catalogerrepeatable recommended length: 64 in section: ADMIN DATA

Definition: The name of a person who created or edited the metadata record.

Usage: In Contributor ver.1, this field is manually editable, however, the system will automatically generate a new instance of this field every time a record is edited and fill in the cataloger's name. Best practice for encoding names is "lastname, firstname". Follow standard capitalization. For each instance of Cataloger, there must be a parallel instance of Catalog Date.

In Contributor ver.2, this field is filled by the system and is not manually editable. The rules by which this field is filled follow. 1st instance: map data from dm_document attribute r_creator_name to uscdoc attribute cataloger; 1st + n instance: map data from dm_document attribute r_modifier to uscdoc attribute cataloger. For each instance of Catalog Date, there must be a parallel instance of Cataloger. Note, n+1 equals the total number of times a record has been edited and includes its initial creation.

This is a non-Dublin Core field.

Examples: Doe, John Smith, Dennis R.

Documentum name (uscdoc): cataloger (Contributor ver.1); r_creator_name & r_modifier (Contributor ver.2)

XML expression: <cataloger>

Other names: Cataloger.PersonalName

Related uscdoc fields: none

Page 9: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Cataloger Commentsnot repeatable not recommended length: 2000 in section: ADMIN DATA

Definition: Comments from a cataloger about the record which are not intended to be seen by the public.

Usage: Catalogers may note problems or peculiarities with a record or notes to oneself or other catalogers about this record. It is intended that records which are approved and ready for publication will typically not include any metadata in this field. This field does not display to the public in any event.

This is a non-Dublin Core field.

Examples: Need to add Subject. Finish this record after record 12. Check if "colored" is preferred to "coloured". Is this a dupe of record 48? Combine with record 86. Then delete 86.

Documentum name (uscdoc): cataloger_comments

XML expression: not applicable

Other names: none

Related uscdoc fields: none

Page 10: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Contains Record ID [current label: Contains Record Id]repeatable mandatory in collection records length: 256 in section: IDENTIFIERS

Definition: A reference to a child record via that record's Record ID.

Usage: This field is rarely used except in collection records for collections that also have sub-collections. Transcribe the Record ID of each sub-collection record. Include the collection prefix. Best practice is to use a globally unique identifier (GUID). However, most of USC's identifiers are only locally unique. Metadata in this field normally takes the form: collprefix-m#. This field facilitates downward navigation from parent records to child records. Do not use this field to reference item records. Normally there will be an instance of the Contents field for each instance of this field.

This is a qualified Dublin Core field. Dublin Core definition and usage: A reference to a related resource. The described resource includes the referenced resource either physically or logically. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

Examples: acsc-m1250 chinese-m1178 chs-m825 examiner-m1663 impa-m76 kada-m2 seakorea-m174 wpacards-m38843

Documentum name (uscdoc): dc_relation_haspart_guid

XML expression: <relation><haspart><guid>

Other names: DC.Relation.HasPart

Related uscdoc fields: none

Page 11: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Contentsrepeatable mandatory in collection records length: 256 in section: IDENTIFIERS

Definition: A reference to a child record via that record's Title. Also a reference to a part of an asset.

Usage: This field is principally used in collection records for collections that also have sub-collections. Transcribe the Title of each sub-collection record. Do not use this field to reference item records. This field may also be used to reference parts of the asset being described and may take the form of a table of contents. Normally there will be an instance of the Contains Record ID field or the Filename (Repeatable) field for each instance of Contents.

This field may be used with a modifier such as "collection" or "album" from the dropdown box (dc_relation_haspart_mod) adjacent to it.

This is a qualified Dublin Core field. Dublin Core definition and usage: A reference to a related resource. The described resource includes the referenced resource either physically or logically. Recommended best practice is to reference the resource by means of a string or number conforming to a formal identification system.

Examples: [collection] Los Angeles Examiner Negatives Collection, 1950-1961 [collection] Los Angeles Examiner Prints Collection, late 1920's - 1961

or Unit_ID: page001. -- Title: Kyung-cho Chung : article drafts. Unit_ID: page002. Unit_ID: page003. Unit_ID: page004. Unit_ID: page005. Unit_ID: page006. -- Title: Sungnakso : Song-uk Chang's acceptance of an

editorial position at Sinhan Minbo Houston branch. -- Principal_date_range: 1972.

Unit_ID: page007. -- Title: Hwa-mok Yi. Form letter : request to be an editor of Sinhan Minbo branch. -- Principal_date_range: 1972.

Unit_ID: page008. -- Title: Sungnakso (blanked form letter). -- Principal_date_range: 1972.

Documentum name (uscdoc): dc_relation_haspart

XML expression: <relation><hasPart modifier="">

Other names: none

Related uscdoc fields: dc_relation_haspart_mod

Page 12: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO
Page 13: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Contributorrepeatable optional length: 192 in section: CREDITS

Definition: The name of an individual or organization that has contributed to the intellectual content of the asset to a lesser degree than Creator.

Usage: Normally prefer forms of names taken from a standardized vocabulary, thesaurus, or reference. However, it is unlikely that every personal or organizational (e.g. corporate) name needed will be found in a standard source. Thus personal or organizational names may be entered which do not come from a standard source but rather are based on the form of the name encountered in the asset being cataloged or by performing a search on the Internet or in some other convenient source to determine the most appropriate form.

When entering a personal name not from a standard source, include titles (Mr. Ms, Dr., Lieutenant, etc.) only when there is some reason to believe the title is part of the normal way in which the name is used. Avoid abbreviations for all but the most common titles. Personal names are input in inverted order (i.e. last name first, first name last), separated by a comma space. If birth and/or death dates are known and/or used, they follow the name after a comma space.

This field may be used with a modifier such as "architect" or "interviewer", from the dropdown box (dc_contributor_mod) adjacent to it, to specify the role of the person or organization. This field may be used with a scheme such as "naf", for the National Authority File, from the dropdown box (dc_contributor_sch) adjacent to it, in order to indicate the vocabulary, thesaurus, or reference from which the form of the name in Contributor is taken.

This is a Dublin Core field. Dublin Core definition and usage: An entity responsible for making contributions to the content of the resource. Examples of a Contributor include a person, an organisation, or a service. Typically, the name of a Contributor should be used to indicate the entity.

Examples: [interviewer] Frost, David [lender] Boy Scout Troop 274 United States. Internal Revenue Service [donor] Wanamaker, Eric (Los Angeles, California) (donated 1935)

Documentum name (uscdoc): dc_contributor

XML expression: <contributor modifier="" nid="" scheme="">

Other names: DC.Contributor.CorporateName; DC.Contributor.PersonalName

Related uscdoc fields: dc_contributor_mod; dc_contributor_nid; dc_contributor_sch

Page 14: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Coverage Datesrepeatable recommended length: 64 in section: SUBJECT

Definition: The date or time period which the asset is about.

Usage: This field is a special type of Subject. That is, it describes the content of the asset. It should not be confused with other date fields (Date Created, Date Issued, Date Modified, Catalog Date, Digitize Date) which are reserved for dates in the asset's and metadata's life. However, for many assets, such as historic photographs, the date the asset was created (e.g. photographed) is nearly always a subject date and should be entered in Coverage Dates. For images in particular, there may also be objects in an image which are associated with specific times which predate the creation of the image, such as an archaeological relic dating from a previous time. That previous time should also be entered in Coverage Dates.

Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). More specific times may be expressed in the form yyyy-mm-dd hh:mm:ss. Less specific times may be expressed by the omission of the unknown component working from right to left. Paired start and end dates/times which indicate ranges of dates/times are separated by a slash /. B.C.E. (Before Common Era, i.e. B.C. or Before Christ) dates are expressed by preceding the date/time with a minus sign -.

This field may be used with a modifier such as "circa" or "after" from the dropdown box (dc_coverage_temporal_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): The extent or scope of the content of the resource. 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, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges. The qualifed field is defined specifically as containing temporal characteristics of the intellectual content of the resource.

Examples: 1900 1955-10-24 1824/1836-01 2000-10-30 13:00:00 -0500

Documentum name (uscdoc): dc_coverage_temporal

Page 15: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

XML expression: <coverage><temporal modifier="">

Other names: DC.Coverage.PeriodName

Related uscdoc fields: dc_coverage_temporal_mod

Page 16: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Coverage Erarepeatable not recommended length: 64 in section: SUBJECT

Definition: The date or time period which the asset is about.

Usage: Use Coverage Era only if a numerical type of date cannot be easily assigned. This field is a special type of Subject. This field describes the content of the asset. It should not be confused with other date fields (Date Created, Date Issued, Date Modified, Catalog Date, Digitize Date) which are reserved for dates in the asset's and metadata's life. However, for many assets, such as historic photographs, the date the asset was created (e.g. photographed) is nearly always a subject date and should be entered in Coverage Era or Coverage Dates. For images in particular, there may also be objects in an image which are associated with specific times which predate the creation of the image, such as an archaeological relic dating from a previous time. That previous time should also be entered in Coverage Era or Coverage Dates if at least an approximate date or date range is known.

This field may be used with a modifier such as "circa" or "after" from the dropdown box (dc_coverage_temporalera_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): The extent or scope of the content of the resource. 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, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges. The qualifed field is defined specifically as containing temporal characteristics of the intellectual content of the resource.

Examples: Jurassic period Stone age 18th century [after] Ming Dynasty

Documentum name (uscdoc): dc_coverage_temporalera

XML expression: <coverage><temporalera modifier="">

Other names: DC.Coverage.PeriodName

Related uscdoc fields: dc_coverage_temporalera_mod

Page 17: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Creatorrepeatable optional length: 192 in section: CREDITS

Definition: The individual or organization principally responsible for the intellectual content of the asset.

Usage: For a photograph, the Creator is generally the photographer. For a work of art, the artist. For a document, the author.

If the photograph is of an artistic work and the name of the artist is known, transcribe the artist’s name in a second Creator field. Other Creators include cartographers (of maps), engravers (of lithographs), printers (of broadsides), authors (of texts), etc.

The preferred (name) authorities are LCSH, NAF, ULAN, LACBD. However, it is unlikely that every personal or organizational name needed will be found in one of these sources. Thus personal or organizational (e.g. corporate) names may be used for Creator which do not come from one of these authorities but rather are based on the form of the name encountered in the asset being cataloged or by performing a search on the Web or in some other convenient source to determine the most appropriate form.

When adding a personal name Creator not from one of the above authorities, include titles (Mr., Ms, Dr., Lieutenant, etc.) when there is some reason to believe the title is part of the normal way in which the name is used. Avoid abbreviations for all but the most common titles. Personal names are input in inverted order (i.e. last name first, first name last), separated by a comma space. If birth and/or death dates are known and/or used, they follow the name after a comma space.

This field may be used with a modifier such as "photographer" or "author", from the dropdown box (dc_creator_mod) adjacent to it, to specify the role of the person or organization. The available roles are mostly a subset of the MARC Code List: Relator Codes -- Term[s] (see http://www.loc.gov/marc/relators/relaterm.html). See full modifier list in Section IV. This field may be used with a scheme such as "naf", for the National Authority File, from the dropdown box (dc_creator_sch) adjacent to it, in order to indicate the vocabulary, thesaurus, or reference from which the form of the name in Creator is taken. See full scheme list in section VI.

This is a Dublin Core field. Dublin Core definition and usage: An entity primarily responsible for making the content of the resource. Examples of a Creator include a person, an organisation, or a service. Typically, the name of a Creator should be used to indicate the entity.

Examples: [photographer] Pierce, C.C. [photographer] C.C. Pierce & Co. [cartographer] Hardy, R.W.H., Lieutenant [printer] Wheeler, S.A.P., Mrs. (San Gabriel, California) [artist] Vischer, Edward Automobile Club of Southern California

Page 18: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

[engraver] H.B. Hall's Sons, New York

Documentum name (uscdoc): dc_creator

XML expression: <creator modifier="" nid="" scheme="">

Other names: DC.Creator.CorporateName; DC.Creator.PersonalName

Related uscdoc fields: dc_creator_mod; dc_creator_nid; dc_creator_sch

Page 19: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Date Createdrepeatable mandatory length: 64 in section: CREDITS

Definition: The date that the asset was created. If born digital, it is the date the digital asset was created. If digitized from an analog source, it is the date the analog source was created

Usage: Many records will describe assets which began as physical and were later digitized. Date Created is the date the physical asset was created, such as the date a photograph was taken, a painting painted, a house built, an institution founded, a person born, etc. Make certain the Date Created makes sense in combination with the specified Format. If the Format is "photographs" then the Date Created should not be the date the building captured in the photograph was built, but rather the date the photograph itself was taken. Likewise, if the Format is "lighthouses", then the Date Created should not be for the date the photograph which depicts the lighthouse was taken, but rather the date the lighthouse itself was built.

Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). More specific times may be expressed in the form yyyy-mm-dd hh:mm:ss. Less specific times may be expressed by the omission of the unknown component working from right to left. Paired start and end dates/times which indicate ranges of dates/times are separated by a slash /. B.C.E. (Before Common Era, i.e. B.C. or Before Christ) dates are expressed by preceding the date/time with a minus sign -.

This field may be used with a modifier such as "circa" or "after" from the dropdown box (dc_date_created_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage: A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format. Qualifier (created): Date of creation of the resource.

Examples: 1900 1955-10-24 1824/1836-01 2000-10-30 13:00:00 -0500

Documentum name (uscdoc): dc_date_created

XML expression: <date><created modifier="">

Page 20: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Other names: DC.Date.Created

Related uscdoc fields: dc_date_created_mod

Page 21: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Date Issuedrepeatable optional length: 64 in section: CREDITS

Definition: The date of a formal issuance, such as publication, of an asset.

Usage: Many records will describe assets which began as physical and were later digitized. Date Issued is the date the physical asset was formally issued, such as the date a photograph was published, a painting first exhibited, etc. Make certain the Date Issued makes sense in combination with the specified Format. If the Format is "half-tone prints" then the Date Issued should not be the date the subject in the image was issued, but rather the date the image itself was issued. Likewise, if the Format describes the subject of an image, then the Date Issued should not be for the date the image which depicts the subject was issued, but rather for the subject such as a publication in the image was issued.

Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). More specific times may be expressed in the form yyyy-mm-dd hh:mm:ss. Less specific times may be expressed by the omission of the unknown component working from right to left. Paired start and end dates/times which indicate ranges of dates/times are separated by a slash /. B.C.E. (Before Common Era, i.e. B.C. or Before Christ) dates are expressed by preceding the date/time with a minus sign -.

This field may be used with a modifier such as "circa" or "after" from the dropdown box (dc_date_issued_mod) adjacent to it. See full modifier list in Section IV.

This is a qualified Dublin Core field. Dublin Core definition and usage: A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format. Qualifier (issued): Date of formal issuance (e.g., publication) of the resource.

Examples: 1900 1955-10-24 1824/1836-01 2000-10-30 13:00:00 -0500

Documentum name (uscdoc): dc_date_issued

XML expression: <date><issued modifier="">

Other names: DC.Date.Created

Page 22: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Related uscdoc fields: dc_date_issued_mod

Page 23: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Date Modifiedrepeatable optional length: 64 in section: CREDITS

Definition: The date a previously available asset was changed.

Usage: Many records will describe assets which began as physical and were later digitized. Date Modified is the date a previously available physical asset was changed, such as the date a new edition of a document was made available.

Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). More specific times may be expressed in the form yyyy-mm-dd hh:mm:ss. Less specific times may be expressed by the omission of the unknown component working from right to left. Paired start and end dates/times which indicate ranges of dates/times are separated by a slash /. B.C.E. (Before Common Era, i.e. B.C. or Before Christ) dates are expressed by preceding the date/time with a minus sign -.

This field may be used with a modifier such as "circa" or "after" from the dropdown box (dc_modifier_mod) adjacent to it.

This is a qualified Dublin Core field. Dublin Core definition and usage: A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability of the resource. Recommended best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF] and follows the YYYY-MM-DD format. Qualifier (modified): Date on which the resource was changed.

Examples: 1900 1955-10-24 1824/1836-01 2000-10-30T13:00:00 -0500

Documentum name (uscdoc): dc_date_modified

XML expression: <date><modified modifier="">

Other names: DC.Date.Created

Related uscdoc fields: dc_date_modified_mod

Page 24: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Descriptionrepeatable recommended length: 2000 in section: DESCRIPTION

Definition: A narrative description of the asset.

Usage: Description is an expansion of the metadata in the Title field. In the Description, make certain it is clear what manifestation of the asset is being described, perhaps by beginning the description with something explicit to the format, for instance, "Photograph of" followed by an expanded version of the title.

Generally use only complete sentences with normal punctuation. Use only one space after periods as a terminal punctuation unless a nearby abbreviation could confuse structure, in which case use two spaces after periods used as terminal punctuation.

Do not use 'throw-away' phrases even if their use is required to make a complete sentence. A 'throw-away' phrase is one which may be eliminated from a phrase without altering the meaning.

For instance, prefer "Photograph of a ball" to "This is a photograph of a ball".Keep the tense in the present if at all possible. But avoid the use of terms such as

"now" or "currently". Also avoid terms which place the cataloger in a certain time or place.

For instance, instead of "Santa Barbara Avenue, now called Martin Luther King Boulevard.", prefer "Santa Barbara Avenue, later called Martin Luther King Boulevard." or "Santa Barbara Avenue, renamed Martin Luther King Boulevard in 1983." or even "Santa Barbara Avenue, now (2002) Martin Luther King Boulevard." Prefer "UCLA is across town from USC" to "UCLA is across town from here"

For images, transcribe all signs and writing (within reason) in and on the image. Generally add these transcriptions to the end of the Description unless they more naturally come earlier in the Description. Enclose all transcriptions in double quotation marks. Use ellipses for illegible writing at the beginning or end of a quote. Use bracketed ellipses for illegible writing in the middle of a quote. In lists of quotes, separate each quote into its own quotation marks, delimited by commas and spaces outside of the quotes (NB, this departs from standard American quotation practice). Avoid the use of semicolons particularly within quotations. Prefer lower case transcription for everything except proper corporate or personal names, the beginnings of sentence-like phrases, and initialisms. See examples below.

Generally include editorial remarks (asides) in square brackets. Indicate questionable information with a question mark in square brackets immediately after the questionable information. If the questionable information is a word only, follow it immediately with no space and [?]. If the questionable information is a phrase, include a space before [?].

Generally use only a single Description field except in the following three cases (mostly applicable to images).

Page 25: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

a. The image contains multiple individual images: In which case briefly describe the entire image in the 1st description and provide more detailed descriptions of each of the individual images in its own succeeding description.

b. The image requires a lengthy transcription: In which case describe the image in the 1st description and transcribe the writing in the 2nd description.

c. There is additional information conveniently available about something or someone in the image which doesn’t describe the actual image: In which case describe the image in the 1st description and place additional information in the 2nd description unless the additional information is extremely short (a sentence or two).For IMAGES, try to describe all of the principle things in the image. Ask

yourself, What is the first thing I notice about this image? What is the second, the third, etc., Is there something unusual about this image? Try to provide sufficient description to answer those questions. Use specific and varied language since most end-user keyword searches will depend heavily on the description field for successful retrieval. Create sufficient description to give a sense of the image such that a reader can form a close concept of the image from the description alone. Most of your time will be spent on this element but try not to exceed 10 minutes. Generally do no research about the image except insofar as it is absolutely essential for a meaningful description. If you must research something (like the spelling of a name), try to use one source only (like the Web or an encyclopedia or dictionary). Spend no more than 5 minutes on research. Ultimately if no definitive answer can be found, explicitly question the information; use (?) in the description to make the uncertainty clear to readers.

This field may be used with a modifier such as "abstract" from the dropdown box (dc_description_mod) adjacent to it. See full modifier list in Section IV.

This is a Dublin Core field. Dublin Core definition and usage: An account of the resource. Description may include but is not limited to: an abstract, a table of contents, a graphical representation, or a free-text account of the resource.

Examples: Photograph of a tall Monterey cypress tree growing in a yard on Figueroa

Street, Los Angeles. Part of a 3-story wood Victorian residence is visible behind and to the left. Utility poles line the sidewalk and street at right. A horse-drawn wagon is visible further up the street.

[a transcription] "Libro Prímero de los Bautismos, esto es en que se asistan la Partidas de los que se christianan en esta nueva Mision de infieles Seraph 'D' San Buenaventura, Obispo, Cardenal, ex-Ministro de la Orden de N.S.P. San Francisco de la Salesia situada en la superior California playa de la canal S. Barbara, Perteneciente; Al Apostolico Colegio de Misioneros de propaganda Fide de San Fernando de Mexico del Orden Serafico. Fundada a expensas del Catholic S. D. Carlos III, Rey de las Espanas y de sus Indias y Dios prospere por los Religiosos de Aposotolico Colegio, y Comenzado en el solemnifico dia Domingo y agua de la Resurrecion de N.S. Jesu-Christo, 31 de Marzo de 1782, […] Fr. Junipero Serra."

Page 26: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

[an abstract] U.S. District Judge Michael Mukasey in Manhattan is to consider new arguments in a case that could have far-reaching consequences for the restitution of Nazi-looted art. Mukasey noted that the case was not an ordinary one and has allowed the office of attorney Mary Jo White to file an amended complaint seeking the forfeiture of the Egon Schiele painting Portrait of Wally, which is being stored at New York's Museum of Modern Art. The case started in December 1996, when, as a Schiele exhibition at the Modern closed, the heirs of Lea Bondi Jaray asked the museum to detain the portrait, which was on loan from Austria. They argued that it had been taken from Jaray during the Nazi regime, but the museum responded that it was contractually obliged to return the work to the lender. Although last July Mukasey ruled that the work could not be viewed as stolen because its recovery by Allied forces was tantamount to its having been recovered by an agent of its true owner, it is not known how he will rule after the new complaint is admitted.

[of an artifact] Rice bowl base fragment: double happiness, Chinese (stamped base mark).

Business card with text "Crispus A. Wright | Attorney at Law | 8500 Wilshire Boulevard, Suite 822 | Beverly Hills, California | Telephone 655-4400 | If no answer call DUnkirk 2-1311." Crispus was a 1938 African-American graduate of the University of Southern California Law School.

Mounted and framed medals for and photograph of Elmo Esprée. Although originally awareded to Elmo Esprée for participation in a battle on 29 October 1943, Mr. Esprée, who served in the 3468 Quartermaster Truck Company on the Burma Road from India to China, did not receive his commendation until the mid 1990s. The gold framed display is headed with a multi-colored ribbon bearing the designation "World War II 1941-1945." Included are head shot photograph of Elmo Esprée showing collar and shoulder insignia, "World War II" medal, "Efficiency, Honor, Fidelity" medal, "Asiatic Pacific Campaign" medal, "Driver-W" insignia pin.

[no asset] No image is available for this record.

Documentum name (uscdoc): dc_description

XML expression: <description modifier="">

Other names: DC.Description

Related uscdoc fields: dc_description_mod

Page 27: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Digitize Daterepeatable optional length: 32 in section: ADMIN DATA

Definition: Date the asset was digitized.

Usage: The date a formerly analog asset was digitized. Best practice for encoding the date value is defined in a profile of ISO 8601 [W3CDTF], follows the yyyy-mm-dd format, and reflects Universal Time (colloquially, Greenwich Mean Time). More specific times may be expressed in the form yyyy-mm-dd hh:mm:ss. Less specific times may be expressed by the omission of the unknown component working from right to left. Paired start and end dates/times which indicate ranges of dates/times are separated by a slash /.

This is a non-Dublin Core field.

Examples: 2006-09-16 1998-04-16 23:26:24 2007/2008

Documentum name (uscdoc): digitize_date

XML expression: <digitizeDate>

Other names: none

Related uscdoc fields: none

Page 28: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: File Name (Repeatable) [current label: File Name]repeatable mandatory

(except for assetless records)

length: 40 in section: IDENTIFIERS

Definition: File name of the asset being described.

Usage: This field connects the metadata to the asset being cataloged. When creating file names, consider the following guidelines:1. Maximum number of files to be created in a particular collection. Do not

establish a file name scheme which will not allow for the maximum expected number of the files to be created for a particular collection.

2. Number of characters. Shorter file names are less prone to mis-keying. Longer file names can be more descriptive. About 20 characters is a good compromise.

3. Characters in file names: never use spaces or periods; generally restrict file names to letters, numbers, dashes ("-"), and underscores

("_"); generally avoid: "#", "$", "*", which some systems treat as wildcards (though

"#" is less problematic than the other two); do not include the file name extension in the File Name (Repeatable) field; generally avoid using both upper and lower case letters, i.e. use only upper

case or only lower case.4. Generally include a few alphabetic characters at the beginning of the file name

which will be unique to the files for the collection.5. If objects being digitized have existing or standardized names or numbers, try to

incorporate these into the file names.6. File names must be unique for each asset. If this principle is not adhered to,

multiple and possibly unrelated files will be linked with some metadata records improperly. Also, depending on when and how the files are archived, one may write over another.This field is used with a system-supplied modifier -- an integer displaying in the

box (dc_relation_haspart_orn_mod) adjacent to it -- which indicates the order in which the files should be displayed.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): An unambiguous reference to the resource (or a related resource that is included either physically or logically in the described resource) within a given context. Recommended best practice is to identify the resource by means of a string conforming to a formal identification system.

Examples

California Historical Society file names begin with "CHS-" Works Progress Administration collection file names begin with "WPA-"

Page 29: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Works Progress Administration census cards have block numbers and card numbers associated with each one: in the file name "WPA-C-LACity-234-001", "234" is the block number, "001" is the card number

The newspaper El Clamor Publico has numbers and dates associated with each issue: in the file name, ECLAM-1855-06-19, "1855-06-19" is the date of a particular issue

Documentum name (uscdoc): dc_relation_haspart_orn

XML expression: <relation><hasPart><orn modifier="">

Other names: DC.Identifier; Integrated Digital Archive Identifier (IDAID); University of Southern California Identifier (USCID); Object Reference Number (ORN)

Related uscdoc fields: dc_relation_haspart_mod

Page 30: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Formatrepeatable recommended length: 128 in section: ATTRIBUTES

Definition: Identifies file format, medium, or dimensions of the physical or digital manifestation of the asset.

Usage: Include information regarding the format of the manifestation of the asset being described. For assets created by digitizing an analog object, Format normally describes the physical object, not the digital manifestation. Do not confuse Format with Type, the latter of which identifies the form of the content of the asset.

This field may be used with a modifier such as "extent" and a scheme such as "aacr2" from the dropdown boxes (dc_format_sch & dc_format_mod) adjacent to it. See full modifier and scheme lists in Sections IV & VI.

This is a Dublin Core field. Dublin Core definition and usage: The file format, physical medium, or dimensions of the resource. Examples of dimensions include size and duration. Recommended best practice is to use a controlled vocabulary such as the list of Internet Media Types [MIME].

Examples 4 photographs : glass photonegative, transparency, photonegatives, b&w ; 10 x 13

cm., 21 x 26 cm. 1 microfilm frame : negative, b&w ; 35 mm. 271 p. : ill. ; 21 x 15 cm. 1 broadside : coats of arms ; 75 x 60 cm. 1 map : col., mounted on linen ; 25 x 35 cm. 1 ms. map : 123.5 x 152.4 cm. 1 wall chart : b&w ; 40 x 23 cm. 2 maps on 6 sheets ; sheets 60 x 60 cm. or smaller 4 parts (20 p. each) ; 25-27 x 20 cm. 1 ms. score (15 leaves) ; 31 x 28 cm. 5 sound discs (3:20:00) : analog, 33⅓ rpm, stereo. ; 25-30 cm. 1 sound track film reel (10 min.) : magnetic ; 35 mm. 1 videodisc (38 min.) : sd., col. ; 30 cm. 1 videocassette (24 min.) : sd., b&w with col. introductory sequence ; 1.2 cm. photographs microfilm frame pages broadside map atlas globe relief model leaves sound discs aerial photographs

Page 31: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

architectural drawings art artefacts job applications newspapers panoramas stereographs strip maps tables (documents) text/plain text/xml multipart/mixed message message/news application image/jpeg image/tiff audio/basic audio/wav video/mpeg

Documentum name (uscdoc): dc_format

XML expression: <format modifier="" nid="" scheme="">

Other names: DC.Format

Related uscdoc fields: dc_format_mod; dc_format_nid; dc_format_sch

Page 32: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Geographic Coordinatesrepeatable recommended length: 64 in section: SUBJECT

Definition: The latitude and longitude of a place which the asset is about.

Usage: Coordinates are entered as pairs separated by a comma -- latitude then longitude. Multiple coordinate sets such as those describing a line or a polygon are entered into separate instances of this field. Prefer decimal degrees to other systems such as degrees minutes seconds. Altitude, if needed, follows longitude, separated from longitude with a comma, and is expressed in meters.

This field must be used in conjunction with a scheme of "point", "line", or "polygon" in the dropdown box (geocoordinate_sch) adjacent to it. For polygons, repeat the first coordinate set in order to close the polygon. A system supplied modifier (geocoordinate_mod) containing a sequential integer is displayed in the box adjacent to it. While it is possible to describe multiple points and multiple polygons, it is not possible to describe discontinuous or branching lines.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): The spatial topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant. Spatial topic, spatial applicability, and jurisiction may be a location specified by its geographic coordinates.

Examples: [polygon] [1] -118.31259,34.11161 [polygon] [2] -118.28554,34.11161 [polygon] [3] -118.28554,34.12806 [polygon] [4] -118.31259,34.12806 [polygon] [5] -118.31259,34.11161 [line] [1] -118.27930,34.04572 [line] [2] -118.27935,34.04564 [line] [3] -118.27940,34.04556 [point] [1] -118.19141,34.02075 [point] [1] -118.19141,34.02075,15.457

Documentum name (uscdoc): geocoordinate

XML expression: <coverage><geocoordinate modifier="" scheme="">

Other names: DC.Coverage.PlaceName

Related uscdoc fields: geocoordinate_mod; geocoordiate_sch

Page 33: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Geographic Coveragerepeatable recommended length: 192 in section: SUBJECT

Definition: The place which the asset is about.

Usage: Enter a place name. It is recommended that the place name come from an established authorative list or gazetteer. When entering place names from one hierarchy in a single record, always move from smallest to largest place name. For instance: roadways, cities, countries. When entering multiple place names from multiple hierarchies in a single record, always complete a hierarchy before moving to the next hierarchy. For instance: city A, country A, city B, country B. Put building names in Subject rather than Geographic Coverage.

This field may be used with a feature type modifier such as "countries" in the text box (dc_coverage_spatial_mod) adjacent to it. Prefer modifiers from the list of feature types maintained by the Alexandria Digital Library. Indicate the controlled vocabulary from which the place name comes using a scheme in the dropdown box (dc_coverage_spatial_sch) adjacent to the modifier text box. See full modifier and scheme lists in Sections IV & VI.

This is a qualified Dublin Core field. Dublin Core definition and usage (paraphrased): The spatial topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant. Spatial topic and spatial applicability may be a named place or location. A jurisdiction may be a named administrative entity or a geographic place to which the resource applies. Recommended best practice is to use a controlled vocabulary such as the Thesaurus of Geographic Names [TGN].

Examples: [roadways] 16 Pennsylvania Avenue [cities] Pasadena [countries, 2nd order divisions] Los Angeles [countries, 1st order divisions] California [countries] USA [enumeration district] 108 [census areas] census tract 261 [celestial globes] usgsarp: Moon

Documentum name (uscdoc): dc_coverage_spatial

XML expression: <coverage><spatial modifier="" nid="" scheme="">

Other names: DC.Coverage.PlaceName

Related uscdoc fields: dc_coverage_spatial_mod; dc_coverage_spatial_nid; dc_coverage_spatial_sch

Page 34: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Languagerepeatable recommended for textual

assetslength: 5 in section: ATTRIBUTES

Definition: The language of the content of the asset.

Usage: Select a language from the dropdown menu. Create a new instance of the field and repeat for each additional language the asset is in. Include the language of signs or other writing in photographs. Note the display after saving will not be the language selected but rather the encoded version of the language selected. For instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO 3166-1 alpha-2 codes for country.

This is a Dublin Core field. Dublin Core definition and usage: A language of the resource. Recommended best practice is to use a controlled vocabulary such as RFC 4646 [RFC4646].

Examples: English Spanish

Documentum name (uscdoc): dc_language

XML expression: <language>

Other names: DC.Language

Related uscdoc fields: none

Page 35: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Other Formatrepeatable optional length: 128 in section: ATTRIBUTES

Definition: Describes an alternative format of the asset.

Usage: Describes an alternative format of the asset, normally a format of the asset in a later state than that being described.

This field may be used with a modifier such as "extent" and a scheme such as "aacr2" from the dropdown boxes (dc_relation_isformatof_sch & dc_relation_isformatof_mod) adjacent to it. See full modifier and scheme lists in Sections IV & VI.

This is a qualified Dublin Core field. Dublin Core definition and usage: The file format, physical medium, or dimensions of the resource. A related resource that is substantially the same as the described resource, but in another format. Examples of dimensions include size and duration. This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/).

Examples: photographs image/tiff 1 microfilm frame : negative, b&w ; 35 mm.

Documentum name (uscdoc): dc_relation_isformatof

XML expression: <relation><isFormatOf modifier="" nid="" scheme="">

Other names: DC.Relation.HasFormat

Related uscdoc fields: dc_relation_isformatof_mod; dc_relation_isformatof_nid; dc_relation_isformatof_sch

Page 36: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Part ofrepeatable mandatory

(except for top collection records)length: 256 in section: CONTEXT

Definition: The exact title of the subcollection, collection or series record of which the current metadata record is a subcomponent.

Usage: Inputting the title of a parent record in the Part of field is the method used for connecting a metadata record and the asset it describes to a larger subcollection, collection or series. Normally the Part of field contains a reference only to its immediate parent collection or subcollection. The exception is when the item record is part of a series as well, in which case two instances of the Part of field contain a reference to the titles of both its collection/subcollection parent as well as its series parent respectively.

This field may be used with a modifier such as "collection" or "album" in the text box (dc_relation_ispartof_mod) adjacent to it. See full modifier list in Secion IV.

This is a qualified Dublin Core field. Dublin Core definition and usage: A related resource in which the described resource is physically or logically included. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.

Examples: [collection] California Historical Society Collection, 1860-1986 [album] Album 2 [exhibit] Black History Month Exhibit, Treasure Room, Doheny Memorial

Library, 2-26 February 1999: "African American Angelenos in the greater community: the historic networks of the Vernon-Central/University Park Neighborhood, 1920s-1990s."

Documentum name (uscdoc): dc_relation_ispartof

XML expression: <relation><isPartOf modifier="">

Other names: DC.Relation.IsPartOf

Related uscdoc fields: dc_relation_ispartof_mod

Page 37: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Part of Record ID [current label: Part of Record Id]repeatable mandatory

(except for top collection records)length: 32

in section: IDENTIFIERS

Definition: The record ID of the subcollection, collection or series record of which the current metadata record is a subcomponent.

Usage: Inputting the record ID of a parent record in the Part of Record ID field is the method used for connecting a metadata record and the asset it describes to a larger subcollection, collection or series. Normally the Part of Record ID field contains a reference only to its immediate parent collection or subcollection. The exception is when the item record is part of a series as well, in which case two instances of the Part of Record ID field contain a reference to the record IDs of both its collection/subcollection parent as well as its series parent respectively.

This is a qualified Dublin Core field. Dublin Core definition and usage: A related resource in which the described resource is physically or logically included. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system.

Examples: chs-m15009 examiner-m1663 impa-m1 kada-m1

Documentum name (uscdoc): dc_relation_ispartof_guid

XML expression: <relation><isPartOf><guid>

Other names: none

Related uscdoc fields: none

Page 38: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Previous Formatrepeatable optional length: 128 in section: ATTRIBUTES

Definition: Describes a previous format of the asset.

Usage: Describes a previous format of the asset, that is, a format of the asset in an earlier state than that being described.

This field may be used with a modifier such as "extent" and a scheme such as "aacr2" from the dropdown boxes (dc_relation_hasformat_sch & dc_relation_hasformat_mod) adjacent to it. See full modifier and scheme lists in Sections IV & VI.

This is a qualified Dublin Core field. Dublin Core definition and usage: The file format, physical medium, or dimensions of the resource. A related resource that is substantially the same as the pre-existing described resource, but in another format. Examples of dimensions include size and duration. This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/).

Examples: 1 photograph : b&w ; 11 x 15 cm. 10.2 x 6 cm photographic postcards, 9 x 14 cm.

Documentum name (uscdoc): dc_relation_hasformat

XML expression: <relation><hasFormat modifier="" nid="" scheme="">

Other names: DC.Relation.IsFormatOf

Related uscdoc fields: dc_relation_hasformat_mod; dc_relation_hasformat_nid; dc_relation_hasformat_sch

Page 39: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Publisherrepeatable mandator

ylength: 192 in section: CREDITS

Definition: The name of an individual or organization responsible for making the asset available, generally in its present form.

Usage: The "University of Southern California. Libraries" will be the principle Publisher for digital assets in USC’s Digital Archive. For descriptions of an asset's non-digital version, the publisher is interpreted more strictly as the traditional print publisher (or parallel role in other areas of dissemination).

This field may be used with a modifier such as "host" or "printer", from the dropdown box (dc_publisher_mod) adjacent to it, to specify the role of the person or organization. This field may be used with a scheme such as "naf", for the National Authority File, from the dropdown box (dc_publisher_sch) adjacent to it, in order to indicate the vocabulary, thesaurus, or reference from which the form of the name in Publisher is taken. See full modifier and scheme lists in Sections IV & VI.

This is a Dublin Core field. Dublin Core definition and usage: An entity responsible for making the resource available. Examples of a Publisher include a person, an organisation, or a service. Typically, the name of a Publisher should be used to indicate the entity.

Examples: [host] University of Southern California. Libraries Oxford University Press Warner Brothers Studios [printer] Sears, Roebuck & Co.

Documentum name (uscdoc): dc_publisher

XML expression: <publisher modifier="" nid="" scheme="">

Other names: DC.Publisher.CorporateName; DC.Publisher.PersonalName

Related uscdoc fields: dc_publisher_mod; dc_publisher_nid; dc_publisher_sch

Page 40: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Record ID [unlabelled]non-repeatable system supplied length: not applicable in section: at top

Definition: A unique identifier for a metadata record.

Usage: The Record ID is system generated and takes the form collection abbreviation, hyphen, "m", integer. The collection abbreviation is a unique abbreviation assigned to each collection normally between 3 and 15 characters in length. The "m" stands for metadata.

This is a non-Dublin Core field.

Examples: impa-m100 usctheses-m1234 kada-m540

Documentum name (uscdoc): recordid

XML expression: <recordId>

Other names: none

Related uscdoc fields: none

Page 41: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Record Typenon-repeatable mandatory length: 48 in section: ATTRIBUTES

Definition: A designation of the hierarchical role the record is intended fulfill.

Usage: A record is either a collection record, an item record, or occasionally a series record. Collection records are at the top of the hierarchy of records. All other records in a collection belong to or point to the collection record as their parent. Another collection record which belongs to or points to a different collection record in the same collection is known as a subcollection record. Item records are at the bottom of the hierarchy of records. All item records point to or belong to a collection record or a subcollection record, never both. A series record is a non-collection record which points to or belongs to a collection record. A series record has item records. That is, item records in a collection may belong to or point to a series record as one of their parents. The Record Type of a collection or subcollection record is always "collection". The Record Type of an item record is always "item". The Record Type of a series record varies.

This is a non-Dublin Core field.

Examples: collection [for mandatory collection or optional subcollection records] item [for optional item records] series [for optional series records] album [for optional series records]

Documentum name (uscdoc): record_type

XML expression: <recordType>

Other names: none

Related uscdoc fields: none

Page 42: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Referencesrepeatable optional length: 256 in section: CONTEXT

Definition: A citation for a related resource.

Usage: Transcribe citation-type information here, for instance when the asset being described is referenced in the cited resource. Most common usage is for a book, article, or Web page in which the asset has been published. Use a standard citation form such as Chicago Manual of Style. Do not invert personal names. Best practice is to cite only references which are considered stable, e.g. which will not cease to exist or will not move.

This field may be used with a modifier such as "journal article" or "exhibit" in the text box (dc_relation_references_mod) adjacent to it. See full modifier list in Secion IV.

This is a qualified Dublin Core field. Dublin Core definition and usage: A related resource that is referenced, cited, or otherwise pointed to by the described resource. This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/).

Examples: [book] "Pictorial History of California" [no additional information available] [book] George Wharton James. The Indians of the Painted Desert Region. Little

Brown & Co., 1903. [conference name] Italy-Japan Symposium "Recent Achievements and

Perspectives in Nuclear Physics" (5th : 2004 : Naples, Italy)

Documentum name (uscdoc): dc_relation_references

XML expression: <relation><references modifier="">

Other names: Relation.References

Related uscdoc fields: dc_relation_references_mod

Page 43: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Repository Addressrepeatable recommended length: 1024 in section: ACCESS

Definition: Physical address of the institution or agency responsible for providing intellectual access to the materials being described.

Usage: The full street address (including city, state, country, etc.) may include telephone numbers, telefacsimile numbers, but not e-mail addresses. This may also be the location of the repository where the physical version of a digital asset is stored. Avoid personal telephone numbers since these will change over time. Use an address which will be generic enough to stay current for a long time.

This is an Encoded Archival Description (EAD) field. EAD description: A generic element for information about the place where someone or something is located and may be reached. Examples include a postal address for a repository, or the electronic mail address and phone number of the party granting publication permission.

Examples: 1200 Getty Center Drive, Suite 1100, Los Angeles, CA 90049-1688 Doheny Memorial Library 206, 3550 Trousdale Parkway, Los Angeles,

California,90089-0189, 213-740-4035 Evangelisch-Lutherisches Missionswerk Leipzig e.V., Paul-List-Str. 19, D-04103

Leipzig, Germany Fax (213)-740-0011 NMS Archives, att.: Arkivleder NMS Arkiv / Chief Archivist NMS Archives,

Misjonshoegskolen/The School of Mission and Theology, Misjonsveien 34, N-4024 Stavanger. Norway; + 47 51 51 62 16 (phone); + 47 51 51 62 25 (fax)

Documentum name (uscdoc): ead_repository_location

XML expression: <repositoryLocation>

Other names: none

Related uscdoc fields: none

Page 44: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Repository Emailrepeatable recommended length: 256 in section: ACCESS

Definition: Email address of the institution or agency responsible for providing intellectual access to the materials being described.

Usage: Avoid personal e-mail addresses since these will change over time. Use an address which will be generic enough to stay current for a long time.

This is an Encoded Archival Description (EAD) field. EAD description: A generic element for information about the place where someone or something is located and may be reached. Examples include a postal address for a repository, or the electronic mail address and phone number of the party granting publication permission.

Examples: [email protected] [email protected] http://www.usc.edu/isd/libraries/services/ask_a_librarian/email/ [email protected]

Documentum name (uscdoc): ead_repository_email

XML expression: <repositoryEmail>

Other names: none

Related uscdoc fields: none

Page 45: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Repository Namerepeatable recommended length: 256 in section: ACCESS

Definition: Name of the institution or agency responsible for providing intellectual access to the materials being described.

Usage: This is the official form of the name of the repository.This is an Encoded Archival Description (EAD) field. EAD description: The

institution or agency responsible for providing intellectual access to the materials being described. Although the repository providing intellectual access usually also has physical custody over the materials, this is not always the case. For example, an archives may assume responsibility for long-term intellectual access to electronic records, but the actual electronic data files or systems may continue to reside in the office where they were created and maintained, or they may be held for long-term storage by a unit such as a data library that is able to provide the appropriate technical facilities for storage and remounting. When it is clear that the physical custodian does not provide intellectual access, use [a different field] to identify the custodian and repository to designate the intellectual caretaker. When a distinction cannot be made, assume that the custodian of the physical objects also provides intellectual access to them and should be recognized as the repository.

Examples: Automobile Club of Southern California East Asian Library, USC Libraries, University of Southern California DM-échange et mission Private collections

Documentum name (uscdoc): ead_repository_name

XML expression: <repositoryName>

Other names: none

Related uscdoc fields: none

Page 46: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Rightsrepeatable recommended length: 1024 in section: ACCESS

Definition: A rights management statement for the resource or reference to a service providing such information.

Usage: Contains one or more of three types of information regarding the asset being described: 1) a rights management statement; 2) an identifier that links to a rights management statement; 3) an identifier that links to a service providing information about rights management.

This field may be used with a modifier such as "owner" or "arranger" in the dropdown box (dc_rights_mod) adjacent to it, to specify the role of the a person or organization in the Rights field. This field may be used with a scheme such as "naf", for the National Authority File, from the dropdown box (dc_rights_sch) adjacent to it, in order to indicate the vocabulary, thesaurus, or reference from which the form of the name in Rights is taken. See full modifier and scheme lists in Sections IV & VI.

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

Examples: "Neither the General Conference nor any General Agency of The United

Methodist Church (successor to the Methodist Episcopal Church) claims any interest in the photos or images."

Associated Press Contact the Greene and Greene Archives for permission to reproduce materials

from the collections and a schedule of fees for reproduction. The patron must determine and satisfy copyright or other use restrictions before publishing or otherwise distributing materials from the collections.

Copyright has not been assigned to the Southern California Library for Social Studies and Research. Researchers may make single copies of images solely for the purpose of private study. Copies for any other purpose must be requested in writing from the director of Southern California Library for Social Studies and Research, 6120 South Vermont Avenue, Los Angeles, CA 90044; phone (323) 759-6063. When the Southern California Library for Social Studies and Research gives permission for publication, it is as the owner of the physical item and is not intended to include or imply permission of the copyright holder, which must also be obtained.

Distributed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License (http://creativecommons.org/licenses/by-nc-sa/2.5/) which permits unrestricted

Page 47: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

use, distribution and reproduction in any medium, provided the work is attributed to Irving Rehman, Ph.D., F.I.C.S., and Chadwick F. Smith, M.D., Ph.D., F.A.C.S., F.I.C.S., and source in the manner specifiied by the publisher.

Reproduction rights for decorative arts images are held by Interfoto. To order reproductions, contact Interfoto, 5901 West Third Street, Los Angeles, CA 90036. Telephone: 213-689-0004.

Documentum name (uscdoc): dc_rights

XML expression: <rights modifier="" nid="" scheme="">

Other names: DC.Rights

Related uscdoc fields: dc_rights_mod; dc_rights_nid; dc_rights_sch

Page 48: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Sourcerepeatable optional length: 128 in section: IDENTIFIERS

Definition: Contains a number, designation or other identifier which helps the user to find a physical (usually) manifestation of the asset.

Usage: This field contains a number, designation or other identifier which helps the user to find a physical (usually) manifestation of the asset. This may be a call number, an accession number, a shelf mark, or other locating device. It may also include record numbers in other external, non-linking, databases which may contain information about an asset.

This field may be used with a modifier such as "call no" or "bar code" in the dropdown box (dc_rights_mod) adjacent to it, to specify the type of information in the Source field. See full modifier list in Section IV.

This is a Dublin Core field. Dublin Core definition and usage: A related resource from which the described resource is derived. The described resource may be derived from the related resource in whole or in part. Recommended best practice is to identify the related resource by means of a string conforming to a formal identification system. This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/).

Examples: [call no] CHS-4059 [bar code] 3-1275-02806-2355 [record id] USC-1-1-1-13518 [ref no] B-30.65.128

Documentum name (uscdoc): dc_source

XML expression: <source modifier="">

Other names: DC.Source

Related uscdoc fields: dc_source_mod

Page 49: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Subjectrepeatable recommended length: 192 in section: SUBJECT

Definition: Keyword or topic of the resource.

Usage: Subjects serve the purpose of keywords for searching, however, the vocabulary used for them is generally highly controlled as this facilitates more refined and comprehensive recall. Subject terms come from pre-existing lists of terms. In compelling instances, locally defined topical terms (non-names) may be used. Try to include at least one term each from LCSH (Library of Congress Subject Headings).

A Subject may also be a person or organization. Use the form of the name as found in some authoritative vocabulary such as the NAF (National Authority File). If a name cannot be located in an authoritative listing, create as complete a form as possible with the information available.

When creating a personal name Subject not from an authoritative source, include titles (Mr., Ms, Dr., Lieutenant, etc.) when there is some reason to believe the title is part of the normal way in which the name is used. Avoid abbreviations for all but the most common titles. Personal names are input in inverted order (i.e. last name first, first name last), separated by a comma space. If birth and/or death dates are known and/or used, they follow the name after a comma space.

Do not transcribe individual place names here (these go in the Geographic Coverage field). However, if a place name is compound (e.g. "San Pedro and Wilmington") or combined with a non-place-name term (e.g. "San Diego -- Street names") then it belongs here in Subject. Likewise, do not indicate time periods here (these go in the Coverage Date or Coverage Era fields). If the time period is combined with a non-place-name term (e.g. "Native American basketry -- 1700-1800") then it belongs here in Subject.

Multiple terms may come from a single authority. Subjects from different authorities may be entered in any order relative to each other, however, keep multiple terms from the same authority adjacent to each other if no other compelling rational prevents it.

This field may be used with a modifier such as "keyword" or "personal name" in the dropdown box (dc_subject_mod) adjacent to it. Indicate the controlled vocabulary from which the place name comes from the dropdown box (dc_subject_sch) adjacent to the modifier box. See full modifier and scheme lists in Sections IV & VI.

This is a Dublin Core field. Dublin Core definition and usage: The topic of the resource. Typically, the subject will be represented using keywords, key phrases, or classification codes. Recommended best practice is to use a controlled vocabulary. To describe the spatial or temporal topic of the resource, use the Coverage element.

Examples: [ftamc] tenpin bowling [lcsh] African Americans [naf] [personal name] Schiele, Egon, 1890-1918

Page 50: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

[naf] [corporate name] United States. Army. Quartermaster Truck Company, 3468th [ulan] [personal name] Leonardo da Vinci [file heading] Los Angeles -- General Views Indian Affairs. Names: Mdewakanton [personal name] Ethington, Philip J. [personal name] Barton, Mrs. Thomas [keyword] ostrich farms

Documentum name (uscdoc): dc_subject

XML expression: <subject modifier="" nid="" scheme="">

Other names: DC.Subject

Related uscdoc fields: dc_subject_mod; dc_subject_nid; dc_subject_sch

Page 51: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Definition: A title by which an asset is known.

Usage: This is the title given to the image, text or other asset as a quick caption-like identifier. This title may often be the only information to accompany the image in many different contexts. Therefore, try to keep the title relevant, fairly short (up to about 20 words or so) yet distinctive, one sentence, and without too many adjectives or adverbs. If there is a title assigned by the creator of the physical asset, prefer this. Avoid abbreviations. If possible, include a place name (if applicable) and a date of creation (year only) at the end of the title. If there is a possible alternative interpretation of the date of creation, make what the date refers to more explicit. If the date is unknown, try to place it within two decades, i.e. ca.1900-1920. If no date can be determined, use “[s.d.]” (i.e. sine dato).

This field may be used with a modifier such as "book" or "series" from the dropdown box (dc_title_mod) adjacent to it. See full modifier list in Section IV.

This is a Dublin Core field. Dublin Core definition and usage: A name given to the resource. In current practice, this term is used primarily with literal values; however, there are important uses with non-literal values as well.

Examples: Caldwell and Brothers General Store and Post Office in Spadra, California, ca.1880 General view, from the west, of Mission Santa Barbara, ca.1900 Portrait of Mr. Joseph M. Willowbrook, Los Angeles, 1903 Drawing of a cowboy with a lasso, California, photograph 1875 WPA household census employee document for Jack W. Abbott, Los Angeles,

ca.1939 El Clamor Publico, vol. I, no. 1, Junio 19 de 1855

Documentum name (uscdoc): dc_title

XML expression: <title modifier="">

Other names: DC.Title

Related uscdoc fields: dc_title_mod

Field label: Titlerepeatable mandator

ylength: 256 in section: DESCRIPTION

Page 52: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

Field label: Typerepeatable mandatory length: 48 in section: ATTRIBUTES

Definition: The general genre of the resource being described.

Usage: Types serve the purpose of identifying the form of the content of the asset, not the format of the asset or manifestations thereof. The vocabulary used for type is generally highly controlled and extremely limited, and comes from a pre-existing list of terms.

This is a Dublin Core field. Dublin Core definition and usage: The nature or genre of the resource. Recommended best practice is to use a controlled vocabulary such as the DCMI Type Vocabulary [DCMITYPE]. To describe the file format, physical medium, or dimensions of the resource, use the Format element.

Examples: collection dataset event image interactive resource physical object service software sound text

Documentum name (uscdoc): dc_type

XML expression: <type>

Other names: DC.Type

Related uscdoc fields: none

Page 53: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

IV. Field Fixed Valuesdc_language dc_type record_typeUndetermined Hindi Ossetian; Ossetic audio albumEnglish Hiri Motu Palawan born-digital material bookSpanish Hungarian Pali collections boxAbkhazian Icelandic Panjabi images collectionAfar Indonesian Persian maps envelopeAfrikaans Interlingua (IALA) Polish multiple types folderAlbanian Interlingue Portuguese physical objects issueAmharic Inuktitut Pushto [Pashto] texts itemArabic Inupiaq Quechua video lantern slides

Armenian Irish Raeto-Romance miscellaneous collection

Assamese Italian Romanian negativesAvestan Japanese Rundi official collectionAymara Javanese Russian official portrait seriesAzerbaijani Kalaallisut Samoan other portrait seriesBashkir Kannada Sango photocopiesBasque Kashmiri Sanskrit picturesBelarussian Kazakh Sardinian seriesBengali Khmer Serbian slide seriesBihari Kikuyu Shona specimen printsBislama Kinyarwanda Sindhi volumeBosnian Kirghiz SinhaleseBreton Komi SlovakBulgarian Korean SlovenianBurmese Kuanyama Somali

Catalan Kurdish Sotho, Southern [Sesotho]

Chamorro Lao [Laothian] SundaneseChechen Latin SwahiliChichewa; Nyanja Latvian Swati

Chinese Letzeburgesch [Luxembourgish] Swedish

Chruch Slavic Lingala TagalogChuvash Lithuanian TahitianCornish Macedonian TajikCorsican Malagasy TamilCroatian Malay TatarCzech Malayalam TeluguDanish Maltese ThaiDutch Manx TibetanDzongkha Maori TsongaEsperanto Marathi TswanaEstonian Marshall TurkishFaroese Moldavian TurkmenFijian Mongolian TwiFinnish Nauru UighurFrench Navajo UkrainianFrisian Ndebele, North UrduGaelic (Scots) Ndebele, South UzbekGallegan Ndonga VietnameseGeorgian Nepali WolofGerman Northern Sami WelshGreek, Modern (post 1453) Norwegian Xhosa

Guarani Norwegian Bokmål YiddishGujarati Norwegian Nynorsk Zhuang

Hausa Ocitan (post 1500); Provençal

Zulu

Hebrew OriyaHerero Oromo

Page 54: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

V. Modifiersdc_contributor_mod dc_coverage_spatial_modactor administrative areas fortifications karst areas advisor: committee member cadastral areas historical sites ledges advisor: dissertation committee chair military areas archaeological sites massifs advisor: doctoral project committee chair political areas hydrographic structures mesas

advisor: thesis committee chair countries breakwaters mineral deposit areas

architect countries, 1st order divisions [use for states, provinces, etc.] canals moraines

arranger countries, 2nd order divisions [use for counties, etc.] dam sites mountains

artist countries, 3rd order divisions gaging stations continental divides author countries, 4th order divisions harbors mountain ranges broadcaster multinational entities marinas mountain summits builder populated places levees ridges captain cities offshore platforms drumlins cartographer capitals piers natural rock formations choir postal areas reservoirs arches (natural formation) choreographer school districts waterworks plains compiler statistical areas launch facilities plateaus composer census areas mine sites playas conductor Metropolitan Statistical Areas monuments reefs curator territorial waters oil fields coral reefs dancer tribal areas parks seafloor features designer hydrographic features viewing locations abyssal features director aquifers recreational facilities continental margins distributor bays amusement parks fracture zones editor fjords camps hydrothermal vents engineer channels performance sites ocean trenches engraver drainage basins sports facilities seamounts former owner estuaries reference locations submarine canyons gift floodplains research areas tectonic features gospel preacher gulfs ecological research sites earthquake features illustrator guts paleontological sites faults interviewee ice masses reserves fault zones interviewer glacier features storage structures rift zones inventor lakes telecommunication features folds (geologic) landscape architect seas towers anticlines legacy oceans transportation features synclines librettist ocean currents airport features valleys lyricist ocean regions heliports canyons manager streams seaplane bases volcanic features mounter of exhibit rivers aqueducts lava fields musician bends (river) bridges volcanoes narrator rapids cableways regionsnetwork waterfalls locks agricultural regions owner springs (hydrographic) parking sites biogeographic regions performer thermal features pipelines barren lands photo studio land parcels railroad features deserts photographer manmade features roadways forests printer agricultural sites trails petrified forests producer buildings tunnels rain forests promoter capitol buildings wells woods recipient commercial sites windmills grasslands reporter industrial sites physiographic features habitats school power generation sites alluvial fans jungles series author court houses arroyos oases series editor institutional sites badlands shrublands singer correctional facilities banks (hydrographic) snow regions singing group educational facilities bars (physiographic) tundras speaker medical facilities basins wetlands station religious facilities storage basins climatic regions translator library buildings beaches coastal zones videographer museum buildings bights economic regions

post office buildings capes land regions research facilities caves continents data collection facilities cirques islands residential sites cliffs archipelagos housing areas craters subcontinents mobile home parks deltas linguistic regions cemeteries dunes map regions disposal sites flats chart regions firebreaks gaps map quadrangle regions fisheries isthmuses UTM zones

Page 55: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

dc_coverage_temporal_mod dc_coverage_temporalera_mod dc_creator_mod dc_date_created_mod

after after actor acquired

before before advisor: committee member after

broadcast broadcast advisor: dissertation committee chair before

circa circaadvisor: doctoral project committee chair

broadcast

not after not after advisor: thesis committee chair circa

not before not before architect not afterarranger not beforeartistauthorauthor emailbroadcasterbuildercartographerchoirchoreographercompilercomposerconductorcuratordancerdesignerdirectordistributoreditorengineerengraverformer ownergiftgospel preacherillustratorintervieweeinterviewerinventorlandscape architectlegacylibrettistlyricistmanagermounter of exhibitmusiciannarratornetworkownerperformerphoto studiophotographerprinterproducerpromoterrecipientreporterseries authorseries editorsingersinging groupspeakerstationtranslatorvideographer

Page 56: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO
Page 57: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

dc_date_issued_mod dc_date_modified_mod dc_description_mod dc_format_modafter after abstract degreebefore before analysis document typebroadcast broadcast availability extentcirca circa biography issuenot after defended degree mediumnot before graduated monogram no of pagespublished not after no-asset no of volumes

not before portrait page noprogram scale

volume no

dc_publisher_mod dc_relation_hasformat_mod dc_relation_isformatof_mod dc_relation_ispartof_modactor extent extent albumarchitect issue issue bookarranger medium medium boxartist no of pages no of pages collectionauthor no of volumes no of volumes exhibitbroadcaster page no page no groupcartographer scale scale issuechoir volume no volume no journalchoreographer lantern slidescompiler loanscomposer miscellaneous collectionconductor negativescurator official collectiondancer official portrait seriesdesigner official seriesdirector other portrait seriesdistributor projecteditor provenanceengraver repositorygospel preacher serieshost slide seriesillustrator specimen printsintervieweeinterviewerinventorlibrettistlyricistmanagermounter of exhibitmusiciannarratornetworkperformerphotographerplaceprinterproducerpromoterreporterseries authorseries editorsingersinging groupspeakerstationtranslatorvideographer

Page 58: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

dc_relation_references dc_rights_mod dc_source_mod dc_subject_modalbum actor accession no corporate namearticle/chapter architect acquisition no file headingbiography arranger area-block-card no genrebook artist barcode keywordbook series author call no personal namecollection cartographer cliché no programconference name choreographer editionelectronic resource compiler file nameexhibit composer isla idjournal conductor issn/isbn/ismnjournal article curator issuemeeting dancer item nomonogram designer legacy idnewspaper director locationportrait distributor microfiche noproject editor neg noprovenance engraver old neg norepository illustrator old ref noseries interviewee original reference notimeline interviewer pages

inventor photo nolibrettist plate nolyricist print boxmounter of exhibit record idnarrator ref nonetwork same imageperformer series ref nophotographer sleeve noprinter unidentified noproducer volumereporterseries authorseries editorspeakerstationtranslatorvideographer

dc_title_mod dc_title_alt_mod geocoordinate_mod dc_title_modalbum article/chapter [an integer] albumarticle/chapter book article/chapterbook book series bookbook series electronic resources book serieselectronic resources illustration electronic resourcesillustration issue illustrationissue journal issuejournal journal article journaljournal article meeting journal articlelantern slides newspaper lantern slidesmeeting original caption meetingmiscellaneous collection parallel miscellaneous collectionnegatives poetry negativesnewspaper prose newspaperofficial collection romanization official collectionofficial portrait series series official portrait seriesofficial series short official seriesother portrait series translation other portrait seriespoetry uniform poetryprose vernacular proseromanization romanizationseries seriesslide series slide seriesspecimen prints specimen printstranslation translationuniform uniformvernacular vernacular

Page 59: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

VI. Node IDs

Node IDs apply only to the fields listed below. Node IDs are not required for any of these fields. Node IDs are not visible in Contributor. Their purpose is to create a specific reference to the Concept IDs used in the thesaurus editor (ConceptChoir Editor). Note that manual changes to concepts in the thesaurus do not currently cascade to those terms used in Contributor (and vice versa) nor are Node IDs updated in the metadata if a new term is typed over an existing term with a Node ID.

To edit any of these fields in collections which employ Node IDs, the metadata in the field must first be deleted using the minus button in Contributor to ensure that a pre-existing Node ID (not displayed) is removed before a new term is keyed into the field.

dc_contributordc_creatordc_formatdc_coverage_spatialdc_relation_isformatofdc_relation_hasformatdc_publisherdc_rightsdc_subject

Page 60: Contributor 2 Functional Requirements: Appendix B · Web viewFor instance, English = en_us. The codes are a combination of the ISO 639-2 codes for languages combined with the ISO

VII. Schemes

dc_contributor_sch dc_coverage_spatial_sch dc_creator_sch dc_publisher_schbmpixn adlg bmpixn bmpixnlacbdp bmpixg lacbdp lacbdpnaf lacbdg naf nafulan naf ulan ulan

tgn

dc_format_sch geocoordinate_schdc_identifier_bib_cite_sch

dc_relation_hasformat_sch

aacr2 line [free text] aacr2aat point aatimt polygon imtuscformat uscformat

dc_relation_isformatof_sch dc_rights_sch dc_subject_schaacr2 guid aataat lacbdp adlfimt naf bmpixsuscformat ulan lacbds

url lcshmeshnafulanunesco