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