Hi Sarit, Just a quick word on maintenance of plugins we develop ...
We usually fix bugs quickly when they are reported. Ongoing development is done on a project basis - if someone funds the work, we’ll do it. This includes extending functionality and upgrading for new versions of ArchivesSpace. We recently did a project with Yale to upgrade all of their plugins for compatibility with AS v3.3.x. The fact that this one didn’t get touched suggests that it didn’t need any modification for the upgrade. Cheers, James > On May 12, 2023, at 6:24 AM, Hand, Sarit <sh...@ap.org> wrote: > > 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 > > <image001.png> > > Sarit Hand > Digital Archivist > AP Corporate Archives > > 200 Liberty Street > New York, NY 10281 > T 212.621.7035 > > sh...@ap.org <mailto:sh...@ap.org> > ap.org <http://www.ap.org/> > <image002.png> > > > From: archivesspace_users_group-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> > <archivesspace_users_group-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> On Behalf > Of Custer, Mark > Sent: Thursday, January 28, 2021 11:27 AM > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org > <mailto:archivesspace_users_group@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-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> > <archivesspace_users_group-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> on behalf > of Pruitt, Adrienne <adrienne.pru...@tufts.edu > <mailto:adrienne.pru...@tufts.edu>> > Sent: Tuesday, January 26, 2021 3:52 PM > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org > <mailto:archivesspace_users_group@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.pru...@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-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> > <archivesspace_users_group-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> on behalf > of Custer, Mark <mark.cus...@yale.edu <mailto:mark.cus...@yale.edu>> > Sent: Friday, November 17, 2017 3:35 PM > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org > <mailto:archivesspace_users_group@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-boun...@lyralists.lyrasis.org > <mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org> > [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of > Olivia S Solis > Sent: Friday, 17 November, 2017 12:39 PM > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org > <mailto:archivesspace_users_group@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: > > It will look horrible. Whole series and collections that are stored offsite > will have this repetitive information in archival object after archival > object. > 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._______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group@lyralists.lyrasis.org > <mailto:Archivesspace_Users_Group@lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
