Grüß Gott,
legen wir einmal für kurze Zeit das Sudoku zur Seite und führen unser Gehirnjogging anhand eines höchst interessanten Beispiels hier weiter. Dabei schlüpfen wir einfach einmal in einen Programmierer, der die Qualitätsbewertung verbessern will.
Öffnen wir dazu das Profil
https://www.familysearch.org/de/tree/person/details/GDGF-1HM
Die erste Aufgabe besteht nun darin, aufgrund der hier vorliegenden (sichtbaren) Daten ein Urteil abzugeben. Vielleicht können Sie den einen oder anderen Aspekt besser machen.
Es handelt sich um ein aus MyHeritage abgeschriebenes Profil mit den üblichen falschen diakritischen Großbuchstaben in den verschiedenen Namensteilen. Das wurde aber schon mehrfach angesprochen und taucht auch in neueren Einträgen von 2024/25 immer mal wieder auf.
Die aktuelle Qualitätsbewertung sagt
Daten ohne Konflikte (2)
Das sind nicht zwei Daten ohne Konflikte, nein 2 sind mit Konflikte. Zum Einen ist der Standardisierte Ort falsch. Leider wird aber nicht die richtige Standardisierung vorgeschlagen. Zum Anderen wird eine biologisch unmögliche Geburt weiter unten, aber nicht vom Probanden, erkannt.
Er dagegen wird begraben, ohne gestorben zu sein. Genau genommen kann man mehrere dieser Abhängigkeiten in Regeln fassen:
- Keine Taufe ohne Geburt
- Keine Einsegnung ohne Taufe
- Keine Einbürgerung ohne Einwanderung
- Kein Begräbnis ohne Tod
- usw.
Auch ohne Todesdatum hat der Tod eine Quelle. Wie kann das sein? Ein leeres Datum mit Quelle? Sollte das nich schon bei der Eingabe abgelehnt werden? Ein Klick darauf offenbart sogar ein genaues Datum auf dem Grabstein
Das Begräbnis minus 2 Tage ist zumindest in den alten Tagen (vor der Erfindung des Kühlschrankes) eine gute Näherung für den Tod.
Wie so oft ist das genaue Begräbnisdatum in Amerika (wegen des Kühlraumes und der weiten Entfernungen) nur eine Jahreszahl.
Aber diese Jahreszahl besagt, dass der Mathias das biologisch unwahrscheinliche Alter von 120 Jahren erreicht haben soll.
Was sagt uns die Qualitätsbewertung dazu, genauer was sagt sie denn noch.
Vollständigkeit der Daten (4)
Alles richtige Behauptungen, nur zeitlich ziemlich durcheinander, also unsortiert.
Markierung der Quellen (2)
Wieso muss eine Geburt "zwei oder mehr markierte Quellen enthalten"? Was sind "markierte" Quellen? Da gibt es sicher eine Hilfe dafür. Genau genommen beziehen sich alle Quellen auf die Zeit nach der Einwanderung. Die Geburt wird indirekt aus dem Grabstein abgeleitet.
Übereinstimmung der Quellen (6)
Jetzt werden die Einträge wohl mit den transkribierten Quellen verglichen. Das führt zu interessanten, merkwürdigen Analysen
- So ist - um es ehrlich zu sagen - die tschechichisierte Form des Vornamens Matej nirgends belegt. Auch der "Mittelbuchstabe" L wird der neuen Heimat angepasst.
- Ein zweites Geburtsdatum, das eher zum wahrscheinlichem Alter des Probanden taucht auf.
- Wie der Friedhof bezeichnet wird, ist ein weiterer Streitpunkt.
Daten ohne Konflikte (2)
Die zwei Konfliktpunkte wurden schon angesprochen.
Woher stammen nun diese Probleme?
Dazu wechseln wir in den Änderungsdienst. Er beginnt eher harmlos
Der Proband wird anglegt, erhält ein Geschlecht und ein Geburtsdatum 1818, aber kein Todesdatum. Komisch, unmittelbar danach hat er aber ein Todesjahr 1939 und wird dann schon rückwirkend 120 Jahre alt. Wo kommt das her? Hängt es vielleicht am "Wiederherstellen"?
Ich sehe kein Datum. Was solls? Schauen wir weiter:
- Der Proband erhält Eltern.
- Die Abschreibequelle wird hinzugefügt.
- Dann gibt es zwei Jahre Ruhe.
- Kinder und Ehe werden ergänzt.
- Dazwischen wird das Heiratsdatum eingefügt.
Nach einer Nacht (des Nachdenken) erfolgt eine Verschmelzung
Zuerst werden wohl (nach der Begründung zu urteilen) die Kinder einer zweiten Familie mit den bestehenden Kindern verschmolzen.
Dann wird der Vater mit einer gleichnamigen, aber gut 40 Jahre älteren Person *1858 zusammengelegt
40 Jahre ist mehr als ein menschlicher Generationensprung. Aber der Proband wird weiterhin 120 Jahre alt, was die Verschmelzungsanalyse anzeigt
Theoretisch wird damit vorausgesetzt, dass (9ZD1-HQ7) dieselben Eltern wie der (GDGF-1HM) hat.
- Jetzt fängt das Kopfrechnen an: Sohn - Mutter = Geburtsalter: 1818-1776=42 geht gerade noch, 1858-1776=82 biologisches Wunder
- Wessen Tod wird danach noch geändert? Welches Datum gilt dabei? Welcher Ort?
- Und noch eine Verschmelzung.
- Und weitere Kinder werden gelöscht.
Das Chaos ist perfekt.
Mein Kopf raucht [name removed for privacy]
p.s. Jetzt habe ich zwischendurch den Entwurf mehrfah gespeichert. Das hat der Titel "Neue Idee" aber ziemlich übel genommen und QQ daraus gemacht.
Nun traue ich mich nicht, diesen zu korrigieren, da dann die Bilder wieder weg sind.
Kommentare
-
Wie könnte eine halbwegs gangbare Lösung dieser Probleme aussehen?
Abhängigkeiten konsequent(er) umsetzen: Den Eingeber explizit abfragen oder automatisch ergänzen:
- (Kleinkind-)Taufe nur nach Geburt
- Einsegnung nur nach Taufe
- Scheidung nur nach Heirat
- Bestattung nur nach Tod
- usw.
Die automatische Ergänzung kann hart (Taufdatum ⇒ Geburtsdatum usw., Bestattungsdatum ⇒ Todesdatum - 2 Tage) oder weich (Geburtdatum vor dem Taufdatum, Todesdatum vor dem Bestattungsdatum) erfolgen. Übrigens setzen diese Technik schon einige Eingeber von sich aus ein, indem sie das Geburtsdatum unscharf, das Taufdatum dagegen exakt eintragen. Damit ist entweder Geburts- und Taufdatum gesetzt oder beide fehlen.
Besitzen die beiden (weiblichen) Verschmelzungs-Kandidatinnen unterschiedliche Geburtsdaten, dann muss die bereits vorhandene Prüfung auf das Geburtsalter der potentiellen Mütter erfolgen. Eine geeignete Warnung zeigt an, dass diese Altersangabe außerhalb des biologisch wahrscheinlichen Gebärfähigkeitsintervall der gewählten neuen Mutter liegt. Dass geprüft werden muss, ob die neue Mutter überhaupt noch lebt usw., muss wohl nicht explizit erwähnt werden.
Ebenso sollte eine Plausibilitätsprüfung des Ehezeitraums erfolgen.
Mit anderen Worten: Beim Verschmelzen müssen alle Prüfungen erneut durchlaufen werden. Ürigens: Verschmelzen muss der Eingeber aktiv am Bildschirm durchführen. Eine ferngesteuerte GEDCOM-Verschmelzung gibt es nicht. Deshalb kann die Prüfung im Dialog ablaufen.
Zur Erinnerung: FS sollte auch die Umkehrfunktion "Trennung einer Person in zwei Individuen" mit Aufteilung der Ehepartner und Kinder implementieren.
0 -
Abhängigkeiten konsequent(er) umsetzen: Den Eingeber explizit abfragen oder automatisch ergänzen:
(Kleinkind-)Taufe nur nach Geburt
Einsegnung nur nach Taufe
Scheidung nur nach Heirat
Bestattung nur nach Tod
Auch wenn diese Abhängigkeiten durchaus logisch sind, lehne ich eine automatische Ergänzung ab. Wenn die Quellen diese Daten nicht angeben, sollte das System nicht einfach etwas erfinden. Stattdessen macht die Qualitätsbewertung das, was es soll und weist auf fehlende Daten und evtl Konflikte hin -auch wenn der Abschnitt "Daten ohne Konflikte"mißverständlich klingt.
Gibt man durch Verknüpfung einer Quelle eine Bestattung ein, wird der Status in Tod automatisch auf "verstorben" gesetzt, auch wenn das genaue Todesdatum unbekannt ist und möglicherweise Jahre zurückliegt. Ein Lebensalter von 120 Jahren mag zwar wenig wahrscheinlich sein, wäre aber nicht unmöglich. Laut Wikipedia beträgt das bisher höchste offiziell belegt Alter 122 Jahre.
Die eigentliche Ursache für das Chaos in diesem Beispiel liegt meiner Meinung nach aber dem Anschein nach in einer fehlerhaften Verschmelzung. Wie man sehen kann, gibt es ein weiteres Profil des Mathias als Sohn des MatEj. Die Bearbeiterin hat nun den gelöschten Mathias nicht mit diesem Doppel verschmolzen, sondern mit dem Vater MatEj. Obwohl im Verschmelzungsvorgang die unterschiedlichen Daten angezeigt werden, hat sie dies wohl ignoriert und als alles übereinstimmend bestätigt. Warum sie das gemacht hat, müsten Sie die Bearbeiterin selbst fragen.
Bei dem gelöschten Mathias war die Quelle für das Begräbnis aus FindaGrave verknüpft und ist durch das verschmelzen zum Vater "gewandert". All das durch Bestätigung der Bearbeiterin
Helmut (Rier)
0 -
Hallo [name removed for privacy]
das ist eine interessante Betrachtung der Qualitätsanalyse.
Beim Abschnitt "Daten ohne Konflikte" stimme ich zu. Diese Bezeichnung ist irreführend und beschreibt eigentlich den Idealzustand. Daten-Konflikte wäre besser.
Er dagegen wird begraben, ohne gestorben zu sein. Genau genommen kann man mehrere dieser Abhängigkeiten in Regeln fassen:
Keine Taufe ohne Geburt
Keine Einsegnung ohne Taufe
Keine Einbürgerung ohne Einwanderung
Kein Begräbnis ohne Tod
das sehe ich nicht so. Genau genommen folgt das System der Logik "kein Begräbnis ohne Tod" und setzt bei Eingabe eines Begräbnisses den Status auf "verstorben", auch wenn kein exaktes Todesdatum vorhanden ist.
Die Regel "keine Einbürgerung ohne Einwanderung" ist m.E. nicht zwingend. Es ist nicht ungewöhnlich, das z.B. US-Bürger mit einem Elternteil deutscher Herkunft später einen deutschen Pass erwerben, ohne in Deutschland eingewandert zu sein.
Auch ohne Todesdatum hat der Tod eine Quelle. Wie kann das sein? Ein leeres Datum mit Quelle?
Folgt doch eigentlich nur der Regel zum Begräbnis. Ist das Begräbnis mit einer Quelle belegt, gilt dies dann auch für den Tod.
Wieso muss eine Geburt "zwei oder mehr markierte Quellen enthalten"? Was sind "markierte" Quellen?
Muss es ja nicht. Es ist ein Hinweis, den man auch verwerfen kann. Wenn Sie in die Quellenübersicht schauen, gibt es in jeder Quelle einen Abschnitt "Markierung hinzufügen". Dort kann man markieren, für welche personenstandliche Angabe die Quelle dient.
Zusammenfassend bin ich der Meinung, das die Qualitätsbewertung gute Hinweise zur besseren Bearbeitung gibt.
Nun zum Chaos. Dies ist meiner Meinung nach hauptsächlich durch die Verschmelzung entstanden.
Die Bearbeiterin hat hier den MatEj GDGF-1HM mit einem Mathias 9ZD1-HQ7 verschmolzen, obwohl es sich allem Anschein nach um Vater und Sohn handelt. Denn bei MatEj ist ein weiterer Sohn Mathias vorhanden, dessen Profil 2WMM-LDP besser mit dem anderen Mathias hätte verschmlzen werden sollen.
Bei dem gelöschten Mathias war denn ursprünglich auch die Quelle für das Begräbnis 1939 erstellt und ist nun durch die Verschmelzung zum Vater "gewandert". Warum dies die Bearbeiterin nicht beachtet hat (sie hat dies ja als alles übereinstimmend bestätigt), müsste man diese selbst fragen.
Abschliessend noch ein Tipp zu Verschmelzungen. Ich halte es für sinnvoll, hierbei i.d.R. das jeweils älteres Profil bestehen zu lassen, da ansonsten die zum Teil umfangreiche ältere Bearbeitungshistorie ebenfalls gelöscht wird.
Helmut (Rier)
0 -
Grüß Gott Helmut
ich darf noch einmal auf meine Anmerkung über die "weiche" Datumsübernahme hinweisen. Auch sollte man genau lesen, wenn ich "oder" schreibe.
Grundsätzlich stelle ich mir die Frage, ob eine Regel sowohl die Anzahl der Eingabefehler wie auch den Programmieraufwand reduziert. Die Qualitätsbewertung arbeitet reaktiv. FS sollte aber präventiv/proaktiv arbeiten. Das verhindert "ewige" Fehler, die nurmehr zufällig irgendwann einmal beseitigt werden. Das verhindert auch systematische Folgefehler. Beispiel: MatEj ist kein richtig buchstabierter Vorname, auch kein tschechischer oder ungarischer. Leider gibt es diese Schreibfehler in Massen und werden auch noch aktuell erzeugt. Aber das Thema habe ich für mich schon abgehakt. Jetzt bitte kein Gegenbeispiel wie DeO.. im Französischen oder die McD… aus den schottischen Hochländern.
Natürlich findet man (fast) immer eine Ausnahme. Dass die älteste bekannte Person 122 Jahre alt wurde, ist ein schwaches Argument gegen meine Vermutung, dass in den damaligen Zeiten kein Mensch 120 Jahre alt geworden ist. Diese Diskrepanz hat die Qualitätsbewertung nicht erkannt.
Danke noch einmal, dass Du die Verschmelzung als Ursache dieses Chaos noch zweimal ausführlich bestätigt hast. Das stützt meinen Verbesserungsvorschlag, dass beim Verschmelzen das Programm explizit darauf hinweist, wenn die Eckdaten einer Person (Geburt, Taufe, Einsegnung, Heirat, Tod, Bestattung) nicht in einem sinnvollen Intervall (wenige Tage auseinander, Zahlendreher, Tippfehler im Jahrhundert, usw.) liegen.
Das obige Beispiel hat mich bei meinem eigenen Datenbankprogramm auf die Idee gebracht, das Geburtsalter der Eltern zu prüfen, wenn das Geburtsdatum der zu verschmelzenden Personen deutlich auseinander liegt.
Auch ohne Todesdatum hat der Tod eine Quelle. Wie kann das sein? Ein leeres Datum mit Quelle?
Folgt doch eigentlich nur der Regel zum Begräbnis. Ist das Begräbnis mit einer Quelle belegt, gilt dies dann auch für den Tod.
Verstehe ich nicht. Hat der Tod eine Quelle, dann ist dort zumindest das Jahr eingetragen bzw. das Todesjahr wird vom Begräbnis übernommen. Es handelt sich im Beispiel übrigens um dieselbe Quelle, nämlich den Grabstein des Probanden mit genauem Todesdatum. Also ein reiner Flüchtigkeitsfehler: Das Feld nicht ausgefüllt.
Der Status "Verstorben" wird von FS nach meinen Beobachtungen immer dann auch ohne Quelle (0) eingetragen, wenn kein belegtes Datum vorhanden ist. So scheint es 2014 dazu eine große Nacharbeit gegeben zu haben. Wo heute in FS die Schwelle liegt, dass aus "unbekannt"= leer der Eintrag "Verstorben" wird, habe ich nocht nicht untersucht. Der Änderungsdienst einiger Profile zeigt aber, dass dieser Eintrag gezielt gesetzt wird.
Einige ziemlich unvollständige Gedanken zur Programmierung von FS (noch immer regelbasiert, also ohne KI) vom [name removed for privacy]
0
