Print

Print


At 12:22 PM 1/12/01 -0600, Chris Prom wrote:
>Back in September, Richard Reinhart announced a tool in Filemaker which
>will produce valid EAD/SGML for the MOA2 project, and noted that Berkely
>had developed a similar tool for Microsoft Access.  Can someone on the
>list shed light on the status of that Access tool or the testing of
>the Filemaker tool? Has anyone else on the list attempted the Herculean
>task of creating a relational database that can produce valid EAD?

I wrote the original code for EAD generation from the Access database used
at Berkeley, with the database itself implemented
by John Hassan of Berkeley Lib. Systems Office.  As far as I know, the code
has been updated to conform with revisions to the database structure and is
still in use at Berkeley for a variety of projects.  Merrilee Proffit would
be the person
for more details, as she was the project manager in charge of the MOA2 project
which created the database/EAD export system originally.

A database which can produce valid EAD is actually not as hard as you might
think.
There are two major tricks: 1. you have to encode a hierarchical structure
within the
RDBMS; and 2. you have to implement a great deal of nasty, recursive
functions in
your code to produce the nesting box/folder lists.  John Hassan solved the
first
problem in the database by using a single table which encoded a tree structure
with some minimal descriptive metadata (and pointers to other metadata
elsewhere)
captured for each node in the tree, and with each node recording the table
ID number
for the record for its parent node.  The root node for a tree had the field
for its
parent node set to null.  So, you could have a table record for the
collection with a
parent node value of null, one or more records for series, with a parent
node value
pointing to the record for the collection, one or more records for files
for each series,
with their parent node value pointing to the proper record in the table for
that series, etc.
With that in place, producing the list is just a matter of writing the code
to do a recursive
traversal of the tree; you grab the record for the root node, then use SQL
to query for child records that
have a parent node value that points to the root record, then for each of
those you look
for children, etc., etc. until you hit a leaf node.

You *can* do this without using recursion if you're willing to write some
very long code
and limit the number of possible child levels.  But recursion is a lot
easier to maintain
in the long run, I think.

For the geek-inclined, the I started doing this in Visual Basic, and
migrated the whole
thing to Java later.  And no, recursive code written in Visual Basic is not
particular
quick, and you'd be better off using something else, but at the time I
wrote the program,
none of the JDBC/ODBC bridges would work successfully with Access.  The
Java version
I produced still needed some work, and I don't know if it's been brought up
to date with
the new versions of the Berkeley DB, but the basics of producing
<eadheader>, <frontmatter>,
<archdesc> and associated subsections were all in place, along with a very
minimal
front end to show collections/moa2 objects resided in the database, and to
allow you to
generate EAD/MOA2 files for those objects.







Jerome McDonough
[log in to unmask]
Digital Library Development Team Leader
Elmer Holmes Bobst Library, New York University
70 Washington Square South
New York, NY 10012
(212) 998-2425