Adjudication: promote Wikidata canonical name and reclassify search name as alias/nickname

[gregoryfoster]

Background

During the Phase 1 walkthrough, "Denny Heck" was the name entered by the operator. Wikidata returned Q4068793 with the canonical label "Dennis Heck" — his legal/formal name, where "Denny" is the common nickname.

After accepting the candidate, WikidataProvider writes Wikidata aliases as PersonName rows (name_type=alias, confidence=0.70). But the originally-entered name "Denny Heck" remains the primary name at confidence 1.0. The system has no mechanism to:

1. Elevate the Wikidata canonical label ("Dennis Heck") to the primary name.
2. Reclassify the search name ("Denny Heck") as an alias/nickname.
3. Express the operator's intent during the adjudication step rather than requiring a separate edit.

This matters for several reasons:

• The Person.name denormalized field should reflect the canonical identity ("Dennis Heck"), not the search term used to find them.
• Downstream providers and external lookups key off PersonData.name — a nickname produces weaker matches.
• POST /v1/find should return "Dennis Heck" as the authoritative name while still matching on "Denny Heck".

Proposed feature

Option A — Adjudication UI checkbox (recommended)

Add an opt-in checkbox to the WikidataCandidateReview acceptance flow:

☑ Use Wikidata label as canonical name — reclassifies "Denny Heck" (current primary) as nickname; sets "Dennis Heck" as new primary.

When checked, handle_accepted (after enrichment runs):

1. Creates/updates the Wikidata label PersonName as is_primary=True, name_type="primary", confidence=0.95.
2. The existing PersonName.save() demote logic automatically sets the old primary to is_primary=False; its name_type should be set to nickname (not the default former) — this requires a demote_as parameter or a post-demote fixup step.
3. Syncs Person.name / given_name / surname from the new primary.

Option B — Always promote (no checkbox)

Always treat the Wikidata canonical label as the primary name on acceptance. Simpler but loses the operator's ability to keep a preferred common name as primary.

Recommendation

Option A. The checkbox default should be checked when the search name and Wikidata label differ ("Denny" ≠ "Dennis") and unchecked when they are the same (exact match after normalization). This nudges toward canonical names while keeping operator control.

Model changes required

• WikidataCandidateReview: add promote_wikidata_label BooleanField (default True, nullable). Exposed in the acceptance form.
• PersonName.save(): the demote path currently hard-codes name_type="former". Needs a way to specify the demoted name_type (e.g. nickname, alias) — either a kwarg to save() or a separate service function.

/v1/find behaviour after promotion

• Primary name "Dennis Heck" → certainty 1.0
• Alias "Denny Heck" → still searchable, returned with certainty 0.9 (other exact match)

Both names remain in PersonName and are indexed by the search layer — the operator gains canonical identity without losing the search-name match.

Acceptance criteria

• WikidataCandidateReview has promote_wikidata_label field (migration required).
• Acceptance form shows checkbox, pre-checked when label ≠ search name.
• handle_accepted respects the flag; promotes/demotes name records correctly.
• Demoted primary gets name_type from a configurable choice (default nickname when given-names differ, alias otherwise).
• Person.name / given_name / surname sync to new primary.
• /v1/find returns both names with correct certainty scores.
• Tests: promotion path, no-promotion path, name-type assignment logic.