Ruth Tillman doesn’t like to be bored. In addition to being a full time library paraprofessional and part time library student, she has embarked on a number of projects that many of us might see as full-time jobs unto themselves.  I wanted to talk to her about one of her explorations in particular- EADiva.  This website sets out to improve upon a system that students in archival concentrations across the country view with equal parts suspicion and dread- Encoded Archival Description, or EAD.  I asked her about EAD, and what she hopes to accomplish with EADiva.

Tell us a little bit about yourself!

I’m an archives student at the UMD iSchool, with one semester of coursework to go. Between college and library school, I spent a lot of time doing various kinds of web work. A lot involved HTML/CSS/PHP, but some involved XML (eXtensible Markup Language) and SQL. I discovered EAD and Archivists’ Toolkit in my first semester of library school and, since then, I’ve been working on learning more about it. Last fall, Molly Schwartz (who just graduated from the iSchool, congrats!) and I presented a paper at MARAC on using Archivists’ Toolkit to learn EAD.

When I have free time, I’m a crafter when I can be, I’m a bit of a geek, and I’m a gamer—Xbox and tabletop. Right now I’m playing through the Mass Effect series to celebrate my summer break. I’m also interested in accessibility for libraries and doing a self-directed summer study on disability and accessibility.

Can you explain for the uninitiated what EAD is?

EAD stands for Encoded Archival Description. It’s an XML schema designed by archivists, for archivists. It’s used to encode or “mark up” data about archival collections, generally for finding aids.

To break this down even further, EAD is a list of XML tags which you can put around information about archival collections. For example, an item about me might be encoded as <persname normal=”Tillman, Ruth” source=”local”>Ruth Tillman</persname>. The tag tells any search system that my name should be handled as Tillman, Ruth, but display systems will show it as Ruth Tillman. It also tells the system that this is a locally-generated name, not from LCSH or some other naming authority.

Once a finding aid is encoded in EAD, a lot of things can be done with it. It can be transformed and displayed as HTML. It can be transformed into PDF. There are a lot of things one can do with XML to extract and transform data from the EAD file into other files. Fortunately, you don’t necessarily have to learn any of this transformation or scripting, unless you specifically want to get into that kind of work.

Is EAD just for archivists? Or do you think it’s something librarians and other metadata professionals should understand as well?

It’s primarily for archivists. I think metadata and systems librarians should not only be aware that it exists, but be aware of the kinds of elements it has and how it approaches description. Archival materials are quite different from most library holdings, which is reflected in EAD. A site like EADiva might be an good place for one to get an overview.

As for non-metadata/systems librarians, I wouldn’t say there’s an especial need.

What prompted you to create this site?

I was working on a paper and some projects to teach myself more about it and became aware of some of the improvements that could be made to the Library of Congress’s EAD tag library. Since no one else was doing it, I did.

Specific improvements I made are: linking to other elements when they’re mentioned (LoC’s tag library has no internal links) and defining Attributes every time they’re mentioned (LoC uses a DTD format—if you don’t know what it means, that’s kind of the point for why I didn’t—and requires one to check one of three pages for attribute definitions). I also tried to write it in a fairly approachable style, but I think the interlinking and attributes were the biggest improvements.

What lessons did you learn from trying to interpret EAD in plain language?

Well, I learned that there are a LOT of tags and that it’s impossible to remember all of them, but that’s ok. I think my biggest takeaway was that EAD really is designed by and for archivists. It’s completely unsuitable for cataloging library books, but it truly reflects the nature of archival materials. It’s not like Dublin Core, which, the longer I studied it, the more dissatisfied I became with it for its purposes (non-archival, I just saw a lot of problems related to displaying different materials types).

I also learned that it’s quite difficult to translate from tech into non-tech. I’ve done my best and I hope people will ask for clarification if something is too technical for them. I’ll make edits as I can to improve the quality of the description. I had to accept, for example, that people will have to know a few very basic things about XML in order to use the site. However, I put together a page about understanding EAD and XML with some of the basics and a link to another description of XML.

Are there any complementary resources you would point new EAD users to?

I’ve linked each element on my site to the Library of Congress’s EAD tag library. I also really suggest their EAD homepage and its links. For people looking for even more context, I recommend the LoC’s EAD best practices page.

I strongly recommend that, as well as looking at the elements themselves, people learning EAD use a program like Archivists’ Toolkit or the upcoming ArchivesSpace. Simply creating a basic finding aid in the Archivists’ Toolkit sandbox (explained further on their site) and then exporting it as EAD can help one see how that information will look when marked up.

Because of the tools available, one rarely has to create one’s own finding aid from scratch. But that doesn’t mean people should just ignore EAD. It just means that we don’t have the memorize it, thank goodness.