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 <[email protected]> wrote: > Thank you very much, Mark! This will be so useful. > > -Adrienne > > On Jan 28, 2021, at 11:27 AM, Custer, Mark <[email protected]> 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:* [email protected] < > [email protected]> on behalf of > Pruitt, Adrienne <[email protected]> > *Sent:* Tuesday, January 26, 2021 3:52 PM > *To:* Archivesspace Users Group < > [email protected]> > *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 > > [email protected] > <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:* [email protected] < > [email protected]> on behalf of > Custer, Mark <[email protected]> > *Sent:* Friday, November 17, 2017 3:35 PM > *To:* Archivesspace Users Group < > [email protected]> > *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:* [email protected] [mailto: > [email protected]] *On Behalf Of *Olivia > S Solis > *Sent:* Friday, 17 November, 2017 12:39 PM > *To:* Archivesspace Users Group < > [email protected]> > *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 > [email protected] > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > > _______________________________________________ > Archivesspace_Users_Group mailing list > [email protected] > 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
_______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
