Category: What ArchivesSpace Does

Movin’ Around with Reorder Mode in Archives Space 2.2.0

Yale will be soon upgrading PROD to version 2.2.0. This is quite exciting as this is the foundation for our migration from YFAD to the Public User Interface. It also has some updates on commonly used features. I wanted to talk about one in particular—Reorder Mode. If you want to get a head start on learning how this feature works in version 2.2.0, you can try it out in our TEST instance of ArchivesSpace, which has already been upgraded.

Currently in PROD and in older versions of ArchivesSpace, if one needs to reorder their resource record, it was done using drag-and-drop techniques in the tree. One clicked and held the record and dragged it to where they wanted it in the tree. If it’s at the same level as where it previously was, just in a different place, you would hold it between the ‘sibling’ components where you wanted it; if it’s supposed to be a child of a currently sibling component, you can drop it ‘on top’ of the sibling component. A small arrow would should where it was placed in the hierarchy, and a green check box would appear if ArchivesSpace recognized it as a legal move. Let’s look at some screenshots to make that word soup clearer.

Here is a snippet from HVT-0036’s tree, which is in its original order, from PROD.

Here’s me moving the Restoration submaster component to become the sibling between Duplicate and Restoration master. Note the small black arrow between the Duplicate and Restoration master components showing where I’m placing it and the green checkmark by the floating Restoration submaster component (Ghost component?)

And we have the sibling in place!

Now I’m moving the Restoration submaster component to become a child of the Restoration master. I have moved it so it’s on top on the Restoration master—you can see the black arrow resting on the same line of the Restoration master in the tree. Green checkmark of the ghost component shows we’re ready to go.

 

And we now have a child. Please note that if there were other children of the Restoration master component, it would have ended up on the top of the list if that branch of the tree was not open. If the tree was open so you could see the children, you would be able to drag between its soon-to-be siblings.

While this is not unintuitive, it also sets up users for errors. One can accidentally reorder things without trying to since the tree is always open and the ability to reorder is always ‘on.’ The precision of the dragging and dropping is also not always easy to handle. It’s not uncommon when moving a component elsewhere on the same hierarchical level to accidentally make it a child of a would-be sibling, and vice versa.

Therefore, ArchivesSpace has a new feature- Reorder Mode.

Let’s take a look at HVT-0036, this time in TEST.

The tree looks bigger and has larger markings to denote the ‘line’ of the component. Also, there is a new button, which I outlined in red, titled “Enable Reorder Mode.” If I try to move anything without that button being clicked, nothing’s going to happen with the tree, except maybe opening the component below the tree to edit. So, what do I do to move my Restoration submaster?

First, I’m clicking on the button. This turns the button green and changes the label to “Reorder Mode Active.” It also shows two new buttons: cut, which I outlined in green, and paste, which I outlined in purple. The record view below also disappears below the tree.

I can simply move the component by hovering the cursor (which has turned into a four-direction symbol) over the appropriate white box with gray dots to the far left of the component, clicking, and dragging and dropping it. After I move the component to where I want to, a new dropdown appears, asking me where exactly I want to put it. Since I want the Restoration submaster to come before the Restoration master, I’m clicking “Add Items Before.”

It’s now where I want it.

 

You can also move multiple components this way! If you click on the white boxes with the gray dots to the far left of the tree while holding the CTRL key on your keyboard, the boxes will turn blue, and numbers will appear to show the order it will be in when you start dragging the components. (i.e. 1 means the first component in the list, 2 is the second, etc.) This has the bonus possibility of changing the order of a level of an inventory on the fly by changing how you click the components.

So here I have selected these three components to move. I want the order to be Restoration master, Master, and Use copy.

 

At this point, I am dragging the components. ArchivesSpace is kind enough to list the order for me so I know how it’s being moved.

Like with a single component, it will ask me to select whether these components are to be added before a selected component (in this case, Duplicate), after the selected component, or as children of the component. I selected children and they are now children of Duplicate.

Another way to move a component, if you are concerned about not being able to drag it where you want it due to mouse issues or the like, is to click on the name of the component. ASpace will outline it in blue and a move button, which I outlined in orange, will appear.

Clicking on the Move drop down will show the choice to move the component up, down, or down into, meaning within a component as a child. Hovering the cursor over the down into option will open a new drop down to show you where you could possibly put the component.

Since I want this component to be a child of the Restoration master component, I will select that option. It then moves where I want it to be.

Please note that the move button does not work with moving multiple components. If you want to move several components at the same time, you’ll have to try another method.

A final way to move a component, which can be incredibly handy for extremely long inventories, is using cut and paste. This is best done when you want a component to become a child of another component rather than a sibling elsewhere on the list. There is a workaround to use cut and paste for creating siblings, although it’s not ideal. But I will cover that too.

Let’s say I want to make the Duplicate a child of the Master component. First, I select it so it’s outlined in blue. Then I will click Cut. The Cut button will turn gray and the component bar will turn a darker shade of gray.

Then I select the component that will become the new parent, Master. IMPORTANT: you need to click directly on the link, i.e. on “Master.” Simply clicking on the box will not work! The Master component will turn blue.

Click Paste. It will turn gray and the screen will display a loading wheel. Then the child will appear where you selected it, and the Paste button will gray out.

Cut and paste also works for multiple components—again, you select all the components you need to move while holding the CTRL key before clicking cut and going to the new parent. But what if you have an extremely long inventory and you want to make the component a sibling?

Follow the directions for cutting and pasting. When you paste, however, you want to make this component a child of the component directly above or below where you ultimately want to move the original component.

In this case, I wanted Digital copy to be a sibling between Licensing copy and Master. So now that I made Digital copy a child of Master, I can drag and drop it above Master.

Final note/warning: while it is tempting to just go, “hey, let me use the move function,” using it to tell it to go up a level will move the component to the top of the inventory. This is likely what you don’t want to do.

While this is a bit of a change, it does allow for more reliability of reordering and I hope this tutorial is helpful for you! For those who prefer watching this in action, I will be posting a screencast next week explaining all of these methods.

 

 

Meeting User Needs via Improvements to the ArchivesSpace Public User Interface

Hello, everyone! This is Alison Clemens, archivist at Manuscripts & Archives, member of the Yale Archival Management Systems Committee, and team leader of the ArchivesSpace Public User Interface (PUI) Settings & Enhancements Workgroup. Our workgroup is charged with reviewing and documenting any default changes we might want to make to the public user interface, and collecting and maintaining a list of possible future interface changes and enhancements. I’m pleased to give you an overview of some of our workgroup’s initial planning as we prepare to implement the ArchivesSpace PUI here at Yale.

Before I dive into our workgroup’s goals and progress, I’d like to emphasize that lots of behind-the-scenes data cleanup and enhancement work has been and will be instrumental in making the project successful. For example, we did a big project to clean up our people, organization, and subject records in ArchivesSpace, and we literally exorcised some ghosts in the process (no, really — did you know that the Library of Congress Name Authority File includes spirits?). But our ongoing data work will be the subject of a future blog post.

This post will focus on our shared raison d’être: our users, and ensuring that we are providing the best possible services and platforms to meet their needs. I’ll note here that as we consider how to serve our users, we’re thinking about both external users (i.e. patrons) and internal users (i.e. library staff).

Yale’s special collections comprise a fairly large data universe, and figuring out how best to serve the diverse user constituencies of our 10 campus repositories is a challenge. We’re lucky, though, that we’ve got a good team on the case. Our workgroup members include: Stephanie Bredbenner, Processing Archivist at Beinecke Library; Anna Franz, Assistant Head of Access Services at Beinecke Library; and Jonathan Manton, Music Librarian for Access Services at the Music Library. Each of us brings specific skills and perspectives to our work, and we share a focus on taking a user-centered approach to figuring out how to determine and prioritize settings and enhancements for the new PUI.

I’ll pause here to talk a little bit about the logistics of how we’re accomplishing our work. We’re using four platforms to communicate and coordinate: Google Drive, Asana, Slack, and in person and virtual meetings. These tools are invaluable to us as a workgroup, and especially to us as a larger team — there are 30 team members, working from a variety of physical locations, involved in the six workgroups that comprise the PUI project, and communicating about dispersed goals and tasks with a group of that size is a challenge. Fortunately, our virtual communication platforms have made this process easier to manage. We’re also providing ample opportunity for in-person communication via regular workgroup meetings, biweekly workgroup leaders meetings, and monthly open forums.

Now, back to the workgroup’s goals and tasks. Given our desire to put the user first, we naturally concluded that much of our work depends on the data gathered by the Usability & Accessibility (U&A) Workgroup. Although our workgroup members certainly have a sense of user needs, we want to be sure that we take every opportunity to actually hear directly from users about their needs and preferences. Working closely with the U&A Workgroup is instrumental in assuring that we’re successful in doing so.

The activities of the U&A Workgroup will be the focus of a future blog post, but in the meantime, I’ll mention that the U&A Workgroup has already conducted about a dozen user interviews with user constituencies and is in the process of designing and conducting user testing.

This brings us to the PUI Settings & Enhancements Workgroup’s starting point.

Essentially, our job is to take the out-of-the-box PUI (see screenshot below) and turn it into something that’s as responsive as possible to user needs. In order to do this, we revisited the Before Action Review (discussed by Melissa in our last blog post) and considered what we were trying to accomplish, what we thought would change, and how we might know we were successful. In this discussion, we agreed that the two most essential goals for our workgroup are to improve user experience (as demonstrated through metrics provided by the U&A Workgroup) and ensure broad and thoughtful staff input and buy-in.

Screenshot of the Yale ArchivesSpace PUI, titled “ArchivesSpace at Yale DEV INSTANCE,” with a search box and an upper navigation menu with "Repositories," "Collections," "Digital Objects," "Unprocessed Material," "Subjects," "Names," "Classifications," and a small magnifying glass listed as navigation options.
Screenshot of the out-of-the-box Yale ArchivesSpace PUI

To accomplish our goals, we’ve done a few things (so far, and more to come).

Our first task was to address some of the most obvious issues with the current PUI. We’ve discussed a lot of potential improvements, but two general categories of changes have risen to the top. First, we’ve identified some basic improvements we might like to make to the front page. Most of these things are small improvements to make the page clearer and more intuitive; we’re waiting for the U&A Workgroup user testing feedback before we ask for more major changes. We have, though, been examining some other examples of finding aid databases to see what features and framings we like (shoutout to the New York Public Library!), and we’re looking forward to digging more into how to make the PUI’s front page more compelling and user-friendly.

Our second task was to figure out how to address issues with search relevance. Relevance ranking in search results is a known issue in the ASpace PUI, and we wanted to get a sense of exactly how the search should be operating. To assess this, we solicited search use cases from all of the repositories via an online web form. The web form asked staff members to identify any two of their repository’s significant collections and answer questions about how they might search for known items from those collections. Specifically, we asked respondents to indicate a) what search terms they would use to find materials in their collections and b) what search results they would expect to see at the top of the search results list, based on their identified terms. We’re now in the process of analyzing this data. Hearing directly from our colleagues about their search cases and expected outcomes will help us determine a set of use cases to send out for development work.

Although the PUI Settings & Enhancements Workgroup has already done a lot of work, we still have a couple of months of the PUI project left, and our work has really just begun. We look forward to continuing our work and are particularly excited to review the Usability & Accessibility Workgroup’s user testing results and accessibility audit and determine how to prioritize additional changes based on that key data. Stay tuned — we look forward to keeping you updated!

Upcoming Training Sessions

The ArchivesSpace Training Subcommittee is pleased to announce “Phase I” of a series of training sessions for YUL staff, beginning the first week in November. Stay tuned for days & times!

All training sessions will be live streamed and recorded.

Session I: Getting Started in ASpace
How to add users
Where to find documentation & resources
How to stay in the loop

Session II: Navigating the Resource Record
What is a Resource Record in ASpace?
Required and Optimum description requirements
How required fields are indicated
DACS prompts in the Resource Record
The Notes Field

Questions about the training sessions? Contact emily.ferrigno@yale.edu

 

 

 

 

 

 

Mucking around in ArchivesSpace Locally

It may occasionally be part of your job to get inside of the guts of ArchivesSpace so that you can test a new release, diagnose a bug, or generally get a better sense of what’s going on with the system that you rely on. Also, depending on your organizational structure and the way that resources are distributed, you may need to be in a position to help your local IT department answer questions about what’s happening with ArchivesSpace.

It’s (very smart) common practice to not give access to server environments beyond a small cadre of IT department professionals. And you wouldn’t want to experiment there anyway! Thus, you need a sandbox.

A few folks have asked for instructions about how to create this environment. In short, you’ll be installing ArchivesSpace on your local machines and then hooking it up to a copy of your production MySQL database. I’m assuming that your organization uses MySQL behind ArchivesSpace because most do. There’s really great documentation about all of this on the ArchivesSpace github page, but it may be overwhelming if you haven’t done this before. By the way, if you’ve ever managed a database before, you really don’t need this tutorial.

I’ll also talk through configuration, regular updates to the database from your production database, and things to think about when testing.

Congratulations! You’re about to create a consequence-free environment. This means that you should feel free to mess around, take risks, and learn by breaking things. You’re going to break things. Continue reading Mucking around in ArchivesSpace Locally

Working more efficiently with ArchivesSpace — some use cases

We’ve talked a bit already about our work with a vendor to make sure ArchivesSpace supports efficient workflows. After reading Mark’s blog post, I’m re-energized to think of the good this work will do — archivists in repositories will be able to do collection control projects in a far more robust and efficient way!

Right now, we are deeeeeeeeep into this work. During our planning call last night, one of the software developers asked for use cases for some of our requirements for selecting and changing information about containers — I was going to just make a screencast and notes to put in our project management software, but it occurred to me that this could be useful information to document more publicly, especially since folks are asking about how ArchivesSpace can help them do their work more efficiently.

So, here we go.

Here are some use cases.

Managing information about containers in bulk

An entire collection has been described, and I know for sure which containers I’ll be using. I’m now ready to slap barcodes on these boxes, tell the system what these barcodes are, tell the system what kinds of boxes I’m using (we call this a container profile), associate these boxes with a location, and associate an ILS holdings record identifier.

In order to do this, I need an easy way of saying “yeah, I’m looking for boxes that belong to this resource” or even “yeah, I’m looking for boxes that belong to this series.” In our environment (and I know this happens elsewhere too), it’s very common for each series to start over with box 1. So, when I’m at the point of putting a barcode on a box, I need to be sure I know which box 1 I’m sticking that barcode on.[1]
Holy Cow! Look at all of those box ones!
Holy Cow! Look at all of those box ones!

In Archivists’ Toolkit, if you want to do this work, you can only scope it to a single resource record. We know that it might be desirable to do bulk actions across several collections, so we want the option to scope this work to a single resource, but we don’t want to be stuck with it.

And then, in the current Archivists’ Toolkit plug-in, you would pick the containers you want and update various fields. We’ve been thinking slightly differently about which fields we would want to update and how, but suffice it to say that we would want to pick boxes that share an attribute (like location, ILS holdings ID, container type, whatever), and then be able to enter data about that attribute and expect the changes to propagate across containers. [2]

This is really exciting because currently in ArchivesSpace, every time that you associate a container with a component (like “Correspondence from Anne Shirley to Diana Barry 1877”), you would have to enter the barcode anew. This obviously isn’t very efficient, and it can result in a whole lot of errors. In the workflow we’re proposing, you would be able to know that the box one for each of those components is the SAME box one, and you’d only have to enter the barcode once.

Managing the relationship between containers and locations in bulk

Here’s another use case: Maybe I’m doing a shelf-read. I come to a location in my repository that’s described in a location record. But maybe the location associated with those containers in the database isn’t correct! I want a quick and easy way of selecting the containers in my repository that I see in that location and associating those with the appropriate location record. This is currently impossible to do in ArchivesSpace — in fact, it does a really screwy thing where if you look up a location (like “Library Building, A Vault, Row 1, Bay 1, Shelf 1” ) it gives you a list of all the archival objects there (in other words, intellectual description), not the containers! You don’t want to go into every intellectual description and update the repeating box information. This work would make it possible to say “Boxes 3, 4, 5, 7, and 10 from MSS.111, series 4 all belong in this location” and for the system to know that.

Or maybe that location is a palette or a set of shelves that are designated as needing to go off-site. In order to document the fact that they are, indeed, going off-site, I want a quick and easy way to pick those containers and update the ILS holdings ID. If the palette or location is itself barcoded, that makes it even easier to disambiguate what I’m trying to do! [3]

I hope you’ve enjoyed this journey through how we want ArchivesSpace to work. Obviously, software development is an ever-changing endeavour, ruled by compromise and the art of the possible. So don’t take these use cases as promises. But it should give you a good sense of what our priorities and values are as we approach this project.

[1] Our user story for this is: “BULK SELECTION: As an archivist, I want an easy and fast way to choose all or some (contiguous and non-contiguous) records in a result set to further act upon.”

[2] Our user story for this is: “BULK SELECTION: As an archivist, I would like to define a set of container records that are associated with descendant archival_objects of an archival_object with a set Component Unique Identifier in order to perform bulk operations on that set.” which is obviously a perfect storm of software jargon and archives jargon, but basically we’re saying that we need to know which series this belongs to. Since series information is stored in the component unique identifier, that’s what we want to see.

[3] Our user story for this is: “BULK SELECTION: As an archivist, I would like to define a set of container records associated with a location in order to perform bulk operations on that set. When defining a set of container records by location, I would like the option to choose a location by its barcode.”

Cooperation, Co-Everything, and One (of many) Excellent Question(s)

Hi, everybody.  Long-time reader, first-time poster.  I’m Mark Custer, and I’ve been working as an Archivist and Metadata Coordinator at the Beinecke Rare Book & Manuscript Library for just over two years now.  This past year, most of my job duties have centered on ArchivesSpace. In addition to co-chairing Yale University’s ArchivesSpace Committee with Mary Caldera, I co-taught two ArchivesSpace workshops last year that were offered by Lyrasis, a membership community of information professionals, which was formed by the combination of two other regional consortiums.  In October, I helped out at a Boston workshop as a trainer in training; and in December, I co-taught a workshop that was co-sponsored by the Rochester Regional Library Council and the University of Rochester.  Looking back on the year 2014, then, what stands out most to me in my professional life is the increasing importance and necessity of partnerships. The Latin prefix co- was everywhere, and I don’t think that this notion of co-everything will be taking a backseat anytime soon.

These partnerships are precisely the sorts of things that have me so excited about ArchivesSpace.  To me, the most important thing that is emerging from the ArchivesSpace project so far is the community, not the system — don’t get me wrong, though, I’m extremely impressed by how the software has been able to combine the features and functions of Archivists’ Toolkit and Archon into a single project in such a short amount of time!  I’d even venture to say that the community is not only influencing the development of the software by making itself known through its individual and institutional voices, but that the community is also showing signs that it intends to nourish and nurture that software with a collective voice.  And, full disclosure, I’m also currently serving on the ArchivesSpace Users Advisory Council, so if you don’t agree with that statement, please let me know.

Of course, there’s still a long way for us to go.  For instance, at the end of the two-day ArchivesSpace workshop in Rochester, one of the participants asked an excellent question, which I’ll paraphrase here:

“How can I adopt more efficient workflows using ArchivesSpace?”

Each of the instructors, myself included, as well as a few of the other participants, provided a few suggestions to this important question.  What struck me by those answers, though, is that none of the suggestions were ArchivesSpace specific just yet.  That shouldn’t actually surprise me, given the relative newness of ArchivesSpace – both the software and the community – but it does remind me that we have a lot of work to do.  But it’s precisely this sort of work that I’d really like to see the archival community communicating more about in 2015.

As Maureen has already talked about in another blog post (https://campuspress.yale.edu/yalearchivesspace/2014/11/20/managing-content-managing-containers-managing-access/), one of the ways that we’d like to enable more efficient workflows in ArchivesSpace is to enhance its container management features, ideally by really letting those functions run in the background so that archivists can focus on archival description.  A few other (collective) workflows that I hope that ArchivesSpace will make more efficient include:

  • Assessing archival collections
  • Printing box and folder labels
  • Publishing finding aids to external aggregators, such as ArchiveGrid, automatically
  • Integrating with other specialized systems, such as Aeon, Archivematica (check out what the Rockefeller Archive Center has done with Archivematica and the AT in this blog post http://rockarch.org/programs/digital/bitsandbytes/?p=1172, for example!), Google Analytics, SNAC, Wikipedia, etcetera

I’d love to hear how others would like to create efficiencies using ArchivesSpace, so please leave comments here or send me an email.  I think that we need to strive for cooperative systems that promote cooperative data, including web-based documents, and I really do think that the ArchivesSpace community is poised to achieve those goals.

Making ArchivesSpace Accessioning Work for Us (and You)

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.

Managing Content, Managing Containers, Managing Access

In my last blog post, I talked a bit about why ArchivesSpace is so central and essential to all of the work that we do. And part of the reason why we’re being so careful with our migration work is not just because our data is important, but also because there’s a LOT of it. Just at Manuscripts and Archives (the department in which I work at Yale, which is one of many archival repositories on campus), we have more than 122,000 distinct containers in Archivists’ Toolkit.

With this scale of materials, we need efficient, reliable ways of keeping physical control of the materials in our care. After all, if a patron decides that she wants to see material in one specific container among the more than 122 thousand, we have to know where it is, what it is, and what its larger context is in our collections.

Many years ago, when Manuscripts and Archives adopted Archivists’ Toolkit (AT) as our archival management system, we developed a set of ancillary plug-ins to help with container management. Many of these plug-ins became widely adopted in the greater archival community. I’d encourage anyone interested in this functionality to read this blog post, written at the time of development, as well as other posts on the AT@Yale blog  (some things about the plug-in look marginally different today, but the functions are more or less the same).

In short, our AT plug-in did two major things.

  1. It lets us manage the duplication of information between AT and our ILS
    At Yale, we create a finding aid and a MARC-encoded record for each collection*. In the ILS, we also create “item records” for each container in our collection. That container has an associated barcode, information about container type, and information about restrictions associated with that container.
    All of this information needs to be exactly the same across both systems, and should be created in Archivists’ Toolkit and serialized elsewhere. Part of our development work was simply to add fields so that we could keep track of the record identifier in our ILS that corresponds to the information in AT.
  2. It let us assign information that was pertinent to a single container all at once (and just once).
    In Archivists’ Toolkit (and in ArchivesSpace too, currently), the container is not modeled. By this I mean that if, within a collection, you assign box 8 to one component and also box 8 to another component, the database has not declared in a rigorous way that the value of “8” refers to the same thing. Adding the same barcode (or any other information about a container) to every component in box 8 introduces huge opportunities for user error. Our plug-in for Archivists’ Toolkit did some smart filtering to create a group of components that have been assigned box 8 (they’re all in the same collection, and in the same series too, since some repositories re-number boxes starting with 1 at each series), and then created an interface to assign information about that container just once. Then, in the background, the plug-in duplicated that information for each component that was called box 6.
    This wasn’t just about assigning barcodes and Voyager holdings IDs and BIBIDs — it also let us assign a container to a location in an easy, efficient way. But you’ll notice in my description that we haven’t really solved the problem of the database not knowing that those box 8’s are all the same thing. Instead, our program just went with the same model and did a LOT of data duplication (which you database nerds out there know is a no-no).

Unfortunately, ArchivesSpace doesn’t yet model containers, and as it is now, it’s not easy to declare facts about a container (like its barcode or its location) just once. Yale has contracted with Hudson Molonglo to take on this work. Anyone interested in learning more is welcome to view our scope of work with them, available here — the work I’m describing is task 6 in this document, and I look forward to describing the other work they will be doing in subsequent blog posts. We’ve also parsed out each of the minute actions that this function should be able to do as a set of user stories, available here. Please keep in mind that we are currently in development and some of these functions may change.

Once this work is completed, we plan to make the code available freely and with an open source license, and we also plan to make the functions available for any repository that would like to use them. Please don’t hesitate to contact our committee of you have questions about our work.

_________________________________________

* We (usually/often/sometimes depending on the repository) create an EAD-encoded finding aid for a collection at many levels of description, and also create a collection-level MARC-encoded record in a Voyager environment. This process currently involves a lot of copying and pasting, and records can sometimes get out of sync — we know that this is an issue that is pretty common in libraries, and we’re currently thinking of ways to synchronize that data.

Making Our Tools Work for Us

Metadata creation is the most expensive thing we do.

I hear myself saying this a lot lately, mostly because it’s true. In the special collections world, everything we have is unique or very rare. And since we’re in an environment where patrons who want to use our materials can’t just browse our shelves (and since the idea of making meaning out of stuff on shelves is ludicrous!), we have to tell them what we have by creating metadata.

Creating metadata for archival objects is different than creating it for a book — a book tells you more about itself. From a book’s title page, one can discern its title, its author, who published it. Often, an author will even write an abstract of what happens in the book and someone at the Library of Congress will have done work (what we call subject analysis) to determine its aboutness.

In archives, none of that intellectual pre-processing has been done for us. Someone doing archival description has to answer a set of difficult questions in order to create high-quality description — who made this? Why was it created? What purpose did it serve for its creator? What evidence does this currently serve about what happened in the past? And the same questions have to be addressed at multiple levels — what is the meaning behind this entire collection? What does it tell us about the creator’s impact on the world? What is the meaning behind a single file collected by the creator? What purpose did it serve in her life?

Thus, the metadata we create for our materials is also unique, rare, intellectually-intensive, and essential to maintain.

Here, as part of a planning session, Mary and Melissa are talking through which tasks need to be performed in sequence.
Here, as part of a planning session, Mary and Melissa are talking through which tasks need to be performed in sequence.

Currently, we use a tool called Archivists’ Toolkit to maintain information about our holdings, and this blog is about our process of migrating to a different tool, called ArchivesSpace. Because, like I say, the data in ArchivesSpace is expensive and unique, we’ve taken a very deliberative and careful approach to planning for migration.

We’re lucky to have a strong group, with diverse backgrounds. Mary Caldera and Mark Custer are our co-chairs, and have strong management and metadata expertise between them. Melissa Wisner, our representative from Library IT, has a background in project management and business analysis. She was able to walk us through our massive project planning, and helped us understand and make sense of the many layers of dependencies and collaborations that will all have to be executed properly in order for this project to be successful. Others on the group include experts in various archival functions and standards. And beyond this, we have established a liaison system between ourselves on the committee and archivists from other repositories at Yale, so we can make sure that the wisdom of our wider community is being harnessed and the transition to this new system is successful for all of us.

Anyone interested in viewing our project timeline is welcome to see it here. We know that other repositories are also involved in transition to ArchivesSpace, and we would be happy to answer questions you may have about our particular implementation plan.