Achtung: Diese Website unterstützt die derzeitige Version Ihres Internetbrowsers nicht. Wenn Sie unsere Website bestmöglich nutzen wollen, empfehlen wir Ihnen, Ihren Browser zu aktualisieren oder einen anderen Browser zu installieren.

Hauptnavigation überspringen
FamilySearch
  • Übersicht
  • Stammbaum
  • Suchen
  • Ich folge
  • Meine Einreichungen
  • Geschützte Personen
  • Aufzeichnungen
  • Aufnahmen
  • Familienstammbaum
  • Genealogien
  • Katalog
  • Forschungs-Wiki
  • Friedhöfe
  • Übersicht
  • Galerie
  • Personen
  • Suchen
  • Übersicht
  • Gelegenheiten zur Mithilfe
  • Dein Mitwirken
  • Indexierung
  • Alle Aktivitäten
  • App „Together“
  • Herkunft des Nachnamens
  • Zu meiner Person
  • Gesichter vergleichen
  • Berühmte Verwandte
  • Meine Geschichte aufzeichnen
  • Meine Abstammung veranschaulichen
Anmelden Konto erstellen
Anmelden Konto erstellen
  • Übersicht
  • Stammbaum
  • Suchen
  • Ich folge
  • Meine Einreichungen
  • Geschützte Personen
  • Aufzeichnungen
  • Aufnahmen
  • Familienstammbaum
  • Genealogien
  • Katalog
  • Forschungs-Wiki
  • Friedhöfe
  • Übersicht
  • Galerie
  • Personen
  • Suchen
  • Übersicht
  • Gelegenheiten zur Mithilfe
  • Dein Mitwirken
  • Indexierung
  • Alle Aktivitäten
  • App „Together“
  • Herkunft des Nachnamens
  • Zu meiner Person
  • Gesichter vergleichen
  • Berühmte Verwandte
  • Meine Geschichte aufzeichnen
  • Meine Abstammung veranschaulichen
Zum Inhalt springenStartseite
  • Startseite
  • FamilySearch-Hilfe
  • Verbesserungsvorschläge
  • Gruppen
  • Anmelden
  • Registrieren
  • Startseite› Willkommen in der FamilySearch Community!› Verbesserungsvorschläge

    Merkwürdige Qualitätsbewertung

    Wiesenmichel
    Wiesenmichel ✭✭✭
    4. April in Verbesserungsvorschläge

    Grüß Gott,

    ich habe zwar vor längerer Zeit einmal eine erweiterte Qualitätsbewertung vorgeschlagen, etwa in der Form, dass zwischen Primär- (Kirchenbüchern, usw.) und Sekundärquellen (Abschreibungen aus anderen Archiven) unterschieden werden sollte. Aber die jetzige Lösung (? Beta-Version ?) scheint mir dann doch ein wenig aus dem Ruder zu laufen. Ist das wirklich neu, oder verstecken sich dahinter nur die alten 'Forschungsempfehlungen'? Die Seite

    https://www.familysearch.org/de/tree/person/details/M4CK-PLM

    hat also 'Mittlere Qualität' mit folgender Erklärung:

    grafik.png

    Klickt man auf den (verstümmelten) Link, so erhält man weitere Informationen

    Bewertung der Datenqualität • FamilySearch

    und lernt, dass drei wichtige Kriterien für die Bewertung eine Rolle spielen, die nach meiner Meinung eigentlich schon bei der Eingabe der Daten zu heftigen Fehlermeldungen bis zur Ablehnung führen sollten. Übrigens sollte der Vater auch nicht ca. 9 Monate vor der Geburt des Kindes verstorben sein (bekannte Ausnahmen: Kriegsehen).

    Betrachten wir die Seite einfach einmal gemeinsam aus meiner subjektiven Sicht, über die man sicher geteilter Meinung sein kann:

    grafik.png

    Ich zähle einfach auf:

    • Nicht eine Quelle, keine Zusammenarbeit, keine Erinnerungen (Woher stammen die Daten? Welche Qualität haben diese?)
    • Ein möglicher Doppeleintrag acht Jahre später, der nicht zusammengeführt wurde
    • Ortsangaben mit frei gewählten Abkürzungen, Mischmasch auch deutschen und englischen Bezeichnungen, keine Umlaute
    • 'Standardisierung' führt ganz und gar nicht zu einheitlichen Ortsbezeichnungen (es reichen schon zwei Tage zwischen Tod und Bestattung für eine neue Formulierung)
    • Verwaltungshierarchie unvollständig (Oberamt fehlt), falsche (nicht offizielle) Bezeichnungen (Schwarzwald ist eine geografische Bezeichnung)
    grafik.png
    • Immerhin ist das erste Kriterium zur Qualitätsabwertung 'Ein Kind, das vor der Geburt seiner Mutter geboren wurde' nicht erfüllt, obwohl der Christian mit seinen 12 Tagen Lebenszeit und seinem Geschlecht wohl auch keine Chance hatte, dieses Kriterium zur Abwertung zu erfüllen.
    • Mutter fehlt
    • biologischer Vater fehlt (Balthasar ist nur 'Stiefvater')
    • Redundanz: die 0 Quellen werden noch einmal einzeln aufgelistet.

    Mein Fazit: Mäßige Qualität

    Bei den Geschwistern wird es manchmal ein wenig besser. Hier die Magdalena:

    grafik.png

    Immerhin zwei Quellenangaben, aber sonst ein herrlicher Mischmasch und alles am selben Tag. Dass diese Primär-Quellenangaben schon bei ihrer Erfassung falsch sind, habe ich ja bereits in meinem letzten Beitrag in diesem Forum dargelegt.

    Nicht für ungut, Euer Hans-Jürgen (Scheibl)

    Es kann nur besser werden.

    1
    1
    Up Down
    1 Stimmen

    Active · Zuletzt aktualisiert 4. April

    Willkommen!

    Anscheinend sind Sie neu hier. Um zu beginnen, melden Sie sich an oder registrieren sich.
    Anmelden
    Registrieren

    Kommentare

    • Wiesenmichel
      Wiesenmichel ✭✭✭
      4. April

      Grüß Gott,

      es geht leider weiter.

      Eigentlich sollte jede Internet-Seite selbsterklärend sein, aber schon grübele ich über folgende Seitehttps://www.familysearch.org/de/tree/person/details/KFH6-N6T

      grafik.png

      mit der Bewertung 'Hohe Qualität' nach. Also schaue ich mir diese an:

      grafik.png

      In der Rubrik 'Vollständigkeit der Daten (2)' soll die 'Stadt' bei der Bestattung fehlen. Dautmergen war sicher damals nur ein Dorf (Gemeinde). Aber bei den anderen Ortsangaben wird auch nicht 'Stadt' verlangt. Richtig wäre hier die Forderung nach dem Friedhof, den es nicht unbedingt in jedem Dorf/Weiler/Gehöft usw. gab. Also sollte FS die Kirchen und Friedhöfe (48.24273, 8.74078) erfassen.

      Die fehlende Ortsangabe zum Tod ist berechtigt, könnte aber dem Eingeber schon bei der Eingabe nahe gelegt werden.

      In der Rubrik 'Übereinstimmung der Quellen' wird der Vorname 'Antonia Keib' beanstandet. Zumindest auf der Seite ist dieser nicht zu finden. Aha, das bezieht sich auf eine der 34 Quellen. Dort werden aber auch die nach Amerika ausgewanderten Kinder aufgezählt.

      Warum dann der falsche Nachname 'Amtsbote', aber nicht die Namen 'Petters' oder 'Teters' beanstandet werden, bleibt ein Geheimnis der KI.

      In der Rubrik 'Daten ohne Konflikte' wundere ich mich erst einmal darüber, dass es 'ohne' heißt. Eigentlich finden wir hier doch Daten mit Konflikten.

      Es wird auf einen Standard verwiesen, der sogar eine eigene ID hat. Wo kann man diesen nachschauen? Ist das eine interne Meldung zur Fehlersuche? Stimmt der Standard wirklich? Oder liege ich falsch mit

      grafik.png

      am Geburtstag bzw.

      grafik.png

      am Todestag. Existiert das Oberamt Rottweil wirklich bis 1945 oder endet es nich 1933?

      So jetzt muss ich die "Wochenschau" im Fernsehen anschauen und lass es einfach.

      Herzliche Grüße Hans-Jürgen (Scheibl)

      Es kann nur besser werden.

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      5. April

      Im Grunde geht es beliebig weiter:

      https://www.familysearch.org/de/tree/person/details/KF21-YC8

      grafik.png

      Hier hat der Eingeber die <> wohl erfunden, um die Unschärfe des Geburtsdatums und des Ortes darzustellen, weil FS hier jedem Eingeber alle Freiheiten lässt. So können wir die Zusätze in jeder beliebigen Sprache finden (vor, before, …). Hier lautete mein alter Vorschlag schon vor Jahren, Symbole einzuführen, die an das Datum angefügt werden:

      • 25.11.1836< vor 1836
      • 01.02.1836> nach 1836
      • 01.07.1836~ berechnet
      • 01.07.1836? wahrscheinlich 1836 (Mitte des Jahres ist genauso richtig/falsch wie 'etwa 1836', lässt aber exakte Datumsberechnungen zu)
      • 18.10.1835= durch Primärquellen gesichertes Datum

      Der eigentliche Trick besteht nun darin, dieses Symbol überall zu vererben, d. h. beispielsweise für die Kurzdarstellung

      Rosalia Maier (1816? - 1845=)

      Sie ist wahrscheinlich 1816 geboren und 1845 gesichert verstorben.

      Analog werden auch abgeleitete Eigenschaften wie das Alter mit den Symbolen versehen, d. h., bei einer Altersangabe von 29? ist somit mindestens ein Datum unsicher. Ggf. kann man vereinbaren, das = dann stillschweigend wegzulassen.

      Das Qualitätssicherungsprogramm nimmt jedoch 1836 als gesichertes Jahr an und erzeugt daraus seine Meldungen. Es erkennt dabei nicht, dass G4B5-5P7 das genaue Geburtsdatum 03.09.1846 liefert, womit die sechs altersbedingten Beanstandungen unter 'Daten ohne Konflikte' in Luft auflösen.

      Die Beanstandung des Taufalters von 9 Jahren bezieht sich auf 2 (ohne Maßeinheit). Richtig sind wohl zur damaligen Zeit 2 Tage, obwohl sich diese Karenzzeit in neueren Zeiten immer mehr verlängert hat, weil die nahen Angehörigen nicht mehr im gleichen Dorf leben, um rechtzeitig zum Tauffest erscheinen zu können. Ähnliches gilt seit der Erfindung der Kühlung durch Linde bei den Beerdigungen, bei denen auch nicht mehr die übliche 2-Tage-Regel gilt.

      Bei den ersten sechs Beanstandungen werden die Vornamen der Kinder genannt. Leider wird dies bei den weiteren Beanstandungen durch 'diese Person' ersetzt. Auch hier wäre es wünschenswert, den Namen der betroffenen Person einzusetzen.

      Aber immerhin erkennt die QS jetzt mehrfache (biologische) Eltern. Also zum Beispiel:

      Rosalia Maier (KF21-YC8) hat zwei leibliche Väter.

      Somit wird es langsam besser.

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      5. April bearbeitet 5. April

      Ich plappere einfach einmal weiter, auch wenn ich dabei den einen oder anderen Gedankenfehler mache. Als nächstes fällt mir die folgende Seite mit einer Qualitätsbewertung 'Hohe Qualität' auf. Das ist spannend:

      https://www.familysearch.org/de/tree/person/details/2BLY-XZM

      Interessant scheint mir die Spalte 'Eltern und Geschwister' zu sein, da dort die Catharina Wager zweimal auftritt.

      image.png

      Richtig, das Programm meldet wegen des Hinweises 'Stiefverhältnis' keine doppelten Eltern. Offensichtlich hat die Beata zuerst den Nicholas Wager geheiratet und mit ihm die Catharina Wager gezeugt. Aber irgend etwas stimmt doch da nicht mit den Jahreszahlen (wahrscheinlich muss ich dann doch noch einmal genauer auf Monat und Tag hinschauen).

      • der Nicholas stirbt 1868
      • die Catharina kommt 1867 auf die Welt (das geht in Ordnung)
      • aber schon 1866 soll die Beata den Bruder Victor Wager geheiratet haben, also vor dem Tod des Nicholas und vor der Geburt der Catharina
      • dann müsste doch der Victor der biologische Vater sein, oder?
      • auch müsste die erste Ehe vor dem neuen Heiratsdatum 07.08.1866 geschieden worden sein
      • leider lässt sich aufgrund des Nachnamens 'Wager' der Catharina nicht entscheiden, ob es wirklich ein Stiefverhältnis oder doch eine echte Adoption ist.

      Das muss ich mir morgen früh, wenn ich wieder etwas wacher bin, näher anschauen.

      p. s.:

      Ich glaube, ich muss die Überschriften doch anders interpretieren. 'Daten ohne Konflikte' scheint sich auf den Statistikbalken zu beziehen. Danach folgt in Klammern die Anzahl der Konflikte. Unklar ist mir noch, warum die Abweichung 1 (der leere Teil im Balken) jeweils auf dem Statistikbalken eine unterschiedliche Länge hat. Was wird denn unter den Rubriken als Basiszahl gezählt?

      image.png

      Vielleicht hilft ja ein Klick auf den Konflikt und die Logik der ID wird offenbart, und ich kann prüfen, ob meine Daten stimmen. Noch dazu sehe ich die Kombination „Dautmergen, Rottweil, Rottweil, Württemberg, Germany“ mit dem Denglisch-Mischmasch auf der ganzen Seite nicht. Offensichtlich scheint aber die Verwaltungshierarchie vom 8. Mai 1867 bei der Taufe richtig zu sein. Aber dort fehlt das Oberamt gänzlich.

      Bedeutet die ID, das FS schon mindestens 11.964.755 verschiedene Standards angelegt hat, aus der sich der Eingeber die richtige heraussuchen soll? Warum? FS kann das doch für den 07.05.1867 und natürlich auch für den 08.05.1867 automatisch generieren. Dann gibt es solche Fehlermeldungen in Zukunft nicht.

      Legen Sie eine Ortstabelle (mit Koordinaten) an, aus der sich der Eingeber den richtigen Ort heraussucht. Das muss er so und so machen. Liefern Sie ihm für die Ereignisdaten die richtige Hierarchie. So wird ein Schuh daraus:

      image.png

      Oha, mit einem Klick auf den Konflikt kann ich ihn verwerfen, also einen beweisbaren Fakt nach Gutdünken vernichten. Wenn ich nur wüsste, was hinter dieser ID steckt (siehe die vorherigen Beispiele, die sich auch auf verschiedene Hierarchien mit Rottweil beziehen, jedoch den Zeitbereich 1871-1945 angeben. Diese ID geht aber nur bis 1938, warum, warum?)

      Gruß vom verwirrten Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      6. April

      Grüß Gott,

      immerhin 23 Mitforscher haben ein Auge auf dieses Thema geworfen. Vielleicht finden diese ja noch andere Beispiele. Ich habe wieder eines:

      https://www.familysearch.org/de/tree/person/details/M4CJ-4DS

      Der Fehler liegt natürlich daran, dass die Maria Rapp (MTWZ-W3Z) und (M4CJ-48X) zweimal ins System eingegeben wurde. Der bei beide Eingaben fehlende Vater lässt eine uneheliche Geburt vermuten. Das ist aber nicht der Punkt, denn jetzt tauchen 'Vormundschaften' durch die Großeltern auf, die aber bei der Geburt einiger der Kinder bereits verstorben sind (Josef Rapp †1852, Theresia Wager †1837). Bei der Totgeburt '(Daughter) Rapp' fehlt logischerweise diese Familienbeziehung.

      image.png

      Immerhin meldet die Qualitätsbeziehung 'Diese Person hat 2 leibliche Mütter'. (Vorschlag: Name der Person einsetzen)

      Es würde mich nun brennend interessieren, aus welchen Dokumenten man diese rechtliche Vormundschaft für drei Kinder um 1850 herum entnehmen kann.

      p. s.: Ich hatte auch schon mal vor Jahren vorgeschlagen, den religiösen Beziehungstyp 'Siegelung' einzuführen. Vielleicht ist das hier der vom Eingeber beabsichtigte Typ.

      Herzliche Grüße Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      6. April

      Ich untersuche gerade Profile mit mehr als zwei IDs. Daher geht es Schlag auf Schlag

      https://www.familysearch.org/de/tree/person/sources/M4CJ-48G

      image.png image.png

      Die Quelle hat 'Hohe Qualität', also sollte man sich auf sie verlassen können. Nur ist die Meldung 'Das Geschlecht dieser Person stimmt nicht mit den Angaben in dieser Quelle überein' ein vernichtendes Urteil für eine Quelle. So lässt FS das Verschmelzen der folgenden Profile aufgrund des unterschiedlichen Geschlechts nicht zu

      https://www.familysearch.org/de/tree/person/details/MTWZ-ZR9 männlich

      https://www.familysearch.org/de/tree/person/details/M4CJ-48G weiblich

      https://www.familysearch.org/de/tree/person/details/GQBF-KCH weiblich und gelöscht

      p. s.: Warum bekomme ich ständig die Meldungen (das Komma steht zwar hier falsch vor dem Bild, aber es beruhigt die Rechtschreibprüfung 😎),

      image.png

      obwohl scheinbar für mich alles funktioniert.

      Dann arbeite ich einfach ein wenig weiter. Euer langsam nervender Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      6. April

      Hier haben wir wieder einen interessanten Fall

      https://www.familysearch.org/de/tree/person/details/M4CJ-W3C

      FS schlägt selbst eine Verschmelzung mit (MHNC-4N7) vor, die man aber wegen des unterschiedlichen Geschlechts nicht durchführen kann. Richtig, man kann vor der Verschmelzung natürlich erst das Geschlecht anpassen.

      In diesem Fall ist es sogar hilfreich, dass FS bei der Suche nach Verschmelzungskandidaten keine Rücksicht auf das Geschlecht der beteiligten Personen nimmt.

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      6. April

      'Mittlere Qualität' Wie werden eigentlich die Fehlermeldungen gewichtet? Es kann doch nicht nur die Anzahl sein.

      https://www.familysearch.org/de/tree/person/details/MHV7-CHV

      Vorsichtig gesagt herrscht auf dieser Seite totales Chaos.

      Zwei Daniel mit unterschiedlichen Nachnamen (stimmt die Zuordnung zum Vater?). Dann vier Jahre später ein weiterer Daniel mit dem Nachnamen der Mutter (ist sie wirklich verheiratet?). Im gleichen Jahr wird aber auch eine Francisca von dieser Mutter geboren, jedoch von einem anderen Vater gezeugt. Ein Daniel kommt weit vor der Eheschließung der zweiten Ehe zur Welt. Der zweite Daniel sieht wie aus der ersten Ehe aus.

      Die Qualitätsbewertung erkennt hier irgendetwas (nur was?)

      image.png

      Das ist aber nicht der Daniel mit dem Geburtsjahr 1824, der eigentlich auch bemängelt werden müsste. Ebenso die Francisca vier Jahre vor der Eheschließung. Schön wäre es - wie schon mehrfach gesagt -, wenn man den Namen der Person lesen könnte, auf den sich die Anmerkung bezieht.

      Wenn wir schon dabei sind, so könnte man diese Anmerkung

      image.png

      mit dem Ereignis 'Bestattung' versehen, um langwieriges Suchen zu vermeiden. Hier wird der Ereignisort der Bestattung gar nicht erwähnt. Dautmergen wird einfach abgehackt.

      Nur so nebenbei: Das ist natürlich falsch:

      image.png

      Möglicherweise ein Folgefehler von der erwähnten Hack-Aktion. Wo ist 'Dautmergen' geblieben.

      Hier versagt nicht nur die Reihenfolgeprüfung von FS bei der Eingabe, sondern auch die nachträgliche Prüfung durch die Qualitätssicherung.

      So langsam fühle ich mich als Beta-Tester, Euer Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      9. April bearbeitet 9. April

      Es gibt weiter rätselhafte Bemerkungen zu den Konflikten auf der Seite

      https://www.familysearch.org/de/tree/person/details/GBJW-9Q8

      image.png

      Wenn man nun auf der Seite nach 'Plze' sucht, findet man vier Treffer auf dem sichtbaren Bereich. Keiner davon bezieht sich auf den Standart-Ort Pilsen (Plzeñ). Einzig die drei Hierarchie-Angaben 'Plzeňský kraj' lassen eine Ähnlichkeit mit der Konfliktmeldung erkennen. Soll also diese Meldung dem Einreicher sagen, dass die Zuordnung von Babina 1846 zum Bezirk Pilsen hiatoriasch falsch ist?

      Der Einreicher korrigiert also seinen Ort und ergänzt die Hausnummer, auf die er nicht verzichten will

      image.png

      Im Gegensatz zu meiner früheren Mitteilung (als die große Freiheit der Gestaltung zumindest kurz ausgeschaltet war)

      https://community.familysearch.org/de/discussion/170272/fehler-bei-den-ortsangaben#latest

      wird diese Korrektur jetzt wieder übernommen. Theoretisch kann ich dann aber wieder einen falschen Text eintippen, Hauptsache der gewählte 'Standardisierte Ort' ist dahinter unsichtbar richtig gewählt.

      Nun ja, leider fehlt eine Versionierung, sodass ich eigentlich mit ständig wechselndem Verhalten rechnen muss. Daher bleibe ich bei meinen Screenshots für die Dokumentation. Morgen kann es schon wieder ganz anders aussehen.

      Leider muss ich auch feststellen, dass das Programm doch nicht meiner schönen Idee folgt, nur den (einzigen) Standard vorzuschlagen, der sowohl für den Ort als auch für das Datum gültig ist. Noch sind es nur einige wenige Angebote. Das kann sich aber schnell ändern, wenn man weiter in der Geschichte zurückgeht. Dann werden die Orte zwischen den Herrschaften verkauft, verpfändet, vererbt, teilweise vererbt usw.

      Herzliche Grüße vom Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      10. April bearbeitet 10. April

      Um den Sinn oder Unsinn der "Standardisierung" von Orten im Datenmodell von FS zu verstehen oder auch nicht, dient hier ein Beispiel, bei dem die Einreicherin die Ortsangabe deutlich ausgeschmückt hat:

      grafik.png

      Welcher "Standardisierte Ort" steht jeweils dahinter? Kann man den Ort herausfinden? Welchen Ort meint die Einreicherin?

      grafik.png

      So geht es auf jeden Fall nicht, da es leider mehrere 'Benešov' in Tschechien gibt. Selbst als Einreicher hätte ich Schwierigkeiten, den richtigen Ort zu bestimmen. Dabei ist Beneschau noch ein Beispiel mit relativ wenigen Doppelungen. Nebenbei bemerkt ist der letzte Eintrag in diesem Kurzausschnitt falsch, da es 'heute' (2025) keine 'Tschechoslowakei' mehr gibt. Eine automatische Überprüfung der Zuordnung auf das Existenzintervall der 'Tschechoslowakei' (1918-1992) sollte dies natürlich finden.

      Wie kann man dieses Problem lösen?

      Die sicherste Methode wären Koordinaten (49.78378, 14.68984), weniger sicher wären "offizielle", moderne Ortsnamen wie 'Benešov u Prahy' usw.

      Übrigens hat die 'Qualitätsbewertung' keine Meinung zu diesen Daten.

      Es gibt immer etwas zu tun, Euer Hans-Jürgen (Scheibl)

      0
    • Wiesenmichel
      Wiesenmichel ✭✭✭
      11. April bearbeitet 11. April

      Das Problem der "freien Gestaltung" von "Standardisiert"en Orten wirkt sich leider weiter negativ aus:

      grafik.png

      Die Eingaben stammen im Übrigen von derselben Einreicherin, jedoch mit einem Zeitunterschied von drei Jahren. Dabei wurde die Sekundärquelle (abgeschriebene Quelle) leicht verbessert.

      grafik.png

      FS fügt jetzt aber noch eine unverständliche Fehlermeldung zur Ortsangabe an eine Ereignismeldung an, die aber links nicht erscheint. Ein geheimnisvoller Algorithmus erkennt nun einen Verstoß. Ist es der Begräbnisort Kralové oder der Pfarrort Benešov?

      Toll, was man in FS alles machen kann. Das Datum wird erweitert, sogar die Nachkommen der Antonia, die Quelle usw. kann man dort angeben. Vielleicht meldet sich ja mal jemand Kompetentes und erklärt mir, was der Begriff "Standardisierung" im Sinne von FS bedeutet.

      grafik.png

      Da es sich bisher auf GEDCOM Daten bezieht, könnte auch eine fehlerhafte Übernahme solcher Daten vorliegen.

      Aber ein Erfolgserlebnis haben diese Ergänzungen, da sie auf die Primärquelle des Sohnes verweist:

      Site faviconStátní oblastní archiv v Praze

      Oh weh, wie soll man das reparieren, denn es geht z. B. mit der Mutter in gleichem Stil weiter? Da traue ich mich erst einmal nicht heran:

      grafik.png

      Das Problem ist doch, dass man im nächsten Schritt keine Details, sondern nur Blöcke übertragen kann

      grafik.png

      und Schwups hat die Anna zwei verschiedene (aber ähnliche) Eltern.

      Nebenbei hat dann das Kind Antonie auch mal keine Eltern.

      Herzliche Grüße Hans-Jürgen (Scheibl)

      0

    Willkommen!

    Anscheinend sind Sie neu hier. Um zu beginnen, melden Sie sich an oder registrieren sich.
    Anmelden
    Registrieren
    Clear
    No Groups Found

    Willkommen!

    Anscheinend sind Sie neu hier. Um zu beginnen, melden Sie sich an oder registrieren sich.
    Anmelden
    Registrieren

    Quick-Links

    • Support kontaktieren
    • Meine Gruppen
    • Meine Lesezeichen0
    • Meine Themen
    • Meine Entwürfe0

    Kategorien

    • Alle Kategorien
    • 501 FamilySearch-Hilfe
    • 158 Allgemeine Fragen
    • 135 Familienstammbaum
    • 22 Erinnerungen
    • 66 Suchen
    • 49 Indexierung
    • 7 FamilySearch-Benutzerkonto
    • 20 FamilySearch-Center
    • 8 Community-Zentrum
    • 116 Verbesserungsvorschläge
    • Gruppen
    Das ist eine Eingliederung. Sie kann durch die Löschtaste oder die Rücktaste gelöscht werden. Drücken Sie Tab, um in die Eingliederungsmöglichkeiten hineinzukommen.
    • Über uns
    • Mitmachen
    • Blog
    • Seitenübersicht
    • DNA
    • So erreichst du uns
    • Cookie-Präferenzen

    Nutzungsbedingungen von FamilySearch | Datenschutzmitteilung

    © 2025 Intellectual Reserve, Inc. Alle Rechte vorbehalten. Ein Service der Kirche Jesu Christi der Heiligen der Letzten Tage

    Logo der Kirche Jesu Christi der Heiligen der Letzten Tage

    Sprache ändern

    Vor kurzem verwendete Sprachen