[Archivesspace_Users_Group] Access term plugins

[Custer, Mark]

Nancy,

Just a quick note to say, primarily, HEAR, HEAR!!! 😊

Now, as for tips, I’d also suggest that “shared terms” 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.

I just made an example in “test.archivesspace.org” to illustrate the issue, but here’s what the data behind the scenes looks like:

Agent URL: http://test.archivesspace.org/staff/agents/agent_person/807              Agent Name: Doe, Jane                 Linked to: repository/2/resources/151
Agent URL: http://test.archivesspace.org/staff/agents/agent_person/809              Agent Name: Doe, Jane                 Linked to: repsotiory/3/resources/114

Okay, so here’s the rub:

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.

Yikes!

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 😊

And I’ll also add that we’d really, really, really like to see the updates that you mention for “similar terms” 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 topical term or an occupation 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)?

Mark



From: archivesspace_users_group-bounces at lyralists.lyrasis.org [mailto:archivesspace_users_group-bounces at lyralists.lyrasis.org] On Behalf Of Kennedy, Nancy
Sent: Thursday, 11 October, 2018 2:17 PM
To: Archivesspace Users Group (archivesspace_users_group at lyralists.lyrasis.org) <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] Access term plugins

All,
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.

Shared terms:  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.

Similar terms: 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.

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.

Thanks,
Nancy



Nancy Kennedy
Smithsonian Institution
kennedyn at si.edu<mailto:kennedyn at si.edu>

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