I want to preface my comment by saying that I'm a computer developer that
works at an archive -- so I have a specific bias towards information
technology, and I don't have formal training in library science or archival
The archive where I work (Archives of American Art) has used EAD for several
years now, and in addition to providing interoperability with RLG, we have
found using EAD-based finding aids to be enormously useful for our own needs
within the Archives.
In my mind, the most useful feature of EAD is it provides a standard format
for organizing the *content* of a finding aid. If you create finding aids
using Microsoft Word, or PDF, or HTML, you've tied the content of the
finding aid -- it's series, folder headings and other descriptive data -- to
the way in which it's *displayed*. If you decided in the future that you
needed to move a finding aid from PDF format to HTML format, or vice versa,
you would be hard pressed to do so (particularly if you needed to convert a
hundred finding aids). With an EAD-based finding aid, it's very easy to
generate an HTML version, a PDF version, or even a Microsoft Word compatible
version, all from the same XML.
This is based on a very fundamental idea in computer programming: separating
content from presentation. By having the important content of your finding
aid stored in a flexible format -- EAD XML -- it becomes much easier to
create multiple presentations.
Here at the Archives, we took this one step further by pulling data directly
from our EAD finding aids and putting it into a database to support our
collection digitization process. Each collection has its own mini-site, and
(almost) all of the content on that site is driven directly from the data
encoded in the finding aid. You can see this at
My main point is that there are many more reasons than simple
interoperability or search-ability that make EAD such a compelling
Information Technology Specialist
Archives of American Art
On 3/16/07 8:53 AM, "Kristi Warab" <[log in to unmask]> wrote:
> I was recently wondering the same thing. We reorganized our archival
> collection in a format that would allow for easy EAD mark up sometime in the
> near future. However, we never did get around to the mark up part. Our goal
> was to have our documents findable on the web. We posted our finding aids in
> PDF format to our website, and when I searched the web, I did find our
> documents. Of course, this might depend on what search engine you use. I do
> know that google makes PDFs searchable.
> Kristi Warab
> Technical Services Librarian
> Wheelock College
> 132 The Riverway
> Boston, MA 02215
> Phone: 617-879-2221
> Fax: 617-879-2408
> From: Encoded Archival Description List on behalf of Chris Prom
> Sent: Thu 3/1/2007 10:01 AM
> To: [log in to unmask]
> Subject: Re: Way EAD_XML?
> I don't know if you remember me, but we met at the ICA meeting in
> Iceland last year. Really enjoyable time.
> In any case, my personal opinion is that the only real reason to
> have an EAD/XML instance at this point is for interoperability,
> in other words, if you wish to share with other systems. That,
> however, is a VERY compelling reason, at least for me.
> From the end user's point of view, EAD is meaningless, except to
> the extent it may make the collection more accessible outside of
> the local context. For example, if you wish to share your
> National and University Library descriptive it with other systems
> or international consortia, you can probably get it into EAD
> format pretty easily from your SQL source, then send those files
> to whoever is responsible for the project.
> In the Archon database system that we set up at University of
> Illinois, we run the SQL source into both HTML and EAD using PHP
> scripts. This works perfectly fine--the differences between the
> two scripts are relatively trivial and if you tech staff has a
> script to do html output, they should be able to tweak it for ead
> output with relatively minimal fuss, as long as you can provide
> them very specific directions and tweak the output to make sure
> it is well formed and valid. (As an aside, I have found it A LOT
> easier and more compact to write a PHP script than it is to
> monkey around with a verbose or complex XSLT sytlesheet).
> If you have any interest in seeing how our scripts work, you can
> download the archon application from www.archon.org. After you
> have it installed, look in the templates/ead folder. Or if you do
> not wish to do that, I can share the relevant PHP scripts with
> you off list. One caveat about our EAD script: there is a slight
> bug in the current release, which prevents the output of certain
> fields in the <c0x> levles, this has already been fixed in our
> source code and will be corrected in the next release of our
> software, scheduled for Late April or early May.
> Christopher J. Prom
> Assistant University Archivist
> University of Illinois Archives
> 19 Library
> 1408 W. Gregory Dr.
> Urbana, IL 61801
> phone: 217.333.0798
> fax: 217.333.2868
> e-mail: [log in to unmask]
> web: http://web.library.uiuc.edu/ahx
> On Thu, 1 Mar 2007, [iso-8859-1] Írn Hrafnkelsson wrote:
>> Dear list members
>> I was wondering if some one out there could help me.
>> We in the National and University Library of Iceland, Manuscript Department,
>> have built an in-house SQL database for describing and cataloguing our
>> private and personal archives. And now we are in the process of making our
>> finding aids in EAD style for each collection for web display.
>> My coworker, from the IT department, says that there is no need for making
>> EAD_XML documents at this point. He says: We have no need for them and can
>> just make them later. It is just enough to have them in HTML to display on
>> the web.
>> So the questions are
>> 1. Way to make the EAD documents in XML, is there some need for that?
>> 2. We have all the information in our SQL database and can make HTML
>> documents for each collection, is that not enough?
>> 3. Is it of any good for the user to have access to the XML document
>> 4. Is not just for you archivist and manuscripts people to have the
>> documents in XML
>> With hope for some answers and maybe you could direct me to some papers or
>> documents with some answers.
>> Írn Hrafnkelsson
>> National and University Library of Iceland
>> Manuscript Department