[Archivesspace_Users_Group] RFC: EAD import/export: mapping multiple unitid's and external-id's

[Majewski, Steven Dennis (sdm7g)]

Request for comments:

I’m testing a patch relating to these JIRA tickets:

[AS-99] As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EAD - JIRA<https://archivesspace.atlassian.net/browse/AS-99>

[AR-1542] As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EAD - JIRA<https://archivesspace.atlassian.net/browse/AR-1542>

[AR-1268] Need ability to parse the unitid for multiple values on EAD import - JIRA<https://archivesspace.atlassian.net/browse/AR-1268>


 I’ve noticed that when there are multiple <unitid>’s in EAD, the last one overwrites previous ones so the last value is the one imported. In our cases, if there are multiple <unitid>’s, the first one is always the primary one. Other identifiers may into other systems may be added after the primary one. I would expect this to be the natural order — does this conflict with anyone else’s experience ?   ( Does anyone *want* the last value to override initial value? )

I propose changing this to make the first unitid the primary one on import.


The other changes import additional <unitid>’s as external_ids IF they have a @type attribute. @type will be mapped to external_id.source. On export, external_ids are exported as unitid with @type=external_id.source.

<unitid>’s following the initial primary without a @type attribute are dropped.

( This could be changed, as I don’t believe external_id has any *required* attributes: In our use cases, it didn’t seem to  make much sense to keep an external id without an indicator of what system it’s an id into. )


I also note that AppConfig[:show_external_ids] is false by default. Is there a reason for this ?
I believe that initially the external ids were mostly used for mapping conversions from Archon and AT.
We have a strong need to link ArchivesSpace resources to resources in other systems. I would guess that this is a pretty widely shared requirement. ( Was hiding them a way of keeping users from editing them because Archon/AT migration depended on them ? )

Chasing this setting currently only makes existing external ids viewable and editable.
I think it also makes sense to make them more generally available.
Currently, you can’t add an external id from the frontend if there isn’t one already.


Any comments or objections ?



— Steve Majewski / UVA Alderman Library


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20170424/9c573dbb/attachment.html>