<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Nancy,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Just a quick note to say, primarily, HEAR, HEAR!!! <span style="font-family:"Segoe UI Emoji",sans-serif">
😊</span>  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Now, as for tips, I’d also suggest that “<b>shared terms</b>” just cannot be reviewed in the staff interface at this time, even if you switch repositories like a pro with multiple browsers.  The reason:  what you see in the “Linked Records”
 section is not actually the records that are linked according to the database (so, it’s an inaccurate label name for the time being). Instead, what you see there is the result of a search for the name of that record – so that whole situation is even worse
 right now, since admins can be led astray if they look to the staff interface at all for this type of work.  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I just made an example in “test.archivesspace.org” to illustrate the issue, but here’s what the data behind the scenes looks like:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agent URL: <a href="http://test.archivesspace.org/staff/agents/agent_person/807">
http://test.archivesspace.org/staff/agents/agent_person/807</a>              Agent Name: Doe, Jane                 Linked to: repository/<span style="background:yellow;mso-highlight:yellow">2</span>/resources/151  
<o:p></o:p></p>
<p class="MsoNormal">Agent URL: <a href="http://test.archivesspace.org/staff/agents/agent_person/809">
http://test.archivesspace.org/staff/agents/agent_person/809</a>              Agent Name: Doe, Jane                 Linked to: repsotiory/<span style="background:yellow;mso-highlight:yellow">3</span>/resources/114<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Okay, so here’s the rub:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When you’re logged in to repository 2, when you access agent_person/807, the linked record that you see is “resources/151”.  Okay, that’s right.  Switch to agent_person/809, and the linked record that you see is “resources/151”.  O…kay…
 (that’s not right)….  Now switch to repository 3.  When you access agent_person/807, the linked record that you see is “resources/114”.  Switch to agent_person/809, and the linked record that you see is “resources/114” yet again.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Yikes!  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, that needs to be addressed first and foremost in my opinion.  People can have the same name, of course, so a search for that alone often doesn’t cut it.  But, if the search was done on the database ID and then confined to that specific
 field in the index, sure, that would work.  But as things stand now, all agent merging (at the very least) needs to be done outside of the staff interface, especially for the other reasons that you mention.  In fact, we’re going through a project like that
 right now, and my colleague Alicia Detelich has written some great ways to extract that data so that you can review the actual, honest-to-goodness links in a spreadsheet format outside of ArchivesSpace.  I guess if you have a database where everything is perfect
 this isn’t an issue, but given that you can create agent records with the same string since as long as the “source” and/or “rules” differs it will be considered unique, this is definitely an issue that we’re having to deal with, and I imagine that not everyone
 has perfect data <span style="font-family:"Segoe UI Emoji",sans-serif">😊</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And I’ll also add that we’d really, really, really like to see the updates that you mention for “<b>similar terms</b>” as well.  The typeahead is nice, but doesn’t show enough info for anyone to make a decision about what to link to, exactly
 for the reasons that you mentioned (e.g. is that term “Actors” a <i>topical</i> term or an
<i>occupation </i>term, and what about the one after that?).  I feel like someone has created some mockups before about how to help distinguish typeahead suggestions, but I can’t seem to find that in JIRA right now.  Maybe someone else remembers the ticket(s)?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mark<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> archivesspace_users_group-bounces@lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces@lyralists.lyrasis.org]
<b>On Behalf Of </b>Kennedy, Nancy<br>
<b>Sent:</b> Thursday, 11 October, 2018 2:17 PM<br>
<b>To:</b> Archivesspace Users Group (archivesspace_users_group@lyralists.lyrasis.org) <archivesspace_users_group@lyralists.lyrasis.org><br>
<b>Subject:</b> [Archivesspace_Users_Group] Access term plugins<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All, <o:p></o:p></p>
<p class="MsoNormal">Does anyone have plugins to adjust display of subject and agent terms?  For both ongoing description and legacy cleanup, we would like to make it easier for our users to address shared terms and similar/duplicate terms.  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Shared terms:</b>  In the Subject (or Agent) record, we’d like to display the used_within_repository data, resolved to the repo_code or name.  It is difficult for our staff users to merge or cleanup subject records, without knowing which
 other repositories are also using the term.  Right now, only admin users can tell if a term is shared across repositories, making it hard for users to coordinate merges.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Similar terms:</b> We have terms that are duplicates, and others that are similar, but have a different type, for example.  Ideally, our users would also like to see the first_term_type on screen, from within the context of the resource
 record or even within the typeahead.  While users have various methods for getting around the first_term_type issues, we’re looking for ways to make the term type more easily accessible in searches, typeahead, or within the context of a resource record.  We’d
 like to ease the learning curve by making the data more immediately visible, rather than needing a lot of click-through to verify.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We are in the earliest of planning stages, and would appreciate any tips – or if you’ve already done something similar, would love to see what you’re doing to help distinguish similar terms / shared terms.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, <o:p></o:p></p>
<p class="MsoNormal">Nancy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Nancy Kennedy<o:p></o:p></p>
<p class="MsoNormal">Smithsonian Institution<o:p></o:p></p>
<p class="MsoNormal"><a href="mailto:kennedyn@si.edu">kennedyn@si.edu</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>