Angle Bracket Fetish: Reflecting on EADiva 5 Years Later
What happens on the day after the apocalypse? When all your plans go up in smoke, what do you want for your future? How do you make sense of your past? In my new game Snake People, now funding on Kickstarter, players create a world of cataclysm, memory, and mortality. Choose your species, choose your apocalypse.
5 years ago, on May 18, 2013, posted introduced EADiva to the world. I'd been working on the project since the previous fall—I bought the domain name in September 2012. Looking back now, I'm still on board with the objectives I stated in that first post:
My goal in creating this site was to make a resource oriented toward people who are attempting to learn EAD but may not have much more experience with XML than one gets in basic library school classes. The Library of Congress's tag library uses some terms which may confuse a person who is unable to read a DTD. Attributes are described separately from elements, causing a need for much back-and-forth to understand how they relate to the elements. Element pages also don't link to the elements they mention, making the user spend much more time navigating.
I continue to hope that lowering barriers to technical aspects of our work will not only aid people in getting their initial questions answered, but build their comfort and enable further exploration and understanding. And in these five years, I've reflected a lot on where this project may be helpful and where it inadvertently reinforces a poorer understanding of archival description which has been a problem in our field.
Learning in Brackets
I took the title from Mike Rush's presentation in the “Thirty Years On: SAA and Descriptive Standards” panel, 2011. As Bill Landis points out and Bill Stockting reinforces in the same panel, American archival practice since the development of EAD has focused a lot more on the brackets than on engaging the overall standard ISAD(G). If we think only in terms of the encoding elements vs. the kind of content which should be in our description, our description will be the lesser for it.
Shortly after launching EADiva, I got two excellent recommendations from Rebecca Goldman and “an archivist friend” (all I can find in an email about it) to incorporate DACS cross-references. In mid-2013, DACS was only available as a PDF, but by the end of the year, the revised DACS had been published with an HTML form for easy linking. Still, that did not frame DACS as a starting place so much as a thing to consider or place to check when one was looking at a particular element. It's also important to remember, DACS does not require EAD. Nor do DACS content elements map 1-1 to EAD elements.
The starting place of good description isn't in the brackets. It's in the content standards, it's in consideration of honest description, it's in asking who's being left out and what gets prioritized in the description.
I don't want to limit or put a should on how anyone uses EADiva. But I'm going to suggest where I think it could be most useful:
- As a reference for building transformations. Whether it's writing your XSLT or otherwise using your XML, you may need a reference point. If you're using EAD 2002, I believe the EADiva 2002 site is still the best reference.
- A place to explore encoding differences between EAD 2002 and EAD3. The two versions of EADiva interlink in the sidebar of element pages and the EAD3 site tends to explain differences from EAD 2002. If you're migrating encoding formats and want to understand and assess current options, I think it offers a useful comparison.
- As a place to see what's possible in encoding choices. I strongly support encoding content as data, when that's possible. Maybe you want to think about how you'd encode for linked data or the best ways to record complex dates in ways which are machine-actionable.
- As the second place to go when doing a library school assignment. With DACS and the overall literature on description being the first.
There are other possibilities, of course. Description in a good system may be the most efficient. If you're using ArchivesSpace or Archivists’ Toolkit (for definitions of good), you don't get to/have to make many encoding decisions. Similarly, if you're using the ArchivesSpace Public User Interface, you may not need to worry about XSLT. Working in brackets increases descriptive variation. It can also be risky. In my last position, I managed to use regular expressions to help a coworker recover closing tags after he somehow managed to remove the forward slashes from closing tags of a ~8000-line finding aid. Sometimes that's how your institution works. Sometimes you're working with the finding aids exported from a system and need to understand the encoding standard.
So, if you're coming to EADiva to figure out how to do archival description, I'd suggest you don't do so through memorizing EAD. But if you're trying to answer the general question “how do you I make this work?” then I hope the pair of tag libraries help you answer the question. I'll do my best to keep them up as long as people are asking.
Hearing from You
If you can think of useful ways for the EADiva site(s) to direct visitors toward starting from a place of considering content and content standards without it getting in the way of their serving as a reference, I'd appreciate it. And I'm also curious — if you've used EADiva, where did you first encounter it? What did you use it for? What is your assessment of the project's place in the overall world of archival description?