The third version of Encoded Archival Description (EAD) is on the cusp of being released, which prompts me to offer up a quickie history of EAD’s development and to summarize what’s coming with EAD3.
EAD has come a long way since the launch of version 1.0 in 1998. I was one of the lucky members of the initial EAD research group, which was recognized in the same year by the Society of American Archivists with its annual Coker award. Having been there at the beginning, it has been nothing short of amazing to observe both the depth and breadth of EAD adoption all over the world over the ensuing sixteen years. It doesn’t seem like that long ago that lots of archivists didn’t think it was possible to wrangle the anarchic finding aid into submission by development of a standard. EAD version 2002 introduced quite a few changes to the initial DTD, particularly in response to needs of members of the international archival community who were among the early adopters.
And now EAD3 is on target to launch in the winter of 2015. Mike Rush, co-chair of SAA’s Technical Subcommittee on EAD, recently presented a webinar to bring us all into the loop about some of the significant changes that are coming. TS-EAD has done a great job of soliciting input and communicating about the revision process. An enormous amount of information is here, and a nice summary of the principles behind the array of changes is here.
In a nutshell, EAD3 is intended to “improve the efficiency and effectiveness of EAD as a standard for the electronic representation of descriptions of archival materials and a tool for the preservation and presentation of such data and its interchange between systems.” A specific objective is to achieve greater conceptual and semantic consistency in EAD’s use; this should be good news to techies responsible for implementations of the standard, some of whom have been vocal for years about the extent to which the excessive flexibility of EAD’s design has proven challenging. Two other goals are to find ways to make EAD-encoded finding aids connect more effectively with other protocols and to improve multilingual functionalities.
TS-EAD has been working madly to finalize the schema and isn’t making the latest version available as little tweaks are made, but you can see a relatively final version of the element list here.
So, what are some of the significant changes that we’ll see in EAD3? I’m going to assume that readers are familiar enough with EAD elements that these will make sense. Note that this is a very partial list.
- Lots of changes are coming to the metadata about the finding aid, currently found in <eadheader>, which is changing to <control>. I particularly like the new element <otherrecordid> that enables record identifiers from other systems to be brought in. This will make it possible, for example, to add the record i.d. for a companion MARC record.
- We’ll see new and modified <did> elements, which are the basic descriptive building blocks of a finding aid. A new one is <unitdatestructured>, an optional sibling of <unitdate>, which will enable the parts of a date to be pulled out for manipulation of whatever sort. It bears noting, however, that this is an example of a new functionality that won’t be useful unless entire bodies of finding aids are retrospectively enhanced. That said, I really like the new attributes @notbefore and @notafter.
- A <relations> element is being added in concert with the same as found in Encoded Archival Context: Corporate Bodies, Persons, and Families (EAC-CPF). <relations> will be a provisional element due to debate within TS-EAD about whether it makes sense in descriptions of archival materials in addition to being found in authority records for the named entities that occur in those descriptions. I confess that my understanding of <relations> isn’t all it could be, but, like some TS-EAD members, I’m dubious that it belongs in a descriptive context. Isn’t it enough to point out relationships among named entities within authority records? Is it intended as a stopgap until we have masses of EAC-CPF records widely available? (If so, use of <relations> in EAD will perpetuate the mixing of descriptive and authority data …) One stated value of <relations> is that it’ll support uses of Linked Open Data. Experimentation will determine this element’s fate.
- Access term elements (those found within <controlaccess> have been tweaked. For example, <persname> can now be parsed into multiple <part>s for name and life dates. <geographiccoordinate>, which is self-describing, is a new subelement of <geogname>. Nice.
- The “mixed content” model in which some elements can contain both other elements and open text has been streamlined. For example, <repository> must now contain a specific element such as <corpname> rather than open text without specification of the type of name. This is good; adds to the name’s utility as an access point.
- Some descriptive elements have been “disentangled,” such as <unitdate> no longer being available within <unittitle>. I like it; presumably a file name that consists solely of a date will now be coded as such. On the other hand, would it be a display and stylesheet problem to have no <unittitle> within a <did>?
- Some minor elements have been deprecated (i.e., they’re going away). In general, my reaction is “good riddance.”
- Multilingual functionalities have been expanded by adding language code and script codes to most elements. It’s now possible to encode this data inline via the new <foreign> element. “Foreign” in an international standard? Well, I wasn’t the one who had to come up with an ecumenical word, so I’m not throwing any stones.
- Linking elements have been simplified, mostly by deprecating some that have been minimally used and by limiting where others are available. One thing does bug me: <dao> will be available only within <did>. Problematic for those who have included sample images at the head of the finding aid? Or who want to affiliate images with e.g. <scopecontent> or <bioghist> rather than within a particular <did>?
Observations? Disagreements? Worries? Please let me know what you think by leaving a comment.
Jackie Dooley retired in from OCLC in 2018. She led OCLC Research projects to inform and improve archives and special collections practice.
I’m really interested in working through how to implement the new set of elements and attributes available in EAD3 for physical description; specifically the physdescstructured and parallelphysdescstructuredset elements. These were designed with the complexities of electronic records in mind, but at first glance it seems they’ll prove useful for description of audiovisual materials as well, whose complexities sort of mirror those of e-records. For instance, where you want to include multiple ways of expressing a component’s extent, or where you have different types of physical records making up a single intellectual component.
To agree with and extend what Megan said about the physdescstructured elements: I’ve recently exchanged some helpful emails with Mike Rush (thanks, Mike!) about using terms from PBCore vocabularies in child elements of physdescstructured, such as unittype and physfacet. PBCore is undergoing a sort of revitalization due, at least in part, to the American Archives of Public Broadcasting project. This XML-based structural standard is especially useful for audiovisual materials, and it could provide needed guidance on how to state the name of a format (such as a 1/4-inch audio reel) and its most important physical characteristics (e.g., those that would effect playback, basic access). PBCore covers both physical and digital audio, film, and video. Changes in both the PBCore website and the standard itself are underway, but keep an eye on the website, http://pbcore.org/. The vocabularies are maintained in the Open Metadata Registry. Additionally, Mike suggested that relations (imagine pointy brackets around relations) could contain a wrapper element, namely objectxmlwrap, for metadata from a standard other than EAD — such as PBCore. relations can be used within archdesc and component elements (c01, c02, etc.), meaning we could jump into PBCore for a description of an AV item (or subseries, etc.), including, e.g., segments and instantiations as appropriate. For AV materials, item-level and even sub-item level description is often needed, and although such non-EAD descriptions could be linked to, e.g., in connection to a digitized segment of an oral history interview, it would be nice to have the option to embed the description in the finding aid. There’s work to be done in the PBCore vocabularies from what I can tell, and relations is experimental in EAD3, but is any of this worth pursuing? What do you all think? Thanks.
This is a very helpful run-down of the direction that this will be taking us. Thanks so much, Jackie!
I’ve been thinking a lot about elements (like ) that will require enhancements. It would be great if a body (perhaps like ArchiveGrid, or even a module within our management tools like ArchivesSpace) could start thinking about a suite of enhancement tools for finding aids to make our data a lot more actionable. These could be reconciliation tools that could bring in LCNAF and LCSH URIs to controlled access points to make them more linking-friendly, a set of regular expressions that could identify normalized dates from date expression statements, or a validation layer that could identify when DACS single-level minimum elements are missing. It seems to me that our standards are bringing us much closer to a world of manipulable, linkable data, and now our data just needs to catch up!
Stupid pointy brackets!!!! I was alluding to unitdatestructured as an example of elements that would require enhancement.
I also don’t like the element named “foreign” – what’s “foreign” to you may be “native” to someone else. Why not just call it what it is, a coded value?
Karen, EAD element names are meant to be human-readable for their intended meaning, so calling it generally a coded value wouldn’t fit. But maybe something like ? ?
Oops, it looks like WordPress doesn’t like pointy brackets. I suggested “languagecode” or “otherlanguage.” Other ideas?
Yes, that’s what I meant: LanguageCode & ScriptCode
From what I understand, the point of foreign is that it’s foreign to the language in which it occurs. Par example that last phrase was foreign but wouldn’t be if I were writing this comment in English. This helps designate and display words which people may want to realize aren’t things they don’t know in English, because the person is ESL and the phrase is German. See also TEI.
Good to know, Ruth. I’m still not sure it’s the best word … 🙂
Thanks for the good news about rolling tweaks in future, Mike!
Jackie, thanks for the kind and supportive comments on EAD3. Although we are no longer accepting comments on the current revision (although bug reports are still very welcome), my TS-EAD colleagues and I remain eager to hear from the community as they begin to grapple with EAD3 and the implications of the revision. One important change that was out of scope of the recent webinar is that after the final release of EAD3 we will be accepting comments on an ongoing basis, with the intention of fixing bugs and making minor backwards-compatible changes on an as-needed basis rather than letting them accrue to a critical mass. Significant changes or new features will still be saved for major revisions, but the community can expect EAD to receive more regular upkeep.