Halbadoptionen
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)
Kommentare
-
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".
0 -
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:
Avoid invalid words and characters
You cannot save a name with an invalid character in any of the name fields.
- Avoid names with initials only.
- Avoid words that are not names. Examples include not named, unnamed, Mister, Wife, twin, or son.
0 -
@ 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.
0 -
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.
0 -
OK, hier ist der erwähnte Link:
0 -
Are these suggestions for how to improve FamilySearch's Family Tree?
0 -
Yes, to improve FS's Family Tree, that is my main (and only) goal.
But look here:
Let's follow rule #1.
- Avoid names with initials only.
- Avoid words that are not names. Examples include not named, unnamed, Mister, Wife, twin, or son.
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)
0 -
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)
0 -
That rule refers to using only initials such as M L in place of my given name and surname, not to using middle initials.
0 -
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.
1 -
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?
- Es fehlen mir dazu sämtliche Primär-Quellen.
- Ich gehe davon aus, dass es zu den vielen (bisher in meinen Kommentaren aufgelisteten) religiösen Adoption durch die Großeltern keine Artefakte (hier Kirchenbücher aus den Frühzeiten der Aufzeichnungen) gibt, die eine Adoption überhaupt einmal beschreiben. Kennt jemand einen Fall, dass aus einer Patenschaft (levans) eine Adoption wurde?
- Es handelt sich in allen mir bekannten Fällen um uneheliche Geburten von einer der Töchter. Diese Geburten werden nachträglich (auch erst nach mehreren 100 Jahren) von einigen Forschern durch Adoption zu "Familien" hochstilisiert.
- Bisher kenne ich aus den Kirchenbüchern heraus ausschließlich "nachträgliche Legitimierungen" durch Heirat. Selbst die Forderung eines Mannes nach nachträglicher Anerkennung einer "Vaterschaft" ohne Heirat ist mir bisher nicht untergekommen. (Wie war eigentlich damals die Regelung mit den Alimenten?)
- Die biologische Vererbung ist ein "Muss", alle anderen Beziehungsformen in FS sind ein "Kann". Diese Kann-Beziehungsform darf keinen direkten Einfluss auf die biologische Vererbung haben (Verlust einer Generation, "weil der Algorithmus den kürzesten Weg sucht"). Ist der Algorithmus wichtiger als die Realität? Muss nicht der Algorithmus geändert werden? Kann ein Algorithmus als Grund gelten?
- Somit muss der Algorithmus melden, dass er aufgrund der Benutzereinstellungen eine Generation ausgelassen hat.
- So könnte beispielsweise in der Verwandtschaftslinie das Adoptiv-Elternpaar (z. B. farbig) anders dargestellt werden als die biologischen Elternpaare. Zur Not reicht eine Fußnote in einem der betroffenen Diagramme, um die aktuelle Auswahl des Benutzers "bevorzugt" darzustellen. Halt, vielleicht mache ich gerade einen Gedankenfehler, da diese Auswahl ja immer nur für ein konkretes Kind im Verhältnis zu seinen Eltern gilt, oder? Theoretische kann eine Adoption bei langen Linien also mehrfach vorkommen. Damit reicht eine allgemeine Fußnote nicht aus.
- Alle nicht-biologischen Beziehungen müssen parallel zur biologischen Vererbung verwaltet werden.
- usw. usw.
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)
0 -
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.
0 -
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.
0 -
Grüß Gott, Julia,
ich schlage ja nur einige wenige (abgesehen von den "Standardisierten Orten") Verbesserungen vor, die alle Probleme beseitigen könnten:
- Trennung von obligaten Beziehungen (biologische Vererbung) und optionalen Beziehungen (Adoption, Pflegschaft, ...)
- Einführung eines zusätzlichen Beziehungstyps: "Siegelung" für die religiöse Adoption der LDS (auch ich bin kein LDS)
- Beziehungen treten zwischen zwei Individuen (Ehe, Geburtshilfe) auf, die Eltern-Kind-Beziehungstypen sind nur ein Teil davon. Theoretisch können auch Beziehungen entstehen, für deren Existenz mehr als zwei Personen notwendig sind Geburt: Mutter - Kind - Hebamme).
- Bestimmte Beziehungstypen schließen sich gegenseitig aus (Eltern können nicht die eigenen Kinder adoptieren, Eltern können nicht Paten der eigenen Kinder werden).
- Eine Erklärungskomponente für die von mir mehrfach aufgeführten unterschiedlichen Ergebnisse, die aufgrund der Einstellungen "bevorzugt" auftreten, da ich mir nicht merken kann, wann, wo und welche Einstellung ich irgendwann in FS vorgenommen habe. So könnte der Fächerstammbaum nicht nur ein Erstellungsdatum sondern auch ein Hinweis auf diese Einstellungen auf dem Diagramm anzeigen.
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:
- Bei den Eltern von 'Matej Benes" sind zwei verschiedene Großeltern in der Rolle "Siegelung" eingetragen. (Leider zur Zeit nicht. Vielmehr gibt es einfach zwei scheinbar gleichberechtigte Elternpaare mit einer Mutter aber zwei verschiedenen Vätern.)
- Sie haben dort das Elternpaar XY oo XX statt der Möglichkeit VY oo VV als bevorzugt ausgewählt.
- Somit ergebe sich die weiteren Ahnen.
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:
- Ein Kind hat ab seiner Geburt genau eine (möglicherweise uns noch unbekannte) Mutter
- Ein Kind hat ab seiner Geburt genau einen (möglicherweise uns noch unbekannten) Vater
- Ein Kind kann möglicherweise mehrere (...) Adoptionsmütter haben, deren Zeitintervalle sich nicht überschneiden dürfen. Ab wann? Tod der Mutter, Tod beider Elternteile?
- ... usw.
- Ein Kind (=Individuum) kann möglicherweise einen Siegelungsvater haben (je nach den mir unbekannten LDS-Regeln vielleicht auch mehrere)
- Ein Kind kann möglicherweise mehrere Spielkameraden haben (auch zeitlich parallel)
- Ein Kind kann möglicherweise mehrere Hebammen, Kinderärzte, Lehrer ... haben
- ...
- Ein Kind(=Individuum) kann möglicherweise mehrere Ehepartner haben, deren Zeitintervalle sich nicht überschneiden dürfen.
oder (ein wenig Spaß muss sein und wir biegen uns die Regeln zurecht) 😉
- Avoid names with initials only.
- But middle initials are allowed. (new extended rule)
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.
- Wo ist das Existenzintervall?
- Sprachenmischmasch (Cz, D): Plzeň-sever <=> Tschechien;
- Verwaltungsebenen: Böhmen <=> Pilsner Region
Erneut und letztmalig mein Vorschlag:
- der Eingeber sucht den richtigen Ort
- aufgrund des Ereignisdatums wird die Verwaltungshierarchie automatisch berechnet
- die FS-Helfer kümmern sich um die geschichtlich richtige Einordnung
Grüße vom Hans-Jürgen (Scheibl)
0 -
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.)
0 -
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.
0 -
@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:
- Das unbekannte Geburtsdatum einer Person liegt geschätzt 30 Jahre (Generationenabstand) nach den Eltern bzw. 30 Jahre vor dem ersten Kind.
- Das unbekannte Geburtsdatum einer Person wird aus dem Heiratsdatum bzw. Todesdatum abgeleitet. Auch die Geburt eines gleichnamigen zweiten Kindes lässt auf das Sterbedatum schließen.
- Das unbekannte Geburtsdatum eines Ehepartners ist gleich dem Geburtsdatum des anderen Partner.
- Jede Person muss mindestens eine (Primär-)Quelle enthalten. GEDCOM, abgeschrieben aus MyHeritage usw. sind keine Primärquelle.
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)
0 -
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.)
0 -
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)
0 -
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.
0 -
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
- eine biologische Vererbung ist auch immer eine rechtliche Vererbung
- eine rechtliche Vererbung ist nicht immer eine biologische Vererbung
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)
0
