[Archivesspace_Users_Group] Container profiles ad nauseam

Valerie Addonizio vaddoniz at jhu.edu
Mon Apr 25 12:11:45 EDT 2016

My question today is for institutions that are already managing their containers with container profiles, and it is regarding legacy box types:

Hopkins has undergone a survey project to identify the physical dimensions for every single box we hold (>17,000). This data is currently stored in an Excel database in preparation for integrating this into AS through the API after we migrate in. Related to this work, Hopkins is paring down its box types to a canonical list of preferred boxes, each of which will have a container profile with dimensions.

As you might imagine, we have a certain number of record center cartons, document cases, and flat boxes, and then a looooooong tail of "custom" boxes, the dimensions of which are all over the place. In pure numbers, we have about 55 legacy box types, one of which is "custom," of which we then have 125 discrete examples. From these 180 different types of boxes, we plan to only use 20 or fewer types in the future.

I have the dimensions of each of these 180 types of boxes, and it's good data because it does inform the extent of each of the collections they are in. But where I'm hesitating is how to leverage that data without creating chaos.

Did institutions  using box types kept their legacy and funky box dimensions? Have you created container types for these? It is unwieldy to use container types with this much legacy information shoved in? Have you undergone major re-housing projects?

And while I know a container type is not required, I for one am heavily invested in using the containers functionality for creating extent statements. I can initially populate the extent statement with an accurate extent calculation from my excel database (so, not using container types at all for legacy collections), but what then when we change a single box? It seems like not using container types means we will need to manually count and calculate the extent each time we change it, and that undermines a huge part of this awesome functionality.

Any insight or follow-ups welcome. Thanks!


Valerie Addonizio
The Sheridan Libraries
Johns Hopkins University
vaddoniz at jhu.edu

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160425/4ecd52ed/attachment.html>

More information about the Archivesspace_Users_Group mailing list