Feature Request - agent pick behavior

[dustymc]

Is your feature request related to a problem? Please describe.

From @DellaCHall in #7352

1. Agent auto-populate issue: I used to be able to type a name exactly and it would just populate into any agent/determiner field, if there were no duplicates. Now it seems to search every field, including relationships, so all people/organizations associated with an agent also show up, then I have to click the correct one. This added extra step seems silly when typing a full name exactly, and might actually deter people from adding relationships, due to the annoyance (for example, I'll probably remove my relationship with my husband, so I can enter data faster). Is there a way to have it auto-populate the agent if there are no duplicates in the name fields, like it used to? I'm not sure what is gained by this particular change, so maybe I just need a different perspective to understand it.

Describe what you're trying to accomplish

Figure out how the agent selector should work

Describe the solution you'd like

A usable selector which doesn't make giant messes.

Describe alternatives you've considered

From @ewommack

Try entering your user name instead of your full name. That works for me to only pull up me. With the relaxation of allowing people to have the same name now we're going to hit into having two or even more of the same person coming up in an exact name search as this as we get more and more people with the same or very similar names brought into the system. I think it is probably safer to have us search for people unless you know exactly who you want.

Additional context

One scenario worth avoiding in a system without unique keys on preferred name is that one collection 'curates' an agent, then another collection dumps lots of inappropriate data (eg stuff collected by a different agent with a similar or identical name) to that record. Ideally all agent selections would involve examining metadata, which the current behavior is designed to encourage.

Priority

?

[Jegelewicz]

Ideally all agent selections would involve examining metadata, which the current behavior is designed to encourage.

Not really though. If I get a HUGE list of names simply because they all contain a relationship to the name I entered, I can't really see through it to things that might matter (like the agent with an almost-matching name). When I am looking to select an agent in data entry, I don't want to have to scroll through the 50 agents who have the same name in a RELATIONSHIP - the relationships don't matter here as I am trying to find a person who uses this name as a NAME.

[dustymc]

HUGE list of names

Absolutely, there's a cost to false positives, the question is where it starts to outweigh the cost of false negatives (which leads - maybe "also leads" - to creating duplicates).

agent with an almost-matching name

Names carry very little data; I'm sure we are collectively about to create a million duplicates, but hopefully not by the people who want to give proper attribution; they need to look at more than names.....

uses this name as a NAME

... in part because people put random things in random places if they can; assuming names will be properly labeled is a recipe for failure. (Go check out the test error logs from about 1PM today....)

ANYWAY - I messed with some stuff, it should be NOT searching on relationships or 'other' now (because there are a million identical 'did this thing' remarks), and I think I've got the code set up so that it's relatively easy to adjust that if we've gone too far.

Feedback would be greatly appreciated.

[Jegelewicz]

Attempting to pick with agent url fails

[Jegelewicz]

But wikidata url works

[dustymc]

That doesn't use the function, it's just a search, and test doesn't get to mint identifiers - but it should behave that way, https://arctos.database.museum/agent/21278832 works now, thanks!

[dustymc]

I'm reopening for #7456 - it would be very useful for me to have a coherent picture of how this should work, rather than many smaller issues.

The current situation is that there are a bunch of addresses of the format...

I don't think I can realistically ignore specific words, or that that would do anything useful if I could.

I could somehow complicate the picker (eg a name-only search option or similar), which I expect would lead to more duplicates being created. (But the system is designed to support duplicates, that's not a technical problem or constraint I feel I must live under.)

I could ignore more data under the one search field, which I'd also expect to lead to more duplicates (and the parenthetical bits above still apply).

Maybe @ArctosDB/agents-committee is willing to suggest something about these specific data.

Just in case it's somehow not clear: Someone can also create 56,000 more agents with preferred name 'unknown' (perhaps even defensibly - clearly the one current 'unknown' represents lots of people and agencies).

My solution would involve simply not using agent 'unknown' for anything, which might involve filing an Issue if there are any remaining 'requirements.'

[Jegelewicz]

My solution would involve simply not using agent 'unknown' for anything

This is probably the correct answer, but might be hard for people to accept? See https://www.datafix.com.au/BASHing/2018-10-18.html on when you have Nothing Interesting to Say.

If you have nothing to enter in a field for a particular record, there's nothing wrong with leaving the data item blank. Please?

[AJLinn]

Sorry to duplicate Derek's comments, must have missed that in the comments removed that were marked off-topic. Was there a new issue created from those? Shall I create a new issue for "agent unrecorded" so the agent-pick-behavior issue isn't hijacked?

[dustymc]

new issue

Yes please.

[Nicole-Ridgwell-NMMNHS]

Frustrated trying to create an agent today. I'm trying to add that the agent was a student of the University of New Mexico, but ran into this:

I get a ton of results, agents with relationships to UNM, many different subunits of UNM, but it seems to have maxxed out because University of New Mexico isn't one of them.

edit: I managed to get it added by using the stable identifier for UNM.

[campmlc]

Yes, pulling all related agents is hugely problematic and disfunctional across multiple tools. Hopefully when @dustymc gets back we can prioritize a solution.

[dustymc]

relationships

The agent pick explicitly ignores relationships.

[Jegelewicz]

The agent pick explicitly ignores relationships.

That may be true, but something is still picking them up. #7434 (comment) is an example of the issue.

[campmlc]

In create loan, the main loan form ignores relationships, but the create loan shipment pick does not.

[Jegelewicz]

I think the problem is that we have two places for relationships?

and only one of them is being ignored?

[dustymc]

only one of them is being ignored

No

[DellaCHall]

I think it may be tied to what @dustymc pointed out many comments back:

The current situation is that there are a bunch of addresses

Can addresses be ignored in the pick? Not sure if that solves everything, but it might resolve the University of New Mexico comment.

[campmlc]

But I don't want to have to choose between 40+ separate related agents even without addresses. Plus, I need the address to create a loan shipment to the specific agent I enter.
I'm happy to do a demo of this problem. I think it would be obvious if you could see what we are dealing with at the level of the interface.

[campmlc]

This is becoming a serious issue affecting work and Arctos functionality. Request that we have a zoom to resolve asap so we can demonstrate the problem. @mkoo @dustymc

[campmlc]

Please see #7458 which was closed but is not resolved and is absolutely related to this.

[dustymc]

Can addresses be ignored

Yes - and that will just about inevitably lead to the creation of duplicates, but perhaps fewer than if lots of data are returned....

I can do just about anything, I'm asking if I should (or must)!

loan shipment

That is a different thing (but probably related, I suspect that will re-use some or all of whatever's developed here).

don't want to have to choose

There was a very long discussion, it was agreed that limiting agents to high-information entities wasn't what The Community wanted, that lead to the current data model in which just about anyone can create just about anything - I believe that decision has been made, what's left is how to choose. There's also a bit of a positive feedback loop in that if we cast a wide net then a user might find 40 John Doe agents which they must pick through, and if we don't cast a wide enough net then a user won't find their John Doe, will create a duplicate, and the next user will have 41 to sort through. I suspect that ignoring more and more data (where this has been leading) is about the most disruptive thing that we can do, but I'm also not entirely sure what the alternatives are (more search options on all forms??), how any of that relates to usability (someone's immediately going to declare the more-options form too complicated to use??), or if I need to care about things like duplicates at all (see eg #7649).

I don't need a demo, I know how things work, I need to know how things should work (in a scalable, actionable way).

There's an Agents Committee meeting tomorrow, I believe the agenda could be modified.

[campmlc]

Yes, please, let's address at Agent's Committee meeting tomorrow, so we can show how things should work in a functional way for operators, which currently is not the case.

[Jegelewicz]

I just verified UNM, I think this will fix

#7434 (comment)

?

[Jegelewicz]

Something is not working. I am adding a relationship to an agent and searched University of New Mexico, which is a gold star, verified agent, but does not even show up in the pick list!

Maybe this is a cache thing, but I verified it yesterday. Easy to see how this would be the cause for creating duplicates...

[dustymc]

It often takes me slightly more than zero time to implement things. Sort outside the main form will be addressed by #7438.