Re: [Archivesspace_Users_Group] Viewing suppressed records permission

[Hughes, Margaret]

Lisa, that’s it! Thank you so much for pointing me to that other setting.

It still seems a bit wonky, though. First I enabled the Show Suppressed under 
Global Preferences– didn’t work for other users. Then enabled the Show 
Suppressed under Repository Preferences – didn’t work for other users. Then 
enabled the Show Suppressed under User Preferences, and it is now displaying 
suppressed records to other users who should have permission to view them!

It seems redundant to have view/show suppressed be a global/repo/user 
preference setting as well as a user group permission. Also I still don’t quite 
get how the global/repo/user preferences defer to each other. But I’m glad to 
have figured this out!

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Lisa Calahan
Sent: Thursday, September 20, 2018 2:07 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Viewing suppressed records permission

Hi Margaret,

I wonder if you need to set either the Global or Repository Preference to "Show 
Suppressed?" in order to view the records? I haven't had a chance to recreate 
your issue, but that might be at play.

Lisa
[cid:image001.png@01D450ED.EE904310]

On Wed, Sep 12, 2018 at 11:05 AM, Hughes, Margaret 
mailto:mhug...@library.ucla.edu>> wrote:
Hi all,

We’re having trouble with the “view suppressed records in this repository” 
permission. I’ve recreated it in the sandbox and have attached screenshots 
here. Here are my steps:


1.   I edited the Archivists of the test repository group to give them 
permission to both suppress the major record types and view suppressed records.

2.   I created another user called “other user” and added them to the 
Archivists group. (see screenshot)

3.   I created a resource called “testing suppression”.

4.   Logged in as “other user” I suppressed the “testing suppression” 
resource.

5.   I got an error message saying I no longer had permission to view the 
record.

6.   I searched for “testing suppression” and no search results display 
(still logged in as “other user”). (see screenshot)

7.   I logged in as admin and searched for “test suppression” and the 
suppressed in included in search results. (see screenshot)

Are there any other dependent permissions that needs to be enabled that could 
be blocking the ability to view suppressed records? Am I missing something?

I know there have been other conversations about suppression being buggy – I 
actually was not able to un-suppress the test resource and crashed the sandbox 
when I tried. I searched quickly for a JIRA ticket and didn’t see this issue. 
Are institutions successfully using the suppress records functionality?

Thanks for your help!

Maggie

--
Margaret Hughes
Collections Data Archivist
310.206.6203

UCLA Library Special Collections
A1713 Charles E. Young Research Library
Los Angeles, CA 90095-1575


___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group



--
Pronouns: She/her/hers
Head of Archival Processing
University of Minnesota Libraries
Archives and Special Collections
Elmer L. Andersen Library, Suite 315
222-21st Ave. S.
Minneapolis MN 55455

Phone: 612.626.2531
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Viewing suppressed records permission

[Lisa Calahan]

Hi Margaret,

I wonder if you need to set either the Global or Repository Preference to
"Show Suppressed?" in order to view the records? I haven't had a chance to
recreate your issue, but that might be at play.

Lisa


On Wed, Sep 12, 2018 at 11:05 AM, Hughes, Margaret  wrote:

> Hi all,
>
>
>
> We’re having trouble with the “view suppressed records in this repository”
> permission. I’ve recreated it in the sandbox and have attached screenshots
> here. Here are my steps:
>
>
>
> 1.   I edited the Archivists of the test repository group to give
> them permission to both suppress the major record types and view suppressed
> records.
>
> 2.   I created another user called “other user” and added them to the
> Archivists group. (see screenshot)
>
> 3.   I created a resource called “testing suppression”.
>
> 4.   Logged in as “other user” I suppressed the “testing suppression”
> resource.
>
> 5.   I got an error message saying I no longer had permission to view
> the record.
>
> 6.   I searched for “testing suppression” and no search results
> display (still logged in as “other user”). (see screenshot)
>
> 7.   I logged in as admin and searched for “test suppression” and the
> suppressed in included in search results. (see screenshot)
>
>
>
> Are there any other dependent permissions that needs to be enabled that
> could be blocking the ability to view suppressed records? Am I missing
> something?
>
>
>
> I know there have been other conversations about suppression being buggy –
> I actually was not able to un-suppress the test resource and crashed the
> sandbox when I tried. I searched quickly for a JIRA ticket and didn’t see
> this issue. Are institutions successfully using the suppress records
> functionality?
>
>
>
> Thanks for your help!
>
>
>
> Maggie
>
>
>
> --
>
> Margaret Hughes
>
> Collections Data Archivist
>
> 310.206.6203
>
>
>
> UCLA Library Special Collections
>
> A1713 Charles E. Young Research Library
>
> Los Angeles, CA 90095-1575
>
>
>
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>


-- 
Pronouns: She/her/hers
Head of Archival Processing
University of Minnesota Libraries
Archives and Special Collections 
Elmer L. Andersen Library, Suite 315
222-21st Ave. S.
Minneapolis MN 55455

Phone: 612.626.2531
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Viewing suppressed records permission

[Hughes, Margaret]

FYI to any interested parties, I created a JIRA ticket for this issue: 
https://archivesspace.atlassian.net/browse/ANW-771

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Hughes, Margaret
Sent: Wednesday, September 12, 2018 9:06 AM
To: Archivesspace Users Group 
Subject: [Archivesspace_Users_Group] Viewing suppressed records permission

Hi all,

We're having trouble with the "view suppressed records in this repository" 
permission. I've recreated it in the sandbox and have attached screenshots 
here. Here are my steps:


1.   I edited the Archivists of the test repository group to give them 
permission to both suppress the major record types and view suppressed records.

2.   I created another user called "other user" and added them to the 
Archivists group. (see screenshot)

3.   I created a resource called "testing suppression".

4.   Logged in as "other user" I suppressed the "testing suppression" 
resource.

5.   I got an error message saying I no longer had permission to view the 
record.

6.   I searched for "testing suppression" and no search results display 
(still logged in as "other user"). (see screenshot)

7.   I logged in as admin and searched for "test suppression" and the 
suppressed in included in search results. (see screenshot)

Are there any other dependent permissions that needs to be enabled that could 
be blocking the ability to view suppressed records? Am I missing something?

I know there have been other conversations about suppression being buggy - I 
actually was not able to un-suppress the test resource and crashed the sandbox 
when I tried. I searched quickly for a JIRA ticket and didn't see this issue. 
Are institutions successfully using the suppress records functionality?

Thanks for your help!

Maggie

--
Margaret Hughes
Collections Data Archivist
310.206.6203

UCLA Library Special Collections
A1713 Charles E. Young Research Library
Los Angeles, CA 90095-1575

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Tang, Lydia]

Hi all,
Just FYI, here is my drafted JIRA ticket.  I didn’t mention anything about 
changing the placement of the CUI in the data entry of the staff interface.  
Please feel free to comment on the ticket, in case I missed or misinterpreted 
anything!
https://archivesspace.atlassian.net/browse/ANW-770

On a slightly related note, I drafted up this ticket about the Collection 
Organization view of the PUI.  I would love to start a conversation about this.
https://archivesspace.atlassian.net/browse/ANW-769
I was reading up on Yale’s usability studies, Grand Valley State U also did a 
usability study recently, and just from my own observations, and I feel like 
the collection navigation sidebar view is possibly more helpful than the 
current main view.  I’m proposing expanding the sidebar to become the primary 
view of the collection (but with box and folder visible in this view) and 
possibly if an archival component is clicked upon, it expands open within this 
view.  I noted that it’s difficult currently to see the hierarchy of a long 
finding aid and suggested that the hierarchy be collapsed but always visible in 
this view.  What do people think about this idea?  I’d love to hear your 
thoughts on the list or on the ticket.  If there’s a lot of disagreement, I can 
close the ticket.
Looking forward to hearing your thoughts!
Lydia
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Linda Hocking]

Maggie-


This is what I see when looking at a finding aid in the public interface after 
having selected a particular item from the pull down "Collection Organization" 
list-


Balance book, 1795-1796
Item 1
Item   Identifier: Item 1
Litchfield Historical Society  Elijah Boardman Papers  Elijah Boardman Business 
Papers, 1794-1824  Balance books Balance book, 1795-1796


Here's the link if you want to look at it- 
http://archives.litchfieldhistoricalsociety.org:8081/repositories/2/archival_objects/14454

So I can tell that it's Item 1, and if I clicked up to "Elijah Boardman 
Business Papers" it would show me the series number, but it won't show them 
together. I'm wary of manually entering the whole string in the CUI, but maybe 
that's the only way to get it to display. On the other hand, if I do that, and 
the system is changed to show the whole hierarchy, it will be redundant.

Anyway, for us, this is an issue of having to go through multiple steps to 
figure out where something is within the order of the collection more so than 
anything to do with the search.

Thanks,
Linda

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Hughes, 
Margaret 
Sent: Thursday, September 20, 2018 12:54 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions


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 
, 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-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Thursday, September 20, 2018 8:58 AM
To: Archivesspace Users Group 
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

harme...@purdue.edu







From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Hughes, Margaret]

Correction: I just realized that the CUI is already visible in the staff 
interface view-mode. So, in response to Lydia’s question, I wonder if we could 
keep the CUI in the same place in staff interface?

From: Hughes, Margaret
Sent: Thursday, September 20, 2018 9:54 AM
To: Archivesspace Users Group 
Subject: RE: [Archivesspace_Users_Group] Component Unique Identifiers questions

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 
, 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-boun...@lyralists.lyrasis.org
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Thursday, September 20, 2018 8:58 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@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
harme...@purdue.edu



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Larry Weimer
Sent: Thursday, September 20, 2018 10:16 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@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 
mailto:mhug...@library.ucla.edu>> wrote:
Confusion 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Hughes, Margaret]

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 
, 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-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Thursday, September 20, 2018 8:58 AM
To: Archivesspace Users Group 
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
harme...@purdue.edu



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Larry Weimer
Sent: Thursday, September 20, 2018 10:16 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@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 
mailto:mhug...@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  which comes after the title . Maybe 
this is specific to our practice, and it's something that could also be fixed 
with a 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Harmeyer, Neal A]

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
harme...@purdue.edu



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Larry Weimer
Sent: Thursday, September 20, 2018 10:16 AM
To: Archivesspace Users Group 
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 
mailto:mhug...@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  which comes after the title . 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  
to precede the , 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-boun...@lyralists.lyrasis.org
 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org]
 On Behalf Of Tang, Lydia
Sent: Monday, September 17, 2018 10:07 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@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 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Larry Weimer]

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 
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  which comes after the
> title . 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  to precede the , 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-boun...@lyralists.lyrasis.org [mailto:
> archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of
> Tang, Lydia
> Sent: Monday, September 17, 2018 10:07 AM
> To: Archivesspace Users Group  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 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Linda Hocking]

Lydia & Maggie,


I'm glad you brought this up! I am using the CUI to identify the Series, 
subseries, or item number. We are currently not using (and may decide not to 
use) the container management system. Every time I print a finding aid for 
someone (our users are not all computer savvy) I have to write those numbers in 
or manually count them. In the public interface, I can see the level of the 
item or folder I'm looking at, but not where it belongs in the overall 
hierarchy (so I can see "Item 1" but not that it's part of Series 2, Folder 7). 
It's incredibly time consuming to have to go back to the staff interface to 
figure out where something someone wants to see is. I get that the container 
management system might rectify this problem to some extent, but our 
intellectual description almost always matches physical location so it seems 
like a heck of a lot of work to implement that for little reward, especially 
since the information is in the system- there's just no good way to see it. 
Thanks again.


Linda


Linda Hocking, CA

Curator of Library & Archives

Litchfield Historical Society

P.O. Box 385

Litchfield, CT 06759

860-567-4501

lhock...@litchfieldhistoricalsociety.org

eboardman.tumblr.com



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Tang, 
Lydia 
Sent: Thursday, September 20, 2018 9:24 AM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

Hi Maggie,
Thanks for following up with my questions, I'm glad we're having this 
discussion because I think we could create a JIRA ticket about this issue if we 
(as the membership) would like to see this area potentially altered/clarified.
I personally would support having the CUI default to a public audience and have 
it appear before the , not be visually associated with a top 
container.  However, where would it be viewed instead in the staff interface?
I would prefer if the CUI was a free-text field which *wouldn't* autopopulate 
the level of description because I can think of other formats of a CUI - such 
as if someone wants to record the identifiers that the creator used for their 
working filing system or recording the corresponding file id for digitized 
content derived from the original format.  Or, are people recording this sort 
of information in a note field instead?  How would others feel about this?
Thanks!
Lydia
On 9/19/18, 6:31 PM, "archivesspace_users_group-boun...@lyralists.lyrasis.org 
on behalf of Hughes, Margaret" 
 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  which comes after the title . 
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 
 to precede the , 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-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Tang, Lydia
Sent: Monday, September 17, 2018 10:07 AM
To: Archivesspace Users Group 

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 

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Tang, Lydia]

Hi Maggie,
Thanks for following up with my questions, I'm glad we're having this 
discussion because I think we could create a JIRA ticket about this issue if we 
(as the membership) would like to see this area potentially altered/clarified.
I personally would support having the CUI default to a public audience and have 
it appear before the , not be visually associated with a top 
container.  However, where would it be viewed instead in the staff interface?  
I would prefer if the CUI was a free-text field which *wouldn't* autopopulate 
the level of description because I can think of other formats of a CUI - such 
as if someone wants to record the identifiers that the creator used for their 
working filing system or recording the corresponding file id for digitized 
content derived from the original format.  Or, are people recording this sort 
of information in a note field instead?  How would others feel about this?  
Thanks!
Lydia
On 9/19/18, 6:31 PM, "archivesspace_users_group-boun...@lyralists.lyrasis.org 
on behalf of Hughes, Margaret" 
 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  which comes after the title . 
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 
 to precede the , 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-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Tang, Lydia
Sent: Monday, September 17, 2018 10:07 AM
To: Archivesspace Users Group 

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://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_ANW-2D279=DwIGaQ=nE__W8dFE-shTxStwXtp0A=lG1-HSCEGsZJf-_mV6BDLh4PvkC3fOv47rKbM_dbh1g=cxdroSAnMNN8v-ziOfa-FfAKri3ejziRJdFf2j2n25E=eIJZHSrMBRwzDOHE6Gr1BPXa2gRqmtrrY_xI0FAb0co=