I would like to add a quick note that the database tool that we have
produced is a direct outgrowth of our digital imaging projects, and not
primarily a tool for creating finding aids.  As those who have used it can
attest, the database can do an awful lot, and can produce an extremely
flexible structure.  However, this is just as dangerous as it is useful,
and the database has a pretty high learning curve.  As you can imagine, it
does best at producing container lists; the Access database that we use at
Berkeley does not have the facility to produce front matter for finding
aids at all (but I believe that the Filemaker database does).  What the
database excels at is helping us to record a wide variety of descriptive
data in addition to all of the workflow and metadata related to digital
imaging and TEI transcriptions and linking it all up in the end.  The
database has been written to help us with a number of projects, and not
just those related to EAD.  To complicate things further, in our digital
imaging projects, we are attempting to describe things at the item level
(since we digitize at the item level) and are grappling with how to
describe items, and how that item level description fits into EAD.

This database is not ready for primetime; at Berkeley, for a number of
projects with varied descriptive data, we are still largely extracting EAD
from the database with customized Visual Basic routines, so it is not to
the point of pushing a button and letting the machine go to work.  We are
using the database on all of our digital imaging projects, which is a huge
improvement over having a customized database for each new project, and
this is a big plus.  I'm sure that it will all get better over time, but
right now we are still in the baby steps stage.

I ain't no archivist, but I will echo Bill's comments that valid EAD is not
the hardest part; the hardest part is creating good, consistent
description, especially in multi-institutional grant funded projects with
significant time and funding constraints! I gave a presentation on this
database and the MOA2 project at SAA two years ago.  While the database has
gotten a lot better between now and then, we still have a ways to go,
especially in learning how to effectively and consistently use it.


Merrilee

Merrilee Proffitt
Director of Digital Archives Development
The Bancroft Library
UC Berkeley

At 02:35 PM 1/12/01 -0800, you wrote:
>Jerome McDonough wrote:
>
>> A database which can produce valid EAD is actually not as hard as you might
>> think.
>
>This has been a really interesting discussion and I, for one, continually
more about a variety of technical solutions for encoding from the postings
on this list.
>
>I did want, though, to comment on the quote above. Producing *valid* EAD
isn't the only issue. You can actually get a valid EAD instance without any
recursion at all, since the DTD only requires, apart from some <eadheader>
subelements,  that you use an <archdesc> with the LEVEL attribute set, one
nested <did>, and nothing else. I'm sure Jerome wasn't referring to
anything quite this simple in the quote above, but I think it is equally
important to pay as much attention to standards-based archival description
that will facilitate useful searches, retrieval, and presentation to end
users, especially in multi-intitutional system environments.  Speaking for
myself only, I'd say that the best database in the world used without
attention to the quality of the descriptive data being encoded and the
standards that went into formulating that data will only produce EAD
instances that probably aren't worth the effort that went into their creation.
>
>--
>   Bill Landis
>Manuscripts Librarian, Special Collections and Archives
>The UCI Libraries, University of California
>P.O. Box 19557, Irvine, CA 92623-9557
>949 824.3113 [824.2472 FAX]
>[log in to unmask]
>
>