[Archivesspace_Users_Group] Component Unique Identifiers questions

Hughes, Margaret mhughes at library.ucla.edu
Thu Sep 20 12:54:08 EDT 2018


Larry—Thank you for sharing how you’re (not) working with the CUI. Regarding the other ASpace example for the field,  accession number, we also track that information via linked accessions or an Immediate Source of Acquisition note.

Linda and Neal – I’m glad you brought up the PUI as that’s not something we’re using right now, and so I wasn’t familiar with how the CUI is utilized in the PUI. Do I understand correctly that not being able to see where an archival object belongs in the overall hierarchy is only an issue when discovering archival objects (files, items, etc) via search? And this is because the CUI does not display in the PUI at all currently?

Lydia—I agree that a JIRA ticket about this issue is needed. I would also support having the CUI default to a public audience, have it appear before the <unittitle>, and not be visually associated with a top container.  Could it continue to be located in the same place as it is now in the staff interface’s edit mode? And we could make the CUI visible in the same place in the staff interface in view mode, as well?  I agree with the reasons you stated (working filing system, file id, etc) that the CUI should be a free-text field which *wouldn't* autopopulate the level of description.

Maggie

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Harmeyer, Neal A
Sent: Thursday, September 20, 2018 8:58 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

Thank you all for bringing up this topic. At Purdue (we are using version 2.2.1 at the moment), we do use the CUI to help distinguish the intellectual arrangement; this has proven very helpful in search results and has eliminated confusion we encountered after our migration from Archon. We use the CUI to note Collection #, Series #, and Sub-Series #, with notes of File # and/or Item# if necessary. Basically, by doing this a researcher or staff member can “drop” themselves into the intellectual arrangement of the resource and know where they are really quickly. We’re not using the EAD outputs at this time.

I would also like to join Maggie and Lydia in noting the idiosyncratic way the Level of Description displays in Instance top containers. From my experience—and someone please correct me if I am wrong—the CUI/Level of Description only displays in the Instance when Series is selected as the Level of Description. I also wonder if this is intended behavior? As noted by Maggie and Lydia’s screenshots, this can become a long string of text. Furthermore, it then is exported into the public interface-generated PDF output under Summary Information container info (see attached on page 3). This gives a greater importance to a Series than other aspects of the collection. I do not believe it is necessary to note the Level of Description/CUI the Summary Information here, as it those details are visualized and recorded elsewhere to greater effect.

Unless there is a reason behind it, I do support eliminating the display of Level of Description and CUI in the Instance top container display on the staff side and the public outputs.

Cheers,
Neal
--
Neal Harmeyer
Digital Archivist
Purdue University Archives and Special Collections
harmeyna at purdue.edu<mailto:harmeyna at purdue.edu>



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 Larry Weimer
Sent: Thursday, September 20, 2018 10:16 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

Maggie,

To answer your first question, we (New-York Historical) do not currently use the CUI field at all. We include "Series X" or "Subseries X.1" in the component title. The other ASpace example for this field, accession number, we would include in an Immediate Source of Acquisition note (though we more commonly just refer to the source by their name and date, rather than the number. We use the "Related Resource" field to link the accession number to the collection.)

Larry

Larry Weimer
Head of Archival Processing
New-York Historical Society

On Wed, Sep 19, 2018 at 6:31 PM, Hughes, Margaret <mhughes at library.ucla.edu<mailto:mhughes at library.ucla.edu>> wrote:
Confusion over the CUI field came up recently for us, as well, and we're wondering how we should move forward using it.

Regarding the first question: I'm wondering if other institutions are using the CUI to record information like "Series I" or "Subseries 8.4"? And if so, are you happy with how the CUI exports in the EAD? As far as I understand, the CUI field exports in EAD as <unitid> which comes after the title <unittitle>. Maybe this is specific to our practice, and it's something that could also be fixed with a stylesheet, but it seems like it would make more sense for the <unitid> to precede the <unittitle>, if it is indeed intended for information like "Series I" or "Subseries 8.4". Then the result in the EAD would likely display as "Series 1 Correspondence". If institutions are not using the CUI to record "Series 1", are you including that in the title field? Or not noting series and subseries numbers at all?

Relating to the second question, as you said the top container field pulls and displays both the Level of Description (if it is "series") and the information in the CUI, so it results in top containers like “Series Series X". Is this the intended behavior? My inclination is that displaying this information in the top container does not make sense and is not helpful, especially in cases where containers belong to multiple series. I tested it with adding a box to four different series and it lists all four in the top container (see attached screenshot). Are others experiencing this and accepting it/ignoring it?

Any help is much appreciated!

Maggie


-----Original Message-----
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<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Tang, Lydia
Sent: Monday, September 17, 2018 10:07 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] Component Unique Identifiers questions

Hi all,
I’m passing along a question for a friend and then have a set of slightly related questions of my own:

  1.  I am trying to find a way to have a series identifier code appear on the finding aid.  The Component Unique Identifier does not appear to print, and the only examples I have come across have just added Series 1 to the beginning of the series name as in:
Series 1. Athletic Council records, 1903-1975.  Does anyone use the Series code on your finding aid, and if so, where do you add it?
  2.  My question: I have a legacy imported collection which uses the Series info in the CUI.  It displays as “Series Series X” in the top container field.  Sorry if I’m stating the obvious, but this label pulls the first “series” from the level of description – only if it is at a series level (I tried changing it to subseries and other smaller levels) and the rest is free text from the CUI.  When there are materials from more than one series are shared in a Top Container, it lists off possibly up to two series (it didn’t seem like it listed off 3 or more, but I might have been confusing myself).  I am not sure that Staff Interface recommendations by SIEWG touched on the CUI, so I wanted to ask:
     *   Would it be helpful to have a publish function for the CUI?  Just trying to imagine it, it would be an established default setting with a check box to manually change.
     *   Is displaying the information in the Top Container the most efficient/logical place - especially in cases of extensive intellectual arrangement of items belonging to multiple series sharing a container?  There is a JIRA relating to CUI display: https://archivesspace.atlassian.net/browse/ANW-279  Does this resonate with the broader membership (you all)?
     *   Is deriving a portion of the label from the level of description for the CUI universally helpful?  How about in cases of electronic file names or labeling physical objects with the corresponding scanned object identifier?  Alternatively, would enabling this action for smaller levels of description (sub-series, file, item, etc), be helpful?
I’m just trying to wrap my head around it, so any feedback/clarifications are greatly appreciated!
Lydia
--
Dr. Lydia Tang, CA, DAS, DMA, MLIS
Special Collections Archivist-Librarian
Philosophy, Aesthetics, and Ethics Bibliographer Michigan State University Libraries
366 W. Circle Drive (DB 6)
East Lansing, MI 48824-1048
Email: ltang5 at msu.edu<mailto:ltang5 at msu.edu>
Phone: 517-884-8984

_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group


[Image removed by sender.]<http://www.nyhistory.org/exhibitions/walk-way-footwear-stuart-weitzman>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180920/e841d5e5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image001.jpg
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180920/e841d5e5/attachment.jpg>


More information about the Archivesspace_Users_Group mailing list