EAD Application Guidelines for Version 1.0

Appendix B: EAD Crosswalks

This appendix includes four "crosswalks" intended to enable comparison of EAD elements with the data elements defined in three related metadata standards or frameworks: ISAD(G), Dublin Core, and USMARC. Use of these crosswalks may facilitate mapping of data between and among these metadata tools, such as for exporting data from EAD-encoded finding aids to create USMARC records. Further information about the relationship between EAD and these other standards is contained in various sections of these Guidelines.

The four crosswalks are these:

B.1. ISAD(G) to EAD
B.2. EAD to ISAD(G)
B.3. Dublin Core to EAD

A conservative approach was taken in compiling these crosswalks. In other words, only clear equivalencies between data elements were included. Other roughly compatible elements that may be identifiable by users were omitted because the match was felt to be ambiguous or uncertain.

Listing of two EAD elements side by side indicates that the second element is a subelement of the first. For example, "<controlaccess><persname>" indicates that the <persname> element should be nested within <controlaccess>.

Listing of different EAD elements on separate lines within a table cell indicates that all of the listed elements can be mapped to the matching data element from the corresponding metadata tool.

B.1. ISAD(G) to EAD

3.1.1 Reference code(s) <unitid> COUNTRYCODE and REPOSITORYCODE attributes
3.1.2 Title <unittitle>
3.1.3 Dates of creation <unitdate>
3.1.4 Level of description <archdesc> and <c> LEVEL attribute
3.1.5 Extent of the unit <physdesc>, <extent>
3.2.1 Name of creator <origination>
3.2.2 Administrative/Biographical history <bioghist>
3.2.3 Dates of accumulation <custodhist><date type="accumulation">
3.2.4 Custodial history <custodhist>
3.2.5 Immediate source of acquisition <acqinfo>
3.3.1 Scope and content <scopecontent>
3.3.2 Appraisal, destruction and scheduling <appraisal>
3.3.3 Accruals <accruals>
3.3.4 System of arrangement <arrangement>
3.4.1 Legal status <archdesc> LEGALSTATUS attribute
3.4.2 Access conditions <accessrestrict>
3.4.3 Copyright/Reproduction <userestrict>
3.4.4 Language of material <archdesc> LANGMATERIAL attribute
3.4.5 Physical characteristics <physdesc><physfacet>
3.4.6 Finding aids <otherfindaid>
3.5.1 Location of originals <odd>
3.5.2 Existence of copies <altformavail>
3.5.3 Related units of description <relatedmaterial>
3.5.4 Associated material <separatedmaterial>
3.5.5 Publication note <bibliography>
3.6.1 Note <odd>

B.2. EAD to ISAD(G)

<accessrestrict>3.4.2 Access conditions
<accruals>3.3.3 Accruals
<acqinfo>3.2.5 Immediate source of acquisition
<altformavail>3.5.2 Existence of copies
<appraisal>3.3.2 Appraisal, destruction and scheduling
<archdesc> and <c> LEVEL attribute3.1.4 Level of description
<archdesc> LANGMATERIAL attribute3.4.4 Language of material
<archdesc> LEGALSTATUS attribute3.4.1 Legal status
<arrangement>3.3.4 System of arrangement
<bibliography>3.5.5 Publication note
<bioghist>3.2.2 Administrative/Biographical history
<custodhist>3.2.4 Custodial history
<custodhist><date type="accumulation">3.2.3 Dates of accumulation
<odd>3.6.1 Note
<odd>3.5.1 Location of originals
<origination>3.2.1 Name of creator
<otherfindaid>3.4.6 Finding aids
<physdesc> <extent>3.1.5 Extent of the unit
<physdesc> <physfacet>3.4.5 Physical characteristics
<relatedmaterial>3.5.3 Related units of description
<scopecontent>3.3.1 Scope and content
<separatedmaterial>3.5.4 Associated material
<unitdate>3.1.3 Dates of creation
<unitid> COUNTRYCODE and REPOSITORYCODE attributes3.1.1 Reference code(s)
<unittitle>3.1.2 Title
<userestrict>3.4.3 Copyright/Reproduction

B.3. Dublin Core to EAD

Table B.3 maps the 15 elements in the Dublin Core (DC) Element Set to EAD elements within <eadheader> and <archdesc>. DC remains a "work in progress" as of early 1999, and so it is possible that this mapping will change in future.

In mapping DC to EAD, it is first necessary to consider which "resource" the metadata is describing: the finding aid per se, or the collection of archival material. If the described resource is the finding aid, it is most appropriate to map DC elements to subelements of <eadheader>. If, on the other hand, a DC record is being created for an archival collection itself, the DC elements should be mapped to <archdesc> subelements, most of which are found in the high-level <did>.

All DC elements are listed in this table, but some DC elements have no clear corollary in EAD. Where the boxes have been left blank, no clear equivalent exists.

DUBLIN COREEAD <eadheader>EAD <archdesc>
<geogname> (spatial) <unitdate> (temporal)
Type(126)<archdesc> with LEVEL attribute
Identifier<eadid><unitid> with COUNTRYCODE and REPOSITORYCODE attributes
Language<language><archdesc> with LANGMATERIAL attribute


Table B.4 does not include all possible USMARC fields to which EAD elements might be mapped to generate a partial USMARC record for the collection; it instead focuses on the most significant and useful fields. In addition, USMARC fields that contain coded data, such as Leader and Directory fields, are not included, because it is unlikely that such information would be provided in a finding aid in a format that could be directly ported into a USMARC record (or vice versa).

Note that this mapping is between an EAD finding aid and a USMARC record describing that same collection, not to a USMARC record describing the finding aid per se.

The table only includes MARC fields for which there is a direct, logical analog to an EAD element. Where an EAD element has a more specific subelement that can accurately be mapped (such as <acqinfo> within <admininfo>), the subelement is mapped.

The right-hand column listing EAD elements specifies the use of a subelement within another element in some situations. In other cases, this column provides a list of optional elements, leaving it to the archivist to determine which one best fits the data being encoded.

It is most useful to map to USMARC the EAD data that is encoded in the high-level <did> or in other <did>-level elements such as <bioghist>, <scopecontent>, and <controlaccess> to their field equivalencies in USMARC records. Since most repositories create USMARC records only at the "collection level," mapping from more detailed components of EAD finding aids, while theoretically feasible, is less likely to be useful in practical terms.

Note that EAD data being mapped to USMARC fields that require authority-controlled data must be in controlled access form in order to be imported into a valid USMARC record.

041 Language<archdesc> LANGMATERIAL attribute
100 Main entry--personal name<origination><persname>
110 Main entry--corporate name<origination><corpname>
111 Main entry--meeting name<origination><corpname>
130 Main entry--uniform title<unittitle>
240 Uniform title<controlaccess><title>
245 Title statement<unittitle>
300 Physical description<physdesc>
340 Physical medium<physdesc>
351 Organization and arrangement<organization>
<archdesc> LEVEL attribute
500 General note<odd>
506 Restrictions on access note<accessrestrict>
510 Citation/references<bibliography>
520 Summary, etc.<scopecontent> <abstract>
524 Preferred citation of described materials<prefercite>
530 Additional physical form available<altformavail>
536 Funding information<sponsor>
540 Terms governing use and reproduction<userestrict>
541 Immediate source of acquisition<acqinfo>
544 Location of other archival materials<separatedmaterial>
545 Biographical or historical data<bioghist> <abstract>
555 Cumulative index/finding aids(128)
561 Ownership and custodial history<custodhist>
581 Publications about described materials<bibliography>
583 Action<processinfo>
584 Accumulation and frequency of use<accruals>
600 Subject--personal name<controlaccess><persname role="subject">
<controlaccess><famname role="subject">
610 Subject--corporate name<controlaccess><corpname role="subject">
611 Subject--meeting<controlaccess><corpname role="subject">
630 Subject--uniform title<controlaccess><title role="subject">
650 Subject--topical<controlaccess><subject>
651 Subject--geographic name<controlaccess><geogname role="subject">
655 Genre/form<controlaccess><genreform>
656 Occupation<controlaccess><occupation>
657 Function<controlaccess><function>
69x Local subject access<controlaccess><subject source="local">
700 Added entry--personal name<controlaccess><persname>
710 Added entry--corporate name<controlaccess><corpname>
711 Added entry--meeting name<controlaccess><corpname>
720 Added entry--uncontrolled<name>
730 Added entry--uniform title<controlaccess><title>
740 Added entry--uncont./related anal. title<title>
752 Added entry--hierarchical place name<geogname>
852 Location<repository> <physloc>


  1. It would be appropriate to establish "archival finding aid" as a resource type if an enumerated list of types is established for Dublin Core.

  2. The data format of an EAD finding aid is SGML or XML.

  3. In a USMARC record a note in the 555 field would mention the existence of the EAD-encoded finding aid, but no specific EAD element maps to this field.

Table of Contents
Home Page Preface Acknowledgments How to Use
This Manual
Setting EAD
in Context
Creating Finding
Aids in EAD
Authoring EAD
Publishing EAD
EAD Linking

Go to:

Copyright Society of American Archivists, 1999.
All Rights Reserved.

[VIEW OF LC DOME] The Library of Congress

Library of Congress Help Desk (11/01/00)