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