[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-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> On Behalf Of Rachel Aileen Searcy
Sent: Tuesday, November 6, 2018 9:38 AM
To: Archivesspace Users Group <archivesspace_users_group at 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&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko&m=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o&s=oGY6499D7rcudpNsvJYpkct1MJgdGPGj-M44Pg9DlNI&e=>). 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&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko&m=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o&s=DU2fH99VS6HGDcQwtaqNbP70YUuUHHzoiAvKfOybgk0&e=>, as well as instructions<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_11kWxbFTazB6q5fDNBWDHJxMf3wdVsp8cd7HzjEhE-2Dao_edit-23&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=F0JE8U9-xhxe_nE7d7aEUi-uqfKqvYJ222bS0oz9mko&m=a8VhzFOWwpTiqB1van_vrBlDJZ3W0W2hIqSQFWtyA7o&s=-JgXLLuZk9sdTeKhnhLQgx03FobqKtmMxNdXVopJOcI&e=> 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 <mayoc at bc.edu<mailto:mayoc at 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_NNNNN" where the numerical portion is pulled from the 'archival_object_NNNNN' 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.Pruitt at tufts.edu<mailto:Adrienne.Pruitt at 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.pruitt at tufts.edu<mailto:adrienne.pruitt at tufts.edu> |617-627-0957
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group<https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwMFaQ&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=S8ME4Fo5XAeEtz-SEJljWkmvBYIPb_6ILuGWdUkOXtE&s=fTvu_1amNaLXp4WRGkvgY0OdpV3LaA82ly7l70dQZjc&e=>


--
Chris Mayo
Digital Production Librarian
Thomas P. O'Neill, Jr. Library
Boston College
chris.mayo at bc.edu<mailto:chris.mayo at bc.edu>
_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org<mailto:Archivesspace_Users_Group at lyralists.lyrasis.org>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lyralists.lyrasis.org_mailman_listinfo_archivesspace-5Fusers-5Fgroup&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=WwSkYr7X9POdZNK4180yTjrK5hSljcuCPIN--y1VRZk&m=S8ME4Fo5XAeEtz-SEJljWkmvBYIPb_6ILuGWdUkOXtE&s=fTvu_1amNaLXp4WRGkvgY0OdpV3LaA82ly7l70dQZjc&e=


--
Rachel Searcy
Accessioning Archivist, Archival Collections Management
New York University Libraries
212.998.2539 | rachel.searcy at nyu.edu<mailto:rachel.searcy at nyu.edu>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20181106/04bdc4f2/attachment.html>