Implementing ArchivesSpace at NYPL: Part 1

In 2014, the Archives Unit at The New York Public Library began its evaluation of ArchivesSpace. Following a rigorous review of the application, we began implementation in earnest in 2016, and started using it in production earlier this year. Historically, Special Collections developed its own systems for collection/data management, which could be developed and tailored to suit our needs. As such, moving from a homegrown data management system/model to a community-designed one represented a major shift in how the Library evaluates and implements systems. Instead of being able to build to our wants/needs from the ground up, ArchivesSpace required us to meet the application halfway in its assumptions and practices.

When assessing and implementing ArchivesSpace, we used these questions as guidelines:

•     How can we adapt the tool to meet our existing descriptive practices?
•     How ought we adapt our local practices to meet ArchivesSpace’s expectations?
•     How can we modify the application to expedite minimal processing?
•     How can we integrate ArchivesSpace into our metadata ecosystem?

This post will focus on the first two questions regarding modifications to both ArchivesSpace’s and NYPL’s data models/policies; a follow-up will explore processing changes and integrations.

Adapting ArchivesSpace for Description

ArchivesSpace was developed as the successor to the Archivist’s Toolkit, which was designed in the early 2000s by a consortium of university archives. In contrast, NYPL’s descriptive model evolved internally, and was codified in a locally-developed FileMaker database. As such, the data models instituted in ArchivesSpace and within Special Collections did not align when we began evaluating ArchivesSpace. For example, ArchivesSpace’s EAD XML output takes advantage of little-used attributes such as altrender to store descriptively meaningful data, regardless of the attribute’s intended application. On the other hand, NYPL’s EAD XML is very semantically strict; fields and attributes are applied only if we can put them to their intended documented use.

Furthermore, many practices developed at NYPL had no congruent modeling in ArchivesSpace. In order to accommodate NYPL’s multidivisional descriptive practices, we apply multiple identifiers to collections. This ensures that references to materials stay present even as it moves through different descriptive environments (e.g. a collection with a Dance catalog record getting a finding aid via Special Collections). ArchivesSpace does not handle this use case out-of-the-box, instead only allowing up to one identifier to be applied to a collection/component at a time. 

When approaching these issues, our guiding principle was “how can we make the system work for us?” Our existing descriptive practices had been in place for years, and we built our processes/systems around them. As such, we were not interested in implementing entirely new descriptive models and warping our workflows and infrastructure around them. We decided to develop plugins for ArchivesSpace (code that overrides existing functionality to modify/create behavior) that would extend/modify its data models to meet our local practices. Primarily, this involved modifying ArchivesSpace’s EAD output to match the standard that we developed, and extending its data model to support multiple identifiers for collections/components. We were able to accomplish both, thus laying the semantic groundwork for metadata creation/management in ArchivesSpace.

Adapting Policies to ArchivesSpace

Implementing ArchivesSpace provided us the opportunity to reevaluate our existing descriptive practices. Our local descriptive systems evolved over time, and did not necessarily develop in line with the practices established elsewhere in the archival community. As above, many of ArchivesSpace’s assumptions about description and practice needed to be altered to meet our local needs. However, we also used the opportunity to explore how we could adapt our practices and policies to ArchivesSpace, and how it could improve our processing and data management.

For example, we reevaluted how we manage controlled headings as part of our implementation. Historically, our descriptive systems have treated authorized headings as metadata attached to a collection/item, instead of using an entity-based model. This had ramifications on data management and processing workflows, as headings could not be centrally controlled. As we lacked a centralized authorities resource, managing a local archival name authority was out of the question.

In contrast, ArchivesSpace uses an entity-based authorities model out-of-the-box. This transformation from treating authorities as strings to things required a rethinking of how we create and manage authorities in Special Collections. We developed new policies around creating headings from existing authorities, which now includes providing URIs for names and subjects. ArchivesSpace’s entity-based model also provides the ability to establish locally-generated names as authorized headings (provided that they meet an established standard); we hope to turn these headings into the first-ever local NYPL archival name authority.

In addition to developing policies and practices around the newly-possible, we created a local manual for our instance of ArchivesSpace. This manual serves the dual purpose of providing guidance on using the application and documenting best practices for creating and managing archival descriptions. As policies develop, we will update the manual to reflect the latest developments in ArchivesSpace.