At Yale generally, and especially in my repository, the Beinecke Rare Beinecke Rare Book and Manuscript Library, we take accessioning very seriously. To give you a sense of the investment we make, within the Beinecke’s Manuscript Unit, I lead a staff of four (1 professional [me] and three paraprofessionals) who work exclusively on manuscript accessioning. That doesn’t include our Printed Acquisitions department, which handles all of the published material that we acquire. It is a high volume of material, and we capture a lot of information at the point of accessioning, information that is relied upon and regularly queried by both staff and researchers.
As we began the process of implementing ArchivesSpace at Yale, the accessions module was the first that we reviewed in detail. This was partly because of its importance, but also because it presented an opportunity for me and my colleagues at the Beinecke. In 2012 the Beinecke Manuscript Unit implemented the Archivists’ Toolkit for manuscript accessioning, breaking from the accessioning database that the library had used since 1985 and which is still used by the Printed Acquisitions department today. Although using the AT for manuscript accessioning has been a great improvement for my operation, introducing a second accessioning database has complicated a previously simple situation. [The reasons we didn’t adopt the AT for printed accessioning are beyond the scope of this post, but I’m happy to provide further background to anyone interested.] We hoped that ArchivesSpace would allow us to reunite our accessioning databases and serve as a robust platform for further improvements in our accessioning operation.
In our analysis of ArchivesSpace accessions last winter, we identified a few crucial areas that required further development before we could consider implementing it as a single accessioning database for the Beinecke Library.
- We needed finer control over who could edit accession records in order to better secure our accessions data.
- We needed advanced search functionality in the staff interface (not just the public interface) in order to support sophisticated staff use of accession data.
- We needed to be able to generate a variety of reports specific to accessioning in order to support a wide range of staff use cases.
- We needed to be able to import MARCXML records as accessions (not just as resources) in order to improve the efficiency of our printed accessioning program.
- We needed to be able to import records directly from OCLC WorldCat via their API in order to improve the efficiency of our printed accessioning program.
- We needed to be able to spawn copies of existing accessions in order to improve the efficiency of our printed accessioning program .
- We needed to be able to create accession-to-accession relationships in order to reflect the sibling and part relationships that many of our accessions have to each other.
- We needed to implement a strict scheme for system-generated accession identifiers in order to ensure unique, meaningful identifiers across all repositories.
- We needed to be able to capture complex information documenting payments in order to fully record the financial transactions that generate a majority of our accessions.
- We needed to be able to record “material type” codes in order to migrate data in our current systems and support specific search strategies.
To achieve these goals we contracted with Hudson Molonglo, the firm that built ArchivesSpace, both to make changes to the core application and to develop a series of plugins. [We chose not to undertake work related to reports because of ongoing development by Lyrasis.] We worked with them over several months in the spring and are currently in the midst of further accessioning-related development (simultaneous with container-related development work).
Over the summer we issued pull requests to merge some of our development work into the core ArchivesSpace application. After review by the ArchivesSpace Users Advisory and Technical Advisory Councils, that code was incorporated into the ArchivesSpace 1.1.0 release. The application now includes the ability to set edit permissions separately for each of the major record types (accessions, resources, digital objects), advanced search in the staff interface, the ability to import MARCXML as an accession record, the ability to spawn copies of accessions, and the ability to create accession-to-accession relationships.
We also completed development work on several plugins, all of which are freely available on our committee’s GitHub repo.
- aspace_yale_accessions: This plugin modifies the four-part accession identifier. The first part is restricted to fiscal year (based on the accession date), the second part is a department code selected from an enumerated list, and the third is a system-generated sequential four-digit number for each department and fiscal year. The fourth segment is suppressed.
- extended_advanced_search: This plugin extends the fields available in the staff advanced search to include fields not included in the core application’s advanced search, including some user defined fields and fields created by our material_types and payment_module plugins.
- material_types: This plugin allows us to add Material Type subrecords to our accession records. A Material Type subrecord consists of a set of Boolean check boxes that indicate the presence of certain formats (books, manuscripts, art, maps, games, etc.).
- payments_module: This plugin allows us to add payment information to our accession records. A given accession record can have one Payment Summary subrecord, which can then have zero or more associated Payment records. Together these capture the financial details of our purchased accessions, including price, invoice number, fund code, currency, etc.
During our current round of development we are working on two additional plugins. These are necessary in order for ArchivesSpace to be a viable replacement to our existing database for printed accessions and should be ready early in the new year.
- aspace_oclc: This plugin will allow us to import bibliographic records from WorldCat as accessions in ArchivesSpace. This is accomplished via the WorldCat Metadata API.
- yale_marcxml2accession_extras: This plugin will modify the generic MARCXML > accession import mapping created for the core application, extending it to accommodate our local needs.
We have additional development goals related to accessions in ArchivesSpace, but our work to date addresses most of the requirements we identified as critical to resolve before migrating our production accessioning databases to ArchivesSpace. I’m happy to discuss any of this work in further detail, either in the comments or elsewhere.
