Once again, the Mid-Atlantic Regional Archives Conference (MARAC) delivered big conference value. Probably the biggest bang for the buck for me was the Encoded Archival Description (EAD) Workshop on Thursday.
For my non-archivist friends and family who read this blog, here is a quick overview (archivists, feel free to scroll down to Workshop). Because archivists want potential visitors and researchers to easily find and use our collections, we write documents called finding aids and put them on the Internet. (We also publicize collections by launching exhibits, press releases, and other outreach efforts, but for now, let's just stick with the topic at hand.)
Finding aids can hold a little or a lot of information. It all depends on the cultural heritage institution's preference. But to offer the same types of information categories across the board, we follow a set of standards called "Describing Archives: A Content Standard" (DACS -- rhymes with quacks).
Because we put our finding aids online, we have the option of adding more information and/or making edits later. This flexibility provides a good argument for entering the minimal amount of information required by DACS into a finding aid and throwing it up on the web, even if we haven't processed the entire collection yet. That way, folks can find the repository that has the historical information they need and use it. Otherwise, some backlogged collections could take years to process, and no one would know they even exist (happens all the time, sadly). That brings up the topic of "More Product, Less Process," but I'll just give you a link to the original piece and you can read about that at your leisure.
[In practice, I prefer to give a substantial amount of information in my finding aids. I want to give the researcher a leg up on his/her work by providing a good historical foundation for the collection as well as descriptions of each series in the collection. This way, when the researcher goes to look into a given folder or box, he/she will know what else there is nearby that might fit into his/her work. They might not have the time to fish around for it otherwise.
I also like to provide links to related materials elsewhere in the repository. For an example, at Rutgers, I processed a box of materials from an administrator who served during the late 1800s through the early 1900s (until he died, slaving away at his desk). When I wrote my finding aid, I researched his biographical history and found that he never left the place since entering as an undergraduate. Rutgers keeps files on students, and I was able to locate this administrator's undergrad box, which held all kinds of interesting items, including a number of photographs of him through the years. I also found his obituary describing his dedication to his students and death at his desk. I believe it to be true because he corresponded with every single student and potential student during his tenure. He was a very busy man.]
One last, very important piece on EAD before I start in on the Workshop -- EAD is a markup language based on XML (extensible markup language). XML code works on the premise that content is separate from structure and appearance. It's very flexible and allows the user to change how information appears without changing the actual content. It also allows users to easily make different versions of a document by applying different style sheets. Style sheets decode the XML to display the document on the web.
EAD has its own set of elements and attributes that specify the characteristics of a document. These characteristics are based on recognizable standards, and there are a lot of organizations that have made public their style sheets for others to use (awfully kind of them). OK, on to the workshop!
Now that you have a little background, I can tell you about the workshop given by the very knowledgeable and helpful Michele Combs, from Syracuse University. Prior to the day-long class, I had used EAD, but had never taken a course on it. So, I was counting on this introductory workshop to provide me with a good working knowledge of the basics. I was not disappointed. In fact, Michele said that SAA typically covers the same material in a two-day workshop (for a LOT more $$$).
Michele and Dale Patterson (archivist at the United Methodist Church Archives in Madison, NJ) provided us with software (XML and text editors) and an array of handy files to use in the workshop and afterward. Via PowerPoint slides, she gave us a good background on EAD and XML. She also explained how to use the code correctly, since there are a number of ways to make errors (although the XML editor, oXygen, showed us immediately where and how we went wrong).
There were around 35 people in the class, and most had no experience with EAD. At times, the class was slowed by individual class members' technical challenges, but we thoroughly covered all the ground in the agenda and had time for lots of questions.
Michele talked a bit about the standards to use with EAD and why it is very important to use them. What I found out later, when I sat in on the NY Caucus meeting, was that she's working with a few other EAD pros to create a consortium of organizations that will put all their EAD finding aids in one spot so that they are easily locatable and searchable by potential users. The idea is based on the Online Archive of California (definitely check it out). All these organizations need to apply the same standards to their EAD documents to make the search functions and style sheets work correctly on each.
Michele also explained how EAD documents are divided into two main sections, the "header" and the "archdesc." Because so much of the information we deal with as archivists and librarians is specific to the repository, the top section of the EAD document is dedicated to the finding aid itself, and not the collection. That portion is the header. It contains specific codes for the repository and descriptive and identifying information about the finding aid (names, dates, creator, etc.). This portion of the finding aid usually is invisible to the public, but provides valuable information to someone working with the document on the back end.
The other section, the archdesc, is further divided into two parts:
1. did = the description of the collection as a whole
2. dsc = the actual inventory (boxes, folders, etc.)
Here's one example of the did portion of a finding aid, as displayed online: The Plainfield Garden Club Finding Aid (I reprocessed the collection, but did not write the finding aid). So, from the top all the way down to the Container Listing is the did. After that, it's all dsc.
Mind you, many organizations do not go into as much detail as we did in the inventory. Here's an example of a short, but sweet finding aid with a pretty nifty style sheet: Alice Gold and Silver Mine Records. It fulfills many of the DACS requirements, but does it in a minimalist way.
In the workshop, we worked off our own finding aids to enter content into a template Michele provided. She also gave us a style sheet that unfortunately didn't include some of the elements I had in my finding aid. As the class went on, I wished more and more that we had another workshop on style sheets. It seemed that the answer to many of my questions revolved around them and other things we wouldn't be covering in the introductory course.
Because he was sitting to my right, I was able to ask Dale quite a few questions. He was very helpful and pointed me to the EAD Cookbook, where I could learn more about the more advanced stuff. Now I just need to carve out some time to apply what I've learned.
Some folks had difficulty with the inventory section, but since it was hierarchically based, I could follow the code pretty well. I liked using oXygen because it made it so much easier than coding by hand. The templates and style sheets were already entered into the software, so we just needed to apply the elements and attributes to our content. We also were able to open "working document" versions of our EAD files within our browsers. This way, we could track our progress each time we saved a new change to the document. Talk about instant gratification!
Overall, this workshop exceeded my expectations. Michele and Dale did an excellent job making EAD easy to understand and apply. I now feel a lot more comfortable noodling around with EAD and look forward to learning more about this very useful way of making collections more accessible.