The Beast

No, really, we call our homegrown archival management system the “Beast”. It is an Access database launched in the early-mid 2000s. Originally started as the locations register, the database evolved to support the creation of EAD finding aids published on ArchivesUM. A JAVA based conversion program pulls information from the database into EAD elements in a XML file. Files are then checked by hand for XML and EAD compliance before upload to ArchivesUM. You can read all about its creation in “Taming the ‘Beast’: An Archival Management System Based on EAD.“*

At the time, the Beast did some good things. It launched local EAD implementation, got more finding aids online, and consolidated collection information into a central location. It did a great job at facilitating putting up abstracts of new accessions or unprocessed collections.

Over the years the Beast has evolved including development on the conversion scripts, but this has been pretty minimal in terms of new functionality over the past several years. The decision was made to wait for ArchivesSpace instead of making major changes to the Beast.

Here’s a highlight of general issues with the Beast and our associated practices:

  • It was built based on current local policies/practices at the time making its functionality rigid in cases. It was seen as a tool to get away from paper instead of viewing it as a source of reusable data.
  • While staff enter information using forms in Access for either “accessions” or “finding aids”, most of the information is stored in the same table making it difficult on the back end to know what you are looking at.
  • It is clunky and difficult to link multiple accessions with a collection description.
  • Some fields don’t map to the best EAD tag choice (ex: all extent information is dumped into <physdesc> and not <extent>.)
  • For container lists, the Beast/ArchivesUM stylesheet requires that your intellectual and physical order MATCH EXACTLY. This limits flexibility in description and processing at various levels and often requires spending too much time physically moving around materials.
  • Not all finding aids uploaded to ArchivesUM are EAD compliant (they are all XML compliant.) People fell on the side of getting the finding aid up instead of figuring out the EAD error and required changes in the Beast.
  • We did not do a good job at quality control. We just didn’t. We didn’t utlize controlled fields when we could have (ex: linear feet is spelled ten ways) and didn’t enforce adhering to local policies (ex: dates entered in date fields don’t match format of acceptable dates in our processing manual.)

In future posts I’ll share how we are mapping the Beast fields to ArchivesSpace as well as the specific data cleanup issues we are facing.

*Jennie A. Levine, Jennifer Evans, and Amit Kumar, “Taming the “Beast”: An Archival Management System Based on EAD,” Journal of Archival Organization, 4, no. 2 (2007): 63-98. http://dx.doi.org/10.1300/J201v04n03_05

Advertisements

2 thoughts on “The Beast

  1. Just found this, and feel the need to comment/clarify, for what it’s worth. First, I have to say that I cannot wait for the ArchivesSpace to go live at University of Maryland, and the work that Cassie is doing is extremely valuable to moving forward. But as the one of the creators of what has now become “legacy” – there are some other things to add to the picture. I will say that actually, the reusability of the data was very much in our minds. At the time we created the Beast and ArchivesUM, the discussion in archives was very much focused on “EAD vs. HTML” and we had to use the structured data argument to get support for EAD. The goal was that “sometime in the future” putting everything into EAD/Beast would make things easier for a migration into something like ArchivesSpace. However, we were focusing very much on the “tags” and not so much on the content. The Beast also predates DACS and the UMD Libraries’ Processing Manual was developed after the Beast was in full swing. While it’s true that there are a lot of ways data has been entered inconsistently since the Processing Manual was created, by that time, there was a lot of legacy data in the Beast already (as in, retyped from finding aids only available on paper).

    I can also say that initially there was a reason for putting all the accession/finding aid data in one table – we had a dream/goal of having it represent a real workflow somehow. But that never truly worked 😦

    The Beast/ArchivesUM was a fun project, and, as Cassie noted, accomplished a lot at the time. But oh, how I wish that ArchivesSpace had existed in 2001.

  2. Thanks Jennie for adding this! I definitely glossed over much of the planning and background. Imagine where we would be if the Beast never existed? Certainly, in a much worse place than we are right now.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s