I thought it would be helpful to spend a minute looking at our data before we dive into mapping Beast fields to ArchivesSpace.
I’ll note that while I refer to the Beast database, we actually have three separate Beast databases. This was due to size and performance issues as well as the department and unit structure of the Libraries (which has since changed). While the three databases share the same table and relationship structure, often the data entry practices and habits varied between them, including adherence (or not) to our local requirements and national content standards, such as DACS.
Here’s a screenshot of the database structure:
Fun, right? The meat of our information is stored in the archdescid table with an auto generated primary key of archdescid. This field ties all of our tables together. If you are familiar with EAD some of the field names will look familiar (unitid, abstract). Other fields tie information to other UMD systems (pid) or unit structure (corpname).
You will also notice that similar types of EAD information are not clustered together. So, we have EAD publication information stored in its own table, yet the <address> for the repository, which appears in <publicationstmt> is stored in the archdescid table. In current practice, this does not matter as we apply a converter script to create the EAD. From a trying to understand how this data interacts with each other perspective it has me scratching my head as to why we did not store like information together.
In upcoming posts we’ll talk about how this information can map to ArchivesSpace accession records.