Use of preferred name as unique key for agent table

[Jegelewicz]

Several recent issues point to the limitation of using preferred name as the unique key for agents.

#4526
#4524
#4505
#4530

As time goes on and our membership diversifies, we are going to have more and more people that are "same name, different agent". Butchering one or both agents' "preferred name" by adding parenthetical details does not seem appropriate. I suggest we pursue the path that Wikidata follows. There can be multiple people with the exact same name, but they each carry a unique identifier (the "Q number") and a few details are used to highlight their differences. See the search results for John Smith.

When someone discovers that two Q numbers refer to the same person, they can request a merger of the two. Note that this does NOT release the merged identifier for reuse!

A merge is a multistep process, first requiring that the collective data about the items be pooled together in one page (the recipient item), and finally resulting in the redirection of the obsolete page to the recipient item.

This would make bulkloading more difficult when two preferred names are the same, but a simple message that tells one to enter the identifier for the "John Smith" they intend should work. Any other ideas? At some point this will become an issue, because I think that cultural collections may be less inclined to add parenthetical remarks to a preferred name, but then again, I could be wrong! @AJLinn @marecaguthrie @wellerjes

Also, perhaps tomorrow's webinar on Bionomia will be instructive.

[dustymc]

#4526 needs more resolution before this (or certain parts of it) can be discussed.

I think the environment under a unique "natural" key must be fairly different than that without such a constraint.

Note that this does NOT release the merged identifier for reuse!

Yea, that's been on the radar for a while, it would allow merged agents to continue resolving, which would be pretty fabulous. The opposite doesn't seem like something wikidata would have to regularly deal with - they don't allow mass/low-effort creation of strings-as-objects at all as far as I can tell; if we're going to adopt their model, perhaps we'll be forced to adopt that approach as well.

FWIW this all seems like the right direction to me, but it's very different than what seems to happen and what "we" seem to want to happen in Arctos.

[AJLinn]

Butchering one or both agents' "preferred name" by adding parenthetical details does not seem appropriate. I suggest we pursue the path that Wikidata follows. There can be multiple people with the exact same name, but they each carry a unique identifier (the "Q number") and a few details are used to highlight their differences

I like this idea - yes, adding parenthetical notations in the preferred name is not ideal so any way we can avoid that is my preference. Adding dates of birth/death, addresses, "alive" dates are all excellent ways to distinguish one agent from another. I have now made it a habit that when I create a new agent, I always add additional information in at least 2 additional fields (address, relationships, dates, etc.). It drives me batty to open an agent record and only find a preferred name, plus first and last. It only takes a few seconds more to add those additional pieces of information that might save multiple people a great deal of effort down the line.

[dustymc]

It drives me batty to open an agent record and only find a preferred name, plus first and last. It only takes a few seconds more to add those additional pieces of information that might save multiple people a great deal of effort down the line.

AMEN! (But #4554 (comment) suggests we're not willing to make that leap for some reason that I can't quite understand - hopefully just because the proposal isn't understood??)

pursue the path that Wikidata follows...carry a unique identifier

We've always had local unique identifiers, we've had global unique identifiers for the last several years, and we can carry anyone else's identifiers (unique, useful, or not). There's nothing to pursue, we've always been there, this is mostly a social issue - but it's one that I don't think we can use as long as the potential for 5783 "J. Smith" (and that's it) Agents can exist; I still think #4554 as proposed (that is, automagically periodically drop all string-only+collector-only Agents), or something very much like it, is a hard prerequisite to moving past unique preferred name keys.

[lin-fred]

Wait until after verbatim agent magic happens and then re-discuss

[Jegelewicz]

Adding this from @ekrimmel interviews about agents:

Preferred name in practice has too many technical restrictions to actually capture preferred name in spirit.

Agent search is not intuitive. It is picky about formatting, and returns false positives because of the weight Arctos places on preferred names.