[Archivesspace_Users_Group] Offsite boxes and ASpace

Tue Jan 26 15:52:06 EST 2021

Hello, all,

This question - of making onsite/offsite locations visible to users - has come up at Tufts, and it looks like Yale, at least, has solved it. (Hooray!) If anyone has a good solution for this (plugin or otherwise), would you mind pointing me to it?

Thank you very much!

Adrienne Pruitt | Collections Management Archivist
Digital Collections and Archives
Tufts University
adrienne.pruitt at tufts.edu<https://exchange.tufts.edu/owa/redir.aspx?C=t5B1d8GNpPJJzaAAvUfcGAPuBinqgxXyoK8_O0ggQHCOYyG6Tc_XCA..&URL=mailto%3aadrienne.pruitt%40tufts.edu> |617-627-0957
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Custer, Mark <mark.custer at yale.edu>
Sent: Friday, November 17, 2017 3:35 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Offsite boxes and ASpace

Hi Olivia,

Hear, hear!!! 😊

Just a quick note to say that this is something that we’ve discussed at Yale, as well, and I think that we might start to address it via a plugin at some point (it would be a nice feature to go directly into the core code, but in order for that to happen, I’d think that the Location module would need to be updated so that staff could indicate which locations were the offsite ones without having to add that data to a config file).

Also, I believe that the location information is already in the PUI index, so it would just be a matter of choosing when/where to display that data.   I don’t think that there’s a good EAD solution, unless you implement a specific way to use the physloc note, as you mentioned, but even then you’ve got to do some grouping since those boxes are often repeated in a finding aid, and any top-level, auto-generated note should be easy to read.

Here’s what I’d like our ASpace PUI site to have (eventually):

  *   We could configure which locations are offsite (for us, we’d just need to add 3 location IDs to an array of offsite locations). In the future, though, it would be nice if you could use the Location module in ASpace to designate this rather than doing it in a configuration file; and anything that’s not tagged as being offsite would then be inferred to be on site.
  *   Each top-container landing page would have an automatically generated note indicating that the materials were stored offsite and requires X amount of time to retrieve (and, of course, the part about how long it would take would need to be configurable, as well)
  *   Each archival object, accession, and resource associated via an instance with one of those top containers would have the same message.
  *   We’d also have 2 facets to indicate onsite vs. offsite (or, available today vs. needs X amount of lead time, whatever would make the most sense).  How handy would that be to exclude “offsite” archival components if you’re only going to be in town for a day or two?
  *   If a resource or accession had any offsite material attached to it, then an auto-generated note would display at the top level description, indicating as much (e.g. Boxes 1-3 and 5 in this collection require five business days to retrieve, upon receipt of request)

All that said, it would be great to have the same info available in the staff interface, too.

Have any other institutions tackled this problem already?  For now, we really only indicate this by manually adding notes to our MARC Holdings records, and I’d love not to repeat that practice in our finding aids for the reasons you mentioned, Olivia.

Mark

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Olivia S Solis
Sent: Friday, 17 November, 2017 12:39 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Offsite boxes and ASpace

Hello all,

We're trying to figure out a situation that can't be uncommon. We've got a lot of onsite boxes. We've got a lot of offsite boxes. Researchers need to request offsite boxes a week in advance. Many of our collections have nebulous access restrictions like, "Portions of this collection are stored offsite". I want clarity for our researchers.

We're slowly carrying out a shelf read project and soon will know exactly where every box is. How have some of you all who have all of your containers anchored to locations communicated that something is offsite to researchers?

We publish EAD records to a regional consortium and are working on setting up Aeon to integrate with it and, eventually, the ASpace public interface.

I have thought about adding a physical location tag for all archival objects that have associated offsite boxes stating such, but I don't like this for a couple of reasons:

  1.  It will look horrible. Whole series and collections that are stored offsite will have this repetitive information in archival object after archival object.
  2.  It will not automatically update when the box moves. For various logistical reasons, many of our boxes move around a lot or are slated to move to new locations. The whole point of having box location information in a database is that we only will have to change the information in one place.

Even if there's not a good EAD solution, we can point researchers to the public interface. I've not much experience with the public interface, but should it be difficult to customize the box display so that you can see building information associated with a box?

I'm just curious how other institutions have tackled this problem. I'd like it to be readily apparent to researchers when they need a week to access a box.

Thanks!

Olivia

--

Olivia Solis, MSIS

Metadata Coordinator

Dolph Briscoe Center for American History

The University of Texas at Austin

2300 Red River St. Stop D1100

Austin TX, 78712-1426

(512) 232-8013
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20210126/86f3b0ab/attachment.html>