Re: [Archivesspace_Users_Group] Alma Integration

[Megan Firestone]

Hi all,

It's great to see all this interest in an Alma/AS integration.  I created a
Google sheets with everyone who expressed interest and if there are more
who want to put their names done feel free.

Here is the link:
https://docs.google.com/spreadsheets/d/1dw7ViWhhNfy0Q_33fIqIEhzxe4p35Qj1YGF1_3hm4jg/edit?usp=sharing

Best,
Megan

On Fri, Nov 2, 2018 at 2:32 PM Hilton, Adrien 
wrote:

> Hi Everyone,
>
>
>
> It looks like the day and time that is most convenience for everyone is
> Wednesday, November 28th at 1pm Eastern. Mark your calendars. We’ll send
> out the call logistics closer to the meeting.
>
>
>
> Have a nice weekend.
>
> Adrien
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> *On Behalf Of 
> *Hilton,
> Adrien
> *Sent:* Thursday, November 1, 2018 11:07 AM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> Hi All,
>
>
>
> Looks like enough interest.
>
>
>
> Please fill out this Doodle poll with your availability following
> Thanksgiving for a conference call.
>
>
>
> https://doodle.com/poll/rdarq6tyapi8i73k
> 
>
>
>
> If you have thoughts on how to structure the meeting and/or agenda items
> feel free to send them my way.
>
>
>
> Best wishes,
>
> Adrien
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> *On Behalf Of 
> *Lacher-Feldman,
> Jessica
> *Sent:* Wednesday, October 31, 2018 6:04 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> And the University of Rochester!
>
>
>
> *From: * on
> behalf of Tara Laver 
> *Reply-To: *Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Date: *Wednesday, October 31, 2018 at 6:00 PM
> *To: *Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject: *Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> Nelson-Atkins, too.
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org [
> mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org
> ] *On Behalf Of 
> *Susan
> Luftschein
> *Sent:* Wednesday, October 31, 2018 4:52 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> As is USC.
>
>
>
> *Sue Luftschein, Ph.D.*
>
> *Head of Special Collections/Archival & Metadata Librarian*
>
> *USC Libraries Special Collections*
>
> *University of Southern California*
>
> *Doheny Memorial Library*
>
> *3550 Trousdale Parkway, Room 207*
>
> *Los Angeles, CA 90089-0189*
>
> *tel:213-740-4046* <213-740-4046>
>
> *fax:213-740-2343*
>
> *lufts...@usc.edu* 
>
>
>
> *From:* archivesspace_users_group-boun...@lyralists.lyrasis.org <
> archivesspace_users_group-boun...@lyralists.lyrasis.org> *On Behalf Of *Beth
> Kilmarx
> *Sent:* Wednesday, October 31, 2018 2:47 PM
> *To:* Archivesspace Users Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Subject:* Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> IUP is definitely interested in the Alma/Aspace intergration
>
> Sent from my iPhone
>
>
> On Oct 31, 2018, at 5:40 PM, Zhang, Bin  wrote:
>
> We at Sacramento State (part of California State University system) are
> also interested in integration between ASpace and Alma/Primo.  Like
> Northwestern and others we are considering harvesting EADs directly to
> Primo, but would like to export collection-level records to Alma…
>
>
>
> ---
>
> Bin Zhang
>
> Digital Information Services Librarian
>
> Library Systems & IT Services, University Library
>
> California State University, Sacramento
>
> +1 (916) 278-5664 | bzh...@csus.edu
>
>
>
>
>
> *From: * on
> behalf of "Custer, Mark" 
> *Reply-To: *Archivesspace Group <
> archivesspace_users_group@lyralists.lyrasis.org>
> *Date: *Wednesday, October 31, 2018 at 1:51 PM
> *To: *Archivesspace Group  >
> *Subject: *Re: [Archivesspace_Users_Group] Alma Integration
>
>
>
> Adrien, Susan, Vernica, and all:
>
>
>
> Add me to the interested list!   We are not using Alma right now, but
> since we will eventually migrate from our current ILS to another one that
> has a robust API, I’d love to keep up with what other institutions are
> doing.
>
>
>
> I’ll also say that my thoughts on the matter so far has been along the
> same lines of what Leilani and Benn mentioned – namely, bypassing the ILS,
> but we still need to get those records to WorldCat, etc.  That said, I’ve
> no clue yet whether we’ll be able to achieve that 

[Archivesspace_Users_Group] Tracking media for preservation and access

[Christie Peterson]

Hello everyone,

We're actively looking for a new system for managing information about our
A/V media, not just the content and where it lives intellectually within
archival collections, but also the format, the age and condition of the
media, and whether and when it has been migrated to other media, at a
minimum.

For example, I'd like to be able to run a report that would tell me what we
have on film that has never been forward-migrated, then another that would
tell me what has been forward-migrated, but over 10 years ago. Maybe what
was digitized to or received on DVD but never saved on networked storage.
We're talking on a scale of tens of thousands, very likely more, individual
items.

We've been asking around on specialized listservs and elsewhere, but I
thought I'd ask here as well, since we're in ArchivesSpace and would like
to implement something that works with and builds on the ASpace data we're
already spending so much time on.

It doesn't seem like there's anything out-of-the-box that will do what we
need, and a veritable garden of home-grown solutions out there. I'd love to
hear from you if you're using a system (whether home grown or not) that you
think works well.

Many thanks for your thoughts and responses,

CP

Christie S. Peterson
Manager of Technical Services for Special Collections
Smith College
cpeter...@smith.edu
she/her/hers
___
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

[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>>
 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).
 This plugin allows the user to select individual components from a resource 
record (including 

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>>
 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).
 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 mailto:ma...@bc.edu>> 
wrote:
Hi Adrienne,

We ran into a similar issue at Boston College when we migrated from 

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).
 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 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 - 

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). 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 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 |617-627-0957
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org

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).
 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 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 

[Archivesspace_Users_Group] Set-Cookie: Secure attribute

[Huebschen, Alan M]

Good morning everyone,

In my attempts to secure our installation of ArchivesSpace, I've run into an 
issue setting the "Set-Cookie" attribute through Apache. I'm currently routing 
ArchiveSpace through Apache for SSL as dictated in the HTTPS readme file, but 
it appears that ArchivesSpace only sees the http connection and does not set 
the Secure attribute. I've attempted to force the attribute to set with Apache 
but none of the settings changes seem to work when it comes to set-cookie 
(other attributes do change when set in Apache). Is there a way to force this 
attribute to be set properly?

-Alan Huebschen
Brookens Library
Information Systems
(217) 206-7115

___
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

[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