Do you use Android or Apple for your electronic ecosystem? When upgrading to a smart phone, I had a difficult time choosing which environment to virtually live in. I own a Mac, but use an IBM at work. I love the design and utility of Apple products, but use my Google account as if it were my personal assistant. My thinking was: If I am going to invest my time and money in this electronic world, I want to make sure what I get makes sense with all the other electronic stuff that I use on a daily basis, so that it’s useful and productive instead of time-consuming and frustrating. I’m an Android … I mean, I own an Android (a couple, actually). But the decision wasn’t obvious or easy to come by. Mainly because neither would have been a bad choice. (Sorry, Windows, you never made the running).
This is similar to the way we felt here at the AMNH Library about ArchivesSpace and AtoM. The two are solidly comparable content management systems for archives, but different flavors. In testing, they both met our basic requirements for creating, managing, and publishing finding aids; they just handled them differently. In terms of cost-efficiency, both are open-source applications freely available to use, but support and/or customization have a price tag. We preferred the look and feel of AtoM over ArchivesSpace, but ASpace was easier to navigate and made sense to those of us who were already familiar with Archivists’ Toolkit. AtoM was developed by Artefactual Systems (also behind Archivematica and Binder); ArchivesSpace boasts a large U.S. membership base whose many charter members include the Smithsonian, Yale, Harvard, and NYPL. Are you following me on this see-saw?
Well, the devil is in the details, as they say. And as the Metadata Analyst on this project, I was very eager to investigate the details behind the details. We chose ArchivesSpace for those who wish to skip the rest.
Based in Vancouver, AtoM was originally built on the compliance to international standards, specifically the General International Standard Archival Description ISAD(G) and Rules for Archival Description (RAD). In fact, AtoM was initially developed as the International Council on Archives “Access to Memory” (ICA-AtoM). You can read more in Jessica Bushey’s documentation of the project: https://www.ica-atom.org/download/ICA-AtoM_JBushey.pdf
As the merger of the two widely used open-source applications for finding aids, Archon and Archivists’ Toolkit, ArchivesSpace supports Encoded Archival Description (EAD). For those of you reading from the U.S., I don’t have to tell you that this is THE standard for encoding finding aids! The EAD tag library is hosted by the Library of Congress, and the standard is endorsed by the Society of American Archivists. We have had some discussions about the global network of data and the importance of adopting international standards, but in the end we agreed that it was necessary to engage with our community of users and professional groups.
So, support for EAD was a heavy factor in considering which system to choose. While ISAD(G) maps well to EAD, we did notice some gaps in AtoM for some elements of description. Here are some EAD fields that are not supported by AtoM:
- Abstract
- Dimensions
- File Plan
- Index
- Legal Status
- Materials Specific Details
- Physical Facet
- Preferred Citation*
- Separated Materials*
Would our finding aids suffer obscurity without these specific tags? Absolutely not. We could roll up <abstract> into the <scopeandcontents>, but why should we when ArchivesSpace has a place for it? None of the above fields are deal breakers when encoding finding aids – we absolutely need Title, Creator, Dates, Extent. However, our in-house finding aid template uses at least two elements from the above* so these gaps would make an impact on our current workflow. AtoM could be customized to fully support EAD, at a cost. ArchivesSpace fully supports EAD out-of-the-box. A point for ASpace!
Importing EAD-encoded finding aids into a non-native EAD environment, AtoM, revealed another noteworthy detail. Last year, Bill Levay and I tested AtoM 2.1.0. Aside from some general EAD import issues we had with an earlier release, <ead:titleproper> did not map to the Title field in AtoM. Ingested xml files were labeled “Untitled”. Other EAD data that got dropped upon import were Extent and Scope and Content. Skimming the issue lists on AtoM’s website, it appears that later releases may have resolved EAD mapping problems. I hope that version 2.3.0 has better support for EAD imports, because now we’re in deal breaker territory.
Our EAD finding aids are created by Archivists’ Toolkit. Importing EAD xml into AT’s successor, ArchivesSpace, was fairly straightforward. Besides some duplication of names, we found that our data landed more or less where we expected it to be. Using the plugin to migrate our AT data into ASpace proved to be the best way to ingest our finding aid data. Another point for ArchivesSpace.
Coming out of the metadata, there were some other differences that we observed in the AtoM environment. And perhaps it is a detail that is closely tied, again, to EAD. Because EAD is hierarchical in its structure, we tend to see the finding aid data as a single parent unit (collection information) containing children (sub)units (series, folder and item information). Children can have siblings (other subunits) or children (subsubunits) up to twelve levels.
At the top of this finding aid tree there is a general description of the collection as a whole.
In ArchivesSpace, the default view of finding aids, called Resource records, is a list of the top-level descriptions, collection information. In AtoM, the default view of its Archival Descriptions in the database is listed as equally weighted units of description: records for folders or items (even digital objects) will appear alongside collection-level records. There are several ways to facet the information, but you have to specify the parameters from a number of choices.
And, perhaps because AtoM sees all resource descriptions as equal, the system requires the following elements for each component to a finding aid:
- Identifier
- Title
- Dates
- Extent
- Creator
- Scope and Content
- Name and location of repository
Screen shot of a component file in AtoM. The pink box located under the title indicates mandatory elements that need data.
While not an exhaustive set of mandatory fields, it does overlap with some data that can be described at a higher level and we certainly do not require many of these fields for children components. On the other hand, in a digital environment where pieces of information can be aggregated and reassembled easily there could be great value in seeing pieces of finding aids as complete self-describing units. But my archivist senses tingle at the idea of context lost: respect des fonds. Even the order in which files are kept have meaning. The layout of finding aids in AtoM gives me some pause, though it does seem to point to a future where the user is driving the organization of information, which is exciting to think about!
Speaking of files, container lists were also treated a little differently in AtoM. Rather than storing the container information with the finding aid, the data is linked to a separate table called Locations. Box and folder information is input separately as a link to physical storage.
Container information links to an external table under Locations. To input this data, the user must click on “More” to find “Link physical storage”.
Container “links” are created using the table above. Data appears with the finding aid on the right-hand sidebar under a heading called “Physical storage” (you can see an example of this in a previous screen shot).
Again, this felt detached from the finding aid as a complete whole. Box and folder numbers, while they may not give context, do allow you to locate materials within a finding aid. These numbers are incidental, yet are relative to the collection at hand. Adding this data outside of the component it is describing felt unsettling because those numbers on their own hold no value without the thing it’s referencing. And if we found a meaningful use for the AtoM Locations table, it would be filled with non-descript digits.
In contrast container information in ArchivesSpace can be entered along with other data for the child component (or Archival Object). Box and folder numbers can be input under Instances. Locations can also be added to the instance.
In ArchivesSpace, container information is listed within the Archival Object under Instances.
Expanding the collection record, highlighted in blue above, displays the children components along with their respective box and folder numbers.
When considering the best system for supporting EAD-encoded finding aids, ArchivesSpace was the clear winner. Though AtoM handled EAD pretty well for an application that was not built for the standard, there were enough differences in the system landscape that we would require a shift in the way we think about and handle finding aids. If the AMNH Library is going to invest time and energy transitioning into a new system for archives, we want to make sure what we implement makes sense with all the other finding aids and descriptive tools we already have, so that it’s useful and productive instead of time-consuming and frustrating.
If you’re interested in seeing how these systems did against our functional requirements, visit the Process page on our site. There a few reports listed under “Data Management”.
I realize that I have not said a peep about EAC-CPF support because neither ArchivesSpace nor AtoM came close to what we need for our rich descriptive entity records. For that we turn to xEAC. I’ll fill you in on the next blog post!
