[Archivesspace_Users_Group] Question about intent behind container information

[Bowers, Kate A.]

Thanks, Mark!

Your picture of how you use the system is really, really helpful in orienting ourselves when we look at the data we have in the system. Our primary users of "containers" are coming from quite a different set of activities, which goes very far to explain at least part of our perplexity.  Another part is derived, I think, from the fact that most of the container data is ingested EAD.

I'm very grateful for your patience and helpful explanations!

Kate



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, May 18, 2016 3:37 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Question about intent behind container information

Kate,

We don't ever go about looking for the right box record this way.  As I mentioned earlier, we primarily rely on the "Manage Top Containers" feature to search for and identify boxes.

The other time that a box "title" is really important to us is when we're linking to a pre-existing top container within the context of a finding aid. When you're in the context of a resource record and you use the typeahead search feature, you're only searching for top containers that have already been linked to that resource, so this is where that specific display string comes in handy.  We already know what resource we're in, so we don't need to see that information display again (it wouldn't hurt anything, but it would make the display string much longer).  And for the repositories that use multiple box 1s, it's really important for them *not* to link box 1 from series 4 to box 1 that's in series 1 - they're not the same box -- or the one in series 2, etc.  So, I'm pretty sure that's the primary reason behind this design decision.

Of course, that does *not* mean that the display string in the typeahead must match the title of the box on the top container screen, or that additional data elements couldn't live on this page. We just don't use those pages in the way that you're describing, so our feedback during the initial development of this feature was to make sure that it would work for our day to day work, and also to ensure that it was completely compatible with the old database model (which was pretty tricky to handle, especially given all of the ways to create top containers, like with imports and the RDE tool).

Mark

P.S.  It certainly should be the source of this data, but I'm pretty sure that it's only going to grab series-level information if it's tagged as such at the c01 level, in EAD speak.


From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A.
Sent: Wednesday, 18 May, 2016 2:27 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Question about intent behind container information

Mark:

Thank you so much for responding.

You must need be able to recognize a box so that you know you are interacting with the right box record.  I am confused about how you can recognize the right box when what you see is something like "Series I, Series II, Box 1".  This information seems quite generic and could apply to hundreds of boxes.

I am also not certain that series-level identifier and level information is the source of this data. Is there any documentation about where this display information originates?  Is there someone who would know?

Thanks!

Kate

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, May 18, 2016 2:11 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Question about intent behind container information

I honestly don't remember, but I think it was to help us out since we have a mixture of repository policies, some of which assign multiple box 1s in a collection (starting box numbers over again with each series), and others that ensure distinct box numbers throughout an entire collection.  So, perhaps it acted as a crucial reminder to us after our migration to make sure that we didn't wind up with conflated containers in a collection when we didn't intend that to happen.



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A.
Sent: Wednesday, 18 May, 2016 1:53 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Question about intent behind container information

OK, I see that. However, why is it then showing series information?

Kate

From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Custer, Mark
Sent: Wednesday, May 18, 2016 1:35 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Question about intent behind container information

Kate,

That is the expected display when viewing a top container page all by itself.  That's not to say that other information displaying on this page wouldn't be helpful, though!  One reason that we didn't go with the Resource/Accession title here is because it's possible to have more than one resource within a single top container.  That said, it would be useful to display that information if feasible, and we've also requested to see other container information in the Linked Records table that's just below the bottom of the screen shot that you sent (e.g. I know I'm looking at the contents of a box 1, but do those titles have folder numbers assigned to them, 'cause really, I'm trying to navigate to folder 10 right now?).

We do almost all of our work with top containers by going through the "Manage Top Containers" feature.  Users will need to have the appropriate permissions to use that tool, though (assigning those permissions is described in the documentation that you linked to below).

For example, I just created a test repository that has two top containers in it.  One top container houses two collections, and the other just houses part of the second collection.  We don't manage those containers directly from their top container pages.  Instead, we manage them in bulk (or find a single one by scanning in a barcode in the keyword field).  Here's what that should look like, and here's where'll you see a lot more information about the top container:

[cid:image001.png at 01D1B12A.657D2C60]

...and yes, I assigned one of those series an Arabic numeral and the other a Roman one, just to make it clear(er) that that single container housed material from two different series in two different collections.  Also note that the Resource/Accession displays both the unitid (or accession id) along with the resource/accession title.

Does that make sense?  I'd suggest using the "Manage Top Containers" feature to manage the containers exclusively, not least because you can edit them in bulk that way.

Mark



P.S.  And do you have this option in your repository dropdown section???

[cid:image002.png at 01D1B12A.657D2C60]

You'll need to be able to manage and bulk edit top containers in order to test 1.5 thoroughly.



From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Bowers, Kate A.
Sent: Wednesday, 18 May, 2016 12:42 PM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] Question about intent behind container information

We are just starting to get our heads around containers, so please excuse the very basic nature of this question.  I have checked the documentation (https://docs.archivesspace.org/Default.htm#ContainersFuncOverview.htm%3FTocPath%3DManaging%2520Containers%2520%28new%2520with%2520version%25201.5.0%29|_____0<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.archivesspace.org_Default.htm-23ContainersFuncOverview.htm-253FTocPath-253DManaging-252520Containers-252520-2528new-252520with-252520version-2525201.5.0-2529-257C-5F-5F-5F-5F-5F0&d=AwMFAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=s7ciGQfUJeaV_ryx908hbeXDoU9aqDwDN0Z0VbfsJ3Y&m=_5UNZFLKeKSAU0LF53AmFy9cA3hoR1Bsmed4wN8P1WA&s=MzDRDeyFX3BJxv-upYerab6RT7FT0_5w52f7oSgTweY&e=>), but it doesn't address where the data for displays comes from.

I am confused by what I am seeing on the screen.  It appears that the unit identifiers values ("I" and "II") and level value ("series") of the first child level in the collection have been pulled into this display. Is that the case? I would have expected that the collection unitid would be essential and would be used in any display of a box number.

Can anyone explain what is happening here, or perhaps if this is indeed what is supposed to happen?  Is this an error from the 1.5 upgrade, or is this how it is supposed to work?

[cid:image003.jpg at 01D1B12A.657D2C60]

Thanks!

Kate


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160518/bdd4c75a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16709 bytes
Desc: image001.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160518/bdd4c75a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 7716 bytes
Desc: image002.png
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160518/bdd4c75a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 43823 bytes
Desc: image003.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160518/bdd4c75a/attachment.jpg>