Es geht bei den Online-OFBs nicht darum, mit der UIDs einzelne Personen miteinader zu vergleichen. Das geschieht mit der Funktionalität “Ähnliche Personen” über den Vergleich von Geburts- und Sterbedaten auch mit einer gewissen Unschärfe.
Die UIDs werden benutzt, um einen Perma-Link angeben zu können, der sich nicht durch Umgewichtung von UIDs ändern darf.
Hallo Hermann,
Albert hat recht! Die UID ist in GEDCOM 7.0 für Records und Events zulässig.
”UID is a globally-unique identifier for a record or event”
Ok, der Perma-Link ist also permanent bezüglich der Kombination Person+OFB, nicht bezüglich der Person. Aber was machst Du, wenn zwei Forscher sich entscheiden ihre OFBs zusammen zu werfen und ein gemeinsames neues OFB zu veröffentlichen? Dann müssen sie sich für eine Reihenfolge entscheiden. Du hast dann ggf. temporär drei OFBs.
Alt 1 mit der Reihenfolge 1a, 2b. Alt 2 mit der Reihenfolge 2b, 1a. Und Neu mit der gewählten Reihenfolge, etwa 1a, 2b. Wohin zeigt dann der Perma-Link, der 1a beinhaltet? Auf das OFB Alt1 oder auf das OFB Neu?
Meine Erwartung wäre, dass der Perma-Link mit 1a auf eine Trefferseite geht, die Günter Mustermann auf Alt 1, Alt 2 und Neu auflistet. Und genau das selbe für den Perma-Link, der 2b enthält.
Oha, das habe ich übersehen! Die UID ist im Element IDENTIFIER_STRUCTURE neben anderen Kennzeichen definiert. Dieses Element kommt in den meisten Datensatztypen auf der Ebene 1 vor (0:M). Aber es ist kein Bestandteil des Elements EVENT_DETAIL, aber, und das war mein Fehler, dort ist UID auf der Ebene 2 als einziges Element aus der IDENTIFIER_STRUCTURE explizit einzeln aufgeführt. EVENT_DETAIL ist für einige Ereignisse in einem INDI Datensatz definiert.
Ein Permalink gilt immer nur für eine Person in einem OFB. Für ein zweites OFB ist ohnehin ein weiterer Link erforderlich, weil das OFB selbst auch im Link genannt wird.
Die Verwirrung kommt ein bisschen, weil versucht wird, eine Person mit einer UID zu identifizieren. Dafür ist die UID im GEDCOM Standard nicht eingeführt worden. Deswegen ist auch die Erläuterung irreführend, die zur UID in GEDBAS steht.
GEDCOM bietet die Möglichkeit, Personen mit weltweit eindeutigen Kennungen auszustatten. So lassen sie sich über Stammbäume hinweg finden und verknüpfen. Dies ist zugleich der sicherste Weg für einen dauerhaften Link, der auch möglichst alle Aktualisierungen der Datei übersteht.
In GEDBAS kann eine UID als Perma-Link direkt zu einer Person führen. Wenn man die UID kennt, landet man mit dem Link direkt bei der Person ohne dass man die konkrete GEDBAS-Datenbank kennen muss. Das finde ich sehr hilfreich, auch wenn die Erfinder der UID (die Programmierer von PAF) vor mehreren Jahrzehnten daran noch nicht gedacht hatten. Etwa:
https://gedbas.genealogy.net/uid/b43cd5ad-695c-4e1f-9c9d-25918d292256
Ich fände die gleiche Funktionalität für die OFB sehr hilfreich.
Und im nächsten Schritt will ich nicht einmal mehr wissen, ob die Person in GEDBAS-Datenbanken oder in den OFB vorkommt. Im Sinne von gedbas4all oder im Sinne des Zentrums der Projekte möchte ich, dass ich alles zu einer Person finde. Egal ob sie in GEDBAS oder in OFB oder in DES-Datenbanken, etwa den Verlustlisten auftaucht. Bei letzteren wird eine UID auch verwendet um einen Datensatz eindeutig zu referenzieren, etwa in https://des.genealogy.net/search/uuid/d04acdb7-6488-11ef-b615-0242ac104001
Es wird schon einen Grund haben, warum die UID zusammen mit der REFN und der EXID in einem Sprachelement im Standard aufgeführt wird. Ich finde die UID ist ein sehr mächtiges und zu wenig genutztes Element, das weit über den GEDCOM-Standard hinaus wirkt und Nutzen stiftet.
Für mich sind diese drei Kennzeichen klar hierarchisch aufgebaut:
[Hermann_Hartenthaler]
13. MärzAEmmerich: Also hat der Datensatz in verschiedenen GEDCOM Dateien immer dieselbe UID.Genau! Das ist der Sinn der UID. Wenn ich eine Person in verschiedenen
Weltbäumen und bei Geneanet und bei MyHeritage und… anlege, dann lege
ich eben nicht jedesmal eine neue UID an, so wie Du, Albert, es
vorschlägst, sondern ich nehme immer die selbe UID, damit klar ist, dass
das im Kern immer der selbe Datensatz zur selben Person ist.
Du schreibst „anlege“. Meintest du „importiere“?
Ein Personen-Datensatz hat doch nur die gleiche UID, wenn er aus einer
GEDCOM importiert wird. Wenn diese Person nicht importiert, sondern von
Hand angelegt wird, bekommt der Datensatz vom Programm automatisch eine
eigene UID spendiert (sofern das Programm UID unterstützt und der
Anwender das nicht über Optionen abwählen kann). Und als Anwender kannst
du die UID nicht einfach ändern. Mir fallen spontan keine Programme ein,
bei denen du als Anwender die UID nachträglich ändern oder eine zweite
UID eintragen kannst. (Abgesehen natürlich von hinzugefügten
benutzerdefinierten Kennzeichen, wenn vom Programm unterstützt. Und
webtrees zählt da nicht, weil man da direkt im GEDCOM Code „rumpfuschen“
kann.)
Manchmal kann man importieren, manchmal muss man Datensätze einzeln neu anlegen. Bei FamilySearch und WikiTree würde ich neue Informationen immer von Hand neu anlegen. Beide erzeugen aber keine UID.
Wo gibt es überhaupt eine Unterstützung für das Kennzeichen _UID oder UID?
Also Legacy Family Tree (LFT) und MyHeritage (MH) können es definitiv. Aber beide mit bugs.
Die UID kann ja eigentlich in 3 verschiedenen Formen angegeben werden: 32 hexchar, 36 hexchar oder formatiert.
MH gibt die UID manchmal als 36 HexChar (incl. 4 Prüf Char) und manchmal als 32 HexChar aus. Ich konnte kein System erkennen. Meines Wissens sollte 32 HexChar eigentlich nicht mehr benutzt werden.
LFT kann eigentlich UID und nennt das dann IntelliShare. Allerdings kann LFT keine 32 HexChar, gibt aber keine Fehlermeldung aus, korrigiert nicht sondern setzt einen wilden Wert ein, der aber schon in der Datei existiert. Dadurch entsteht totales Chaos. Eine Datei kann dann schnell 200 unterschiedlich Records mit gleicher UID haben. Und ohne Fehlermeldung!!
Also nicht ohne Kontrolle von MH nach LFT mit GEDCOM übertragen!!!
Möge es helfen
P.S. FTB benutzt die UID auch auf tieferen Leveln und soweit ich gesehen habe, bezieht sich die UID dann z.B. auf eine Heirat auf MH mit UID xyz, also remote.
Hmmm…
In meinem Programm ist die grundlegende Struktur von GEDCOM abweichend.
So gibt es keine FAM-Records. Beim Export erzeuge ich die Familien aus
den vorhandenen Daten. Da kann ich aktuell keine UID für einen
FAM-Record sichern. Ebenso sind bislang keine Möglichkeiten für UID in
2. Ebene vorghanden.
Deiner Aussage nach darf ich dann gar kein GEDCOM 7 exportieren?
Dann kann ich mir die Export- (und Import-) Funktion ja sparen.
Gruß, Stefan Mettenbrink.
Na doch, Du kannst GEDCOM 7 exportieren. UID ist ja kein Pflichtfeld sondern überall optional.
Aber wenn ich Dich richtig verstanden habe, verwirfst Du beim Import etwa FAM:UID und INDI:BIRT:UID, was beides in GEDCOM 7 gültig ist. Aus meiner Sicht darfst Du deshalb nicht behaupten, dass Dein Programm GEDCOM-7 konform sei.
Ich glaube ein Beispiel sollte helfen, GEDCOM von FTB (MH):
1 _DISABLED Y
0 @U1@ SUBM
1 RIN MH:U1
0 @I1@ INDI
1 RIN MH:I1
1 _UID DF92C503387B11D884040003748909329890
1 _UPD 15 NOV 2025 19:12:33 GMT+1
1 SEX M
1 BIRT
2 _UID 6918c291e008d1f0b418482ae34c07bb
2 RIN MH:IF1
2 DATE 3 JUL 1889
1 DEAT
2 _UID 6918c291669ca1f0b418482ae34c07bb
2 RIN MH:IF2
2 DATE 8 APR 1959
2 AGE 69
1 EVEN
2 _UID 6918c291b0c541f0b418482ae34c07bb
2 RIN MH:IF3
2 TYPE Reference Number
1 EVEN
2 _UID 6918c2917b9991f0b418482ae34c07bb
2 RIN MH:IF4
2 TYPE Militärdienst
1 OCCU
2 _UID 6918c291fd0de1f0b418482ae34c07bb
2 RIN MH:IF5
1 FAMS @F2@
1 FAMC @F6@
0 @I2@ INDI
1 RIN MH:I2
1 _UID DF92C504387B11D88404000374890932999D
1 _UPD 15 NOV 2025 19:12:33 GMT+1
aber nicht alles, was die großen Firmen machen, muss gut sein 
Moment.
Erst schreibst Du UID ist optional, wenn ich es aber nicht unterstütze,
bin ich nicht GEDCOM 7 konform?
Andere Felder die in GEDCOM 7 definiert sind unterstütze ich ebenfalls
nicht.
Mit der Voraussetzung wir es kaum ein Programm geben, das GEDCOM 7
konform ist. Welches Programm unterstützt denn alle(!) Möglichkeiten von
GEDCOM 7?
Gruß, Stefan Mettenbrink.
EVENT_DETAIL wird für alle Attribute (Fakten) und Ereignisse in Personen und Familien genutzt. Damit kann jede dieser GEDCOM Strukturen mit einer eigenen UID verfolgt werden. Einzig die LDS_Ereignisse haben diese Unterstruktur nicht.
Der Ansatz wurde in GEDCOM 7.0 übernommen, weil es das bereits als _UID in mehreren Programmen gab. Das kommt den Genealogen entgegen, die vorrangig die einzelnen Ereignisse dokumentieren, und daraus dann in einem zweiten Schritt Personen zusammensetzen. Vorteil: Die Zusammensetzung kann recht flexibel geändert werden, wenn man z.B. dann doch merkt, dass der Sterbeeintrag zu einem anderen Geburtseintrag gehört als bisher.
Allerdings! Es ist ja grausam, wenn die selbe UID auf Ebene 2 für unterschiedliche Ereignisse verwendet wird. So ein Schrott!
Korrektur: die UID sind zwar am Anfang und am Ende identisch, aber in der Mitte unterscheiden sie sich. Passt also, kein Schrott. 
Noch einmal: Die UID wurde im GEDCOM Standard eingeführt, um eine Datenstruktur (z.B. einen Datensatz, oder auf Ebene 1 ein Ereignis, ein Fakt etc) zu identifizieren und verfolgen zu können. Und nicht ein Subjekt (also z.B. eine Person).
Wenn ich manuell eine vorhandene UID aus einem vorhandenen Datensatz in einen neuen Datensatz übertrage, dann breche ich mit der Logik, für die die UID eingeführt wurde. UIDs sind definitiv NICHT eingeführt worden, um weltweit Personen als gleich zu identifizieren.
Wenn ein Anwender in einem Programm einen Datensatz neu anlegt, dann darf bei Befolgung des GEDCOM Standards keine bereits vorhandene UID eingesetzt werden. UIDs sind laut Standard optional, aber wenn sie benutzt werden, muss bei einem Standard-konformen Anlegen eines neuen Datensatzes eine gemäß den Vorschriften zu UIDs zufällig erzeugte UID eingesetzt werden, die mit völlig ausreichender Sicherheit anders als alle anderen vorhandenen UIDs ist.
GEDBAS versucht jetzt diese Konstruktion für einen ursprünglich nicht vorgesehenen Zweck zu benutzen, nämlich für die Verfolgung von Personen. Das funktioniert zum Teil schon, aber auf keinen Fall sind gleiche Personen immer mit gleicher UID ausgestattet. Wenn zwei Forscher unabhängig voneinander dieselbe Primärquelle auswerten, haben sie verschiedene Datensätze und somit auch verschiedene UID. Das hochgeladen, finde ich mit der Suche nach der UID eben nicht alle Datensätze, die identische Personen beschreiben. Sondern nur die, die die Datensätze (oder UID) von anderen übernommen haben.
Ein System zu entwickeln, in dem zwei verschiedene Datensätze gekennzeichnet werden, weil sie dieselbe Person beschreiben, wäre eine ganz andere Aufgabe. Dafür müsste auch ein anderes Konzept verwendet werden als der Missbrauch der UID nach GEDCOM Standard. Und vor allen Dingen sind sich die Forscher ja längst nicht einig, welche Daten wirklich zu einer bestimmten Person gehören. Da werden in den “Weltstammbäumen” Personen und Familien mit abenteuerlichsten Verknüpfungen konstruiert, die einer genauen Überprüfung mittels Originalquellen dann sehr oft nicht standhalten. Wie in einem solchen Wirrwarr einer “tatsächlichen Person” eine eineindeutige ID zugeschrieben werden sollte, und diese ID dann allen Vorkommen dieser Person auch zugeordnet ist, hat wohl noch keiner lösen können.
Es kann sogar passieren, dass trotz identischer UID klar verschiedene Personen in den Datensätzen stecken. Das passiert insbesondere dann, wenn ein vorhandener Datensatz mit rudimentären Daten mehrfach kopiert wird (oder eine UID in einen weiteren Datensatz kopiert wird), und dann mit unterschiedlichen Quellen weiter Daten ergänzt werden. Da der ursprüngliche Datensatz mit geringem Inhalt auf sehr viele verschiedene Personen zutreffen kann, entwickelt sich das schnell auseinander. Dabei ist also eine Übernahme einer UID in einen neuen Datensatz genauso kritisch - auch der könnte mit Daten zu anderen Personen weiterentwickelt werden. Jesper Zedlitz hat diesen Effekt in GEDBAS durchaus bemerkt und berichtet…
Deswegen sollte das “Kopieren” bereits vorhandener UID in neue Datensätze auf jeden Fall unterbleiben.
Und es ist auch der Grund, warum ich Datensätze mit derselben UID nicht ohne ausführliche Prüfung verschmelze. Das hat mich schon vor manchem gravierenden Arbeitsfehler bewahrt!
(korrigierte Aussage!!):
Eine UID zeichnet sich gerade dadurch aus, dass sie eineindeutig ist:
Also unterschiedlich zu allen anderen UID. Und nur einmal zur Identifikation einer Struktur eingesetzt.
Aber im Beispiel von Klaus Bartels sind auch nur unterschiedliche UIDs zitiert - das passt also!
Hier möchte ich Stefan Mettenbrink unterstützen:
Offiziell ist gar nicht definiert, was “ein Programm ist konform mit dem Standard” bedeutet. Daher sollten die Aussagen eher so aussehen:
Stefan Mettenbrink hat völlig recht: Der Standard ist so mächtig, dass wohl kein Programm ihn vollständig umgesetzt hat (z.B. PLAC.FORM fehlt in den allermeisten Programmen). Und wenn ein Programm UID nicht unterstützt, sollte es die beim Import auch verwerfen: Die Alternative, unverstandene Inhalte eines Importes unverändert zu erhalten und dann unverstanden so wieder zu exportieren, könnte zu kuriosen Konstrukten führen. Es ist daher die laut Standard zugelassene Vorgehensweise, nicht unterstützte Teile des Standards beim Import zu ignorieren.
Das ist aus meiner Sicht aber schon ein Armutszeugnis. Wenn ich ein Programm erstelle, das einfach gar nichts unterstützt und beim Import einer GEDCOM-Datei alles ignoriert und beim Export einfach das folgende Minimum ausgibt, dann kann ich behaupten, dass ich GEDCOM 7 beim Import und Export korrekt unterstütze.
0 HEAD
1 GEDC
2 VERS 7.0
0 TRLR