Code Table Request - agent attribute - bad duplicate of

[dustymc]

Goal

Make a term make sense in a new environment.

Context

#7352 is happening. There is no deletion in it. The current definition cannot make sense.

Table

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctagent_attribute_type

Proposed Value

bad duplicate of - no change

Proposed Definition

Nonpreferred member of a pair of duplicates.

Priority

I'll go with my proposal at release time unless there are comments.

@ArctosDB/arctos-code-table-administrators

Approval

All of the following must be checked before this may proceed.

The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example.

• Code Table Administrator[1] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• Code Table Administrator[2] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
• DBA - Appropriate code or handlers are in place as necessary. (ID_References, Media Relationships, Encumbrances, etc. require particular attention)

Rejection

If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.

1. Can a suitable solution be found here? If not, proceed to (2)
2. Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
3. Take the discussion to a monthly Arctos Working Group meeting for final resolution.

Implementation

Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.

• Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.

• Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition. URLs should be included as text, separated by spaced pipes. Do not include HTML in definitions.

Close this Issue.

DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.

Special Exemptions

In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.

1. Adding an existing term to additional collection types may proceed immediately and without discussion, but doing so may also subject users to future cleanup efforts. If time allows, please review the term and definition as part of this step.
2. The Committee may grant special access on particular tables to particular users. This should be exercised with great caution only after several smooth test cases, and generally limited to "taxonomy-like" data such as International Commission on Stratigraphy terminology.

[Jegelewicz]

There is no deletion in it.

Please explain how merging will work.

[dustymc]

merging

Without delete there can be no such thing, so not entirely sure what you're asking. (With delete there can be no history, and there's a huge amount of data/number of Issues suggesting that's absolutely necessary.)

MAYBE records wearing particular relationships will take an extra something to select in the picks, or their pages will default-redirect (probably not, that would require unsupportable assumptions about cardinality), or something of the sort, that would all need an Issue.

There are (expandable, but I think they're fairly thorough already) tools that can move ties from one agent to another - I think a collection discovering that things are attributed to the wrong agent has an existing solution.

[Jegelewicz]

This needs further discussion - 50 Michelle Koos is just not going to work.

[Jegelewicz]

I do not understand why we can't "encumber and redirect to Michelle S. Koo" the M. Koo created by Joe Blow today. This is actually what I mean by "merge".

[dustymc]

do not understand why

"the" - cardinality. For lots of reasons (I think there's even a github issue template!), one agent ends up representing multiple entities. Those are hard to avoid even in a system with delete, and of course those deletes also make messes that we want to avoid. "When one then redirect" might be possible, but I don't see any way to avoid the possibility of "you probably don't want this but here it is anyway, maybe one of those is what you're looking for."

[AJLinn]

MAYBE records wearing particular relationships will take an extra something to select in the picks, or their pages will default-redirect (probably not, that would require unsupportable assumptions about cardinality), or something of the sort, that would all need an Issue.

Maybe the not-valid duplicates can have a different color or greyed out background during the pick-window like parts that are "missing" or "deaccessioned" in their part disposition?

[dustymc]

not-valid duplicates

That's a good opener to a slightly deeper discussion that we eventually (sometime after the first bad duplicate is flagged post-next-release!) need to have, so here we go. There are two possibilities:

Option One, we can do what we've been doing with duplicates, send out notifications, let them cook for a while, then move all the links to the 'good' one and pretend the 'bad' no longer exists (make redirects or gray it out or whatever). We'd still have the old, so any mistakes are probably more understandable and more correctable that they are now - the new outlook on Agents is a bit of improvement even here.

Option Two, we can NOT make those automated updates, which I think it probably more in line with the realities of where we are now, and perhaps even more with where we're going. I think we do have incorrect duplicate flagging (but maybe the revised view of the world will change that), I think that's probably not always noticed in the notifications or sufficiently reviewed, and it probably makes some messes. We could instead - well, whatever, maybe send out notifications (monthly, weekly, once, whatever) and make the merger tool available as a UI tool, or something of the sort. (It would have to be modified to be more precise, I don't think there's any problem with that.) That would be a bit more work for collections, but only if they want it (and need it, having loaded data against an apparently-flaky agent), and it would remove any possibility of "the system" (on behalf of whomever flagged a duplicate) oopsie-ing two not-actually-the-same Agents together.

[dustymc]

I've done two things:

1. Determined date, determiner, and method are required for bad duplicate of
2. The search and display/detail UIs have some shinybits

Search excludes duplicates by default

https://arctos-test.tacc.utexas.edu/agent.cfm?srch=waylon

Users can request duplicates be included, relationships are visible in results

https://arctos-test.tacc.utexas.edu/agent.cfm?srch=waylon&include_bad_dup=true

and the detail page has special styling and verification icons

https://arctos-test.tacc.utexas.edu/agent/21347411

---

I will plan to set the same default (exclude duplicates) on the agent picker, and ignore them altogether for #7322. (That is, someone who wants to use a bad duplicate in their records will have to check some buttons and use internal forms with big red boxes.)

---

Vague merge plan which can be revised - even radically - if the data come to demand it:

• The system will send periodic notifications to contacts of collections with duplicate-involved records
• The notifications will include instructions for moving agent-links
• We can figure out what the tools under those instructions look like when there's a real-world use case.