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.