Arca Metadata Guidelines For MODS Usage
in ARCA / Islandora Implementation

This is a working document. MODS elements are given with examples of usage (with corresponding dublin core terms) and recommendations (ACTION ITEMS) for consortial use of standards for any taxonomies.

We refer heavily to the MODS schema on the LoC website: http://www.loc.gov/standards/mods/  as well as to the DLF Aquifer Implementation Guidelines for Shareable MODS Records.  DFL recommended Required elements are listed.

In general, objects in Arca should adhere to the standards outlined by the Library of Congress. Their guidelines are found here: https://www.loc.gov/standards/mods/userguide/generalapp.html 

This document will attempt to provide more precise guidance when the above is unclear.

 

https://wiki.dlib.indiana.edu/download/attachments/24288/DLFMODS_ImplementationGuidelines.pdf

(2nd Draft  July 28, 2015. Principal authors: Elizabeth Padilla, BCIT epadilla@bcit.ca  and Adena Brons, MLIS/MAS student, UBC iSchool. This is a working draft document based first on fields used in BCIT’s current dublin core standard digital collections. Please contact Epadilla@bcit.ca for any edits or suggestions to this document.


TITLE

SUBJECT

Subject authorities used in Arca:

PUBLISHER

DATES

Format:

<originInfo>  <dateIssued>

<originInfo> <dateCaptured>

<originInfo> <dateValid>

<originInfo> <dateModified>

DESCRIPTION / ABSTRACT & NOTE

<abstract>

<note>

TYPE & GENRE

<typeOfResource>

<genre>

FORMAT and PHYSICAL DESCRIPTION


TITLE

 

MODS - Element <titleInfo> + subelement <title> correspond to Dublin Core - Term dc:title

 

 <titleInfo>

A word, phrase, character, or group of characters, normally appearing in a resource, that names it or the work contained in it.

 

http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#title

 

Usage:

<titleInfo> contains the following subelements:

<title>

<subTitle>

<partNumber>

<partName>

<nonSort>

 

Required: The DLF guidelines require the use of at least one <titleinfo> <title> element.

 

“When no title appears on the item being described, a title should be supplied. The guidelines recommend against the use of brackets or other punctuation to indicate the title has been supplied rather than appearing on the item; the displayLabel attribute, however, may be used to indicate that the title is supplied.” –DLF Guidelines

 

Dates may be recorded here only if considered part of the title (e.g., a date in a uniform title). (Publication dates are included under <originInfo>.)

 

Examples

<titleinfo>

                <title>BCIT Update</title>

                <subtitle>BCIT’s weekly news bulletin</subtitle>

</titleinfo>

 

 <titleinfo type=“alternative” displayLabel="also known as:">

                <title>The Update</title>

</titleinfo>

SUBJECT

 

MODS - Element <subject> corresponds to Dublin Core - Term dc:subject

 

<subject>

A term or phrase representing the primary topic(s) on which a work is focused.

 

http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#subject

 

Usage

Subelements:

<topic>

<geographic>

<temporal>

<titleInfo>

<name>

<genre>

<hierarchicalGeographic>

<cartographics>

<geographicCode>

<occupation>

 

Required: DLF Guidelines require use of at least one <subject> element in a record. For objects with multiple distinct subjects, these should be placed into separate <subject> fields.

 

“Information in <subject> describes subject content represented in or by the work, and typically answers

such questions as who, what, where, and when.” -DLF Guidelines 

“Subelements within <subject> are used to differentiate subject content. While MODS does allow for placing multiple values in a single <subject><topic> string, parsing subject terms into separate subelements is the preferred practice and highly recommended in the DLF/Aquifer guidelines. Place distinct, multiple subjects in separate <subject> fields.”

 

“Use of the authority attribute is recommended if applicable to record the name of the authoritative list for a controlled value. Specify authority at the <subject> level in most cases (exceptions are <subject><name>, <subject><titleInfo>, and <subject><geographicCode>). If providing subjects from different authorities, use a separate <subject> element for each. This is required even when subjects differ only at the subelement level.

 

Locally developed terms should be listed separately, with "local" indicated as the source using the authority attribute at the <subject> level.” -DLF Guidelines           

 

 

Examples

 

In case of multiple topics in same object:

<subject authority="lcsh">

<topic >Identity (Philosophical concept) in literature.</topic>

</subject>

<subject authority="lcsh">

<topic>Indian women in literature.</topic>

</subject>

<subject authority="lcsh">

<topic>Indian women authors.</topic>

</subject>

<subject authority="lcsh">

<topic>Indian women -- Legal status, laws, etc.</topic>

</subject>

<subject authority="lcsh">

<topic>Indian women -- Civil rights.</topic>

</subject>

In case of several elements relating to a single topic:

<subject authority="lcsh">

<topic>Real property</topic>

<geographic>Mississippi</geographic>

<geographic>Tippah County</geographic>

<genre>Maps</genre>

</subject>

 

<subject>

<temporal encoding="w3cdtf">1975-05-15</temporal>

</subject>

Subject authorities used in Arca:


PUBLISHER

 

MODS Element <originInfo> with subelement <publisher> correspond to Dublin Core dc:publisher

 

<originInfo> <publisher>

The name of the entity that published, printed, distributed, released, issued, or produced the resource.

 

http://www.loc.gov/standards/mods/mods-outline-3-5.html#originInfo

 

Usage

 

<publisher> information is recommended but not required by DLF Guidelines.

Information about an institution responsible for digitizing and delivering online a previously published resource should be included in <note>, rather than <originInfo><publisher>.

 

Examples

 

<originInfo>             

<publisher>Library of Congress, Cataloging Distribution Service, in collaboration with Follett Software Company</publisher>

</originInfo>

 

<originInfo>

<publisher>Kinsey Printing Company</publisher>

</originInfo>

 

<originInfo>

<place>

<placeTerm type="code" authority="marccountry">onc</placeTerm>

<placeTerm type="text">Toronto, Ontario</placeTerm>

</place>

<publisher>Random House</publisher>

</originInfo>

 


DATES

 

MODS – Element <originInfo> & subelements <dateIssued>, <dateCreated>, <dateCaptured>, <dateValid> ,<dateModified> , <copyrightDate>, <dateOther> correspond to Dublin Core -Terms dc:date, dcterms:created dcterms:issued, dcterms:available, dcterms:modified, dcterms:valid, dcterms:dateAccepted, dateSubmitted, dcterms:dateCopyrighted

Primary MODS subelement: <dateIssued>

<originInfo> & date subelements

 

http://www.loc.gov/standards/mods/mods-outline-3-5.html#originInfo

 

Usage

 

“Every MODS record containing at least one date should have one and only one date element with the attribute keyDate="yes". The key date will be used by aggregators for date indexing, sorting, and display. The date marked as the key date should be the date considered by the metadata provider as the most important for end user access” –DLF Guidelines

 

“The following date elements are not recommended for use. In some cases they may be considered technical metadata, and would not generally be used by aggregators to provide access to a resource:

<dateIssued> - date on which the resource was published, released or issued.

<dateCaptured> - date on which the resource was digitized or a subsequent snapshot was taken

<dateValid> - date in which the content of a resource is valid

<dateModified>- date in which a resource is modified or changed”

–DLF Guidelines

 

However, given that the institutional repositories will often be dealing with materials that have been digitized and uploaded at some remove from their original creation, we suggest that <dateCaptured> at least, is worth using.

Usage of dateCreated vs dateIssued

dateIssued - The date the resource was published, released or issued.

dateCreated - The date of creation of the resource. If creation date is also the origination date, use the <dateIssued> element or repeat both <dateCreated> and <dateIssued>.

All objects require a dateIssued.

 

Format:

<originInfo>  <dateIssued>

 

Required in Arca.

Definition: The date the resource was published, released or issued.

 

Example

<originInfo>

                <dateIssued encoding="w3cdtf" keyDate="yes" >1989-02-14</dateIssued>

        <frequency authority="marcfrequency">Annual</frequency>

</originInfo>

 

 

<originInfo> <dateCaptured>

 

Definition: the date on which the resource was digitized or a subsequent snapshot was taken.

 

Example

<originInfo>

                <dateCaptured encoding="w3cdtf">2014-03-04</dateCaptured>

</originInfo>

 

<originInfo> <dateValid>

 

Definition: A date in which the content of a resource is valid.

 

Example

<originInfo eventType="production">

<dateValid encoding="iso8601" point="start">20011008</dateValid>

<dateValid encoding="iso8601" point="end">20011027</dateValid>

</originInfo>

 

 

<originInfo> <dateModified>

 

Definition: a date in which a resource is modified or changed.

 

Examples

 

<originInfo eventType="manufacture">

<dateModified encoding="iso8601">20031008</dateModified>

</originInfo>

 

 


DESCRIPTION / ABSTRACT & NOTE

 

MODS – Element: multiple possibilities. See below. Each maps to the dc:description element.  

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

 

<abstract>

MODS -Element <abstract> correspond to Dublin Core - Term dcterms:abstract

A summary of the content of the resource

http://www.loc.gov/standards/mods/mods-outline-3-5.html#abstract

Usage

 

DLF recommends recording “a succinct summary of the content of the digital resource.”

Use <abstract> as the primary field for describing your object.

 

Examples

 

<abstract xlink:href= "http://www.ojp.usdoj.gov/bjs/abstract/cchrie98.htm"/>

 

<abstract> Cantaloupe melon was the source of a lethal outbreak of Listeria in 2011. This research investigated whether washing a contaminated cantaloupe rind was sufficient in preventing the transferring of Escherichia coli. Hence, the null hypothesis for this study was that there is no association between washing a contaminated cantaloupe melon and the presence of the contamination in the flesh. In this study, 10 cantaloupes were used to produce a sample size of 20 per washed and unwashed treatments. Each of the samples was transferred to EC broth to determine the presence and absence of Escherichia coli (E. coli), the indicator organism that acted as the “outbreak contaminant.” The results showed 100% of the unwashed melons and 80% of the washed melons to have E. coli transferred into the flesh. A Chi Square analysis produced a p-value of 0.035. The study determined that there was a statistically significant association between washing a melon and the presence of E. coli in the melon flesh. The author recommends washing melon rind as a means to prevent foodborne illness caused by surface contaminants. </abstract>

 

<note>

<note> maps to dc:description. Use sparingly.

General textual information relating to a resource. Used also in Arca as a catchall for uncontrolled information such as author keywords.

 

http://www.loc.gov/standards/mods/mods-outline-3-5.html#note

 

Usage

<note> should be used only for information that cannot be encoded in another, more specific MODS element.

 

The DLF guidelines, on page 50-1, provide a table mapping MARC 5XX fields. It provides information on how to map information such as alternative formats available and target audience, as well as others.

 

The MODS user guide also has a list of <note> implementations, created by MODS users. http://www.loc.gov/standards/mods/mods-notes.html

 

Examples

 

<note type="statement of responsibility">written by Burt Kimmelman</note>

 

<note>Based on a play which originally appeared in France as "Un peu plus tard, un peu plus tôt"</note> 

                


TYPE & GENRE

 

MODS elements <typeOfResource> & <genre> both correspond to Dublin Core term dc:type

 

 <typeOfResource>

A term that specifies the characteristics and general type of content of the resource.

 http://www.loc.gov/standards/mods/mods-outline-3-5.html#typeOfResource

 

Usage:

The following values may be used with <typeOfResource>:

text

cartographic

notated music

sound recording-musical

sound recording-nonmusical

sound recording

still image

moving image

three dimensional object

software, multimedia

mixed material

 

 

<genre>

A genre term(s) designates a category characterizing a particular style, form, or content, such as artistic, musical, literary composition, etc. <genre> provides terms that give more specificity than the fixed type terms used in <typeOfResource> 

http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#genre

Required in Arca.

Usage:

Genre terms may be from a controlled list with a designation of the authoritative list used in the authority attribute, or it may be an uncontrolled term.

It is recommended to use a term from a controlled list, or recommend an additional term for the list.

Where more specification is needed, such as “booklet” or “newsletter,” the MODS  <genre>  Element should also be used

                

 

Examples

 

<typeOfResource>moving image</typeOfResource>

<genre>motion picture</genre>

 

<typeOfResource>text </typeOfResource>

<genre authority="marcgt">newspaper</genre>

 

Suggested authorities:

Use any of the above, but note which is used in the “authority” attribute.

 

 

 

 


FORMAT and PHYSICAL DESCRIPTION

MODS <physicalDescription> corresponds to Dublin Core dc:format and MODS subelements <extent> & <form> correspond to dcterms:extent, dcterms:medium

 

<physicalDescription>

https://www.loc.gov/standards/mods/userguide/physicaldescription.html 

 

Usage

Subelements:

<form>  - specifies physical form or medium of the item.

Use controlled vocabulary where possible, and document the source using the “authority” attribute.

Possible sources:  https://www.loc.gov/standards/sourcelist/genre-form.html               

<reformattingQuality> - a term that indicates an overall assessment of the physical quality of an electronic resource in relation to its intended use.

        The following values may be used with <reformattingQuality>: access, preservation, replacement

<internetMediaType>  - an identification of the electronic format type, or the data representation of the resource.                     

<extent> - a statement of the number and specific material of the units of the resource that express physical extent.

<digitalOrigin>- a designation of the source of a digital file important to its creation, use and management.

The following values may be used with <digitalOrigin>:  born digital, reformatted digital, digitized microfilm, digitized other analog                    

<note> - general textual information about the physical description of a resource.

Required: DLF requires at least one use of the element <physicalDescription>, one subelement <digitalOrigin> and at least one subelement <internetMediaType>

For the subelement <form>, it is recommended to refer to an authority list. LoC maintains a source list: http://www.loc.gov/standards/sourcelist/ with the Format Source Code list here: http://www.loc.gov/standards/sourcelist/format.html 

For the subelement <internetMediaType>, use the following list of possible entries (under the Template column): http://www.iana.org/assignments/media-types/media-types.xhtml 

For the subelement <extent>, follow the format used in the MARC 300 field.

Examples:

<physicalDescription>   

<form authority="marcform">electronic</form> 

         <digitalOrigin>born digital</digitalOrigin>   

<reformattingQuality>access</reformattingQuality>   

<internetMediaType>text/html</internetMediaType> 

</physicalDescription>

 

 <physicalDescription>   

<form authority="marcform">print </form>   

<extent>ill., music ; 26 cm</extent> 

<reformattingQuality>replacement</reformattingQuality> 

</physicalDescription>

 

<physicalDescription>   

<extent>1 sound disc (56 min.) : digital ; 3/4 in.</extent> 

</physicalDescription>


ACCESS/USAGE RIGHTS & CONDITIONS

MODS element <accessCondition> corresponds to Dublin Core -Terms dcterms:accessRights, dc:rights, and dcterms:rightsHolder

<accessCondition>

Definition: information about restrictions imposed on access to a resource.

https://www.loc.gov/standards/mods/userguide/accesscondition.html

Also look at CDL copyright implementation http://www.cdlib.org/groups/rmg/

Usage

DLF recommends the use of at least one <accessCondition> element with the type attribute containing the value useAndReproduction in every record.

The suggested values for the attribute type are: use and reproduction and restriction on access,

Examples

<accessCondition type="restriction on access">Restricted: cannot be viewed until 2010; Members of donor's family</accessCondition>

<accessCondition type="use and reproduction" displayLabel="Restricted">Copying allowed only for non- profit organizations</accessCondition>

Arca’s future goals include a standardized statement for the accessCondition field. The nature of this statement - whether CC license or something else - remains to be determined.


IDENTIFIER

MODS element <identifier> corresponds to Dublin Core - Term dc:identifier

<identifier>

Contains a unique standard number or code that distinctively identifies a resource. It includes manifestation, expression and work level identifiers.       

https://www.loc.gov/standards/mods/userguide/identifier.html 

Usage

        <identifer> has no subelements but the attribute type is required.

The guidelines recommend that <identifier> be used to encode any identifying character string uniquely associated with a resource, but reserves <location><url> for encoding the URL to the resource in its repository context. Persistent URIs that serve both as a unique identifier and a URL to the resource in its repository context should be encoded using both elements

Suggested values for type are:

Examples

<identifier type="music publisher">N.M. 275 Nova Music</identifier>

<identifier type="isbn" invalid="yes">0877780116</identifier>

<identifier type="lccn">##2001336783</identifier>

<identifier type="uri" displayLabel="Electronic resource (JPEG)">http://susdl.fcla.edu/cgi-bin/cgiwrap/~fdl/fdlcgi?FA00000011%2F.jpg</identifier>

<identifier type="doi">doi:10.1006/jmbi.1995.0238</identifier>

<identifier type="uri">http://hdl.loc.gov/loc.law/llst.072</identifier>


SOURCE / PART OF / LOCATION / PART

MODS element <location> corresponds to Dublin Core - Terms dc:source and dc:relation, dcterms:isPartOf

<location>

"location" identifies the institution or repository holding the resource, or a remote location in the form of a URL where it is available.

http://www.loc.gov/standards/mods/mods-outline-3-5.html#location

Usage

The following subelements are defined for <location>. Attributes are indented and italicized.

               <physicalLocation> - the institution or repository that holds the resource or where it is available.

               <shelfLocator> - Shelfmark or other shelving designation that indicates the location identifier for a copy.

               <url> - the Uniform Resource Location of the resource.

                <displayLabel>

                <dateLastAccessed>

                <note>

                <access> accepts values: preview, raw object, object in context

                <usage>

<holdingSimple> - General information about what the institution identified in physicalLocation holds of the resource and its specific location.

<copyInformation> - Information about a specific tangible instance of a bibliographic resource or set which comprises one or more pieces via indication of sublocation and/or locator.

                                               <form>

                                               <sublocation>

                                               <shelfLocator>

                                               <electronicLocator>

                                               <note>

                                               <enumerationAndChronology>

               <holdingExternal> - Holdings information that uses a schema defined externally to MODS.

DLF requires use of one <location> element with at least the subelement <url>. One instance of <location><url> must include the attribute <usage> with the value “primary display.”

Examples

<location>   

<physicalLocation authority="marcorg">DLC MicRR Microfilm 82/528 MicRR

</physicalLocation>

</location>

<location>  

<url displayLabel="French version">http://www.cgiar.org/ifpri/reports/0297rpt/0297-ft.htm</url>

</location>

<location>

<physicalLocation>Library of Congress </physicalLocation>  

<sublocation>Prints and Photographs Division Washington, D.C. 20540 USA</sublocation>  

<shelfLocator>DAG no. 1410</shelfLocator>

</location>

<part>

The designation of physical parts of a resource in a detailed form.

http://www.loc.gov/standards/mods/mods-outline-3-5.html#part

Usage

The following subelements are defined for <part>.

<detail> - contains numbering and type of designation of the part in relation to the host/parent item in which a host item resides

<extent> - contains the measured units making up the part, such as pages, minutes, etc.

<date> - contains date information relevant to the part described.

<text> - contains unparsed information in textual form about the part

Use <part> when the MODS record in question refers to either a physical or structural part of a resource, rather than an intellectual part (which should be recorded in various subelements under <title>). A newspaper issue would generally be indicated with <part>, rather than indicating the issue number as part of the title in MODS. The <part> element at the top level would also be used to describe one reel of microfilm in a set, or in any other case in which the part being described is not an intellectual whole by itself. When in doubt, and only part numbers or names are needed, use <titleInfo>

<title><partNumber> and/or <titleInfo><title><partName>

Examples

<titleInfo>   

<title>Dana</title> 

<subTitle>an Irish magazine of independent thought</subTitle>   

<partNumber>Vol. 1, no. 4</partNumber>

</titleInfo>

<part>   

<detail>   

<title>Wayfarers (Poem)</title>   

</detail>   

<extent unit="pages">     

<start>97</start>   

<end>98</end> 

</extent>

</part>


LANGUAGE

MODS element <language> corresponds to Dublin Core Term: dc:language

<language>

a designation of the language in which the content of a resource is expressed.

https://www.loc.gov/standards/mods/userguide/language.html 

Usage        

Subelements:  

<languageTerm> contains the language(s) of the content of the resource. It may be expressed in textual or coded form. If in coded form, the source of the code is contained in the value of the authority attribute. If no authority is given, it is assumed that the content is textual. (Alternatively, instead of using a textual form, the content may be in coded form with an authority attribute, and an XSLT stylesheet may be used to translate the code into a textual form.) If there is more than one representation of the same language, e.g. using different forms of the same language (code or text) or from different authorities, <languageTerm> is repeated within the <language> container. If the content of the resource is in more than one language, <language> is repeated.

This element is required in all resources in which language is primary to understanding the resource.

Examples

<language>   

<languageTerm type="code" authority="iso639-2b">fre</languageTerm>

</language>

<language objectPart="summary">   

<languageTerm type="code" authority="iso639-2b">ita</languageTerm>   

<languageTerm type="code" authority="iso639-2b" >fre</languageTerm>

</language>

EXTENT | PHYSICAL DESCRIPTION

MODS element <physicalDescription> with subelement <extent> corresponds to Dublin Core Term: dc:extent

See also: Format | physicalDescription

<physicalDescription> <extent>

"physicalDescription" is a wrapper element that contains all subelements relating to physical description information of the resource described. Data is input only within each subelement. “Extent” a statement of the number and specific material of the units of the resource that express physical extent.

http://www.loc.gov/standards/mods/mods-outline-3-5.html#physicalDescription

Usage

The following subelements are defined for <physicalDescription>.

<form>

<reformattingQuality>

<internetMediaType>

<extent>

<digitalOrigin>

<note>

The use of your content standard of choice is strongly recommended if the subelement <extent> is used - DLF Guidelines

Examples

<physicalDescription>   

<extent>7" x 9"</extent>   

<note displayLabel="Location within resource">Between entry for April 7 and April 19, 1843</note>

</physicalDescription>

<physicalDescription>   

<extent>1 sound disc (56 min.) : digital ; 3/4 in.</extent>

</physicalDescription>

NAME / CREATOR / CONTRIBUTOR

MODS element <name> corresponds to Dublin Core Terms dc: creator and dc:contributor

<Name>

The name of a person, organization, or event (conference, meeting, etc.) associated in some way with the resource.

http://www.loc.gov/standards/mods/mods-outline-3-5.html#name

Usage

Application: "name" is a wrapper element that contains all subelements related to name information. It is equivalent to the MARC 21 1XX and 7XX fields or Creator and Contributor in Dublin Core. If it is desired to indicate the concept of main entry, the <role> subelement may be used with the value "creator" (e.g. <role><roleTerm type="text">creator</roleTerm></role>. Other role values may be used to indicate the particular relationship between the name and the resource. The type of name (personal, corporate, conference) may be indicated, although this is not required.

Attributes

        type - This attribute indicates the type of name. The following values may be used with it:

           personal

           corporate

           conference

authority - The name of the authoritative list for a controlled value is recorded here. An authority attribute may be used to indicate that a name is controlled by a record in an authority file (e.g., authority="naf"). A list of authorities is maintained at: www.loc.gov/marc/sourcecode/authorityfile/authorityfilesource.html.

Subelements:

<namePart> - Required -"namePart" includes each part of the name that is parsed. Parsing is used to indicate a date associated with the name, to parse the parts of a corporate name or to parse parts of a personal name if desired (into family and given name). Names are expected to be in a structured form (e.g. surname, forename).

<displayForm> - used to indicate the unstructured form of the name. It includes a name as given on the resource.

<affiliation> - contains the name of an organization, institution, etc. with which the entity recorded in <name> was associated at the time that the resource was created. It may also contain other elements that are part of the affiliation, such as email address, street address, job title, etc.

<role> - A term(s) that designates the relationship (role) of the entity recorded in name in relation to the resource.

<description> - may be used to give a textual description for a name when necessary, for example, to distinguish from other names.

The DLF Guidelines require at least one <name> element to describe the creator of the intellectual content of the resource, if available. Include as many <name> elements for contributors as are readily available.

In addition to describing creators, <name> is used as a subelement of <subject>

ACTION ITEM: Should Personal Names in namePart be a string containing the whole name, or should we break it down by name type: “given’ ‘family’?

ACTION ITEM: roleTerm authority=marcrelator uses a controlled term list:     http://www.loc.gov/marc/relators/relaterm.html

Examples of Personal Name as one string:

  <name type="personal">

<namePart type="termsOfAddress">Dr.</namePart>   

<namePart>Brown, Bradford. F.</namePart>   

<affiliation>Chemistry Dept., American University</affiliation> 

<role>     

<roleTerm type="text">creator</roleTerm>     

<roleTerm type="code">cre</roleTerm>   

</role>

<role>     

<roleTerm type="text" authority=”marcrelator”>author</roleTerm>     

<roleTerm type="code" authority=”marcrelator”>aut</roleTerm>   

</role>

</name>

OR: Examples of Personal Name with separate fields for first and last:

<name type="personal">  

<namePart type=”given”>David</namePart>  

<namePart type=”family”>Pepper</namePart>  

<displayForm>David Pepper</displayForm>  

<role>    

<roleTerm type="text">director</roleTerm>    

<roleTerm type="code">dir</roleTerm>  

</role>

</name>

PROVENANCE / RELATED ITEM

There is not simple mapping from the Dublin Core Term dc:provenance to MODS. Dublin Core states “A statement of any changes in ownership and custody of the resource since its creation that are significant for its authenticity, integrity, and interpretation.” Depending on interpretation this could refer to the MODS elements <location>, <originInfo>, or <relatedItem>. Reformatting information could correspond to the MODS element <physicalDescription> with the various subelements. I include information on the MODS element <relatedItem> below as the other elements have been discussed elsewhere in this guide.

<relatedItem>

Information that identifies other resources related to the one being described.

http://www.loc.gov/standards/mods/v3/mods-userguide-elements.html#relateditem

Usage

Notable Attributes

Type The value of the type attribute describes the relationship between the <relatedItem> and the resource being described in the MODS record. This attribute may contain the following values: preceding, succeeding, original, host, constituent, series, otherVersion, otherFormat, isReferencedBy.

Recommended in the following situations:

  1. to point to a full metadata record for a related item
  2. to provide contextual information useful for full description of the resource.
  3. to provide additional information about intellectual constituent units of the resource being described

Examples

<titleInfo>  

<title>The dancer's guide and ball-room companion</title>

</titleInfo>

<relatedItem type="host" displayLabel="Parent"> 

<titleInfo>     

<nonSort>The</nonSort>     

<title>American ballroom companion [computer file] :</title>     

<subTitle>dance instruction manuals, ca. 1600-1920 /</subTitle>   

</titleInfo>   

<identifier type="lccn">98801326</identifier>   

<identifier type="uri">http://memory.loc.gov/ammem/dihtml/dihome.html</identifier>

</relatedItem>

<relatedItem type="otherVersion">   

<titleInfo type="uniform">     

<title>Modern maturity (NRTA edition)</title>   

</titleInfo>   

<identifier type="lccn">sn 84010086</identifier>

</relatedItem>

ABSTRACT

MODS element <abstract> corresponds to Dublin Core Term dc:abstract

<abstract>

a summary of the content of the resource.

http://www.loc.gov/standards/mods/mods-outline-3-5.html#abstract

Usage

When creating a MODS record for a digital surrogate, record a summary of the content of the original resource. If only a portion of the resource was digitized, summarize only that portion.

Examples

<abstract xlink:href= "http://www.ojp.usdoj.gov/bjs/abstract/cchrie98.htm"/>

<abstract>Describes the results of an ongoing evaluation of State activity relating to improvement of criminal records. Activities reviewed include upgrading of accuracy and completeness of records, automation, implementation of positive identification procedures and procedures for responding to firearm background check inquiries. The report describes the nature of activities initiated, time until completion, and impact on availability of records. Characteristics of individual states are represented in some areas. The document was prepared by Queues Enforth Development under BJS award 95-RU-RX-K002. 2/00 NCJ 179768</abstract>

No MODS recommendations made due to mixed and often improper use of field.

 

 

 --  Working Document --