[Archivesspace_Users_Group] merge Top Container functionality

Rachel Aileen Searcy rachel.searcy at nyu.edu
Wed Jun 5 09:22:25 EDT 2019


This is great news! - thank you for the update on this, Christine. We
wanted to add our voices to the chorus that we too are looking forward to
this functionality. We would also very much welcome the ability to merge
container profiles, as Kevin just brought up.

Thanks,
Rachel

On Wed, Jun 5, 2019 at 8:21 AM Christine Di Bella <
christine.dibella at lyrasis.org> wrote:

> For container management improvements, merging top containers has been the
> priority for awhile based on the Staff Interface Enhancement Working Group
> recommendations and what we've heard from the community -- that's
> definitely what we're aiming for first. But, as you note, there's a JIRA
> for merging container profiles as well. We'll need to revisit this when we
> get there, but I'd think that once we get top containers worked out, adding
> the ability to merge container profiles would be a comparatively short step
> from there.
>
> (Of course, if a community developer is able to tackle merging container
> profiles before we get there, we 'd love to hear from them. The program
> team or community members could likely create a more detailed specification
> for how it should look/behave based on what's in the JIRA.)
>
> Christine
>
> -----Original Message-----
> From: archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of
> Kevin Clair
> Sent: Tuesday, June 4, 2019 7:48 PM
> To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] merge Top Container functionality
>
> Thanks, Christine! Will there be similar functionality for Container
> Profiles? Someone at our shop asked me about that the other day and I saw
> there's a ticket for it at
> https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_ANW-2D550&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=0e1WDtwfatT5pXluM5NJQ8U6w6Aq7hlx6hjwS_PwgFI&e=
> , but it looks like it hasn't been updated since last summer.  -k
>
> On 6/4/19, 2:50 PM, "
> archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of
> Christine Di Bella" <
> archivesspace_users_group-bounces at lyralists.lyrasis.org on behalf of
> christine.dibella at lyrasis.org> wrote:
>
>     Hi Benn,
>
>     Merging Top Containers has been on our development roadmap, and we
> know it is of great interest to a number of people in the community, but
> until recently we had not been able to identify a developer to take this
> on. We've now determined that we will be able to work on this after some of
> the large projects related to agents and infrastructure that are currently
> in progress have been completed. We're aiming for this functionality to be
> available in the application later this year.
>
>     Christine
>
>     Christine Di Bella
>     ArchivesSpace Program Manager
>     christine.dibella at lyrasis.org
>     800.999.8558 x2905
>     678-235-2905
>     cdibella13 (Skype)
>
>
>
>     -----Original Message-----
>     From: archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of
> Benn Joseph
>     Sent: Tuesday, May 21, 2019 5:22 PM
>     To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
>     Subject: [Archivesspace_Users_Group] merge Top Container functionality
>
>     Hi all,
>     I'm curious whether there are any updates re: the ability to merge Top
> Containers. It looks like ANW-462 deals specifically with this but I can't
> tell if there has been much activity on it lately:
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_ANW-2D462-3FatlOrigin-3DeyJpIjoiZTc0MWQ4MDdlMjhjNGFlZmE4YTEwYzg3YTQ0ZmQzZTkiLCJwIjoiaiJ9&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=B-W8Y4bxQ_l6xQ-rv-XOPKDsOq4yF4EJxCKeQnJnKIw&e=
>
>     Thanks!
>     --Benn
>
>     Benn Joseph
>     Head of Archival Processing
>     Northwestern University Libraries
>     Northwestern University
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.library.northwestern.edu&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=6YgNz1fy5Ld4xc-vCQ2ZXPR7HADFt1gIsPzEPtV_dKQ&e=
>     benn.joseph at northwestern.edu
>     847.467.6581
>
>
>
>     -----Original Message-----
>     From: archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of
> Tang, Lydia
>     Sent: Wednesday, January 16, 2019 12:18 PM
>     To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
>     Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for
> Container Management Enhancements - Call for Community Input
>
>     I second the ability to merge containers!  😊
>     Lydia
>
>     From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on
> behalf of Valerie Addonizio <vaddoniz at jhu.edu>
>     Reply-To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
>     Date: Wednesday, January 16, 2019 at 1:17 PM
>     To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
>     Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for
> Container Management Enhancements - Call for Community Input
>
>     I know that the comment period is closed, but this seemed like a
> logical place to ask whether the idea of container merging functionality
> was considered as part of this effort (I know it is not in the scope of
> work, but was it considered and not selected?) and whether other
> institutions are in need of such functionality?
>
>     From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:
> archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of
> Bowers, Kate A.
>     Sent: Thursday, December 20, 2018 4:16 PM
>     To: Archivesspace Users Group
>     Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for
> Container Management Enhancements - Call for Community Input
>
>     Dear ArchivesSpace community:
>
>     Apologies for the length of this. I’ll try to address a lot of
> comments, but not all!  Please let me know if (as they may well do) my
> elaborations only elicit more questions!
>
>     In general, most of these proposals are derived from facing problems
> of scale. Harvard has 30 repositories and over 200 users of ArchivesSpace.
> Others have to do with managing “medium rare” materials’ locations and
> containers in ArchivesSpace.  (Medium-rare is a tongue-in-cheek term used
> to cover materials that might exist in multiple manifestations but that
> have archival or rare characteristics or treatment. Examples include entire
> libraries ingested into an archives, author’s own copies of their books,
> annotated books, or the record copy of serials or reports kept by
> institutional archives.)
>
>      • Multi-field top container indicators
>          Some commenters wondered if the multiple fields were to
> accommodate child containers. To clarify, the suggestion was to facilitate
> parsing top container identifiers.  As a few commenters have surmised, this
> is to cope with legacy numbers.  These are especially common on medium-rare
> materials.
>          One suggestion was to use a sort algorithm that would obviate the
> need for separated fields for data. However, because there would be is more
> than one algorithm necessary over the installation, such a solution would
> require an added field to identify the algorithm and probably a third field
> retain a value derived by the algorithm to be sorted alphanumerically.
> Thus, the direct 3-field solution seems simpler. (A 4-field suggestion was
> mooted in the committee as potentially more useful communally.) It does
> occur to me that there just might not be enough really old, really big
> repositories with lots of legacy identifiers in the ArchivesSpace community
> for the parsing of legacy numbers to be a common problem. I appreciate the
> recognition that a plug-in might be needed instead, but it would be worth
> hearing from any repositories with similar issues.
>
>      • Container and location profiles by repository
>            We were envisioning a one-to-one profile-to-repository
> scenario. Due to the ArchivesSpace staff user interface requirement that
> one identify only a single repository at login, it is extremely easy for
> users to forget the impact they might have beyond their repository if they
> change or delete a shared record.  We have already experienced mistaken
> mergers and deletions of agents due to the design of AS staff user
> interface that does not allow one to see where the record may be linked
> beyond their repository.  For this reason, it is wise to be able to limit
> changes and deletions of location profiles and container profiles impact to
> the same chosen repository.
>
>      • Inactive
>          As Maureen wisely intuited, inactive locations are necessary to
> recording a complete location history.  However, there are additional use
> cases. When a repository is renovating, for example (as is happening now at
> the Schlesinger Library) the shelves in a location may be inactive for a
> time and become active again when the building re-opens.  Other scenarios
> include water intrusion or other occasions when a smaller sub-set of
> shelves may have to become inactive until repairs are completed and tested
> before the shelving can again come into use. Because inactive locations are
> to be eliminated by default from search results, we can prevent them from
> overwhelming staff members’ search results or sending staff to unusable
> locations.
>
>      • Notes in containers and locations
>          Notes are for dedicated shelving or rehousing issues.  Notes on
> containers may contain things like “Label falling off” “Acidic-needs
> replacing” “Acid box replaced with acid-free box 2017-06-08” “Not on shelf
> 2015-10-10”.  Notes on locations may contain things like “only use as last
> resort—overhead drip pan makes retrieval difficult” “reserved for outgoing
> transfers until 2019-01-01”.  In locations especially, we would expect the
> reason for a location becoming inactive might be noted.  “Made inactive
> because next to heating duct—do not reactivate”.
>
>      • Bibliographic record IDs in containers
>          This data would allow for more sustainable interoperability
> between systems and more flexibility in workflows.
>          Especially with medium-rare materials, the physical item’s
> location might need to be recorded before description is finalized, and if
> the description is to be created in foreign system and ingested to
> ArchivesSpace, hooking up the container and location will be problematic.
> In this scenario, a resource with initial description in a bibliographic
> system could be placed on an archives’ shelf, and the description, once
> completed in the ILS, could be ingested via MARC XML ingest for example.
> After the resource is ingested, the ILS bibliographic record number could
> be searched in the containers to link the container to the resource.
>          When an ILS system migrates, it is unlikely that the migration
> would maintain obsolte holding or item system numbers, but it is common to
> migrate with obsolete bibliographic system record numbers embedded into the
> new system.  Should there be a need to re-migrate holdings or items from
> ArchivesSpace to a new ILS, bibliographic record numbers would ensure
> continuity.
>
>     Thanks for reading!
>
>     Kate
>
>
>
>
>
>
>     From: archivesspace_users_group-bounces at lyralists.lyrasis.org <
> archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of
> Maureen Callahan
>     Sent: Monday, December 17, 2018 2:09 PM
>     To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
>     Subject: Re: [Archivesspace_Users_Group] REMINDER: Proposal for
> Container Management Enhancements - Call for Community Input
>
>     A million thanks to folks from Harvard for showing leadership and
> investing to improve the experience of the software for all of us.
>
>     I was having pleasant flashbacks to my days at Yale working through
> the original specifications for the container management functionality --
> what it all means, what it should do, how this will improve the experience
> for archivists and patrons, and how to abstract all of this work to more
> general archival and data management principles. It's such fun, hard work!
>
>     Generally speaking, it would be really helpful if user stories gave a
> better sense of what you want to accomplish instead of what you want to see
> on the screen. For some of this, I had a hard time understanding where you
> were coming from and I think it's possible that there are different ways of
> accomplishing what you've laid out. "As an W, I want to have X feature, so
> that Y behavior happens in Z way and lets me do my work in ABC fashion." I
> think that many of the goals behind this proposal are sound, but that
> perhaps there's too narrow an approach to solutions to meet these goals.
> Developers might find better ways to address the problems you've identified.
>
>     1. Hell YES there need to be easier ways to browse/sort/find
> locations!!!!
>
>     2. I agree that it would be useful to have the option to filter
> locations/container profiles by the repository they tend to belong to and
> that this should also be extensible so that it's easy to change this
> information after a move or administrative change. I sort of remember that
> folks at NYU talked about this as a possible outcome in the beginning of
> their location profile work, so it may be worth talking with them about the
> best way to think about it and any reasons they might have opted to not
> associate a repository with a location profile.
>
>     3. Lora did some nice work with search to make it possible to see the
> entire breadcrumb trail of where a search result comes from (the
> hierarchies of AOs within a resource). I'm thinking that perhaps you just
> want the same thing to happen when you look at the associated archival
> objects / accessions in a top container, rather than adding another column
> (resource) to the search result.
>
>     4. As someone who has had to do a lot of systems migrations that
> involved moving heterogenous data into more structured places, I get really
> nervous about a notes field for either the location or the top container.
> If there are common types of information that end up in this field, it may
> be worth considering adding more structured fields to either the location
> or the location profile or container or container profile so that it can be
> better managed, queried, and kept tidy & up-to-date. What's the scenario by
> which someone would actually look at this notes field? What do you want to
> go in there?
>
>     5. Soooooo tell me more about this inactive location idea. AFAIR,
> ArchivesSpace doesn't keep an audit trail of previous locations. What's the
> value of knowing that inactive locations exist when there aren't containers
> living in those locations and there's no way to see that those locations
> perviously held containers?
>
>     6. This may be implicit in your proposal, but it sounds like you want
> "repository" to be a multi-valued field in your location profiles and your
> container profiles. Paige boxes, for instance, will probably end up being
> associated with every repository.
>
>     7. I was initially a bit perplexed by the request to add additional
> fields for container indicators, but reading between the lines, my guess is
> that you want to be able to sort them properly in various circumstances.
>
>     If, for instance, you have boxes 2, 2a, and 3, you want to be able to
> make sure that when you sort by indicator, they appear in this order.
> That's a great goal! But I think that you might want to state this goal
> instead of stating one possible outcome.
>
>     I definitely DO NOT want a three-part container indicator because who
> knows what kind of crap people will put in those fields and they could
> potentially be a nightmare to clean up. Plus, it would have to account for
> every possible heterodox way that people design their container indicators
> -- or just default to Harvard's scheme, which... I mean, this is software
> for the whole community.
>
>     Instead, I would suggest making the requirement that you want for
> alphanumeric characters to sort properly and clever developers can come up
> with the best way to do this. That seems like a more elegant solution than
> changing the data model.
>
>     8. YES BIBIDs!!!! But my read is that a BIBID is a control number for
> intellectual description, not for holdings. I know that folks are currently
> putting BIBIDs in user-defined fields in the resource record, and it would
> be great for those to have a canonical spot to help with systems
> integrations. I would much rather see the addition of a BIBID to the
> resource record, which can then be displayed with the top container by the
> system if desired (although why?). There's already a field for the ILS
> holdings ID to go with the top container.
>
>     Thanks all,
>     Maureen
>
>
>     --
>     Maureen Callahan
>     Sophia Smith Collection Archivist
>     Smith College Special Collections
>     Northampton, Massachusetts 01063
>     413 585 2981
>     mcallahan at smith.edu<mailto:mcallahan at smith.edu>
>
>     Pronouns: she/her/hers
>
>     Smith College Special Collections is now housed at Young Library<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.smith.edu_libraries_about_new-2Dneilson_wheres-2Dmy-2Dlibrary&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=6_5o894RumU3UiMWDspYsi9hvlxzwybbDZhwqxoqzUk&e=>.
> Learn more about renovations to Neilson Library here<
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.smith.edu_libraries_about_new-2Dneilson&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=D7vktPydut0KZQpgPuTDeMfGLme5d9GNsfXHoWV7CRk&e=
> >.
>
>     On Mon, Dec 17, 2018 at 12:42 PM Rackley, Marilyn <
> marilyn_rackley at harvard.edu<mailto:marilyn_rackley at harvard.edu>> wrote:
>     Dear all,
>
>     Please remember to review the Harvard Library proposal for container
> management enhancements and submit feedback by Wednesday, December 19,
> 2018. See the email below for more information.
>
>     In case people are not able to access the attachment, the proposal can
> also be accessed through this link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D14-2D6CFEAATfwYc1JZoAmCSD3CQVW7p3b3&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=fciHLC2ou0tXKp-JlPlsrEmslFw9tnR331DgXAhVLvo&m=K5QjuKlUxPPrg2p5830gF8oT3Voegkm_3vzVJ05lgm4&s=bInpBUPKeV0QKr-JQH2j9yaDdfw8v580qBTSZmMBwx4&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=https-3A__drive.google.com_open-3Fid-3D14-2D6CFEAATfwYc1JZoAmCSD3CQVW7p3b3&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=1GjU8ktQ9bncQdhvdE2zi0a2fHSWL8NDj17jV9byJn8&e=
> >.
>
>     We really appreciate all the comments provided so far.
>
>     Best,
>     Marilyn
>
>     From: Rackley, Marilyn
>     Sent: Monday, December 3, 2018 9:36 AM
>     To: archivesspace_users_group at lyralists.lyrasis.org<mailto:
> archivesspace_users_group at lyralists.lyrasis.org>
>     Subject: Proposal for Container Management Enhancements - Call for
> Community Input
>
>     Dear ArchivesSpace Community,
>
>     The Harvard Library has been reviewing container and location
> management functionality in ArchivesSpace and we are proposing to make
> enhancements to this functionality that we would like to contribute to the
> core code.
>
>     With these enhancements, we hope to make finding, viewing, and
> updating information related to containers and locations in the staff
> interface more efficient and effective.
>
>     We have completed the draft proposal attached to this email and we are
> now asking for community review and feedback. The proposal includes the
> rationale for the changes, a list of database fields to be added, user
> stories describing the specific changes we are proposing, and mockups of
> the related updates to the staff interface. Please note that in the
> proposal, certain changes are designated as being a lower priority; it is
> possible that we may not be able to complete all the proposed changes at
> this time.
>
>     If you have questions or feedback, please email me at
> marilyn_rackley at harvard.edu<mailto:marilyn_rackley at harvard.edu> and/or
> Robin Wendler at robin_wendler at harvard.edu<mailto:
> robin_wendler at harvard.edu>. We will be accepting comments through
> Wednesday, December 19, 2018.
>
>     We look forward to receiving community input.
>
>     Best,
>     Marilyn
>
>     Marilyn Rackley
>     Aeon Project Manager and Digital Librarian Harvard Library |
> 617.496.4043 marilyn_rackley at harvard.edu<mailto:
> marilyn_rackley at harvard.edu>
>
>     _______________________________________________
>     Archivesspace_Users_Group mailing list
>     Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:
> Archivesspace_Users_Group at lyralists.lyrasis.org>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=fciHLC2ou0tXKp-JlPlsrEmslFw9tnR331DgXAhVLvo&m=K5QjuKlUxPPrg2p5830gF8oT3Voegkm_3vzVJ05lgm4&s=FB4KqB3TcRmkmN9zqyRn6s9tpjfpDzM3U9XYqkb3Ock&e=
> <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=wwc_Z_TbmWbPFh7My2zRxmrGgCNO-71Fwzlmd8YZVUY&m=bbRMI526TLbYRRGdpIJjhaQSNXcp3-xidB745mYa688&s=Ia_oQ7YT5R2fLTqMbss7oSChwO-HRtiNxwPbTe1RCRM&e=
> >
>
>
>
>     _______________________________________________
>     Archivesspace_Users_Group mailing list
>     Archivesspace_Users_Group at lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=fciHLC2ou0tXKp-JlPlsrEmslFw9tnR331DgXAhVLvo&m=K5QjuKlUxPPrg2p5830gF8oT3Voegkm_3vzVJ05lgm4&s=FB4KqB3TcRmkmN9zqyRn6s9tpjfpDzM3U9XYqkb3Ock&e=
>     _______________________________________________
>     Archivesspace_Users_Group mailing list
>     Archivesspace_Users_Group at lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=BRsURHLQOmtDZAN8BQtkBD2HXVpghzeetqPkOR8viw4&e=
>     _______________________________________________
>     Archivesspace_Users_Group mailing list
>     Archivesspace_Users_Group at lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=BRsURHLQOmtDZAN8BQtkBD2HXVpghzeetqPkOR8viw4&e=
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=BRsURHLQOmtDZAN8BQtkBD2HXVpghzeetqPkOR8viw4&e=
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwIGaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=WzsSfhV5voLsah7Ip9vFy81tN7BDqOAUmc829ruDPKo&s=BRsURHLQOmtDZAN8BQtkBD2HXVpghzeetqPkOR8viw4&e=
>


-- 
Rachel Searcy
Accessioning Archivist, Archival Collections Management
New York University Libraries
212.998.2539 | rachel.searcy at nyu.edu
My pronouns are she/her
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20190605/79a52aaf/attachment-0001.html>


More information about the Archivesspace_Users_Group mailing list