Skip to end of metadata
Go to start of metadata

DLF Aquifer Guidelines for Shareable MODS Records: EAD to Aquifer MODS Crosswalk

Introduction

This crosswalk is intended to help institutions wishing to make metadata records for finding aids and other guides to archival collection materials, encoded using the Encoded Archival Description (EAD) data structure, shareable in the context of the DLF Aquifer project and other metadata aggregation initiatives expressly harvesting MODS records. The crosswalk can be applied to EAD records either by the data provider prior to making records harvestable, or by the data aggregator as part of processing harvested EAD records. In either case, use of this crosswalk ensures consistent transformation of EAD encoding into the MODS format.

The crosswalk is based on the assumption that, in terms of harvesting records for EAD instances using the Open Archives Initiative Protocol for Metadata Harvesting (OAI PMH), the utilization of collection-level metadata to create harvestable records serves to make EAD instances compatible in metadata aggregations with other types of digital objects available for OAI harvest. In this way, harvestable records for archival finding aids and other collection guides, whether available in EAD or MODS, serve as an informative surrogate that can be indexed in the context of other harvested records. A standardized pointer (in MODS a <location><url> element) is used to take end users of the data in the aggregator service back to the full, multi-level finding aid on the home repository's finding aids site. Additional pointers can be provided to give aggregators access to the full EAD file for a guide if that is desired.

As a result of this assumption, this crosswalk explicitly uses only EAD elements encoded at the highest levels (those encoded within <archdesc> and not those encoded within <dsc>). Information from lower levels in a multi-level archival description should not generally be included in a shareable metadata record intended for OAI harvesting. The order of the EAD elements in the following crosswalk follows the order in which MODS elements are encoded.

The use of an archival data content standard such as Describing Archives: A Content Standard (DACS) is strongly encouraged for all elements when applicable. This crosswalk draws heavily on the EAD and MARC mappings from DACS contained in Appendix C5 (pages 220-221) of DACS.

Crosswalk

EAD element

DACS chapter(s) recommended for element content

MODS element

Status of MODS element in DLF Aquifer guidelines

Notes

<did><unittitle>

2.3

<titleInfo><title>

Required/ Repeatable

1) Recommended attributes are generally unnecessary for supplied archival titles.

<did><origination> with any of the following subelements: <corpname>, <famname>, <persname>

2.6 and 9

<name><namePart>

Recommended if applicable/ Repeatable

1) MODS <name> @type attribute should be able to be derived based on usage in EAD of <persname> or <famname> subelements (type="personal"), or <corpname> subelement (type="corporate").
2) The value of the MODS <name> @authority attribute is the equivalent of the value of EAD <...name> @source attribute.

No corresponding EAD element

No content guidance in DACS

<typeOfResource>

Required/ Repeatable

1) Since the resource being harvested is the actual finding aid or collection guide, and not, directly, collection materials themselves, the value of "text" can be supplied for this element in all instances.
2) MODS <typeOfResource> @collection attribute value of "yes" should be included in all instances, i.e., <typeOfResource collection="yes">text</typeOfResource>.

<controlaccess><genreform>

Content relevant to this element should be derived from DACS 3.1 Scope and Content Element. See also information about access points in archival description on pages xviii-xxi.

<genre>

Recommended/ Repeatable

1) MODS <genre> @authority attribute is the equivalent of the value of EAD <genreform> @source attribute.

<did><unitdate>

2.4

<originInfo><dateCreated>

Required/ Repeatable

1) MODS @keyDate attribute with a value of "yes" (i.e., <dateCreated keyDate="yes">) can be added to any date mapped from EAD <unitdate> with no @type attribute, or with an @type attribute value of "inclusive."
2) EAD <unitdate> elements with an @type attribute of "bulk" should not be designated as a MODS @keyDate, unless no other <unitdate> exists in the collection-level description in an EAD file.
3) The <place> and <placeTerm> subelements required by the DLF Aquifer guidelines will not generally apply to descriptions of archival collections, since they are not typically published resources.

<did><langmaterial><language>

4.5

<language><langTerm>

Required if language is primary to the resource/ Repeatable

1) If an EAD file contains at the collection level only a <langmaterial> element, with no <language> subelement encoding, map the entire statement to MODS <langTerm>; in this case it will be impossible to derive a value for MODS <langTerm> @authority or @type attribute values from the EAD encoding.
2) If EAD <language> subelements are encoded, only the values encoded therein (and not additional text from the surrounding <langmaterial> element) should be mapped to MODS <langTerm>.
3) If EAD <language> has no @langcode attribute value encoded, the mapped MODS <langTerm> element should have an @type value of "text" (i.e., <langTerm type="text">).
4) If EAD <language> has a @langcode attribute value encoded, that attribute value can be mapped as a separate MODS <langTerm type="code"> element, in addition to the <langTerm type="text"> element.
5) If a @langcode attribute is used in an EAD <language> element, an @authority with the value "iso639-2b" can be added to the MODS <langTerm type="code"> to which it is mapped (i.e., <langTerm type="code" authority="iso639-2b">.

No corresponding EAD element

No content guidance in DACS

<physicalDescription> <digitalOrigin>
and
<physicalDescription> <internetMediaType>

Required/ Not repeatable

1) The value for the MODS <physicalDescription> subelement <digitalOrigin> for EAD-encoded finding aids should be "born digital" if a finding aid was originally created natively in EAD or derived from a database, and "reformatted digital" if it was retrospectively converted to EAD from a Word processed file or a paper original (i.e., <digitalOrigin>born digital</digitalOrigin> or <digitalOrigin>reformatted digital</digitalOrigin>).
2) The value for the MODS <physicalDescription> subelement <internetMediaType> should always be "text/xml" (i.e., <internetMediaType>text/xml</internetMediaType>.

<physdesc><extent> or <physdesc> with no subelements

2.5

<physicalDescription> <extent>

Recommended if applicable/ Repeatable

1) Since physical extent or size of an archival collection is an important comparative piece of information for researchers, this crosswalk recommends that a MODS <physicalDescription><extent> element be provided in all shareable metadata records for archival collections.

<abstract> or <scopecontent>

3.1

<abstract>

Recommended/ Repeatable

1) Prefer EAD's <abstract> element to the full, sometimes multi-paragraph <scopecontent> whenever possible in a shareable metadata record.
2) If no EAD <abstract> element is available, consider mapping only the first <p> within <scopecontent> to MODS <abstract> in the interest of keeping the information about the collection succinct for use and display by aggregators. This recommendation is based on the fact that shareable metadata records always provide a user with a link back to the full finding aid on the repository's web site, where all information from the <scopecontent> element is available.

<arrangement>

3.2

<tableOfContents>

Recommended if applicable/ Repeatable

1) Although not the equivalent of a Table of Contents in published material, EAD's <arrangement> element, if available, provides important information to a user about how a large archival collection is structured. If it is mapped to MODS <tableOfContents> element, a prefatory statement should be included alerting the user of the shareable metadata record about how it differs from a Table of Contents, e.g., "This archival collection is arranged in four series: I. Correspondence, II. Financial files, III. Photographs, IV. Scrapbooks and memorabilia." Also, it is recommended that the following MODS @displayLabel attribute be supplied: "Arrangement of Collection", (i.e., <tableOfContents displayLabel="Arrangement of Collection">).

No corresponding EAD element

No content guidance in DACS

<targetAudience>

Recommended if applicable\ Repeatable

1) This crosswalk recommends that in shareable metadata records for EAD-encoded finding aids a succinct and clear statement be used to alert users to the nature of an archival finding, e.g., "Archival finding aids may not contain digital versions of collection materials and are frequently most useful to researchers who wish to contact or visit the repository holding the collection regarding use of collection materials."
2) If the majority of the content of a collection is available online through the finding aid, this crosswalk recommends that that be stated explicitly, e.g., "The archival finding aid provides full access to materials contained in the collection it describes."

<did><note> or <note> or <odd>

7

<note>

Recommended if applicable/ Repeatable

1) Consider carefully the importance in succinctly describing the collection of information encoded in a generic <note> or <odd> field. Remember that in the context of a shareable metadata record, a link will always direct a user back to the full finding aid on the repository's web site, where all <note> information is available.
2) The DLF Aquifer MODS guidelines recommend that "<note> should only be used for information that cannot be encoded in another, more specific MODS element."

<controlaccess> with any of the following subelements: <corpname>, <famname>, <function>, <genreform>, <geogname>, <name>, <occupation>, <persname>, <subject>, <title>

Content relevant to this element should be derived from DACS 3.1 Scope and Content Element. See also information about access points in archival description on pages xviii-xxi.

<subject> with any of the following subelements: <topic>, <geographic>, <temporal>, <titleInfo>, <name>, <genre>, <hierarchicalGeographic>, <cartographics>, <geographicCode>, or <occupation>

Required if applicable/ Repeatable

1) The DLF Aquifer MODS guidelines require the use of at least one <subject> element with an appropriate subelement in a record if subject is applicable, which it should be to all archival collections.
2) This crosswalk recommends the following mappings of EAD's <controlaccess> subelements to MODS's <subject> subelements:
EAD <corpname> = MODS <name type="corporate">;
EAD <famname> = MODS <name type="personal">;
EAD <function> = No good equivalent in MODS due to its bibliographic nature, although not ideal this crosswalk recommends mapping to MODS <topic> with no @authority attribute on <subject>;
EAD <genreform> = MODS <genre>;
EAD <geogname> = MODS <geographic>;
EAD <name> = MODS <name>;
EAD <occupation> = MODS <occupation>;
EAD <persname> = MODS <name type="personal">;
EAD <subject> = MODS <topic>; and
EAD <title> = MODS <titleInfo>.
3) EAD's @source attribute, when encoded on any <controlaccess> subelement, should be mapped to MODS @authority attribute on <subject>.

No corresponding EAD element

No content guidance in DACS

<classification>

Optional/ Repeatable

1) This crosswalk does not recommend using the MODS <classification> element in shareable metadata records for EAD-encoded finding aids.

No corresponding EAD element

No content guidance in DACS

<relatedItem>

Recommended if applicable/ Repeatable

1) The MODS <relatedItem> element will not typically be useful in a shareable metadata record for an EAD-encoded finding aid.
2) One exception is when digital object content associated with a finding aid can be succinctly pointed to with a single link, in which case using MODS <relatedItem type="constituent" displayLabel="Collection material available in digital format" xlink:href="[persistent URL]"> would be appropriate.
3) If digital object content associated with a finding aid cannot be succintly pointed to with a single link, this crosswalk recommends directing users to the finding aid itself (using MODS <location><url> as indicated elsewhere in this crosswalk) in order to access the associated digital content.

<did><unitid>

2.1

<identifier>

Recommended/ Repeatable

1) This crosswalk recommends the use of the value "local" for the required @type attribute on MODS <identifier> for archival collection numbers assigned by the repository (e.g., <identifier type="local">).
2) This crosswalk recommends the use of the value of "Collection number" for the optional @displayLabel attribute on MODS <identifier> for archival collection numbers assigned by the repository (e.g., <identifier type="local" displayLabel="Collection number">).

No globally reliable corresponding EAD element (in some cases the value of <eadid> @url attribute may be a transactionable URL)

No content guidance in DACS

<location><url>

Required/ Repeatable

1) This crosswalk recommends not relying on the EAD <eadid> @url attribute for mapping to MODS <location><url>.
2) This crosswalk recommends using a persistent URL that provides a link to the online finding aid in its contextual setting (e.g., with navigation to the repository's web site to give users access to further information). If a persistent URL is not possible, use an appropriate, possibly non-persistent URL that will serve the same function.
3) Use the value "primary display" with the required @usage attribute of MODS <url>, and the value "object in context" with the recommended @access attribute of MODS <url> (i.e., <location><url usage="primary display" access="object in context">[persistent URL]</url></location>).

<accessrestrict>

4.1

<accessConditions>

Required/ Repeatable

1) Use the value "restrictionOnAccess" for the required @type attribute of MODS <accessCondition> for information mapped from EAD <accessrestrict>. Use a clear, succinct label, such as "Access to the Collection", for the optional @displayLabel attribute of MODS <accessCondition> for information mapped from EAD <accessrestrict> (i.e., <accessCondition type="restrictionOnAccess" displayLabel="Access to the Collection">).

<phystech> or <userestrict>

4.2, 4.3, and 4.4

<accessCondition>

Recommended if applicable/ Repeatable

1) Use the value "useAndReproduction" for the required @type attribute of MODS <accessCondition> for information mapped from EAD <phystech> or <userestrict>. Use a clear, succinct label, such as "Use of the Collection", for the optional @displayLabel attribute of MODS <accessCondition> for information mapped from EAD <phystech> or <userestrict> (i.e., <accessCondition type="useAndReproduction" displayLabel="Use of the Collection">).

  • No labels