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

[Majewski, Steven Dennis (sdm7g)]

Would it make more sense to concatenate multiple unittitles ?
I don’t think I’ve actually run into one in the wild.

— Steve M.


On Apr 24, 2017, at 3:55 PM, Mayo, Dave <dave_mayo at harvard.edu<mailto:dave_mayo at harvard.edu>> wrote:

+1, and also this is true of unittitles as well; unfortunately, there’s no proper representation of multiple titles as of yet, but at the very least, take-first would be better than take-last there as well.

- Dave Mayo
  Digital Library Software Engineer
  Harvard University > HUIT > LTS > OSC Development Group
From: <archivesspace_users_group-bounces at lyralists.lyrasis.org<mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org>> on behalf of "Majewski, Steven Dennis (sdm7g)" <sdm7g at eservices.virginia.edu<mailto:sdm7g at eservices.virginia.edu>>
Reply-To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Date: Monday, April 24, 2017 at 2:24 PM
To: Archivesspace Users Group <archivesspace_users_group at lyralists.lyrasis.org<mailto:archivesspace_users_group at lyralists.lyrasis.org>>
Subject: [Archivesspace_Users_Group] RFC: EAD import/export: mapping multiple unitid's and external-id's


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://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AS-2D99&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=8XUp_NUPFJOTUgM3ImU47HAhgcOO_Iwy8wN26MqnDjM&s=gjONTAA8AswO9yztiJjm6IRWzU5pxNkp0g4kVIoNCHc&e=>

[AR-1542] As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EAD - JIRA<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1542&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=8XUp_NUPFJOTUgM3ImU47HAhgcOO_Iwy8wN26MqnDjM&s=vUoM7wtXs0KcpYMtywcL5IcCxB_tbkNVoeDJ6t37xyQ&e=>

[AR-1268] Need ability to parse the unitid for multiple values on EAD import - JIRA<https://urldefense.proofpoint.com/v2/url?u=https-3A__archivesspace.atlassian.net_browse_AR-2D1268&d=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=8XUp_NUPFJOTUgM3ImU47HAhgcOO_Iwy8wN26MqnDjM&s=L2gb5t2_G6FkvaJtk553R1A1_Jume2sd4c9AnahwRJg&e=>


 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


_______________________________________________
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

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