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-boun...@lyralists.lyrasis.org [mailto:archivesspace_users_group-boun...@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-boun...@lyralists.lyrasis.org <archivesspace_users_group-boun...@lyralists.lyrasis.org> On Behalf Of Maureen Callahan Sent: Monday, December 17, 2018 2:09 PM To: Archivesspace Users Group <archivesspace_users_group@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 mcalla...@smith.edu<mailto:mcalla...@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_rack...@harvard.edu<mailto:marilyn_rack...@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://drive.google.com/open?id=14-6CFEAATfwYc1JZoAmCSD3CQVW7p3b3<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@lyralists.lyrasis.org<mailto:archivesspace_users_group@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_rack...@harvard.edu<mailto:marilyn_rack...@harvard.edu> and/or Robin Wendler at robin_wend...@harvard.edu<mailto:robin_wend...@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_rack...@harvard.edu<mailto:marilyn_rack...@harvard.edu> _______________________________________________ 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<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@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
