[Archivesspace_Users_Group] AT Migration problem with repository processing note

[Noah Huffman]

Hi Ian,

I’m not sure I have a great solution for this…

The refIDs in AT should be unique within the context of a resource and those refIDs should match the ASpace refID values before the underscore and extra characters assigned by the migarator (e.g. ‘ref64’ in AT becomes ‘ref64_h5n’ in ASpace).

I wonder if you could try matching on a combination of things, like the first part of the refID before the underscore and the ResourceComponent title?  These data elements are both in ATs ResourcesComponents table.  There might be some false matches here if you have lots of common titles like “Correspondence,” but if your titles are somewhat unique it might be a good strategy.  Depending on how many Repository Processing notes you’re trying to move, you could also review the matches before pushing the updates to ASpace.

A better strategy would be to match on the first part of the refID string and also the resource identifier (‘resourceIdentifier’ field in AT’s Resource table and ‘identifier’ field in AS’s resource table).  Determining the resource identifier based on a component’s refID might require some more advanced SQL.  I haven’t done this, but others on the list might have.

Any ideas?

-Noah

From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Hardy, Ian
Sent: Thursday, February 04, 2016 9:50 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org>
Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note

Hi Noah and others, one problem we're running into in moving these repository processing notes is that there doesn't appear to be a consistent identifier shared by the toolkit ResourcesCompoenents and Aspace archival_object table. In particular the persitentIDs in toolkit are not unique in Aspace, so the Aspace migrator adds some extra characters at the end to create it's identifier, the ref_ID. Anyone have a recommended methodology for matching between the platforms?

Thanks,

Ian

On Mon, Feb 1, 2016 at 4:37 PM, Hardy, Ian <ihardy at email.gwu.edu<mailto:ihardy at email.gwu.edu>> wrote:
Thanks Noah and Maureen, I was able to update some test repository processing notes using Noah's scripts as a starting point for interacting with the API. I think this will do the trick for us.

On Mon, Feb 1, 2016 at 10:52 AM, Noah Huffman <noah.huffman at duke.edu<mailto:noah.huffman at duke.edu>> wrote:
Christie,

I have a script that sort of does what Maureen suggests.  Was going to mention it earlier, but it's a bit undercooked....

https://github.com/noahgh221/archivesspace-duke-scripts/blob/master/duke_archival_object_metadata_adder.py

It can read a two-column spreadsheet (as TSV) and batch add Repository Processing notes to archival objects via the API based on ref_ID values in the spreadsheet:

The example above is a modified version of a script that folks at the Bentley wrote:
https://github.com/djpillen/bentley_scripts/blob/master/update_archival_object.py

The comments in the script should help you figure out what you might need to modify.  For full disclosure, I'm a Python noob, so this is probably terribly written, but I can confirm that it works for my use case.

-Noah

-----Original Message-----
From: archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org> [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>] On Behalf Of Callahan, Maureen
Sent: Monday, February 01, 2016 10:43 AM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] AT Migration problem with repository processing note

Hey Christie,

Doing it now, we would probably write a script to do an update using the API (better built-in validation, fewer opportunities to do something stupid). During the migration, there's a choice to keep or re-assign refids - you're definitely going to want to keep those to help match up the components.

It's worth noting that we made those SQL updates because of mistakes in the migrator. I'm interested to know if those ever got fixed.

MC


> On Feb 1, 2016, at 10:36 AM, Peterson, Christie <cspeterson at email.gwu.edu<mailto:cspeterson at email.gwu.edu>> wrote:
>
> Hi Noah,
>
> Yep, that's the kind of thing we're probably going to end up doing.
>
> Many thanks!
>
> Christie
> _______________________________________________
> 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=AwICAg&c=-dg2m7zW
> uuDZ0MUcV7Sdqw&r=JgH2YCQ8D3P9-Lm_x4bv3d2CZBYlbx6hxnLFHtfovi8&m=n1N3sMK
> X9kb8hCXfWyWw-9rmsPmqB9BhN_6Kckdfo5g&s=XXk6iOoNajjfK6Ebn6n3Oe4cvYGTMPW
> o6wDb_Hto0q8&e=

_______________________________________________
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
_______________________________________________
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



--
Ian Hardy
Systems Specialist
GW Libraries
ihardy at gwu.edu<mailto:ihardy at email.gwu.edu>
helpdesk: (202) 994-8278



--
Ian Hardy
Systems Specialist
GW Libraries
ihardy at gwu.edu<mailto:ihardy at email.gwu.edu>
helpdesk: (202) 994-8278
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20160204/34c3e7b8/attachment.html>