[Archivesspace_Users_Group] Offsite boxes and ASpace

Olivia S Solis livsolis at utexas.edu
Mon Feb 1 10:35:40 EST 2021 

Yes, thank you so much, Mark!! Very excited to see progress here, and I too
can't believe that original email I sent was from so long ago. I'm glad you
unearthed it, Adrienne!

:)
Olivia

On Fri, Jan 29, 2021 at 8:36 PM Pruitt, Adrienne <Adrienne.Pruitt at tufts.edu>
wrote:

> Thank you very much, Mark! This will be so useful.
>
> -Adrienne
>
> On Jan 28, 2021, at 11:27 AM, Custer, Mark <mark.custer at yale.edu> wrote:
>
> 
> 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 <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of
> Pruitt, Adrienne <Adrienne.Pruitt at tufts.edu>
> *Sent:* Tuesday, January 26, 2021 3:52 PM
> *To:* Archivesspace Users Group <
> 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexchange.tufts.edu%2Fowa%2Fredir.aspx%3FC%3Dt5B1d8GNpPJJzaAAvUfcGAPuBinqgxXyoK8_O0ggQHCOYyG6Tc_XCA..%26URL%3Dmailto%253aadrienne.pruitt%2540tufts.edu&data=04%7C01%7Cmark.custer%40yale.edu%7C29395ca0ea394c7f06fd08d8c23c41d7%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637472911359825173%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wX39F6MDBD%2FG8pgHhJ1a0YgTsOBznznsTrIL6ztV8iI%3D&reserved=0>
>  |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
> <Screen Shot 2021-01-28 at 11.12.41 AM.png>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>


-- 
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/20210201/18549cd4/attachment.html>

More information about the Archivesspace_Users_Group mailing list