We did that as a preprocessing step, but one use of multiple unittitles would be works with primary titles in multiple languages, right? In which case dropping attributes matters. And what makes a good delimiter depends on the corpus - we used double-dagger, but other places might have EADs that include that character.
So, anyway, my vote is that that can be a good local decision, but not a good "bake into the application" decision. ________________________________ From: archivesspace_users_group-boun...@lyralists.lyrasis.org <archivesspace_users_group-boun...@lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sd...@eservices.virginia.edu> Sent: Wednesday, April 26, 2017 11:15:36 AM To: Archivesspace Users Group Subject: Re: [Archivesspace_Users_Group] RFC: EAD import/export: mapping multiple unitid's and external-id's 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_m...@harvard.edu<mailto:dave_m...@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-boun...@lyralists.lyrasis.org<mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>> on behalf of "Majewski, Steven Dennis (sdm7g)" <sd...@eservices.virginia.edu<mailto:sd...@eservices.virginia.edu>> Reply-To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@lyralists.lyrasis.org>> Date: Monday, April 24, 2017 at 2:24 PM To: Archivesspace Users Group <archivesspace_users_group@lyralists.lyrasis.org<mailto:archivesspace_users_group@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@lyralists.lyrasis.org<mailto:Archivesspace_Users_Group@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=CwMGaQ&c=WO-RGvefibhHBZq3fL85hQ&r=_Mv1dY22K7jvT5MD7xjbvGVzRDOUMhx4WYcnPSIzYnE&m=zgQIq_EonzTUYjmaLT3v1UYkRO-FotGX9Ytr7pqiygE&s=SEbLx0zoDi4MYR_E9qwoxvo9EpQnAX_HmfNPa4oBdpc&e=>
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
