Home » Groups » Encoded Archival Standards Section » Frequently Asked Questions about EAD and EAD3

Frequently Asked Questions about EAD and EAD3

General Questions about EAD3

Why is there another revision of EAD?

Technology, as we all know, has been moving fast. From collection management systems like Archivists' Toolkit, Archon, AtoM, and the new ArchivesSpace to the emerging possibilities of Linked Data and the release of Encoded Archival Context - Corporate bodies, Persons, and Families (EAC-CPF), the technology available to complete archival description has rapidly evolved since the release of EAD 2002. In addition, years of working with EAD, had given archivists more experience with how they felt EAD would work better. In 2010, the SAA Standards Committee charged a new Technical Subcommittee for Encoded Archival Description (TS-EAD) to complete a revision of EAD within 5 years.

Why can't I just put my information into a database?

You can certainly put your finding aid information into a database, but there are several advantages to using EAD:

  • EAD reflects the hierarchical structure of archival collections, and allows for describing both the collection as a whole and its individual parts.
  • EAD is an international archival standard and allows for the standardization of information within and across different repositories. EAD is used throughout the United States, Europe, Australia, and other countries. The structural elements of EAD are easily recognized and used in union catalogs like ArchiveGrid and consortiums like the Online Archive of California, Northwest Digital Archives, and Archives Portal Europe.
  • EAD is expressed in XML, which is a structural and preservation format. XML facilitates repurposing of data. A finding aid in XML can be converted into a variety of different formats for display and access to users. An HTML and PDF version of the finding aid can easily be created via the same EAD document.
  • EAD is interoperable with other standards like Encoded Archival Context.

Where can I find resources to help me continue my EAD training/answer questions that may arise in the future?

Stay tuned on this page. Visit the roundtable's GitHub account. The EAD Roundtable gather further resources as they arise.

Once the EAD is created, what do I do next? How do I build a search index and what's the best method to serve the EAD files? HTML or XML — which format should be published to the web?

Publishing EAD finding aids and making them searchable online is often one of the most significant hurdles for archivists to overcome. Software options like ArchivesSpace allow you to create EAD finding aids without dealing with the XML encoding and to publish them on the web in a searchable format. Local consortia, if you have one available to you, can also be helpful in assisting with publishing finding aids on the web in a searchable format.

Delivering the finding aids on your own, will take some technical knowledge. A publication from OCLC Research, "Over, Around, and Through: Getting Around Barriers to EAD Implementation " provides a helpful overview of the options. You can deliver finding aids directly to your user's browser in XML, but you will need to point to an XSLT stylesheet and you need to be aware that some users may be using browsers that do not provide the same level of support for XML. An XSLT stylesheet can also be used to convert your XML finding aids to HTML or PDF. Doing this may present a more even display to your users, but the downside is that you lose the flexibility of XML and you have to update the HTML or PDF each time the finding aid is updated.

Some options for searching and indexing are also provided in "Over, Around, and Through." You could try a simple options like Google site search or other website indexing system. For those with more experience or technical knowledge of XML, XML publishing platforms like XTF are available.

Are premade templates available? Do you have any good examples of EAD in Action?

The EAD Roundtable plans to collect examples of EAD in Action for EAD3. TS-EAD has also been soliciting examples of EAD3 finding aids and has created a few for testing purposes. There are currently no pre-made templates available, but the EAD Roundtable would like to collect such instances if the community submits them.

Why should I switch to EAD3?

EAD3 has replaced EAD 2002 as the official version of EAD. EAD3 seeks to simplify EAD and to update EAD to connect more easily with other standards like EAC-CPF.

Is EAD3 schema data driven or presentation driven? EAD2 had this tendency to be both and that ruins the entire design of the format. Are we going for fully data encoding schema this time?

The goal of EAD3 was to move away from the presentation angle toward full data encoding. A number of presentation-only elements have been deprecated and other data-centric elements added. However, EAD3 remains a continuation of the 2002 schema and, in order to encourage migration, the transition from mixed presentation and data to full data is not complete.

Starting from standpoint of EAD 2002, where does one look to find out what has replaced a deprecated element? For instance, if I am looking at a particular field that has been dropped, how do I quickly see what should be used in its place?

A migration mapping document will be available as part of the EAD3 documentation made available at the time of the official release. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

For those of us who did not go through the previous migration, what is the adoption path from the current version of EAD to EAD3? How will SAA provide support in terms of documentation or tips?

An XSLT style sheet will be provided to enable migration from EAD 2002 to EAD3. TS-EAD and the Schema Development Team will provide the necessary documentation to use the migration stylesheet. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Is EAD3 built into ArchivesSpace yet?

Not yet. The ArchivesSpace community will need to decide when to undertake the necessary development work to enable import and export of EAD3 after its official release. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

What is Schematron? Why might/how might I use it? What software is required?

Schematron is a schema language that makes it possible to enforce rules on an XML instance that either cannot be enforced via the primary schema or that are not enforced due to other considerations. For example, in EAD3 the ISO 639-2b language code list has been removed from the schema because it continues to change and keeping it up-to-date within EAD is impractical whereas an external Schematron that is not part of the official EAD schema can be more easily maintained.Commonly available XML editors, most notably Oxygen, support Schematron validation. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

General Questions about EAD Elements and Attributes

Why is this wrong: <c02><did><unittitle>Box 12</unittitle></did></c02>? Why is this wrong: <c02><did><title>Series 1: Letters</title></did></c02>?

These are two commonly-made errors. <unittitle> should encode the title of an intellectual unit of description. Whether that unit is housed in a particular box, a series of boxes, or just a folder should be encoded in <container>. If that title contains a proper title, it should be encoded within a <title> element within <unittitle>, never directly inside the <did>. For example: <unittitle>Draft of <title>Pride and Prejudice</title><unittitle>.

Do I have to use the @normal or new @standarddate/@notbefore/@notafter attributes in dates?

No, technical compliance with either EAD 2002 or EAD3 schemas does not require you to use @normal or @standarddate (or @notbefore/@notafter). It is, however, generally considered best practice to record a machine-readable form of a date and may be required by local rules and local validation. The new attributes in EAD3 allow for cases when the exact date may not be known. For more on best practices regarding dates, see DACS 2.4 http://www2.archivists.org/standards/DACS/part_I/chapter_2/4_date

When should I use <c> vs. <cxx>?

<cxx> can be useful in two situations. First, when people will be working with the EAD files manually, <cxx> makes the levels of nested elements more apparent. Second, while XLST can be used to parse levels of <c> tags, you may find it easier to write stylesheet information based on <c04> instead of writing dsc/c/c/c/c/. Conversely, it's much easier to style child elements that differ from children of /dsc/did when using plain <c>, e.g. c/did/unittitle vs c01/did/unititle | c02/did/unittitle | c03/did/unittitle | etc. The decision based on XSLT needs should be made in collaboration with the people creating display.

Questions About EAD3 Tags and Attributes

What's the difference between @standarddatetime/@standarddate/@notbefore/@notafter/@normal for dates?

EAD3 refines dates and has added the new attributes for information about complex cases. @normal remains available within <date> as a way to present a normalized form of the date or date range but does not address cases where only partial information about a date is known. @standarddate, @notbefore, and @notafter are available within <todate>, <fromdate>, and <datesingle> to record either a specific date or dates which can help in placing it. A photograph taken during a childhood summer, for example, might be @notbefore 1970-05-01 and @notafter 1970-09-07. A letter might be @notafter 1871. Ideally, data recorded in any of these elements would conform to ISO 8601, e.g. YYYY/YYYY-MM/YYYY-MM-DD, although it is not constrained by the schema and allows for non-Gregorian calendar use.

@standarddatetime is only used in one element, <eventdatetime>, where it logs the date and time of an edit. Time is important in this case, as one might make multiple edits in the same day. If you're making your finding aid with an automated system, it should automatically populate this, though it's not technically required. The format should be: YYYY-MM-DDTHH:MM:SSZ for UTC or -5:00 for Eastern, -6:00 for Central, etc.

We find the @level attribute to be rather restrictive for the Portuguese scenarios. Because of that we tend to use the @otherlevel attribute to encode all of the options we need to support. This of course becomes an interoperability issue later on. Is there any additional levels in the vocabulary for us to use in EAD3?

@level has the same values in EAD3.

What is the appropriate header info to use to create a valid EAD3 instance?

If the question has to do with the schema declaration, the location of the schema will be http://ead3.archivists.org/schema, so a basic declaration would be: <ead xmlns="http://ead3.archivists.org/schema/">. The <control> element also have a number of required elements which could be considered required header elements and are documented in the tag library.

We have occasionally nested <scopecontent> within <scopecontent> and <bioghist> within <bioghist>. Is this deprecated as part of removing mixed content?

No, this will not be deprecated. Following siblings of <did> will continue to recurse. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Why is <dao> only allowed within <did>?

The rationale for limiting <dao> to <did> boils down to simplification. In our [TS-EAD's] analysis we concluded that <dao> is essentially similar to <container> — both provide information needed in order to deliver records to users, and as such were appropriate children of Descriptive Identification (<did>). This change furthers our goals of improving semantic clarity and better enabling data exchange. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Could you explain the use of the <foreign> element along with Unicode or hexadecimal code?

The <foreign> element will be available in mixed content contexts to tag languages or scripts that differ from the predominant language or script of the surrounding text. There is no direct connection between the use of <foreign> and decisions regarding use of Unicode or hexadecimal character codes. <foreign> concerns the language and script of the contained text, not the character encoding. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Where can <relation> be used? For instance, can we use this element to show the semantic relationship (from schema.org, etc.) between a personal/corp/geographic name in the finding aid and the creator?

<relation> is available only within <relations>, which in turn is a valid child of <archdesc>, <c>, and <c01> - <c12>. Within EAD3 <relation> is intended to describe the relationship of the records described to other external entities, be those other resources, corporate bodes, persons or families, or functions. Within EAD3 it will not be possible to characterize the relationships between the creator of the records and other entities. It is possible to capture such relationships within EAC-CPF. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Can <relations> be used at lower levels of description?

Yes. The <relations> element is available at all levels of description. Where can <relation> be used? For instance, can we use this element to show the semantic relationship (from schema.org, etc.) between a personal/corp/geographic name in the finding aid and the creator? (From the EAD3 webinar with Mike Rush, used with permission of SAA)

Will <addressline> get a @type attribute? In EAD 2002, there is no way to roundtrip elements out of and back into a database system, since a street address can't be separated from a country, etc?

Yes. In EAD3 <addressline> will have an optional @localtype attribute for just this purpose. (From the EAD3 webinar with Mike Rush, used with permission of SAA)

New and Deprecated Elements

More on the new tags and deprecations can be found in the official tag library. This list was created in response to a request for a list and basic description either of the function or the replacement/reason for deprecation.

New Elements

  • <agencycode> — Agency Code
    • Used in <maintenanceagency> to identify the agency responsible for the creation, maintenance, or dissemination of the EAD finding aid. May come from ISO 15511.
  • <agencyname> — Agency Name
    • Required in <maintenanceagency> to name the agency responsible for the creation, maintenance, or dissemination of the EAD finding aid.
  • <agent> — Agent
    • Required in <maintenanceevent> to name the person, system, or institution (but not overall agency) responsible for a particular event of the creation, modification, or deletion of an EAD finding aid.
  • <agenttype> — Agent Type
    • Required in <maintenanceevent> to specify whether the agent is a human, machine, or of unknown type.
  • <chronitemset> — Chronology List Item Set
    • Replaces <eventgrp> within <chronitem> to bundle events and places which all relate to the same date/date set/date range.
  • <citation> — Citation
    • Required in <conventiondeclaration> and <localtypedeclaration>. Cites descriptive rules and conventions used in creating the finding aid.
  • <control> — Control
    • Replaces <eadheader> as one of the two required elements in <ead>.
  • <controlnote> — Control Note
    • Replaces <note> within <notestmt> in <control>.
  • <conventiondeclaration> — Convention Declaration
    • Identifies the non-local descriptive rules and conventions used in creating the finding aid. See <localtypedeclaration> for specifically local rules. Replaces <descrules>.
  • <daoset> — Digital Archival Object Set
    • Replaces <daogrp> and bundles <dao> elements.
  • <daterange> — Date Range
    • A refined date element. May contain <fromdate> and <todate> to designate ends of the date range.
  • <dateset> — Date Set
    • A refined date element. Used to bundle any number of <datesingle> and/or <daterange> elements to encode complex date information.
  • <datesingle> — Date Single
    • A refined date element. Encodes a single date.
  • <descriptivenote> — Descriptive Note
    • A refined replacement for <note>. Provides additional descriptive information in a limited set of elements.
  • <didnote> — Descriptive Identification Note
    • A refined replacement for <note> which can only be used in <did>.
  • <eventdatetime> — Event Date and Time
    • Required in <maintenanceevent> to record the date and time of a maintenance event.
  • <eventdescription> — Event Description
    • Used in <maintenanceevent> to provide a textual description of the maintenance event.
  • <eventtype> — Event Type
    • Required in <maintenanceevent> to record whether the type of event was created, revised, deleted, cancelled, derived, updated, or unknown.
  • <footnote> — Footnote
    • A refined replacement for <note> used to create an annotation or citation for a limited set of elements.
  • <foreign> — Foreign
    • Brought in from TEI to encode words which are in a different language or script than the surrounding text.
  • <fromdate> — From Date
    • Used in <daterange> to designate the starting date of the range.
  • <geographiccoordinates> — Geographic Coordinates
    • Used in <geogname> to specify the geographic coordinates of a location.
  • <head03> — Third Heading
    • Adds a third heading to <head01> and <head02>.
  • <languagedeclaration> — Language Declaration
    • Used in <control> to specify the language and script in which the finding aid is written. Repeatable.
  • <languageset> — Language Set
    • Pulls together languages and their scripts in <languagematerial>. Bundles one or more <language> element with one or more <script> element and a possible <descriptivenote> to explain how the languages and scripts are used in the material.
  • <localcontrol> — Local Control
    • Used to provide any specifically-local information about the finding aid.
  • <localtypedeclaration> — Local Type Declaration
    • Identifies the local descriptive rules and conventions used in creating the finding aid. See <conventiondeclaration> for non-local rules. Replaces <descrules>.
  • <maintenanceagency> — Maintenance Agency
    • Required in <control> to provide information about the agency responsible for the creation, maintenance, or dissemination of the EAD finding aid.
  • <maintenanceevent> — Maintenance Event
    • Required in <maintenancehistory> to provide information about each file maintenance event.
  • <maintenancehistory> — Maintenance History
    • Required in <control> to record the history of events in maintaining the EAD file.
  • <maintenancestatus> — Maintenance Status
    • Used in <control> to record whether a file is revised, deleted, new, deletedsplit, deletedmerged, deletedreplaced, cancelled, or derived.
  • <objectxmlwrap> — Object XML Wrap
    • Used to encode non-EAD XML in <source> or <relation>.
  • <otheragencycode> — Other Agency Code
    • Used in <maintenanceagency> to record a non-standardized code for the agency responsible for the creation, maintenance, or dissemination of the EAD finding aid.
  • <otherrecordid> — Other Record ID
    • Used in <control> to provide any additional record IDs.
  • <physdescset> — Physical Description Set
    • Used to group multiple <physdescstructured> elements which either provide parallel or complementary descriptions of the same materials.
  • <part> — Part
    • Required within access elements to encode parts of a name/title/etc.
  • <physdescstructured> — Structured Physical Description
    • Refines and standardizes <physdesc>.
  • <publicationstatus> — Publication Status
    • Used in <control> to indicate whether a finding aid is inprocess, approved, or published.
  • <quantity> — Quantity
    • Replaces <extent> and now required <physdescstructured>. Designates number of <unittype>s being described.
  • <quote> — Quote
    • Adds inline HTML <q> functionality to EAD.
  • <recordid> — Record ID
    • Replaces <eadid>.
  • <relation> — Relation
    • Used to identify and link to other materials/information which relate to the information being described.
  • <relationentry> — Relation Entry
    • A textual description of the <relation> between two objects.
  • <relations> — Relations
    • Used to group <relation> elements which identify and link to other materials/information which relate to the information being described.
  • <representation> — Representation
    • Used to encode a link to a deliverable version of the finding aid, such as PDF or HTML.
  • <script> — Script
    • Used to designate the script in which either the finding aid or the described materials are written, depending on where it's used.
  • <source> — Source
    • Used to encode information describing a source of evidence used in the finding aid description.
  • <sourceentry> — Source Entry
    • A textual description of the <source> of evidence.
  • <sources> — Sources
    • Used to group <source> elements which describe sources of the evidence used in the finding aid description.
  • <term> — Term
    • Used to pair a descriptive term with the @localtype in <localcontrol>.
  • <todate> — To Date
    • Used in <daterange> to designate the ending date of the range.
  • <unitdatestructured> — Structured Date of the Unit
    • A refined alternative to <unitdate>, which takes advantage of the new <daterange>, <dateset>, and <datesingle> elements.

Deprecated Elements

  • <arc> — Arc
    • Extended links are deprecated in EAD3.
  • <archdescgrp> — Archival Description Group
    • <eadgrp> is deprecated in EAD3. All elements only used in <eadgrp> are deprecated along with it.
  • <bibseries> — Bibliographic Series
    • Within <bibref> and <unittitle>, information about bibliographic series can be encoded within <title> in a <part> with an appropriate @localtype if desired. As <titlepage> is deprecated, it is no longer used there.
  • <change> — Change
    • Changes are now recorded in <maintenanceevent> within <maintenancehistory>.
  • <creation> — Creation
    • Aspects of <creation> are made more specific in elements of <control>.
  • <daodesc> — Digital Archival Object Description
    • <daodesc> is replaced by <descriptivenote>.
  • <daogrp> — Digital Archival Object Group
    • <daogrp> has been replaced by <daoset>, a different way of organizing <dao> elements. As extended linking elements have been deprecated, the grouping element is differently-organized.
  • <daoloc> — Digital Archival Object Location
    • All extended linking elements and their child elements were deprecated.
  • <descgrp> — Description Group
    • The element-grouping function performed by <descgrp> has been deprecated as it did not serve a specific encoding function but was just a way of moving elements around.
  • <descrules> — Descriptive Rules
    • Information about conventions and descriptive rules should now be encoded in <conventiondescription> and <localtypedeclaration>.
  • <div> — Text Division
    • <div> was deprecated as a child element of <titlepage>
  • <dscgrp> — Description of Subordinate Components Group
    • <eadgrp> is deprecated in EAD3. All elements only necessary for <eadgrp> are deprecated along with it.
  • <eadgrp> — EAD Group
    • The <eadgrp> function has been deprecated in EAD3. The function had been rarely used and was not as clean a method of encoding data.
  • <eadheader> — EAD Header
    • <eadheader> has been replaced by <control>.
  • <eadid> — EAD Identifier
    • <eadid> has been replaced by <recordid>
  • <eventgrp> — Event Group
    • <eventgrp> has been replaced by <chronitemset>. It can now include geographic information.
  • <extent> — Extent
    • <extent> has been replaced by <quantity>. It refines the function and is a required child element of <physdescstructured>
  • <extptr> — Extended Pointer
    • All extended linking elements and their child elements were deprecated.
  • <extptrloc> — Extended Pointer Location
    • All extended linking elements and their child elements were deprecated.
  • <extref> — Extended Reference
    • All extended linking elements and their child elements were deprecated.
  • <extrefloc> — Extended Reference Location
    • All extended linking elements and their child elements were deprecated.
  • <frontmatter> — Front Matter
    • <frontmatter> was deprecated as a child element of <titlepage>.
  • <imprint> — Imprint
    • <imprint> was considered superfluous with the introduction of <part>.
  • <langusage> — Language Usage
    • <langusage> in what was <eadheader> is replaced by <languagedeclaration> in <control>. It now requires <language> and <script>.
  • <linkgrp> — Linking Group
    • All extended linking elements and their child elements were deprecated.
  • <note> — Note
    • <note> has been deprecated and refined into four new note elements: <controlnote>, <didnote>, <descriptivenote>, and <footnote>.
  • <ptrloc> — Pointer Location
    • All extended linking elements and their child elements were deprecated.
  • <refloc> — Reference Location
    • All extended linking elements and their child elements were deprecated.
  • <resource> — Resource
    • All extended linking elements and their child elements were deprecated.
  • <revisiondesc> — Revision Description
    • Replaced by the more specific <maintenancehistory>.
  • <runner> — Runner
    • <runner> was purely a formatting element. It did not contain any important encoded data.
  • <subarea> — Subordinate Area
    • <subarea> can be replaced by <part>.
  • <titlepage> — Title Page
    • <titlepage> served only a descriptive, not an encoding purpose. Often, it contained a great deal of duplicate information. It was deprecated as most of its contents could be derived from <control> and <archdesc>. If someone wishes to encode further information to be used entirely in a titlepage function, it could be put in one of the refined note elements. See Appendix B of the tag library for information about ongoing support for <titlepage> through EAD3.

Encoded Archival Standards Section