EAD imports should handle ARKs for archival objects correctly

Description

Currently, when an EAD import happens with archival objects that have ARKs in unitid tags, the ARKs are added to the archival object record as Component Unique Identifiers and ignoring any other unitids for the archival object.

Instead, the import should do the following:
1. Check to see if the archival object has a unitid with a type of 'ARK', and if it does,
a. determine if it is an internal (ArchivesSpace generated) ARK by looking for the AppConfig[:ark_naan] parameter in the appropriate part of the value in the url attribute. It should have a substring like this: "ark:/{AppConfig[:ark_naan]}/{all digits}". And, the {all digits} portion should correspond to an id value in the ark_name table. The corresponding archival_object_id will need to be updated with the newly created (on import) archival object id. Also a new ARK should not be created (which happens automatically when ARKs are enabled and a new archival object is created).
b. if it is an external ARK, the value in the url attribute should be put in the external_ark_url field of the archival object.
c. if the unitid does not have a type='ARK', the text value should be put in the component_id field of the archival object.

Environment

None

Activity

Show:
Andrew Morrison
February 18, 2020, 3:42 PM

Large institutions are likely to have multiple systems besides ArchivesSpace, but only one NAAN. At the Bodleian we certainly do, which is why we’re going to use “external ARKs” in ArchivesSpace. So a configuration setting to always import all ARKs to external_ark_url would be good.

Assignee

Unassigned

Reporter

Laney McGlohon

Labels

Priority

Minor