Re: [Archivesspace_Users_Group] Component unique identifiers

[Arnold, Hillel]

We also tend to use refIDs for digitization. We’ve tried to look at their 
length and semantic meaninglessness as an advantage, and an opportunity to 
examine our workflows for places where colleagues are doing a lot of manual 
data entry, and to replace those points with API calls or some other form of 
automation that doesn’t force folks to do a lot of copying and pasting. The 
`find_by_id` endpoint is super useful for this.

Another option are ArchivesSpace’s external IDs. You can save as many as you 
want and, more importantly, you can specify where the identifier comes from, 
which can be super useful if you have an environment where there are multiple 
identifier sets which get used for specific things. Although these aren’t 
visible in the UI by default, it looks like you can turn them on in the 
config.rb file: 
https://archivesspace.github.io/archivesspace/user/configuring-archivesspace/ 
I’m not sure if these get exported in EAD or anything, but thought I’d throw 
that out there as an option.

Hillel

From:  on behalf of 
"Pruitt, Adrienne" 
Reply-To: Archivesspace Users Group 

Date: Tuesday, November 6, 2018 at 11:22 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Thanks for all of your very helpful responses, everybody!

We have been investigating use of the digitization plug-in, which looks great. 
However, our digitization workflow (especially digitization on demand) usually 
involves items that don’t have pre-existing metadata, which makes it less 
suitable at the moment, since our display system requires item-level metadata. 
As we move into a system that can handle complex objects, and also try out the 
PUI, it sounds like there are a couple of solutions here that might work for 
us. We will probably be contacting some of you with further questions – thanks 
again!

-Adrienne

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Noah Huffman
Sent: 6 November 2018 11:10 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

John’s message reminded me that at Duke, our repository items have 
externally-minted and persistent ARKs. When we created digital object records 
in ASpace based on our repository objects using the service I described 
previously, we store those ARKs in the digital object identifier field in 
ArchivesSpace. So, basically we have two identifiers that connect records in 
ArchivesSpace with records in our repository (the refID and the ARK).  In our 
shop, the refID is really useful for starting and facilitating the digitization 
workflow, but the ARK is more stable.

I’m still not sure we have the most elegant setup and there are a lot of 
identifiers floating around, but it seems to be working for us so far…

-Noah

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Rees, John (NIH/NLM) [E]
Sent: Tuesday, November 6, 2018 10:59 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Wow, this is super helpful.

We’ve been noodling on a similar use case. All our existing repository projects 
leverage our MARC 035 field ids (Voyager ILS-supplied) to mint ids/Fedora PIDs, 
but now we’re embarking on ASpace projects that don’t always have a Voyager 
record, or have ID minting practices from other external systems that we can’t 
replicate in ASpace - or maybe don’t want to.

We’re still struggling with what the ID should actually be – we’re wary of 
using internally-generated IDs.

John

John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
301-827-4510



From: Rachel Aileen Searcy mailto:rachel.sea...@nyu.edu>>
Sent: Tuesday, November 06, 2018 9:38 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied on 
the shorter Archivist's Toolkit refids for file naming, but this became 
untenable with those created by ArchivesSpace. We didn't want to change our 
inter-departmental workflows too radically, so we contracted with HM to develop 
a plugin called the Digitization Work Order plugin (here on 
github<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hudmol_digitization-5Fwork-5Forder=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=T7i8Vt9h589_N4UGea1yf4aXt6K5RSTeDqaAG4Tcg3U=>).
 This plugin allows the user to select individual

Re: [Archivesspace_Users_Group] Component unique identifiers

[Pruitt, Adrienne]

Thanks for all of your very helpful responses, everybody!

We have been investigating use of the digitization plug-in, which looks great. 
However, our digitization workflow (especially digitization on demand) usually 
involves items that don’t have pre-existing metadata, which makes it less 
suitable at the moment, since our display system requires item-level metadata. 
As we move into a system that can handle complex objects, and also try out the 
PUI, it sounds like there are a couple of solutions here that might work for 
us. We will probably be contacting some of you with further questions – thanks 
again!

-Adrienne

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Noah Huffman
Sent: 6 November 2018 11:10 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

John’s message reminded me that at Duke, our repository items have 
externally-minted and persistent ARKs. When we created digital object records 
in ASpace based on our repository objects using the service I described 
previously, we store those ARKs in the digital object identifier field in 
ArchivesSpace. So, basically we have two identifiers that connect records in 
ArchivesSpace with records in our repository (the refID and the ARK).  In our 
shop, the refID is really useful for starting and facilitating the digitization 
workflow, but the ARK is more stable.

I’m still not sure we have the most elegant setup and there are a lot of 
identifiers floating around, but it seems to be working for us so far…

-Noah

From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Rees, John (NIH/NLM) [E]
Sent: Tuesday, November 6, 2018 10:59 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Wow, this is super helpful.

We’ve been noodling on a similar use case. All our existing repository projects 
leverage our MARC 035 field ids (Voyager ILS-supplied) to mint ids/Fedora PIDs, 
but now we’re embarking on ASpace projects that don’t always have a Voyager 
record, or have ID minting practices from other external systems that we can’t 
replicate in ASpace - or maybe don’t want to.

We’re still struggling with what the ID should actually be – we’re wary of 
using internally-generated IDs.

John

John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
301-827-4510



From: Rachel Aileen Searcy mailto:rachel.sea...@nyu.edu>>
Sent: Tuesday, November 06, 2018 9:38 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied on 
the shorter Archivist's Toolkit refids for file naming, but this became 
untenable with those created by ArchivesSpace. We didn't want to change our 
inter-departmental workflows too radically, so we contracted with HM to develop 
a plugin called the Digitization Work Order plugin (here on 
github<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hudmol_digitization-5Fwork-5Forder=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=T7i8Vt9h589_N4UGea1yf4aXt6K5RSTeDqaAG4Tcg3U=>).
 This plugin allows the user to select individual components from a resource 
record (including all if desired), which are then assigned sequential component 
unique identifiers that can be used for file naming or other purposes. The 
plugin also produces a csv of descriptive information of those components, and 
automatically inserts this newly created identifier into the components 
Component Unique Identifier field. We have some demo slides 
here<https://urldefense.proofpoint.com/v2/url?u=https-3A__guides.nyu.edu_ld.php-3Fcontent-5Fid-3D26740399=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=sxduklMTsEb7_XFdBr5_vnRGHkUGLA6omAWn1IGBo1s=>,
 as well as 
instructions<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-2Dao_edit=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=fOyyOc5DCDx0rAcVskO3M1WWo02JAOrFVrU1bGprZQ4=>
 in our local ArchivesSpace manual. I'd also be happy to talk further to answer 
any questions.

Best,
Rachel

On Mon, Nov 5, 2018 at 2:54 PM Chris Mayo mailto:ma...@bc.edu>> 
wrote:
Hi Adrienne,

We ran into a

Re: [Archivesspace_Users_Group] Component unique identifiers

[Noah Huffman]

John’s message reminded me that at Duke, our repository items have 
externally-minted and persistent ARKs. When we created digital object records 
in ASpace based on our repository objects using the service I described 
previously, we store those ARKs in the digital object identifier field in 
ArchivesSpace. So, basically we have two identifiers that connect records in 
ArchivesSpace with records in our repository (the refID and the ARK).  In our 
shop, the refID is really useful for starting and facilitating the digitization 
workflow, but the ARK is more stable.

I’m still not sure we have the most elegant setup and there are a lot of 
identifiers floating around, but it seems to be working for us so far…

-Noah

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Rees, 
John (NIH/NLM) [E]
Sent: Tuesday, November 6, 2018 10:59 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Wow, this is super helpful.

We’ve been noodling on a similar use case. All our existing repository projects 
leverage our MARC 035 field ids (Voyager ILS-supplied) to mint ids/Fedora PIDs, 
but now we’re embarking on ASpace projects that don’t always have a Voyager 
record, or have ID minting practices from other external systems that we can’t 
replicate in ASpace - or maybe don’t want to.

We’re still struggling with what the ID should actually be – we’re wary of 
using internally-generated IDs.

John

John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
301-827-4510



From: Rachel Aileen Searcy mailto:rachel.sea...@nyu.edu>>
Sent: Tuesday, November 06, 2018 9:38 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied on 
the shorter Archivist's Toolkit refids for file naming, but this became 
untenable with those created by ArchivesSpace. We didn't want to change our 
inter-departmental workflows too radically, so we contracted with HM to develop 
a plugin called the Digitization Work Order plugin (here on 
github<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hudmol_digitization-5Fwork-5Forder=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=T7i8Vt9h589_N4UGea1yf4aXt6K5RSTeDqaAG4Tcg3U=>).
 This plugin allows the user to select individual components from a resource 
record (including all if desired), which are then assigned sequential component 
unique identifiers that can be used for file naming or other purposes. The 
plugin also produces a csv of descriptive information of those components, and 
automatically inserts this newly created identifier into the components 
Component Unique Identifier field. We have some demo slides 
here<https://urldefense.proofpoint.com/v2/url?u=https-3A__guides.nyu.edu_ld.php-3Fcontent-5Fid-3D26740399=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=sxduklMTsEb7_XFdBr5_vnRGHkUGLA6omAWn1IGBo1s=>,
 as well as 
instructions<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-2Dao_edit=DwMGaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=egSNa_E82CniRdk2kD1V-niZbqO7XVArIMZPAwDN1cs=fOyyOc5DCDx0rAcVskO3M1WWo02JAOrFVrU1bGprZQ4=>
 in our local ArchivesSpace manual. I'd also be happy to talk further to answer 
any questions.

Best,
Rachel

On Mon, Nov 5, 2018 at 2:54 PM Chris Mayo mailto:ma...@bc.edu>> 
wrote:
Hi Adrienne,

We ran into a similar issue at Boston College when we migrated from to ASpace 
from Toolkit. Our practice had been to combine the collection ID with an 
auto-generated refID to create component unique identifiers, but the 
auto-generated refIDs in Aspace were much too long for our needs.

What we eventually wound up doing is using the database primary key for a given 
archival object as the unique part of its component unique ID, so that any 
given for an archival object we're planning to digitize gets a CUI with the 
format of 'mmsID_N" where the numerical portion is pulled from the 
'archival_object_N' at the end of the archival object's URL. The really 
handy part of this is that it lets us parse our CUIs to make API calls. It's 
also robust to rearrangement, if you are only moving the archival object around 
within the collection hierarchy - the database key remains the same. It doesn't 
survive reprocessing, however, if you are deleting/rebuilding/combining 
archival objects, so we always make sure to begin the process of digitization 
after a collection has been processed or reprocessed. It makes t

Re: [Archivesspace_Users_Group] Component unique identifiers

[Rees, John (NIH/NLM) [E]]

Wow, this is super helpful.

We’ve been noodling on a similar use case. All our existing repository projects 
leverage our MARC 035 field ids (Voyager ILS-supplied) to mint ids/Fedora PIDs, 
but now we’re embarking on ASpace projects that don’t always have a Voyager 
record, or have ID minting practices from other external systems that we can’t 
replicate in ASpace - or maybe don’t want to.

We’re still struggling with what the ID should actually be – we’re wary of 
using internally-generated IDs.

John

John P. Rees
Archivist and Digital Resources Manager
History of Medicine Division
National Library of Medicine
301-827-4510



From: Rachel Aileen Searcy 
Sent: Tuesday, November 06, 2018 9:38 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied on 
the shorter Archivist's Toolkit refids for file naming, but this became 
untenable with those created by ArchivesSpace. We didn't want to change our 
inter-departmental workflows too radically, so we contracted with HM to develop 
a plugin called the Digitization Work Order plugin (here on 
github<https://github.com/hudmol/digitization_work_order>). This plugin allows 
the user to select individual components from a resource record (including all 
if desired), which are then assigned sequential component unique identifiers 
that can be used for file naming or other purposes. The plugin also produces a 
csv of descriptive information of those components, and automatically inserts 
this newly created identifier into the components Component Unique Identifier 
field. We have some demo slides 
here<https://guides.nyu.edu/ld.php?content_id=26740399>, as well as 
instructions<https://docs.google.com/document/d/11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-ao/edit>
 in our local ArchivesSpace manual. I'd also be happy to talk further to answer 
any questions.

Best,
Rachel

On Mon, Nov 5, 2018 at 2:54 PM Chris Mayo mailto:ma...@bc.edu>> 
wrote:
Hi Adrienne,

We ran into a similar issue at Boston College when we migrated from to ASpace 
from Toolkit. Our practice had been to combine the collection ID with an 
auto-generated refID to create component unique identifiers, but the 
auto-generated refIDs in Aspace were much too long for our needs.

What we eventually wound up doing is using the database primary key for a given 
archival object as the unique part of its component unique ID, so that any 
given for an archival object we're planning to digitize gets a CUI with the 
format of 'mmsID_N" where the numerical portion is pulled from the 
'archival_object_N' at the end of the archival object's URL. The really 
handy part of this is that it lets us parse our CUIs to make API calls. It's 
also robust to rearrangement, if you are only moving the archival object around 
within the collection hierarchy - the database key remains the same. It doesn't 
survive reprocessing, however, if you are deleting/rebuilding/combining 
archival objects, so we always make sure to begin the process of digitization 
after a collection has been processed or reprocessed. It makes the CUIs 
somewhat semantically meaningful - but only if you know what you are looking 
at. We're still not sure how we feel about that, but it's what works for us for 
now.

Hope that helps!
Best,
Chris

On Mon, Nov 5, 2018 at 11:00 AM Pruitt, Adrienne 
mailto:adrienne.pru...@tufts.edu>> wrote:
Hello, all,

We’re hoping to move away from semantically meaningful component unique 
identifiers, but need some way to be able to easily auto-generate a unique 
identifier that could be used for file-naming purposes in digitization 
projects. Working with legacy data, we have seen that there can be value in 
being able to easily associate a binary file floating around on a server 
somewhere with a relatively easily parsed identifier that links it to its 
related metadata. However, semantically meaningful identifiers based on 
collection structure  are a rather brittle system prone to breaking when 
collections are rearranged or reprocessed and easy to mis-enter when working 
with so many digits. We’re interested to hear how others are handling their 
identifiers (particularly in regards to digitization workflows.)

Thank you!

Adrienne Pruitt | Collections Management Archivist
Digital Collections and Archives
Tufts University
adrienne.pru...@tufts.edu<mailto:adrienne.pru...@tufts.edu> |617-627-0957
___
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=DwMFaQ=slrrB7dE8n7gBJbeO0g-IQ=WwSkYr7X

Re: [Archivesspace_Users_Group] Component unique identifiers

[Noah Huffman]

Hi all,

Just a +1 for the NYU Digitization Work Order plugin. We make use of that 
plugin at Duke in our digitization workflow, although instead of adding 
component unique identifiers we just use the Ref ID field as the key that 
unites our digital object metadata (stored in Fedora) with ASpace. For the most 
part, we have abandoned semantic filenames so that we can accommodate existing 
filenames for born-digital materials and filenames that may have been generated 
by other units on campus that we might not control.

We created a service in our repository that can post (in batch) very basic 
digital object records to ArchivesSpace and then link those digital objects to 
existing archival objects using the ASpace ref_ID values stored in our 
repository. Then, we can publish finding aids that include links to digital 
objects in our repository and well as embedded image, audio, and video files.

Happy to explain more if folks are interested,

-Noah


Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Rachel 
Aileen Searcy
Sent: Tuesday, November 6, 2018 9:38 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component unique identifiers

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied on 
the shorter Archivist's Toolkit refids for file naming, but this became 
untenable with those created by ArchivesSpace. We didn't want to change our 
inter-departmental workflows too radically, so we contracted with HM to develop 
a plugin called the Digitization Work Order plugin (here on 
github<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_hudmol_digitization-5Fwork-5Forder=DwMFaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o=oGY6499D7rcudpNsvJYpkct1MJgdGPGj-M44Pg9DlNI=>).
 This plugin allows the user to select individual components from a resource 
record (including all if desired), which are then assigned sequential component 
unique identifiers that can be used for file naming or other purposes. The 
plugin also produces a csv of descriptive information of those components, and 
automatically inserts this newly created identifier into the components 
Component Unique Identifier field. We have some demo slides 
here<https://urldefense.proofpoint.com/v2/url?u=https-3A__guides.nyu.edu_ld.php-3Fcontent-5Fid-3D26740399=DwMFaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o=DU2fH99VS6HGDcQwtaqNbP70YUuUHHzoiAvKfOybgk0=>,
 as well as 
instructions<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-2Dao_edit-23=DwMFaQ=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o=-JgXLLuZk9sdTeKhnhLQgx03FobqKtmMxNdXVopJOcI=>
 in our local ArchivesSpace manual. I'd also be happy to talk further to answer 
any questions.

Best,
Rachel

On Mon, Nov 5, 2018 at 2:54 PM Chris Mayo mailto:ma...@bc.edu>> 
wrote:
Hi Adrienne,

We ran into a similar issue at Boston College when we migrated from to ASpace 
from Toolkit. Our practice had been to combine the collection ID with an 
auto-generated refID to create component unique identifiers, but the 
auto-generated refIDs in Aspace were much too long for our needs.

What we eventually wound up doing is using the database primary key for a given 
archival object as the unique part of its component unique ID, so that any 
given for an archival object we're planning to digitize gets a CUI with the 
format of 'mmsID_N" where the numerical portion is pulled from the 
'archival_object_N' at the end of the archival object's URL. The really 
handy part of this is that it lets us parse our CUIs to make API calls. It's 
also robust to rearrangement, if you are only moving the archival object around 
within the collection hierarchy - the database key remains the same. It doesn't 
survive reprocessing, however, if you are deleting/rebuilding/combining 
archival objects, so we always make sure to begin the process of digitization 
after a collection has been processed or reprocessed. It makes the CUIs 
somewhat semantically meaningful - but only if you know what you are looking 
at. We're still not sure how we feel about that, but it's what works for us for 
now.

Hope that helps!
Best,
Chris

On Mon, Nov 5, 2018 at 11:00 AM Pruitt, Adrienne 
mailto:adrienne.pru...@tufts.edu>> wrote:
Hello, all,

We’re hoping to move away from semantically meaningful component unique 
identifiers, but need some way to be able to easily auto-generate a unique 

Re: [Archivesspace_Users_Group] Component unique identifiers

[Rachel Aileen Searcy]

Hi Adrienne,

We had a similar issue here at NYU. Previous digitization projects relied
on the shorter Archivist's Toolkit refids for file naming, but this became
untenable with those created by ArchivesSpace. We didn't want to change our
inter-departmental workflows too radically, so we contracted with HM to
develop a plugin called the Digitization Work Order plugin (here on github
). This plugin allows
the user to select individual components from a resource record (including
all if desired), which are then assigned sequential component unique
identifiers that can be used for file naming or other purposes. The plugin
also produces a csv of descriptive information of those components, and
automatically inserts this newly created identifier into the components
Component Unique Identifier field. We have some demo slides here
, as well as instructions

in our local ArchivesSpace manual. I'd also be happy to talk further to
answer any questions.

Best,
Rachel

On Mon, Nov 5, 2018 at 2:54 PM Chris Mayo  wrote:

> Hi Adrienne,
>
> We ran into a similar issue at Boston College when we migrated from to
> ASpace from Toolkit. Our practice had been to combine the collection ID
> with an auto-generated refID to create component unique identifiers, but
> the auto-generated refIDs in Aspace were much too long for our needs.
>
> What we eventually wound up doing is using the database primary key for a
> given archival object as the unique part of its component unique ID, so
> that any given for an archival object we're planning to digitize gets a CUI
> with the format of 'mmsID_N" where the numerical portion is pulled from
> the 'archival_object_N' at the end of the archival object's URL. The
> really handy part of this is that it lets us parse our CUIs to make API
> calls. It's also robust to rearrangement, if you are only moving the
> archival object around within the collection hierarchy - the database key
> remains the same. It doesn't survive reprocessing, however, if you are
> deleting/rebuilding/combining archival objects, so we always make sure to
> begin the process of digitization after a collection has been processed or
> reprocessed. It makes the CUIs somewhat semantically meaningful - but only
> if you know what you are looking at. We're still not sure how we feel about
> that, but it's what works for us for now.
>
> Hope that helps!
> Best,
> Chris
>
> On Mon, Nov 5, 2018 at 11:00 AM Pruitt, Adrienne <
> adrienne.pru...@tufts.edu> wrote:
>
>> Hello, all,
>>
>> We’re hoping to move away from semantically meaningful component unique
>> identifiers, but need some way to be able to easily auto-generate a unique
>> identifier that could be used for file-naming purposes in digitization
>> projects. Working with legacy data, we have seen that there can be value in
>> being able to easily associate a binary file floating around on a server
>> somewhere with a relatively easily parsed identifier that links it to its
>> related metadata. However, semantically meaningful identifiers based on
>> collection structure  are a rather brittle system prone to breaking when
>> collections are rearranged or reprocessed and easy to mis-enter when
>> working with so many digits. We’re interested to hear how others are
>> handling their identifiers (particularly in regards to digitization
>> workflows.)
>>
>> Thank you!
>>
>> *Adrienne Pruitt *| Collections Management Archivist
>> Digital Collections and Archives
>> Tufts University
>> adrienne.pru...@tufts.edu |617-627-0957
>> ___
>> Archivesspace_Users_Group mailing list
>> Archivesspace_Users_Group@lyralists.lyrasis.org
>> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>> 
>>
>
>
> --
> Chris Mayo
> Digital Production Librarian
> Thomas P. O'Neill, Jr. Library
> Boston College
> chris.m...@bc.edu
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup=DwICAg=slrrB7dE8n7gBJbeO0g-IQ=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk=S8ME4Fo5XAeEtz-SEJljWkmvBYIPb_6ILuGWdUkOXtE=fTvu_1amNaLXp4WRGkvgY0OdpV3LaA82ly7l70dQZjc=
>


-- 
Rachel Searcy
Accessioning Archivist, Archival Collections Management
New York University Libraries
212.998.2539 | rachel.sea...@nyu.edu
___
Archivesspace_Users_Group 

Re: [Archivesspace_Users_Group] Component unique identifiers

[Chris Mayo]

Hi Adrienne,

We ran into a similar issue at Boston College when we migrated from to
ASpace from Toolkit. Our practice had been to combine the collection ID
with an auto-generated refID to create component unique identifiers, but
the auto-generated refIDs in Aspace were much too long for our needs.

What we eventually wound up doing is using the database primary key for a
given archival object as the unique part of its component unique ID, so
that any given for an archival object we're planning to digitize gets a CUI
with the format of 'mmsID_N" where the numerical portion is pulled from
the 'archival_object_N' at the end of the archival object's URL. The
really handy part of this is that it lets us parse our CUIs to make API
calls. It's also robust to rearrangement, if you are only moving the
archival object around within the collection hierarchy - the database key
remains the same. It doesn't survive reprocessing, however, if you are
deleting/rebuilding/combining archival objects, so we always make sure to
begin the process of digitization after a collection has been processed or
reprocessed. It makes the CUIs somewhat semantically meaningful - but only
if you know what you are looking at. We're still not sure how we feel about
that, but it's what works for us for now.

Hope that helps!
Best,
Chris

On Mon, Nov 5, 2018 at 11:00 AM Pruitt, Adrienne 
wrote:

> Hello, all,
>
> We’re hoping to move away from semantically meaningful component unique
> identifiers, but need some way to be able to easily auto-generate a unique
> identifier that could be used for file-naming purposes in digitization
> projects. Working with legacy data, we have seen that there can be value in
> being able to easily associate a binary file floating around on a server
> somewhere with a relatively easily parsed identifier that links it to its
> related metadata. However, semantically meaningful identifiers based on
> collection structure  are a rather brittle system prone to breaking when
> collections are rearranged or reprocessed and easy to mis-enter when
> working with so many digits. We’re interested to hear how others are
> handling their identifiers (particularly in regards to digitization
> workflows.)
>
> Thank you!
>
> *Adrienne Pruitt *| Collections Management Archivist
> Digital Collections and Archives
> Tufts University
> adrienne.pru...@tufts.edu |617-627-0957
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>


-- 
Chris Mayo
Digital Production Librarian
Thomas P. O'Neill, Jr. Library
Boston College
chris.m...@bc.edu
___
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

[Tang, Lydia]

Thanks for bringing this up, Adrienne!
Would you (and others) be willing to share your perspective on the following 
tickets?
https://archivesspace.atlassian.net/browse/ANW-770
https://archivesspace.atlassian.net/browse/ANW-780
I think it would be helpful to hear about the diverse approaches to how CUIs 
are being used.  Ideally, it may also be helpful to upload a sample EAD file to 
the sandbox (http://test.archivesspace.org/staff/) for developers to “play” 
with - it would be great to have at least one representative from an 
institution that has the specific series and box numbering issue, as well as 
yours.
Thanks!
Lydia
-on behalf of Dev. Pri.

From:  on behalf of 
"Pruitt, Adrienne" 
Reply-To: Archivesspace Users Group 

Date: Monday, November 5, 2018 at 11:01 AM
To: "archivesspace_users_group@lyralists.lyrasis.org" 

Subject: [Archivesspace_Users_Group] Component unique identifiers

Hello, all,

We’re hoping to move away from semantically meaningful component unique 
identifiers, but need some way to be able to easily auto-generate a unique 
identifier that could be used for file-naming purposes in digitization 
projects. Working with legacy data, we have seen that there can be value in 
being able to easily associate a binary file floating around on a server 
somewhere with a relatively easily parsed identifier that links it to its 
related metadata. However, semantically meaningful identifiers based on 
collection structure  are a rather brittle system prone to breaking when 
collections are rearranged or reprocessed and easy to mis-enter when working 
with so many digits. We’re interested to hear how others are handling their 
identifiers (particularly in regards to digitization workflows.)

Thank you!

Adrienne Pruitt | Collections Management Archivist
Digital Collections and Archives
Tufts University
adrienne.pru...@tufts.edu |617-627-0957
___
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]

Cory,


Thank you so much for this. I will send it to our developer and see if he can 
set it up. When/if we implement container management, we can change it back.


Thanks again!

Linda



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Cory 
Nimer 
Sent: Friday, September 21, 2018 4:00 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions


Linda,



We are still working on our PUI implementation locally, but I believe it should 
be possible to set your ArchivesSpace configuration options to display a 
composite identifier rather than just the immediate CUI level/value. This would 
prevent having to reenter data for each component, while providing a public 
view of the whole string. With the composite identifier option enabled, rather 
than displaying "Item 1" in the linked example, it should appear as "2012-07-0 
Series 1 Sub-Series 1 Item 1" at that item level. The delimiter between the 
different levels' CUIs and the optional inclusion of the level of description 
is also configurable. Instructions are available in the roll-out documentation 
at 
https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/103209762/Public+Interface+Documentation+for+staff#PublicInterfaceDocumentation(forstaff)-CompositeIdentifierInheritance,
 and in the configuration documentation 
(http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/).



Information on the duplication of the level of description and the CUI value 
from the top container feature's development is available on the Yale 
ArchivesSpace guide 
(https://guides.library.yale.edu/archivesspace/ASpaceContainerManagement, at 
the bottom of the page). Their recommendation at the time seemed to be to 
remove the level information from your CUI value. Perhaps someone from Yale or 
elsewhere could weigh in about your options regarding this functionality.



Thanks,



Cory Nimer

University Archivist

Brigham Young University

801-422-6091



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Linda Hocking
Sent: Thursday, September 20, 2018 12:06 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions



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<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Hughes, Margaret 
mailto:mhug...@library.ucla.edu>>
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

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Cory Nimer]

Linda,

We are still working on our PUI implementation locally, but I believe it should 
be possible to set your ArchivesSpace configuration options to display a 
composite identifier rather than just the immediate CUI level/value. This would 
prevent having to reenter data for each component, while providing a public 
view of the whole string. With the composite identifier option enabled, rather 
than displaying "Item 1" in the linked example, it should appear as "2012-07-0 
Series 1 Sub-Series 1 Item 1" at that item level. The delimiter between the 
different levels' CUIs and the optional inclusion of the level of description 
is also configurable. Instructions are available in the roll-out documentation 
at 
https://archivesspace.atlassian.net/wiki/spaces/ADC/pages/103209762/Public+Interface+Documentation+for+staff#PublicInterfaceDocumentation(forstaff)-CompositeIdentifierInheritance,
 and in the configuration documentation 
(http://archivesspace.github.io/archivesspace/user/configuring-archivesspace/).

Information on the duplication of the level of description and the CUI value 
from the top container feature's development is available on the Yale 
ArchivesSpace guide 
(https://guides.library.yale.edu/archivesspace/ASpaceContainerManagement, at 
the bottom of the page). Their recommendation at the time seemed to be to 
remove the level information from your CUI value. Perhaps someone from Yale or 
elsewhere could weigh in about your options regarding this functionality.

Thanks,

Cory Nimer
University Archivist
Brigham Young University
801-422-6091

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Linda Hocking
Sent: Thursday, September 20, 2018 12:06 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers questions


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<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Hughes, Margaret 
mailto:mhug...@library.ucla.edu>>
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>
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf

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







From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 [mailt

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



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto: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, 

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



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto: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 ou

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<mailto: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>
 
[mailto: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 questi

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 

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=
  

Re: [Archivesspace_Users_Group] Component Unique Identifiers questions

[Hughes, Margaret]

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://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: lta...@msu.edu
Phone: 517-884-8984
___
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

[Kottman, Miloche]

Neal,

Our institution shelves materials by size and we don’t shift collections to 
accommodate additions.  This means that a collection can have multiple call 
numbers.  We use the component unique identifier to indicate at which call 
number a particular box, folder or item is shelved at.

Programmatically assigning identifiers as you suggest would likely negatively 
impact how we use this field, so, I suggest pursuing a plug-in .

--Miloche

. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Miloche Kottman
Head of Cataloging and Archival Processing
University of Kansas Libraries
Lawrence, KS 66045
mkott...@ku.edu<mailto:mkott...@ku.edu>
785-864-3916



From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Harmeyer, Neal A
Sent: Friday, May 11, 2018 9:27 AM
To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers

Good day Linda, Steve, and all,

My archives has also been working with the Component Unique Identifier (CUI) 
following a migration from Archon. At Purdue, we have begun using the CUI in a 
similar manner to Linda’s repository, manually entering the intellectual 
coordinates that reflect the place of the archival object in the intellectual 
hierarchy. The format we chose to enter is: Collection #, Series #, Sub-Series 
#, File #, Item#.

Doing so allows our staff and users to understand immediately the collection or 
intellectual grouping a researcher is requesting—this has proven very helpful 
to distinguish like-named entries in disparate collections. As an example of 
use of CUIs at Purdue, see: 
https://archives.lib.purdue.edu/repositories/2/resources/72. It’s easiest to 
view in the Collection Organization section as one scrolls down.

Like Linda’s example, we’d like to have this done programmatically, wherein the 
software can assign these coordinates immediately upon the creation/save or 
re-order of an archival object in the hierarchy.

Would this functionality be best-served as a new plug-in? Or perhaps a new 
feature?

Thank you for any thoughts,
Neal
--
Neal Harmeyer
Digital Archivist
Purdue University Archives and Special Collections
harme...@purdue.edu<mailto:harme...@purdue.edu>


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 [mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Linda Hocking
Sent: Monday, May 7, 2018 9:40 AM
To: Archivesspace Users Group 
<archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers



Steve,

A belated thank you for this reply. We do not have on site support for database 
issues, but I sent it to our consultant who just had a chance to make the 
change you suggested. It shows the identifier for the particular thing I have 
highlighted, but doesn't show where it is within the hierarchy. For example:
[cid:image001.png@01D3EB86.06257720]
Instead of File--Folder 2, I would like it to say
Series 2--Subseries 2--File-Folder 2. It does give the title for each of those 
in the blue bar, but it doesn't add the identifiers. Is it possible to add 
another line to get it to display this?

Thanks for your help!
Linda



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Majewski, Steven Dennis (sdm7g) 
<sd...@virginia.edu<mailto:sd...@virginia.edu>>
Sent: Thursday, April 12, 2018 3:31 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers


If I understand what you want correctly:

Copy public/app/views/shared/_idbadge.html.erb into 
plugins/local/public/views/shared/
( assuming local plugins are enabled ) and add a line to display 
result.identifier, for example:

$ diff -U 6   public/app/views/shared/_idbadge.html.erb   
plugins/local/public/views/shared/_idbadge.html.erb
--- public/app/views/shared/_idbadge.html.erb
2018-04-12 14:59:32.0 -0400
+++ plugins/local/public/views/shared/_idbadge.html.erb
2018-04-12 14:59:20.0 -0400
@@ -17,12 +17,13 @@
 <%= (props.fetch(:full,false)? '' : '').html_safe %>
   <% if !props.fetch(:full,false) %>
   <%== 
result.display_string %>
   <% else %>
 <%== result.display_string %>
   <% end %>
+  <%= result.identifier %>
 <%= (props.fetch(:full,false)? '' : '').html_safe %>


Since that template is shared in several places, that will add the identifier 
to other resource listings as well.
digital

Re: [Archivesspace_Users_Group] Component Unique Identifiers

[Harmeyer, Neal A]

Good day Linda, Steve, and all,

My archives has also been working with the Component Unique Identifier (CUI) 
following a migration from Archon. At Purdue, we have begun using the CUI in a 
similar manner to Linda's repository, manually entering the intellectual 
coordinates that reflect the place of the archival object in the intellectual 
hierarchy. The format we chose to enter is: Collection #, Series #, Sub-Series 
#, File #, Item#.

Doing so allows our staff and users to understand immediately the collection or 
intellectual grouping a researcher is requesting-this has proven very helpful 
to distinguish like-named entries in disparate collections. As an example of 
use of CUIs at Purdue, see: 
https://archives.lib.purdue.edu/repositories/2/resources/72. It's easiest to 
view in the Collection Organization section as one scrolls down.

Like Linda's example, we'd like to have this done programmatically, wherein the 
software can assign these coordinates immediately upon the creation/save or 
re-order of an archival object in the hierarchy.

Would this functionality be best-served as a new plug-in? Or perhaps a new 
feature?

Thank you for any thoughts,
Neal
--
Neal Harmeyer
Digital Archivist
Purdue University Archives and Special Collections
harme...@purdue.edu<mailto:harme...@purdue.edu>


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
[mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org] On Behalf Of 
Linda Hocking
Sent: Monday, May 7, 2018 9:40 AM
To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers



Steve,

A belated thank you for this reply. We do not have on site support for database 
issues, but I sent it to our consultant who just had a chance to make the 
change you suggested. It shows the identifier for the particular thing I have 
highlighted, but doesn't show where it is within the hierarchy. For example:
[cid:image001.png@01D3E912.A1556E10]
Instead of File--Folder 2, I would like it to say
Series 2--Subseries 2--File-Folder 2. It does give the title for each of those 
in the blue bar, but it doesn't add the identifiers. Is it possible to add 
another line to get it to display this?

Thanks for your help!
Linda



From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>
 
<archivesspace_users_group-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Majewski, Steven Dennis (sdm7g) 
<sd...@virginia.edu<mailto:sd...@virginia.edu>>
Sent: Thursday, April 12, 2018 3:31 PM
To: Archivesspace Users Group
Subject: Re: [Archivesspace_Users_Group] Component Unique Identifiers


If I understand what you want correctly:

Copy public/app/views/shared/_idbadge.html.erb into 
plugins/local/public/views/shared/
( assuming local plugins are enabled ) and add a line to display 
result.identifier, for example:

$ diff -U 6   public/app/views/shared/_idbadge.html.erb   
plugins/local/public/views/shared/_idbadge.html.erb
--- public/app/views/shared/_idbadge.html.erb
2018-04-12 14:59:32.0 -0400
+++ plugins/local/public/views/shared/_idbadge.html.erb
2018-04-12 14:59:20.0 -0400
@@ -17,12 +17,13 @@
 <%= (props.fetch(:full,false)? '' : '').html_safe %>
   <% if !props.fetch(:full,false) %>
   <%== 
result.display_string %>
   <% else %>
 <%== result.display_string %>
   <% end %>
+  <%= result.identifier %>
 <%= (props.fetch(:full,false)? '' : '').html_safe %>


Since that template is shared in several places, that will add the identifier 
to other resource listings as well.
digital_object listing already shows identifier next to the badge, so it looks 
a bit redundant there.
If that's not what you want, then add some qualifier on result.primary_type.
For archival_objects, identifier will display directly beneath the title in the 
'Collection Organization' tab of the resource.

- Steve Majewski



On Apr 12, 2018, at 10:18 AM, Linda Hocking 
<lhock...@litchfieldhistoricalsociety.org<mailto:lhock...@litchfieldhistoricalsociety.org>>
 wrote:

Good morning,

We've just linked our ArchivesSpace instance to our website and are trying to 
move our users away from Archon. There's one major hurdle. We migrated from 
Archon to ArchivesSpace with the first migration tool, and our only container 
instances are nonsensical records created by the import.  In most cases, our 
intellectual description matches up with the  physical location, which means if 
I can see the series number and folder number I can find the item. I'm hoping 
to find out whether we can somehow force the public interface to display the 
component unique identifiers which do not appear when I look at finding aids in 
the public interface (or in the s

Re: [Archivesspace_Users_Group] Component Unique Identifiers

[Majewski, Steven Dennis (sdm7g)]

If I understand what you want correctly:

Copy public/app/views/shared/_idbadge.html.erb into 
plugins/local/public/views/shared/ 
( assuming local plugins are enabled ) and add a line to display 
result.identifier, for example:

$ diff -U 6   public/app/views/shared/_idbadge.html.erb   
plugins/local/public/views/shared/_idbadge.html.erb 
--- public/app/views/shared/_idbadge.html.erb   2018-04-12 14:59:32.0 
-0400
+++ plugins/local/public/views/shared/_idbadge.html.erb 2018-04-12 
14:59:20.0 -0400
@@ -17,12 +17,13 @@
 <%= (props.fetch(:full,false)? '' : '').html_safe %>
   <% if !props.fetch(:full,false) %>
   <%== 
result.display_string %>
   <% else %>
 <%== result.display_string %>
   <% end %>
+  <%= result.identifier %>
 <%= (props.fetch(:full,false)? '' : '').html_safe %>
 

Since that template is shared in several places, that will add the identifier 
to other resource listings as well. 
digital_object listing already shows identifier next to the badge, so it looks 
a bit redundant there. 
If that’s not what you want, then add some qualifier on result.primary_type.
For archival_objects, identifier will display directly beneath the title in the 
‘Collection Organization’ tab of the resource.

— Steve Majewski



> On Apr 12, 2018, at 10:18 AM, Linda Hocking 
>  wrote:
> 
> Good morning,
>  
> We’ve just linked our ArchivesSpace instance to our website and are trying to 
> move our users away from Archon. There’s one major hurdle. We migrated from 
> Archon to ArchivesSpace with the first migration tool, and our only container 
> instances are nonsensical records created by the import.  In most cases, our 
> intellectual description matches up with the  physical location, which means 
> if I can see the series number and folder number I can find the item. I’m 
> hoping to find out whether we can somehow force the public interface to 
> display the component unique identifiers which do not appear when I look at 
> finding aids in the public interface (or in the staff interface without 
> viewing the particular record).
>  
> It’s going to be quite some time before I can modify every finding aid and 
> add containers, so I’m hoping in the meantime there is a temporary fix that 
> doesn’t require me logging into the staff interface (or going back to Archon) 
> every time a patron requests something. I wonder whether other Archon users 
> are having this problem, and would welcome any suggestions. Thank you!
>  
> Linda
>  
> Linda M. Hocking, CA
> Curator of Library & Archives
> Litchfield Historical Society
> P.O. Box 385
> Litchfield, CT 06759
> 860-567-4501
> http://www.litchfieldhistoricalsociety.org 
> 
> archiv...@litchfieldhistoricalsociety.org 
> 
> eboardman.tumblr.com 
>  
> ___
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group@lyralists.lyrasis.org 
> 
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group