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.
(2nd Draft July 28, 2015. Principal authors: Elizabeth Padilla, BCIT firstname.lastname@example.org 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.
Subject authorities used in Arca:
DESCRIPTION / ABSTRACT & NOTE
TYPE & GENRE
FORMAT and PHYSICAL DESCRIPTION
MODS - Element <titleInfo> + subelement <title> correspond to Dublin Core - Term dc:title
A word, phrase, character, or group of characters, normally appearing in a resource, that names it or the work contained in it.
<titleInfo> contains the following subelements:
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>.)
<subtitle>BCIT’s weekly news bulletin</subtitle>
<titleinfo type=“alternative” displayLabel="also known as:">
MODS - Element <subject> corresponds to Dublin Core - Term dc:subject
A term or phrase representing the primary topic(s) on which a work is focused.
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
In case of multiple topics in same object:
<topic >Identity (Philosophical concept) in literature.</topic>
<topic>Indian women in literature.</topic>
<topic>Indian women authors.</topic>
<topic>Indian women -- Legal status, laws, etc.</topic>
<topic>Indian women -- Civil rights.</topic>
In case of several elements relating to a single topic:
MODS Element <originInfo> with subelement <publisher> correspond to Dublin Core dc:publisher
The name of the entity that published, printed, distributed, released, issued, or produced the resource.
<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>.
<publisher>Library of Congress, Cataloging Distribution Service, in collaboration with Follett Software Company</publisher>
<publisher>Kinsey Printing Company</publisher>
<placeTerm type="code" authority="marccountry">onc</placeTerm>
<placeTerm type="text">Toronto, Ontario</placeTerm>
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
“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”
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.
Required in Arca.
Definition: The date the resource was published, released or issued.
<dateIssued encoding="w3cdtf" keyDate="yes" >1989-02-14</dateIssued>
Definition: the date on which the resource was digitized or a subsequent snapshot was taken.
Definition: A date in which the content of a resource is valid.
<dateValid encoding="iso8601" point="start">20011008</dateValid>
<dateValid encoding="iso8601" point="end">20011027</dateValid>
Definition: a date in which a resource is modified or changed.
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.
MODS -Element <abstract> correspond to Dublin Core - Term dcterms:abstract
A summary of the content of the resource
DLF recommends recording “a succinct summary of the content of the digital resource.”
Use <abstract> as the primary field for describing your object.
<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> 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.
<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
<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>
MODS elements <typeOfResource> & <genre> both correspond to Dublin Core term dc:type
A term that specifies the characteristics and general type of content of the resource.
The following values may be used with <typeOfResource>:
three dimensional object
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>
Required in Arca.
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
Use any of the above, but note which is used in the “authority” attribute.
MODS <physicalDescription> corresponds to Dublin Core dc:format and MODS subelements <extent> & <form> correspond to dcterms:extent, dcterms:medium
<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.
<form authority="marcform">print </form>
<extent>ill., music ; 26 cm</extent>
<extent>1 sound disc (56 min.) : digital ; 3/4 in.</extent>
MODS element <accessCondition> corresponds to Dublin Core -Terms dcterms:accessRights, dc:rights, and dcterms:rightsHolder
Definition: information about restrictions imposed on access to a resource.
Also look at CDL copyright implementation http://www.cdlib.org/groups/rmg/
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,
<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.
MODS element <identifier> corresponds to Dublin Core - Term dc:identifier
Contains a unique standard number or code that distinctively identifies a resource. It includes manifestation, expression and work level identifiers.
<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:
<identifier type="music publisher">N.M. 275 Nova Music</identifier>
<identifier type="isbn" invalid="yes">0877780116</identifier>
<identifier type="uri" displayLabel="Electronic resource (JPEG)">http://susdl.fcla.edu/cgi-bin/cgiwrap/~fdl/fdlcgi?FA00000011%2F.jpg</identifier>
MODS element <location> corresponds to Dublin Core - Terms dc:source and dc:relation, dcterms:isPartOf
"location" identifies the institution or repository holding the resource, or a remote location in the form of a URL where it is available.
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.
<access> accepts values: preview, raw object, object in context
<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.
<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.”
<physicalLocation authority="marcorg">DLC MicRR Microfilm 82/528 MicRR
<url displayLabel="French version">http://www.cgiar.org/ifpri/reports/0297rpt/0297-ft.htm</url>
<physicalLocation>Library of Congress </physicalLocation>
<sublocation>Prints and Photographs Division Washington, D.C. 20540 USA</sublocation>
<shelfLocator>DAG no. 1410</shelfLocator>
The designation of physical parts of a resource in a detailed form.
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>
<subTitle>an Irish magazine of independent thought</subTitle>
<partNumber>Vol. 1, no. 4</partNumber>
MODS element <language> corresponds to Dublin Core Term: dc:language
a designation of the language in which the content of a resource is expressed.
<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.
<languageTerm type="code" authority="iso639-2b">fre</languageTerm>
<languageTerm type="code" authority="iso639-2b">ita</languageTerm>
<languageTerm type="code" authority="iso639-2b" >fre</languageTerm>
MODS element <physicalDescription> with subelement <extent> corresponds to Dublin Core Term: dc:extent
See also: Format | physicalDescription
"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.
The following subelements are defined for <physicalDescription>.
The use of your content standard of choice is strongly recommended if the subelement <extent> is used - DLF Guidelines
<extent>7" x 9"</extent>
<note displayLabel="Location within resource">Between entry for April 7 and April 19, 1843</note>
<extent>1 sound disc (56 min.) : digital ; 3/4 in.</extent>
MODS element <name> corresponds to Dublin Core Terms dc: creator and dc:contributor
The name of a person, organization, or event (conference, meeting, etc.) associated in some way with the resource.
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.
type - This attribute indicates the type of name. The following values may be used with it:
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.
<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:
<namePart>Brown, Bradford. F.</namePart>
<affiliation>Chemistry Dept., American University</affiliation>
<roleTerm type="text" authority=”marcrelator”>author</roleTerm>
<roleTerm type="code" authority=”marcrelator”>aut</roleTerm>
OR: Examples of Personal Name with separate fields for first and last:
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.
Information that identifies other resources related to the one being described.
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:
<title>The dancer's guide and ball-room companion</title>
<relatedItem type="host" displayLabel="Parent">
<title>American ballroom companion [computer file] :</title>
<subTitle>dance instruction manuals, ca. 1600-1920 /</subTitle>
<title>Modern maturity (NRTA edition)</title>
<identifier type="lccn">sn 84010086</identifier>
MODS element <abstract> corresponds to Dublin Core Term dc:abstract
a summary of the content of the resource.
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.
<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 --