[Archivesspace_Users_Group] Offsite boxes and ASpace

Hand, Sarit shand at ap.org
Thu May 11 16:24:38 EDT 2023 

Hi Mark,

I was just wondering if this plugin is still operational and/or further development has been made. I want to create an offsite location record so I can give it as a location to our top containers. Ultimately, I would like to be able to generate a report based on what is at the offsite storage AND calculate the extent.

There is one other issue with regard to the extent, I would like to be able to select the extent record based on the type, i.e. Linear ft, rather than just get all the extent regards mixed in for those records that may have linear ft calculated as well as number of items or GB, etc. Does that make sense? I am trying to figure out how to handle locations with offsite storage. I also don’t see how to add an address to a location, i.e. the building address.

Anyone have thoughts on this?

Thank you!
Cheers

[cid:image001.png at 01D98425.14B912F0]

Sarit Hand
Digital Archivist
AP Corporate Archives
200 Liberty Street
New York, NY 10281
T 212.621.7035

shand at ap.org<mailto:shand at ap.org>
ap.org<http://www.ap.org/>
[cid:image002.png at 01D98425.14B912F0]


From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Custer, Mark
Sent: Thursday, January 28, 2021 11:27 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Offsite boxes and ASpace


[EXTERNAL]
Adrienne,

Here's a link to the plugin that Hudson Molonglo developed, which we've been using for about the past six months in production:  https://github.com/hudmol/yale_onsite_locations  If you have any questions about it, let us know.

I would love to see this in the ArchivesSpace core code, but we went with a plugin approach last year so that we could get this feature added ASAP to our instance and so that we could test out how it performs (so far, so great!).  The plugin adds an "Onsite?" checkbox to every location, with the default value being set to True.  And once you start flipping some locations to Onsite = False, then information is stored in the index to indicate whether the Resource and Archival Object and Top Container records are stored onsite or offsite.  And since Resource and Archival Objects can be linked to multiple top containers, those records can have a hybrid status.  So, that's why we now have a facet for "Storage Location", as seen in the attached image.  We haven't really highlighted this new feature to users yet, but I am very interested in seeing how it gets used over time.

We also talked about adding a feature in the staff interface to calculate a note for the collection to indicate which boxes were onsite vs. offsite based on this information, like the "Calculate Date / Extent" function, but didn't wind up adding that to the plugin, although I still like the idea.

And Olivia, since I was still interested in adding such a note to our EAD, even after all these years (has it been over three years? 🙂), I did update our EAD3 export option to include the location information in our EAD files. I did not go with a physloc note, since I agree with you that it would look horrible having that information repeat everywhere if it were to display in the finding aid, so I went with an option of adding the location URI fragment into an attribute on each container element that is associated with an ASpace location record.  Then, since we know which locations that we consider to be onsite vs. offsite, our nightly export process will add a note to each finding aid in the EAD3 control section.  Here's an example:  https://github.com/YaleArchivesSpace/Archives-at-Yale-EAD3/blob/5734391e95a954a99cb03ee54282fd14d028c8e3/brbl-ead/10764.xml#L34-L41  We aren't using that note for anything right now, but I think that it could be useful for creating our MARC holdings records, as well as for adding to our PDF finding aids, etc.  But right now, it's just there so that staff could potentially use it to review and see if it looks like things are assigned as expected.

Mark







________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Pruitt, Adrienne <Adrienne.Pruitt at tufts.edu<mailto:Adrienne.Pruitt at tufts.edu>>
Sent: Tuesday, January 26, 2021 3:52 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Offsite boxes and ASpace

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<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of Custer, Mark <mark.custer at yale.edu<mailto:mark.custer at yale.edu>>
Sent: Friday, November 17, 2017 3:35 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto: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> [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<mailto: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

The information contained in this communication is intended for the use of the designated recipients named above. If the reader of this communication is not the intended recipient, you are hereby notified that you have received this communication in error, and that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify The Associated Press immediately by telephone at +1-212-621-1500 and delete this email. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230511/dfe757c7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1094 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230511/dfe757c7/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5548 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20230511/dfe757c7/attachment-0001.png>

More information about the Archivesspace_Users_Group mailing list