Print

Print


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
methods.

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
http://www.aaa.si.edu/collectionsonline.

My main point is that there are many more reasons than simple
interoperability or search-ability that make EAD such a compelling
technology.

Regards,
Toby 
 
---
Toby Reiter
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?
> 
> 
> 
> Orn,
> 
> 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.
> 
> Thanks,
> 
> Chris
> 
> --
> 
> 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.
>> 
>> 
>> 
>> Yours,
>> 
>> 
>> 
>> Írn Hrafnkelsson
>> 
>> 
>> 
>> National and University Library of Iceland
>> 
>> Manuscript Department
>> 
>>