<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Request for comments:</div>
<div class=""><br class="">
</div>
<div class="">I’m testing a patch relating to these JIRA tickets:</div>
<div class=""><br class="">
</div>
<div class=""><a href="https://archivesspace.atlassian.net/browse/AS-99" class="">[AS-99] As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EAD - JIRA</a></div>
<div class=""><br class="">
</div>
<div class=""><a href="https://archivesspace.atlassian.net/browse/AR-1542" class="">[AR-1542] As an archivist, I would like to associate multiple identifiers with resources/objects and export it in EAD - JIRA</a></div>
<div class=""><br class="">
</div>
<a href="https://archivesspace.atlassian.net/browse/AR-1268" class="">[AR-1268] Need ability to parse the unitid for multiple values on EAD import - JIRA</a>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""> 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? ) </div>
<div class=""><br class="">
</div>
<div class="">I propose changing this to make the first unitid the primary one on import. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
<div class=""><unitid>’s following the initial primary without a @type attribute are dropped. </div>
<div class=""><br class="">
</div>
<div class="">( 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. ) </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">I also note that AppConfig[:show_external_ids] is false by default. Is there a reason for this ? </div>
<div class="">I believe that initially the external ids were mostly used for mapping conversions from Archon and AT. </div>
<div class="">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 ? ) </div>
<div class=""><br class="">
</div>
<div class="">Chasing this setting currently only makes existing external ids viewable and editable.</div>
<div class="">I think it also makes sense to make them more generally available. </div>
<div class="">Currently, you can’t add an external id from the frontend if there isn’t one already. </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">Any comments or objections ? </div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div class="">— Steve Majewski / UVA Alderman Library</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
</body>
</html>