[Archivesspace_Users_Group] REMINDER: Proposal for Container Management Enhancements - Call for Community Input

Mon Dec 17 14:09:06 EST 2018

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

Pronouns: she/her/hers

Smith College Special Collections is now housed at Young Library
<https://www.smith.edu/libraries/about/new-neilson/wheres-my-library>.
Learn more about renovations to Neilson Library here
<https://www.smith.edu/libraries/about/new-neilson>.

On Mon, Dec 17, 2018 at 12:42 PM Rackley, Marilyn <
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://drive.google.com/open?id=14-6CFEAATfwYc1JZoAmCSD3CQVW7p3b3.
>
>
>
> 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
> *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 and/or Robin Wendler at
> 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* <marilyn_rackley at harvard.edu>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20181217/d40bb6ba/attachment.html>