Regelkatalog für Personenreconciliation

Ziel: für eine Kandidatenperson (aus einer externen Quelle, z. B. dem Arbeitsblatt in test.docx) anhand aller vorhandenen Informationen entscheiden, ob sie im FactGrid-Auszug bereits vorhanden ist — und wenn ja, als welches Item.

Dieser Katalog ist die fachliche Spezifikation. Die ausführbare Umsetzung steht in app/server.py (reconcile(), Endpoint POST /api/reconcile); die Tabellenfelder liefert build/enrich_index.py.

---

1. Eingabemodell

Eine Kandidatenperson wird über die Spalten des Arbeitsblatts beschrieben. Jede Spalte mappt auf ein oder mehrere FactGrid-Merkmale:

---

2. Warum ein gestuftes Verfahren? (Datenlage)

Gemessen am Bestand (666.301 Personen, stark mittelalterlich- portugiesisch geprägt). „Dup-Quote" = Anteil der Personen, die sich einen Schlüssel mit mindestens einer anderen Person teilen:

Zusätzlich ist die Feldabdeckung ungleich: Geburtsjahr 55 %, Sterbejahr 21 %, Geschlecht ~100 %, ≥1 externe ID ~30 %. Konsequenz: Es gibt selten ein Merkmal, das immer entscheidet. Daher wird in Stufen gearbeitet — erst deterministisch, dann harte Ausschlüsse, dann starke Treffer, zuletzt gewichtetes Scoring. Die erste zutreffende Stufe entscheidet.

---

3. Namensnormalisierung

Vor jedem Namensvergleich:

1. Kleinschreibung; Diakritika entfernen (NFKD, wie FTS remove_diacritics 2 — „Gonçalo" → „goncalo").
2. In Token-Menge zerlegen (reihenfolgeunabhängig: „Herbart, Wilhelm" == „Wilhelm Herbart").
3. Satzzeichen strippen; Initialen (W.) als Präfix-Match auf volle Token behandeln.

Vergleichsarten: exakt (Token-Mengen gleich) · Teilmenge (alle Kandidaten-Token im Item enthalten oder umgekehrt) · fuzzy (Überlappungs- anteil über Schwelle).

---

4. Der Regelkatalog

Tier 0 — Deterministische Identität ⇒ identisch

• R0.1 Gleiche FactGrid-Q-ID → dieselbe Person (trivial, aber prüfen, wenn die Quelle bereits eine Q-ID nennt).
• R0.2 Gemeinsame externe ID (GND P76, VIAF u. a. — person_extid): identisch. Externe IDs sind global eindeutig; ein Treffer sticht jeden Namens-/Datumszweifel. ~30 % der Personen haben ≥1 solche ID.

Tier 1 — Harte Ausschlüsse ⇒ nicht identisch

Greifen trotz Namensgleichheit. Sie verhindern die häufigste Fehlerquelle (gleicher Name, verschiedene Person).

• R1.1 Geschlecht (P154): verschiedenes Geschlecht ⇒ nicht identisch. Billig und nahezu flächendeckend vorhanden.
• R1.2 Eltern-Relation (P141/P142): ist die eine Person als Vater oder Mutter der anderen verzeichnet, sind sie verschieden. (Erste Regel aus regel.txt: „Vater und Sohn sind nicht identisch.")
• R1.3 Generationsabstand: Geburtsjahr-Differenz > 30 Jahre ⇒ nicht identisch; ebenso unvereinbare Lebenszeitfenster. (Zweite Hälfte der Regel aus regel.txt.)
• R1.4 Biologische Plausibilität: Geburt nach Tod; Lebensspanne > 110 Jahre; „Datum der Erwähnung" außerhalb \[Geburt − 0, Tod + Puffer] ⇒ Widerspruch, nicht identisch.
• R1.5 Widersprüchliche tagesgenaue Geburtsdaten: liegen auf beiden Seiten tagesgenaue Geburtsdaten vor und deren Jahre > 2 Jahre auseinander ⇒ nicht identisch. (Nur grobe Jahresangaben werden toleranter behandelt; abweichende Geburtsorte sind kein harter Ausschluss, sondern ein starkes Gegenmerkmal im Scoring, siehe Tier 3.)

Tier 2 — Starke positive Übereinstimmung ⇒ identisch

• R2.1 Normalisierter Name gleich und Geburtsjahr gleich (zusätzlich Sterbejahr gleich, falls beidseitig vorhanden). Belegt durch die 0,8 %-/0,4 %-Dup-Quoten oben.
• R2.2 Familienname-Q gleich und Vornamen-Q-Mengen überlappen und Geburtsjahr gleich. Greift auch ohne identische Label-Schreibweise.

Tier 3 — Gewichtetes Scoring (alle übrigen Fälle)

Summe der zutreffenden Gewichte; entscheidet zwischen identisch / mehrdeutig / verschieden. Gewichte und Schwellen sind in app/server.py oben einstellbar (Stil wie BERUF_P3_UP) — und zur Laufzeit durch eigene Regeln überschreibbar: Auf /regeln lassen sich natürlichsprachlich formulierte Regeln (z. B. „Personen werden nicht älter als 90 Jahre") LLM-gestützt in Parameteränderungen übersetzen und aktivieren (POST /api/rules/translate, POST /api/rules; Katalog REC_PARAMS). Das betrifft neben den Gewichten und Schwellen dieses Tiers auch die harten Grenzen aus Tier 1 (REC_MAX_GEN_GAP, REC_MAX_LIFESPAN).

Schwellen (Vorschlag): Score ≥ 8 ⇒ identisch · 4–7 ⇒ mehrdeutig (manuelle Prüfung) · < 4 ⇒ verschieden.

---

5. Ergebnisklassen (Report-Sicht, vgl. build/bericht.html §6)

• eindeutig — genau ein Kandidat mit Verdikt „identisch".
• mehrdeutig — 2–5 Kandidaten im Score-Korridor; Vorlage zur manuellen Entscheidung.
• zu unspezifisch — > 5 schwache Kandidaten (typisch bei Allerweltsnamen ohne Datum); Eingabe muss präzisiert werden.
• kein Treffer — keine Kandidaten ⇒ Person ist (vermutlich) neu.

---

6. Bekannte Grenzen

• Patronyme („João Afonso") ohne Datum sind strukturell nicht auflösbar → landen korrekt in „zu unspezifisch".
• Ausschlüsse sind nur so gut wie die Datenabdeckung: fehlt das Geschlecht oder Geburtsjahr beim Item, kann der jeweilige Ausschluss nicht greifen.
• Externe IDs sind das stärkste Signal, aber nur bei ~30 % vorhanden.
• Freitext-Eingaben (Beruf/Ort/Religion) werden gegen FactGrid zu Q-IDs aufgelöst (gecacht); ist die Auflösung falsch, wirkt das Merkmal nicht.

---

7. All-Pairs-Lauf über den gesamten Bestand (build/find_duplicates.py)

Der Katalog oben prüft eine externe Kandidatenperson. Für die Dubletten-Suche innerhalb des Bestands läuft derselbe Regelkatalog item-gegen-item über alle per Blocking gebildeten Paare (geteilte externe ID · Name+Geburtsjahr · Familienname+Vorname+Jahr · gleicher Name ≤ 12 Mitglieder). „identisch"-Kanten werden per Union-Find zu Clustern verschmolzen. Ausgabe: dup_pairs, dup_clusters, dup_cluster_members, name_collisions, dup_meta.

Acht Verschärfungen gegenüber der Einzelfall-Reconciliation — alle nötig, weil im Bestand selbst (anders als beim sauber gepflegten externen Kandidaten) gleichnamige Verwandte, Namensumkehrungen und konfligierende Normdaten massenhaft vorkommen:

1. Namens-Reihenfolge. „exakt" (R2.1, +5) ist reihenfolge-sensitiv (nach einer Nachname-Komma-Drehung „Herbart, Wilhelm" = „Wilhelm Herbart"). Sonst kollabiert die Token-Menge „A son of B" auf „B son of A" — verschiedene (oft Vater/Sohn-)Personen in osmanisch-griechischen Patronymregistern.
2. Anker-Pflicht. Ein score-„identisch" (Tier 3) verlangt einen diskriminierenden Anker (Geburtsjahr oder Geburtsort — siehe Punkt 8 zu Eltern). Name + Wohnort + Religion allein sind in einem Dorfregister nahezu konstant → Deckelung auf „mehrdeutig".
3. Geburtsjahr-Konflikt (−3): beide bekannt und > 2 J. auseinander (≤ 30, sonst harter Ausschluss R1.3) — symmetrisch zum Geburtsort-Konflikt.
4. Sterbejahr-Konflikt (−3): beide bekannt und ≥ 2 J. auseinander.
5. R1.4 erweitert — geboren nach Tod: ist eine Person nach dem Tod der anderen geboren, sind sie verschieden. Fängt Necronyme (ein Kind wird nach einem verstorbenen Geschwister benannt; gleiche Eltern + Name, aber disjunkte Lebenszeit).
6. Weiches Veto → „mehrdeutig" (kein harter Ausschluss, sondern Review):
   • Tagesgenaues Geburtsdatum abweichend (gleiches/nahes Jahr, anderer Tag).
   • Getrennte Normdatensätze: beide tragen unter derselben externe-ID-Eigen­ schaft verschiedene Werte (eigene GND/VIAF/Arolsen-Häftlingsnummern) → getrennt katalogisiert, also verschieden. Beides verhinderte die häufigste Fehlmerge (gleicher Name + Geburtsjahr, z. B. Arolsen-Opfer).
7. Externe-ID-Konflikt statt blindem Tier 0. Eine geteilte externe ID gilt nur als „identisch", wenn kein harter Ausschluss und kein weiches Veto widerspricht; sonst extid_konflikt (Review). Der Dump enthält Haushalts-/ Werk-IDs, die Ehepaare oder Generationen verbinden, und konflierte Normdaten (eine GND auf zwei reale Personen).
8. Geteilte Eltern sind kein Identitäts-Anker. Gleiche Eltern (+4) zählen zwar zum Score, ankern aber kein score-„identisch" für sich allein — Geschwister und Necronyme teilen dieselben Eltern. Nur mit zusätzlicher Datums-/Geburtsort-Übereinstimmung wird daraus „identisch"; sonst „mehrdeutig". (Per Verifikation der häufigste verbliebene Fehlmerge im score-Tier.)

Cluster-Kohärenz. Union-Find über „identisch"-Kanten kann zwei paarweise unvereinbare Records transitiv verschmelzen (A~B~C, aber A/C widersprüchlich). Solche Cluster werden als incoherent markiert (Mitglied nach Tod eines anderen geboren, oder Geburtsjahr-Spanne > 2 J.) und sind im Report filterbar.

Gemessene Präzision (adversariale Stichproben-Verifikation gegen Live-FactGrid, build/verification.json). Zwei Runden hoben die „identisch"-Gesamtpräzision von 0,42 auf 0,70. Je Tier: extid ~0,91 und fam_given_byear ~0,91 (verlässlich für Auto-Merge), name_byear ~0,77 (grenzwertig: geschätzte Jahre, Allerweltsnamen), reiner score ~0,4 (Prüf-Kandidat). Die Review-Routen sind sauber kalibriert (extid_konflikt ~0,88, score-„mehrdeutig" ~1,0). Der Report führt die Tiers nach Vertrauensstufe (hoch/mittel/niedrig) getrennt. Die Stichprobe misst nur Präzision, keinen Recall (nur Kandidatenpaare enthalten).