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.
Grüß Gott,
im vorliegenden Fall
https://www.familysearch.org/tree/person/details/GDDF-9MC
gibt es eine neue, für mich bisher unbekannte Variante der Adoptionen, bei der FS es zulässt, dass nur noch ein Elternteil eine Adoption zulässt
Was ich nicht verstehe ist, dass es zwar zwei Adoptionen gibt (Kateřina und Josef), aber nur eine einzige zweite Familie (Josef) im Folgenden auftritt. Wo ist die Kateřina (*1822) hingekommen?
Jetzt kann man sich bei den unehelichen Kindern (zumindest beim Josef) die verschiedenen Varianten zusammenstellen
Wie immer empfehle ich auszuprobieren, was FS als Fächerstammbaum usw. anzeigt. Auch wenn es mühsam ist, versuche ich noch einmal die alten Beispiele herauszusuchen, bei denen ein oder beide Adoptionseltern zum Zeitpunkt der Geburt des Enkels bereits verstorben waren.
Stimmen die Ergebnisse meiner "Verwandtschaftsbeziehungen" wirklich? Wie heißen die Kindeskinder?
Vielen Dank für alle plausiblen Erklärungen.
Hans-Jürgen (Scheibl)
I'm not going to try to post a translation, because I'm not sure what the question really is; I suspect there's a misunderstanding about how parent-child relationships are structured in the Family Tree. It seems that you're expecting the computer to somehow automagically know stuff that hasn't been entered.
There are several Help Center articles about entering parent-child relationships.
https://www.familysearch.org/en/help/helpcenter/article/how-do-i-add-a-child-to-family-tree
As they clearly state, when such a relationship is entered, it is assumed to be biological until/unless a user specifies otherwise in a separate set of steps.
Other than not allowing a person to be his or her own parent/child, the system enforces no limits on the profiles involved. Some combinations will trigger a data problem warning, but those are not hard stops.
Another thing to keep in mind is that in relationship calculations, FS simplifies life and simply ignores the relationship type. This means that if grandparents have been entered as adoptive parents, then "show my relationship" will be off by a generation, since it always goes for the shortest path.
The user can control what's shown in chart views by using the "preferred" setting; the parent or couple with that checkmark will be first in a descendancy chart, and will be the parents shown in a fan or pedigree chart. Note that it is strictly a per-user setting: it doesn't affect anyone else's views involving those profiles, and has no effect on "show my relationship".
If you want a second parent to show up, you will need to add one. This will only work if you know something about the father. We have been asked not to put blank people into the Tree.
This article https://www.familysearch.org/en/help/helpcenter/article/how-to-enter-names-in-family-tree states:
You cannot save a name with an invalid character in any of the name fields.
@ Maile L
Note: The sample data was not entered by me. Unfortunately, there are several thousand Czech names in FS that contain diacritic capital letters inside the name.
I (as other researchers) have given up correcting them.
All my comments refer to data entered by foreign researchers and are not indicated by the program as erroneous or at least questionable. Here the checking of the data in the FS-program needs to be improved.
By the way, baptism can be done before birth without error message, burial can be done before death without error message. (peanut)
Second parent? The children are all assigned to the two parents indicated above.
In addition, one parent is also added through adoption.
The main flaw of FS is being able to assign multiple parents to one person. Biologically this is (at least up to now) not possible.
Now the legal inheritance (adoption) is mixed with the biological.
Richtig, das Problem ist die Kind-Eltern-Beziehung. Im biologischen Modell können wir einem Kind möglicherweise einen einzigen Vater und möglicherweise eine Mutter zuordnen (möglicherweise = auch unbekannt). Das Kind hat seine vielen Eigenschaften und zwei Fremdschlüssel auf andere Personen in den Rollen 'Vater' und 'Mutter'. Es gibt somit keine zwei (oder mehr) Väter oder zwei Mütter pro Kind schon aufgrund dieses Datenmodells.
Beim GEDCOM-Modell steht dagegen die Familie (family) im Mittelpunkt, der man möglicherweise einen einzigen Vater und eine einzige Mutter, aber beliebig viele Kinder zuordnen kann. Vater, Mutter, Kinder sind Individuen (indi), die man wiederum weiteren Familien in unterschiedlichen Rollen zuteilen kann. Absicherungen gegen inkonsistente Zuordnungen müssen speziell programmiert werden.
Weiterhin bestehen rückbezügliche Verweise im GEDCOM-Modell (Zeiger auf die Familie, Zeiger auf die Kinder), so dass das Datenmodell kein relationale Datenmodell (RDM) ist. Hier kann es zu Fehlern in der Konsistenz der Datenbank kommen.
Falls das FS-Datenmodell dem GEDCOM-Datenmodell entspricht (was aus der Historie zu vermuten ist), dann hat es dieselben Probleme. Weitere Ausführungen würden den Rahmen dieses Kommentar sprengen. Vielleicht hilft ein alter Aufsatz zu GEDCOM 5.5 von mir etwas weiter.
Nun gibt es eine Neuerung FamilySearch GEDCOM 7, die ich bisher jedoch noch nicht studiert habe. Aber Dein Kommentar über die Nicht-Realisation (??) hat mich dann doch überrascht (wenn ich ihn wiederfinde).
Ebenso geht es mit meinen uralten GEDCOM-Experimenten, die ich vielleicht wieder reaktivieren kann.
OK, hier ist der erwähnte Link:
Are these suggestions for how to improve FamilySearch's Family Tree?
Yes, to improve FS's Family Tree, that is my main (and only) goal.
But look here:
Let's follow rule #1.
Paper is patient. But the user does not read the rules. So the FS program must behave properly and seriously fight against it (it = DAU dümmster anzunehmender Benutzer = dumpest supposed user (there might be a special idiom)).
So we take the split function, parse the name and examine each part for special characters and length.
Oh, no, this example is better:
Where does the middle inital come from? What a hassle just to break the rule #1.
Herzliche Grüße Hans-Jürgen (Scheibl)
Um noch ein wenig weiter zu fachsimpeln, habe ich ein fremdes Programm ausgepackt (gehackt), welches das GEDCOM-Datenmodell als Datenbank (nicht wie eigentlich ursprünglich geplant als Datenübertragungsprotokoll) einsetzt und in eine Access-Datenbank umsetzt und dann diese zum Glück öffentlich zugänglich macht. Somit lässt sich die Datenstruktur näher untersuchen und auf Entwurfsfehler abklopfen.
Wie Sie sehen, besteht die Datenbank hauptsächlich aus einem m:m-Beziehungstyp zwischen den Familien (FAMS) und den Individuen (INDI). FAMS verstößt durch die Wiederholfelder _1 bzw. _2 natürlich gegen die 1. Normalform der Relationalen Datenbanktheorie.
Die Tabellen FAMS und INDI haben jeweils zwei Schlüsselkandidaten ID und FAMS, bzw. ID und INDI, so dass in beiden Tabellen die ID-Felder überflüssig sind. Auch in der Verknüpfungstabelle INDI_FAMS könnte man ID durch einen kombinierten Schlüssel aus den beiden Feldern INDI_FAMS.INDI und INDI_FAMS.FAMS ersetzen.
Neben diesen technischen Einzeldetails ist es jedoch wichtig zu erkennen, dass jedes Individuum jeder Familie sogar mehrfach zugeordnet werden kann, da durch die Einführung der ID nicht sicher gestellt ist, dass die Kombination INDI_FAMS.INDI und INDI_FAMS.FAMS nur einmal vorkommen darf. So hätte das Eliminieren von INDI_FAMS.ID auch noch diesen positiven Nebeneffekt: Kein Kind kann mehrfach einer Familie zugeordnet werden.
Auch fehlen im Modell noch weitere Beziehungen, das HUSB und WIFE Verweise auf die Tabelle INDI sind.
Auf den ersten Blick nicht erkennbar ist der zweite m:m-Beziehungstyp CHIL, der die Tabelle FAMS ein zweites Mal mit der Tabelle INDI über das Feld CHIL.CHIL verknüpft.
Die Tabelle OCCU ist eine reine Nachschlagtabelle, um die Berufsbezeichnungen lesbar zu machen.
Das muss erst einmal reichen. Auf Wunsch kann ich das Datenmodell noch etwas näher beleuchten.
Ihr Hans-Jürgen (Scheibl)
That rule refers to using only initials such as M L in place of my given name and surname, not to using middle initials.
Aha, ich verstehe, name <> middle initials. Jetzt verstehe ich die Regel #1 besser. middle initials sind also kein Teil des Namens.
Und was ist mit "Lorenz" auf der rechten Seite? "" sind keine Sonderzeichen?
Der tschechische Vavrinec ist der deutsche Lorenz, der lateinische Laurentius usw.
Wir sollten aber nicht weiter über diese Peanuts diskutieren, die vom jeweiligen Priester oder Kirchenbuchschreiber oder später auch noch vom Ahnenforscher eingeführt wurden.
Ich habe mich inzwischen an die viele verschiedene Schreibweisen gewöhnt, ja sogar an die falschen tschechischen Großbuchstaben innerhalb der Vor- und den Nachnamen. Daher vermeide ich es, diese Forscher auf die FS-Regeln hinzuweisen.
Noch einmal herzlichen Dank für die vielen "Gebrauchsanweisungen" aus dem Help Desk von FS. Ist das eine Aufforderung von Ihnen an mich, die Halbadoption zu einer Volladoption zu korrigieren?
Warum mache ich das nicht?
Manchmal habe ich verrückte Assoziationen. Daher frage ich mich, ob das Portal GENi diese Adoptionen zulässt und diese anders mit 'Sie könnten auf andere Weise verbunden sein" darstellt. Dazu muss ich aber erst noch eine geeigneten Fall (mit Adoptionen) in beiden Portalen finden. Vielleicht hat ja ein anderer Forscher hier schon weitergehende Informationen gefunden. Hier nur mein Ansatzpunkt:
Das wird nun etwas länger dauern.
Herzliche Grüße Hans-Jürgen (Scheibl)
Grüß Gott,
stellen wir uns einen normalen Anfänger-Forscher "X" vor, der nach einen ersten Versuchen voller Freude auf einen seiner Vorfahren 'Matěj Beneš' trifft. Er druckt den zugehörigen Fächerstammbaum sofort aus und zeigt ihn voller Stolz allen seinen Bekannten und Verwandten
X forscht weiter und weiter. Nach einiger Zeit möchte er den Fächerstammbaum verschenken und erzeugt ihn neu. Dabei weiß er natürlich nicht mehr, was er alles in der Zwischenzeit gemacht hat
Nun sieht der Fächerstammbaum aber ganz anders aus.
Leider kann X auf den beiden Diagrammen nicht erkennen, welcher das richtige ist bzw. weshalb die beiden Diagramme unterschiedlich sind. Er hat nämlich keine Fehlermeldung oder einen Hinweis während seinen Forschungen gefunden.
Ich halte hier das Verhalten von FS schlichtweg für falsch. Wenigstens irgendwo sollte ein Hinweis auf dem Diagramm dazu erscheinen.
Gruß vom Hans-Jürgen (Scheibl)
p. s.: Bitte reichen Sie das Problem an die Programmierer weiter. Sie müssen mir nicht die Ursache erklären. Ich kenne diese und habe sie provoziert. Die Daten dazu stammen nicht von mir. Ich halte es auch nicht für einen Benutzerfehler von X, weil dieser einfach zu dumm für die Bedienung von FS ist. Einen Vorschlag wie "Benutze kein Fächerdiagramm!" oder "Schau Dir alle Personen einzeln an!" ist auch nicht wirklich zielführend.
I consider it one of the strengths of FS's tree that you can represent in it every parent-child relationship that a person had during his or her life. The possibility of this throwing off the "show my relationship" algorithm or causing weirdnesses on chart views is not going to change my mind. The solution to those is not to curtail non-biological relationships, but to reconsider which relationships should be entered on those specific profiles.
If the grandparents have been added as adoptive parents merely based on a researcher's desire to "fill the hole" (or hide illegitimacy), then in my opinion, that relationship should be removed, because it does not reflect the people's actual lives. I'm not LDS, so I have no idea what this would do or not do to LDS rites, but given the lack of general outcry over impossible adoptions, I don't think that removing the pseudo-adoption interferes with anything.
Grüß Gott, Julia,
ich schlage ja nur einige wenige (abgesehen von den "Standardisierten Orten") Verbesserungen vor, die alle Probleme beseitigen könnten:
Den letzten Punkt sollte ich vielleicht noch etwas erklären. FS ist für mich ein deterministisches System, d. h., es sollte immer dasselbe Ergebnis herauskommen, wenn keine Veränderungen an der Datenbasis vorgenommen werden (abgeschlossenes System). Das ist aber - wie gezeigt - nicht der Fall.
Schauen wir dazu einmal eine Logiksprache wie PROLOG an, die als Grundlage von so genannten Expertensystemen (ein Vorläufer der heutigen KI) entwickelt wurde. Sie beruht auf Fakten (in FS würde ich es als Ereignisse bezeichnen). Leider sind in FS die Fakten oft unscharf (ungenaue Daten, ungenaue Namen usw.) Dazu kommen dann die Regeln, wie die Fakten zusammenhängen. Daraus können durch Resolution neue, bisher in der Datenbasis nicht vorhandene Fakten abgeleitet werde.
Warum ich so weit aushole? Nun, die PROLOG-Systeme haben eine Erklärungskomponente, die man bei Bedarf aufrufen kann. Sie erklärt dann, warum der eine oder der andere Fächerstammbaum richtig ist.
Im vorliegenden Beispiel würde diese Erklärungskomponente also etwa melden:
Wichtig ist somit der Verweis auf eine von der biologischen Vererbung abweichende Regel, die nicht in der zugrunde liegenden Datenbasis gespeichert ist, sondern auf einer persönlichen Vorliebe des Benutzers beruht. So kommen "Gefühle" ins Spiel, die eigentlich hier nichts zu suchen haben. In der FS-Hilfe tauchen dann so Ausdrücke wie "not comfortable" auf. Ein Gefühl, das ein adoptiertes Kind dazu veranlasst, nach seinem biologischen Eltern zu suchen.
Formulieren wir einmal (unvollständig) einige Beziehungstypen zwischen zwei Personen:
oder (ein wenig Spaß muss sein und wir biegen uns die Regeln zurecht) 😉
Die ersten zwei Regeln sind "Muss"-Regeln. Dann folgen "Kann"-Regeln, meist noch mit zusätzlichen Einschränkungen. Die Regeln definieren Zustände (mit Beginn und (offenes oder festes) Ende) oder Einzelereignisse.
=====================
Ehrlich gesagt sollten wir uns mehr um die Rettung der "Standardisierungen von Datum und Ort" kümmern. Eigentlich ist das nur eine "innere" Standardisierung, denn jeder Eingeber kann den nach außen sichtbaren Teil auch heute noch völlig frei gestalten. Hauptsache er nimmt für die innere Darstellung eine standardisierte Variante. Beim Datum gibt dies inzwischen jede Programmiersprache/jede Datenbank vor, bei den Orten ist das aber nicht so leicht. Hier müssen wir uns eigene Regeln geben.
Vielleicht wird FS dann irgendwann diese freie Anzeige abschalten, so dass nur noch die echten Standards sowohl beim Datum als auch bei den Orten sichtbar werden.
Aber leider ergibt sich dadurch ein erheblicher Informationsverlust, da die internen "Standardisierten Orte" beispielsweise keine Hausnummern oder andere Zusätze/freie Erfindungen, Abkürzungen usw. haben. Vergleichen wir einmal beide Felder bei Zufallsfunden (links Anzeigetext, rechts Standardisierte Orte)
Nebreziny, Bohemia Nebřeziny, Plzeň-sever, Tschechien
Bohemia,Czechrepublic Böhmen, Tschechien
Nebreziny,Bohemia,Czechrepublic Nebřeziny, Plzeň-sever, Tschechien
Nebřeziny č.12, Plzeňský kraj, Česko Pilsner Region, Tschechien
Hier muss noch viel Zeit investiert werden.
Erneut und letztmalig mein Vorschlag:
Grüße vom Hans-Jürgen (Scheibl)
Kinda going at things from bottom to top here:
The algorithm for choosing a background value for a location must be able to do so without a date being entered, because sometimes, we only know "where", not "when".
The Places database is very, very far away from complete and correct. Many things in it use a weird mix of languages, or different types of jurisdictions for the different levels (such as a mix of ecclesiastic and secular); and many places do not have any dates associated with them. (And even the ones that do often have overlaps and/or gaps, or arbitrarily-chosen end dates that don't correlate with any actual change in administration.) You can help improve it by making specific suggestions for corrections in the Places tool (https://www.familysearch.org/research/places/).
LDS rites, such as sealings, have no place in the public view of the Family Tree. They should not -- and as far as I know, do not -- require any relationships to be added that did not exist in the people's actual lives. If the impossible grandparent adoptions are due to such rites, then someone is Doing It Wrong: those adoptions need to be deleted, because you and I should not see any evidence of those rites, anywhere.
And finally: have you explored the new "Other Relationships" section? I've been having fun using it to track the convoluted back-and-forth of godparents (some of whom later became their godchild's parents-in-law). These aren't shown in any chart views, of course, but I've been musing about some sort of color-coding or numbering system to annotate a descendancy chart with them. (Or maybe a fan chart? I'll have to see.)
Grüß Gott,
ich muss mich korrigieren. In der FS-Hilfe werden die Nebenwirkungen einer Adoption nicht beschrieben. Meine aus dem Kopf heraus gemeldeten Zitate stammen aus anderen Portalen. Eine Reihe von Aussagen finden wir heute noch in den Artefakten von FS. FS kann nicht leugnen, historisch aus dieser LDS-Gedankenwelt heraus entstanden zu sein. Ich empfehle daher einfach einmal in Google eine Suche mit
"www.google.com/search?q=Adoption+and+Family+History%E2%80%94Everlasting+Ties&rlz=1C1LENN_enDE505DE515&oq=Adoption+and+Family+History%E2%80%94Everlasting+Ties&gs_lcrp=EgZjaHJvbWUyBggAEEUYOTIHCAEQIRigATIHCAIQIRigAdIBCDQ3NDJqMGo3qAIAsAIA&sourceid=chrome&ie=UTF-8"
Wenn die FS-Sperre die direkte Suche über den Link verhindert (daher in ""), dann einfach manuell suchen
Permission Problem You need the Garden.Uploads.Add permission to do that.
Der erste aufgeführte Treffer
"www.churchofjesuschrist.org/study/liahona/2022/03/digital-only/adoption-and-family-history-everlasting-ties-eternal-connections?lang=eng"
zeigt das Verhältnis von biologischer zu religiöser Vererbung (genauer zwischen biologischen und versiegelten Linien) auf.
Auch hier in der Community wird das Verhältnis angesprochen und weiter geleitet:
"community.familysearch.org/en/discussion/125358/everlasting-ties-eternal-connections"
Daher hatte ich noch den (englischen) Text im Kopf (hier übersetzt)
Es kommt häufig vor, dass adoptierte Personen widersprüchliche Gefühle darüber haben, was dies im Hinblick auf ihre Vorfahren bedeutet.
mit dem schon erwähnten englischen Begriff "uncomfortable" und der damit verbundenen Gefühlswelt. Es ist daher spannend, was aus dieser Gefühlswelt heraus noch in FS zu finden ist. Ob beispielsweise die Adoption höher als die biologische Vererbung eingeschätzt wird usw.
Herzliche Grüße vom Hans-Jürgen (Scheibl)
p. s.: Leider hat FS meinen ursprünglichen Entwurf mit
hartnäckig abgelehnt, daher dieser optisch nicht mehr ganz so schöner Rettungsversuch ganz ohne Bilder und "https:"
Unsere Kommentare müssen sich gerade zeitlich gekreuzt haben. Die Antwort darauf kommt später.
@Julia Szent-Györgyi (the normal user 🙂)
Gruß Gott, Julia,
nicht verstanden??
The algorithm for choosing a background value for a location must be able to do so without a date being entered, because sometimes, we only know "where", not "when".
Der Aufbau einer Ortsdatenbank mit Verwaltungshierarchie ist vollkommen unabhängig von den Daten einzelner Personen. Solche Datenbanken gibt es schon mehrfach, z. B.
Sie müssen sich nur mit diesen Datenbanken in Verbindung setzen, ja, Sie können sich direkt an diese andocken.
because sometimes, we only know "where", not "when".
Eine Person (individuum) ohne ein einziges Datum ist sinnlos. Daher benutze ich folgende Regeln:
Zur Erinnerung: Ein Datum ist ein komplexes Objekt mit Zahlenangaben, ggf. dem zugrundeliegenden Kalender und (wichtig!) einer Aussage über die Zuverlässigkeit: = durch Primärbeleg bestätigt, < vor, \> nach, ~ geschätzt, ? unsicher
LDS rites, such as sealings, have no place in the public view of the Family Tree. They should not -- and as far as I know, do not -- require any relationships to be added that did not exist in the people's actual lives. If the impossible grandparent adoptions are due to such rites, then someone is Doing It Wrong: those adoptions need to be deleted, because you and I should not see any evidence of those rites, anywhere.
Das Löschen ist eine zentrale FS-Aufgabe, indem einmal alle bisherigen Adoptionen aufgelistet und von Helfern überprüft werden. Alle zukünftigen Adoptionen sind nur unter Angabe der Primärquelle erlaubt. Ansonsten bleibt es bei Zufallsfunden, bei denen man die wahre, einzige Mutter noch bestimmen muss. Ähnliches gilt für die Tausende falsch geschriebenen tschechischen Namen. Für beide Aktionen muss jemand das Recht haben, entsprechende Abfragen (queries) zu definieren und ausführen zu können. Für die bis zu 300 Jahre alten "Adoptionen" gibt es keinen Primärbeleg. Die Buchstabenkorrektur kann durch eine Hilfstabelle automatisiert werden. Das ist keine stupide Aufgabe für die Community.
And finally: have you explored the new "Other Relationships" section? I've been having fun using it to track the convoluted back-and-forth of godparents (some of whom later became their godchild's parents-in-law). These aren't shown in any chart views, of course, but I've been musing about some sort of color-coding or numbering system to annotate a descendancy chart with them. (Or maybe a fan chart? I'll have to see.)
Nein, ich sehe nur diese Werkzeuge. Also bitte immer den Link dazu senden. Wo ist diese neue Sektion? Vielleicht auch einmal einen Screenshot dazu beilegen, damit ich auch Spaß habe.
Gruß vom Hans-Jürgen (Scheibl)
Yes, place information and dates are closely related, and yes, a person for whom you don't know at least a century shouldn't have a profile -- but I meant that at the time of data entry, for any individual conclusion, it is important that the algorithm for choosing the background value ("standardized place" in FS parlance) be able to function seamlessly regardless of what order the user is doing things. It needs to be able to offer the correct choices even if said user hasn't gotten around yet to entering any dates. In fact, I would go further: even if dates have been entered, the choices offered should reflect the whole range, because what if the date has a typo or was misread? Also, dates of administrative changeovers do not necessarily correspond with changes in usage: people will continue to use the old labels for years, because it takes that long for the new labels to become familiar. Therefore, if a user wants the conclusion to reflect the placename as recorded in the source -- an admirable goal, generally -- then he needs to be able to choose from the full list.
"Das Löschen ist eine zentrale FS-Aufgabe, indem einmal alle bisherigen Adoptionen aufgelistet und von Helfern überprüft werden."
I disagree. Adoptions are no different from any other conclusion in Family Tree, and should not be treated differently. FS does not allot any of its limited resources to "helpers" or proofreading, and it shouldn't need to. Correctly used, the LDS-specific part of FS does not create relationships or anything else that public users can see. The impossible adoptions that you've encountered can probably be traced to a single user who misunderstood the procedure, and the errors need to be corrected by individual users.
Likewise for any "central" (i.e., automated) change of capitalization in names: CamelCase is a thing, meaning that sometimes, a capital letter in the middle of a name is exactly correct. I don't think an algorithm can be written that can tell the difference in correctness between DeÁtha and KateŘina -- and given FS's track record with automated processes, I don't even want them to try.
---
In the default arrangement, "Other Relationships" are down toward the bottom of the person detail page, below Family Members but above the biography.
(You can re-arrange the left-hand column of the detail page using "My Layout Settings", found as the first item in your Tools box, in the right-hand column. I've moved Other Information below the Family Members section, because I use it a lot less often.)
Grüß Gott, Julia,
die Argumentation im ersten Abschnitt verstehe ich leider nicht. Möglicherweise gehe ich bei meinen Forschungen ja völlig falsch im Sinne von FS vor.
Normalerweise starte ich bei einer Ausgangsperson, für die ein Ereignis dokumentiert ist (und die ich erfasst habe). Um nun meinen Stammbaum zu erweitern, suche ich nach allen anderen Informationen in diesem Dokument, also weitere Personen wie Eltern, Paten, Pfarrer, Hebamme, Schreiber, Orator, Prüfer usw. Wenn ich Glück habe, dann sind bei diesen Personen Orte angegeben. Weiterhin gehe ich davon aus, dass diese Personen wahrscheinlich die gleiche Religion wie meine Ausgangsperson haben (oder das Land eine Einheitsreligion hat).
Nun versuche ich, die zuständige kirchenbuchführende Stelle (analog gilt das in den neueren Zeiten immer auch das Standesamt) für den jeweiligen Ort herauszufinden. Dann hoffe ich, dass das Kirchenbuch nicht zerstört wurde und dass vielleicht ein Index die Suche erleichtert.
Im richtigen Kirchenbuch taucht dann zum ersten Mal ein Datum auf. Wenn nicht, muss ich es nach den schon aufgezählten Regeln abschätzen. Somit habe ich Person, Ort und Datum. Das muss reichen.
Nun kann ich die neue Person mit Ort und Ereignisdatum in meine Datenbank (FS? usw.) eintragen. Dazu muss ich nur den richtigen Ort in FS finden. Die dann in FS (in einigen Jahren modernisierte, aktuelle, vollständige) "Standardisiert Ortsverwaltung" liefert mir die für das Datum sofort die von den vielen Helfern aufgebaute, gesicherte Verwaltungshierarchie, normalerweise für die Forschung interessant aber nicht lebensnotwendig.
Habe ich mich beim Datum einmal vertippt und hat das die Plausibilitätsprüfung von FS nicht erkannt (also Taufdatum weit vor der Geburt, Bestattungsdatum weit vor ...), dann korrigiere ich das Datum. Sofort und in Zukunft berechnet FS die Verwaltungshierarchie neu. Diese Hierarchie wird doch nicht fest angebunden sondern bei jedem Aufruf dynamisch bestimmt. Auch stochere ich doch nicht weiter im Trüben herum, ob es nicht noch ein "schöneres" Geburtsdatum in der Nähe des gefundenen Datums gibt, das ich meiner Person ersatzweise zuordnen mag, weil die Verwaltungshierarchie dann schöner ist.
Was verstehen Sie unter 'Label', an denen die Menschen noch lange hängen? Was soll mir dieses Argument sagen? Wenn ich meine Steuer an einen neuen Grundherren zu zahlen habe, sollte ich das tunlichst auch tun.
------
Offensichtlich besitzt FS keine Möglichkeit, systematische Fehler aus der Datenbasis zu eliminieren, oder doch? Ich würde beispielsweise die Suche nach Adoptionen weitgehend auf ein Land oder sogar auf einen Eingeber filtern. Auch scheint es keinen Ansprechpartner zu geben, dem man systematische Fehler (und deren Verursacher) melden kann. Mein erster Versuch, dies mit einem Klick auf "Verstoß melden" zu erreichen, wurde vom Support mit dem Hinweis auf die Regeln erst einmal abgeblockt (kann man in den alten Kommentaren nachlesen), da es diesen Fall nicht geben kann.
Wenn FS auf die Schwarmintelligenz setzt wird es noch viele Jahre lang religiöse Adoptionen und falsche tschechische Namen geben. DeÁtha ist kein tschechischer Name und enthält keinen der kritischen Buchstaben. Also filtern wir systematisch. Dazu habe ich eine Liste angelegt (hier nur die richtigen Variationen). Man muss also nur die tschechischen Großbuchstaben ČĚŇŘŠŤŮŽ innerhalb der Namen suchen und ersetzen, alle anderen Diakritika aus anderen Sprachfamilien sind uninteressant und bleiben somit erhalten. Das sollte für einen erfahrenen Programmierer keine besondere Herausforderung darstellen (stimmt natürlich nicht, siehe -ovÁ).
Ich habe die "Other Relationships" bzw. "Sonstige Beziehungen" immer expandiert. Hier habe ich noch nie einen Eintrag gesehen und ich schätze, doch schon mehrere tausend Personenseiten besucht zu haben. Vielleicht können Sie einige Ihrer spaßigen Erlebnisse noch veröffentlichen.
Herzliche Grüße vom Hans-Jürgen (Scheibl)
Sorry, ich verstehe die ganze Aufregung nicht. Nach neuem geltendem Recht kann sich jeder Mann beim Standesamt als Frau eintragen lassen. Und kein Mensch darf dann Einwendungen machen. Nicht einmal Sportlerinnen, die es unfair finden, gegen biologische Männer antreten zu müssen.
Und nach Regeln der Kirche Jesu Christi darf eine mit ihrem Kind sitzen gelassene Frau ihr Kind von ihren eigenen Eltern adoptieren lassen. Ich habe derweil erfahren, dass das zu Datenproblemen bei MyHeritage führt. Aha? Und wer hat nach den Datenproblemen von Familysearch gefragt, die ihre gesamte Website umstellen mussten wegen der Gesetzesänderung, dass Männer mit Männern heiraten dürfen?
Ic habs ja gesehen, wieviel Stress das auf Familysearch verursacht, wenn jemand ein schon vorhandenes Ehepaar mit vertauschten Geschlechtern erstellte. Das muss man sich mall vorstellen! Protestler erstellen mutwillig Doppelacounts und wissen womöglich sogar, was das verursacht!!! Inzwischen hat man das aber in den Griff bekommen. Nun! Jetzt darf sich MyHeritage eine Lösung ausdenken, solche Datenprobleme in den Griff zu bekommen. Aber wie ich Familysearch kenne, werden DIE sich darum kümmern, eine Lösung für MyHeritage zu erarbeiten. Die Frage ist dann natürlich, inwieweit MyHeritage solche Lösungen akzeptieren will.
Grüß Gott,
vielleicht sehe ich ja die Ahnenforschung falsch, aber ich gehe von folgendem Modell aus, das aus zwei Bereichen besteht, wobei die biologische Vererbung eine Untermenge der rechtlichen Vererbung ist. Mit anderen Worten
Dazu kommt, dass ein Individuum nach heutigem Wissensstand immer aus einer biologischen Vererbung stammt, auch wenn nicht immer alle Details der beiden Personen bekannt sind. Dabei ist zumindest bei den Menschen immer ein männlicher und ein weiblicher Partner notwendig.
Nun ist es offensichtlich unserer Medizin gelungen, eine dritte Vererbungslinie über die Mitrochondien zu erfinden, indem je ein haploider weiblicher und männlicher Chromosomensatz zusammengeführt und in eine dritte Einzelle eingelagert wird. Damit wird die rein weibliche Vererbungslinie unterbrochen. Das Kind hat einen Vater, aber zwei Mütter. Eine Mutter liefert das Genom, eine weitere die Mitrochondrien, die bekanntlich immer aus der weiblichen Linie stammen.
Aber das ist noch keine allzu drängendes Problem. Vielmehr quälen sich die verschiedenen Genealogie-Programme mit den beiden erwähnten Bereichen herum. Lassen Sie uns einfach einmal ein Datenmodell für die Trennung der beiden Bereiche z. B. in Access durchspielen.
Dabei lassen wir erst einmal (fast) alle Hilfstabellen (Nachschlagtabellen) weg. Eigentlich sollten wir noch Alias-Namen vergeben: Person_1 => Mutter, Person_2 => Vater, wobei im Diagramm Person_1 auch noch der Beziehungspartner ist.
Für die biologische Vererbung erhält jede Person einen reflexiven Verweis (Fremdschlüssel, Zeiger, ...) auf sich selbst in Form von Mutter p_p_aNrM und Vater p_p_aNrV, die auf den Primärschlüssel p_aNr einer anderen Person zeigt. Ist das Feld leer, dann kennen wir die Person leider nicht. Bei unseren Spitzenahnen sind beide Felder leer.
Für alle anderen Beziehungen benötigen wir einen mc:mc-Beziehungstyp, der zwei Personen miteinander verknüpft. Natürlich will man wissen, welche Beziehungsrollen die Personen dabei spielen und fügt noch eine Nachschlagtabelle für die Rollen ein. Interessant dabei ist, dass ein mc:mc-Beziehungstyp symmetrisch ist, d. h., wir können die Beziehung jeweils aus einer der Sicht einer beiden Personen betrachten. Tatsächlich wird dabei die Namensfindung für die inverse Rolle im Deutschen hin und wieder problematisch
Nun sollte keine Diskussion über einzelne Zeilen angefacht werden, wie "biologische Beziehungstypen entstehen doch durch die biologische Vererbung", da wir diese Liste auch in anderen Zusammenhängen benutzen können bzw. immer wieder dynamisch ergänzen können.
Ob wir "Eizellenempfängerin" und "Einzellenspenderin" in Zukunft als einfache Beziehung oder als biologische Beziehung (fest in die Person) einordnen, ist sicher noch eine Diskussion wert. Auch bin ich offen für Vorschläge für eine Zeile "Siegelung" (Wie heißen die Personen?) und weitere Beziehungsrollen.
Fazit: Erneut wollte ich zeigen, dass mit einem geänderten Datenmodell (weg vom GEDCOM-Modell) eine saubere Trennung von biologischer und gesetzlicher Vererbung möglich ist. Auf jeden Fall verhindert dieses Modell eine Dopplung von biologischen Eltern. Bei bestimmten Beziehungsrollen müssen wir Restriktionen wie "unterschiedliche Adoptionen liegen immer zeitlich hintereinander" ergänzen und programmieren.
Es gibt viel zu tun, packen wir es an. Euer (Hans-Jürgen Scheibl)
