Matt (@herbison) over at Hot Brainstem posted a good question to his blog: “Can you skip learning EAD and go right to Archivists’ Toolkit or Archon?” He suggests that the “right way” to create accessible finding aids (EAD, DACS, XML, XSLT, and AT) is not as important as finding a (faster) way to get stuff online. First, I want to say thanks to him for bringing this question to the table.
I was not trained to create EAD finding aids in grad school (although I have experience with XML and HTML). Instead, I was trained to create EAD-compatible MS Word docs that were plopped into an EAD template by an encoder and sent over to the OAC. For me, AT was not part of the process of creating a finding aid.
In my current job, I’m working with old EAD files that were outsourced and tied to a problematic stylesheet (they referenced JPG files and included HTML color codes). I imported these old EAD files into AT — minor editing was needed, but nothing that made me reference the EAD tag library. I have yet to create one from “scratch,” although I did recently attend the basic EAD workshop through SAA. I can now search and edit the contents of our existing finding aids (all 450+ of them) and create new ones within the AT interface…and with less opportunity for human error.
I am moving toward the idea of going straight to AT for EAD since it exports “good” EAD (that I have seen so far). I am going to train our grad students and library assistants how to use AT for accessions and basic processing…why would I need to teach them EAD? I am still in the process of answering that question because we are working on a new stylesheet for our finding aids — which means I need to learn more about XSLT. AT might give me a nice EAD document, but it doesn’t make it look pretty online for me.
AT experts like Sibyl (@sibylschaefer) and Mark (@anarchivist) are right when they suggest that an understanding of EAD is important when you need to do stuff with the EAD that AT exports. Just being aware of elements and the tag library helps me “read” an EAD document…and hopefully, it will help me create better, more beautiful finding aids through stylesheets that interact with the data in functional, interactive ways.
So I suppose the question to consider is, “how much do you need to learn about EAD in order to go right to AT or Archon?”
Touchable Archives 
I certainly don’t think all staff members need to be trained on the nitty gritty of EAD. If they know the basic components of a finding aid and can create that in Excel or Word, whoever works with EAD or AT can mark it up in AT or with a pre-made template in an XML editor and work the magic.
I wish more of my colleagues understood EAD to a greater depth. Our shop has moved to a model very similar to AT with XML exported from an integrated system, but it has been frustrating to have a lot of questions that reveal gaps in understanding when it comes to entering information and handling the resulting files. For example, we only just started using revision notes and it has been difficult to get people to consistently fill it in for updated finding aids. In the long run, they’ll get it certainly…I just feel that I have benefited from having to move up myself from basic on-the-job to understanding much more of the reasons and scope behind the EAD tags for more in-depth development.
Who Cares about Learning EAD?
John Lyles Answer,
05/16/2010
Touchable Archives
http://libarchivist.wordpress.com
Do not learn/implement EAD if it slows/hinders/impedes the procession of the collection – you know the thing that the researcher really wants. 10 years ago archival backlogs were due to staffing. Today, archival backlogs are due to EAD implementation. Is it the archival nature to be inefficient? I understand the benefits of structured data but if AT/ARCHON will allow my student to produce “good” EAD instead of “well formed EAD” then so be it. And I do know EAD, XML, MODS, METS, RDF, TEI, ABC, DEF, GHI, JKL, MNO, PQR, STU, VWX, YZ……….
I learned EAD in grad school much the same way that you did. We dropped and dragged from Word to an Oxygen template and I thought that was all there was to it. And it is… if you work at a big institution like Harvard that has a technical staff that puts everything up for you. But now in my first job, I am the lone archivist in a small research library in a non-profit organization and this project (my project) is their first foray into the world of archiving. EAD implementation was only brought into their filed of view because the terms of our grant require it. This means that I’m the only person with any experience in this and that there was no infrastructure for EAD or archives in general when I got here.
As a result, I had to educate my colleagues (including our IT department) and then myself… a lot. I now have a much better understanding of EAD, XML, XSL, and HTML as a result of a lot of hard work, head-scratching, listserv-surfing (begging), and a whole bunch of trial and error. By going this route, I learned a lot and my understanding and appreciation of EAD (and the process a finding aid goes through to get online) has increased dramatically. I feel that I only learned half the process in grad school and that all this work will pay off in both this job and the next.
Even if I never have to use it all again (and I’m sure I will at some point), I’m glad that I did it. I think all archivists would benefit from the experience (if constraints of time, money, staffing, and backlog allow for it, that is).
This is a very interesting and useful thread being spun here and over at Hot Brainstem.
We designed AT to diminish, not totally eliminate, the requirements of encoding, not only for EAD, but for METS, MARCXML, MODS, etc., and also to promote standardized output of EAD.
We did not design the tool to circumvent the rigors of good multi-level description, however. Producing good EAD with the AT requires skill in recording descriptions compliant with domain content standards.
It’s true, as has been pointed out, the AT, and Archon, suffer for not having interfaces and tools to support data management over time. The AT is a good metadata creation tool, but, without additional interfaces and processes, not an optimal metadata editing tool. I am hopeful some of those features will come via the AT/Archon integration project and, subsequently, with the maturation of that new product.
Hopefully, the wait will be shorter than longer.
Thanks for your comments, everyone. I think the key here is that AT/Archon produce standardized EAD documents. I will be posting about our new processing guide that incorporates traditional finding aid training with the AT User Guide, which I have created for students and staff to use without formal interaction with EAD documents.
I agree with Mr. Westbrook that the goal should not be to eliminate encoding, but to make it easier to create good EAD with less potential for human error or encoding fatigue. I, too, am hopeful to see what features appear with the AT/Archon integration.