GEDCOM/UID-Tag

Name und Bedeutung

Tag

_UID

Formelle Bezeichnung

unique ID for records

Deutsche Bezeichnung

Universelle Identifikationsnummer für Datensätze

Verwendung

Universelle Identifikationsnummern (UUID) werden verwendet, um Datensätze auch nach Weiterbearbeitung oder Export/Import wieder auffinden zu können. Eine UUID erhebt den Anspruch, dass sie weltweit und für alle Zeiten eindeutig vergeben wird, dass also keine Kollisionen ( = mehrfache Vergabe desselben Wertes ) erfolgen. Dabei erfolgt die Vergabe der UUID dezentral, d.h. durch kein übergeordnetes System koordiniert. Die Erzeugung von UUID ist in Wikipedia als Universally Unique Identifier beschrieben. UUID können nur so lange ihre Funktion erfüllen, wie sie bei Export und Import von GEDCOM-Dateien unverändert bleiben. Aufgrund der Anforderung einer dezentralen Erzeugung und einer Kollisionsfreiheit sind UUID komplex und als direkt vom Anwender verwendetes Erkennungsmerkmal kaum geeignet. Ihre Anwendung ist daher auf die durch Programme durchgeführten Vergleiche, ob zwei Datensätze den identischen Ursprung haben, konzentriert.

Formale Beschreibung zulässiger Werte

Aussagen des GEDCOM-Standards

Der GEDCOM-Standard enthält kein explizites Kennzeichen, welches den Anforderungen an den Umgang mit UUID genügt. Daher hat zuerst PAF ein Nutzerdefiniertes Kennzeichen _UID eingeführt, welches inzwischen von einer ganzen Reihe Programmen übernommen wurde.

Am ehesten entspricht das im GEDCOM-Standard mit Version 5.5 eingeführte Kennzeichen RIN noch den Anforderungen für eine UUID. Jedoch hat RIN eine empfohlene Mindestlänge von nur 12 Zeichen, es soll eine Zahl beinhalten und es darf in Datensätzen nur maximal einmal {0:1} eingesetzt werden. Damit sind wesentliche Anforderungen an eine UUID wie in RFC 4122 (englisch) beschrieben nicht erfüllt.

Vereinbarungen zu UID

Mit einer Abstimmung durch die in der Gedcom-L mitarbeitenden Programmautoren wurden folgende Vereinbarungen zu eindeutigen Kennzeichnungen von Datensätzen getroffen: Hinweis: U5 bezieht sich auf U2, welches wegen zu vieler Gegenstimmen noch einmal in eine Bearbeitungsrunde aufgenommen werden soll.

U0 Eindeutige Kennzeichnung von Datensätzen mit _UID

Für die Wiedererkennung und Rückverfolgung von Datensätzen in GEDCOM-Dateien werden weltweit und zeitlich unbegrenzt eindeutige Kennzeichnungen verwendet. Unter dem Kennzeichen _UID wird als Wert eine Zeichenfolge exportiert, die die Kennzeichnung des Datensatzes beinhaltet.

U1 Einsatz und Struktur für _UID

Das Kennzeichen _UID darf beliebig oft {0:M} in jedem Datensatz verwendet werden, es steht dabei auf der Ebene 1 direkt dem Datensatz zugeordnet. Die ersten 36 Zeichen einer _UID beschreiben die Kennzeichnung. Ggfs. weitere vorhandene Zeichen sind nicht signifikant.

U2 _UID und UUID

Die Erzeugung der Datensatzkennzeichnung erfolgt in der Regel auf Basis von 16 Byte langen Bitfolgen, die nach bestimmten Vorschriften erzeugt werden (UUID). Für den Export in GEDCOM-Dateien müssen diese Bitfolgen in einen Text-Wert (String) überführt werden, wofür wiederum verschiedene Darstellungsformen möglich sind. Um eine möglichst hohe Kompatibilität der Darstellung zu erreichen, wird für neu erzeugte _UID die folgende Form empfohlen: Der Wert der _UID besteht aus 16 Bytes (32 Hexadezimalziffern) und wird mit den Zeichen 0-9 und A-F (Großbuchstaben!) dargestellt. An diese 16 Bytes B1 bis B16 wird eine 2 Bytes lange Prüfsumme in Hexadezimaldarstellung angehängt, die nach folgender Vorschrift berechnet wird:

• Prüfbyte 1: [ SUMME AUS ( Bn ) ] MODULO 256 , (für n=1 bis 16)
• Prüfbyte 2: [ SUMME AUS ( (17-n) * Bn ) ] MODULO 256 (für n=1 bis 16)

U5 Empfehlungen zur Erzeugung und Verwendung der 16 Byte Bitfolgen

• Bei der Erzeugung der 16 Byte Bitfolge (UUID) in U2 wird empfohlen, diese gemäß Version 1 oder vorzugsweise gemäß Version 4 der Standardvorschrift RFC 4122 (englisch) zu bilden. Windows-Systeme können auf CoCreateGuid() zurückgreifen.
• Zumindest für Personendatensätze sollten _UID unterstützt werden. Programme, die Verschmelzungen von Datensätzen unterstützen, sollten mehrere _UID pro Datensatz unterstützen und bei den Verschmelzungen alle _UID erhalten.

U7 Erhalt der _UID bei Import/Export

Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben.

Nicht verabschiedete Entscheidungsempfehlungen für Vereinbarungen zu _UID

In der Abstimmung unter den Programmautoren wurde der Entscheidungsvorschlag U4 klar abgelehnt und muss daher in einer erneuten Bearbeitungsrunde neu gefasst werden. U2 und U3 haben zwar eine einfache Mehrheit erhalten, sollen aber wegen zu vieler Gegenstimmen in einem weiteren Arbeits-Durchlauf optimiert werden und erneut zur Abstimmung gestellt werden. U2 wird nun erneut zur Diskussion / Abstimmung gestellt, U3 ist aufgeteilt in U7 bis U9 und wird hier nur noch zur Dokumentation des Ablaufes gezeigt.

U3 Erhalt der _UID bei Import/Export [aufgeteilt als U7-U9 neu zur Abstimmung]

Sofern ein Programm _UIDs unterstützt, müssen die ersten 36 Zeichen von importierten _UIDs im Export unverändert erhalten bleiben. Werden mehrere _UID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der _UID erhalten bleiben. Wird nur eine _UID je Datensatz unterstützt, so wird die zuerst aufgeführte _UID des Datensatzes importiert und die anderen werden verworfen.

U4 Änderungen an _UID

Für den in U3 vorgeschriebenen Erhalt der Werte der _UID werden folgende Ausnahmen zugelassen:

• Besteht die _UID aus 36 hexadezimalen Zeichen, aber die letzten 4 Zeichen stellen keine der Berechnungsvorschrift U2 entsprechende Prüfsumme dar, so dürfen die ersten 32 Zeichen als signifikant gewertet und die letzten 4 Zeichen dürfen durch eine nach der Empfehlung in U2 neu berechnete Prüfsumme ersetzt werden.
• Programme, die mehrere _UID pro Datensatz verwalten können, dürfen dem Datensatz eine nach der Empfehlung in U2 neu gebildete _UID an letzter Stelle hinzufügen, wenn keine _UID vorliegt oder alle _UID eine von der Empfehlung in U2 abweichende Darstellung haben.

Nicht verabschiedete Entscheidungsempfehlungen für Vereinbarungen zu _UID in der 2. Abstimmrunde (2019)

Die Vereinbarungen U2 und U7 (ausgegliedert aus dem ursprünglichen U3) wurden in der 2. Runde verabschiedet. Keine ausreichende Mehrheit fanden dagegen die folgenden Vorschläge:

U6 _UID auf Ebene 2

Programme, die auch eine GUID zur Identifikation von Elementen auf Ebene 1 als Datenfeld führen, können diese GUID unter dem Tag der Ebene 1 auf Ebene 2 mit

2 _UID <GUID>

exportieren. Die Vereinbarungen für die _UID auf Ebene 1 gelten auch für die Ebene 2.

U8 Reihenfolge bei mehreren _UID

Werden mehrere _UID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der _UID erhalten bleiben.

U9 Vorgehen bei nur einer möglichen _UID im Programm

Wird nur eine _UID je Datensatz unterstützt, so wird die zuerst aufgeführte _UID des Datensatzes importiert und die anderen werden verworfen. Es wird aber empfohlen, beliebig viele _UID je Datensatz zu unterstützen, um die Rückverfolgbarkeit über die _UID zu gewährleisten.

[Hinweis: U7 - U9 wurden aus dem ursprünglich vorgestellten U3 durch Trennung der Aussagen gebildet]

Behandlung/Darstellung schwieriger Situationen

Wie eine UUID gebildet werden kann

Die Aufgabe, ohne zentrale Steuerung in dezentralen Programmeinheiten Identnummern zu erzeugen, die mit außerordentlich hoher Wahrscheinlichkeit weltweit einmalig sind und bleiben, kann entsprechend der in Wikipedia zu UUID beschriebenen Methoden erfolgen, Details sind in der englischsprachigen Beschreibung zu RFC 4122 zu finden. Eine UUID ist eine 128 Bit Zahl. Zwecks Darstellung und Übergabe muss sie in eine Darstellung umgewandelt werden. RFC 4122 beschreibt als Normalform eine hexadezimale Darstellung mit 32 Bytes (mit Kleinbuchstaben a-f neben 0-9), die durch Bindestriche in fünf Gruppen unterteilt wird und z.B. folgendermaßen aussieht:

• 550e8400-e29b-11d4-a716-446655440000

LDS: Regelung für GUID

Von der LDS (Mormonen) wurde eine Empfehlung gezeigt, wie eine GUID (UUID) erzeugt und angewendet werden sollte. Diese Seite ist inzwischen bei BetterGEDCOM noch einsehbar: [1] Die in dem zitierten Dokument angegebenen "Spielregeln" für GEDCOM-UUID lauten frei ins deutsche übersetzt wie folgt:

• 1. Jeder Personen- und Familiendatensatz in der Datenbasis sollte mit einer UID versehen sein.
• 2. Diese UID sollte mit exportiert werden und bei einem Import unverändert bleiben, selbst wenn es sich um Programme unterschiedlicher Hersteller handelt.
• 3. Die UID sollte eine 16-Byte Zahl sein.
• 4. Für Windows-Anwendungen wird die CoCreateGuid() API zur Erzeugung der UID empfohlen. Für andere Plattformen wird gebeten eine Methode zu wählen, die die universelle Eindeutigkeit der UID garantiert.
• 5. Beim Verschmelzen sollen alle UID erhalten bleiben. Daraus folgt, dass ein Datensatz n UID enthalten kann.
• 6. Beim Export sollte die UID mit dem Kennzeichen _UID versehen werden und als textliche Hexadezimal-Zahl dargestellt werden. Die bei PAF mit Version 5.0 eingeführte Checksumme ist nicht vorgeschrieben, aber ihr Einsatz wird empfohlen.

Das Dokument enthält auch eine Routine, wie eine erhaltene _UID auf Konformität mit der LDS-Version geprüft werden kann. Das ist eine sehr restriktive Variante, nach der jede andere Darstellung einer UUID beim Import verworfen wird: Verwendung von Kleinbuchstaben a-f führt ebenso wie fehlende oder nicht genau nach der von LDS vorgeschlagenen Berechnung ermittelten Prüfbytes führen dazu, dass die übermittelte _UID verworfen wird und durch eine neue ersetzt wird. Die zu Zwecken der Rückverfolgung übermittelte _UID ist damit hinfällig.

LDS hat diese Version in PAF umgesetzt, allerdings akzeptiert PAF _UIDs ohne Prüfbytes. Diese werden dann von PAF hinzugefügt, der Export enthält also auf jeden Fall die Prüfbytes.

Weil es dazu eine Rückfrage gab: Die in U2 vorgeschlagene Berechnungsmethode führt zu denselben Prüfbytes wie die LDS-Version, die bei BetterGEDCOM hinterlegt ist. Beides sind nur unterschiedliche Darstellungen der gleichen Berechnungsmethode für die Prüfbytes.

Umgang in PAF mit den UUID

PAF hat einige Besonderheiten beim Umgang mit den UUID:

• PAF bildet die UUID mit einer von RFC 4122 (englisch) abweichenden Routine und stellt sie ohne Bindestriche und mit Großbuchstaben dar. PAF akzeptiert auch UUID, die abweichend von den Vorgaben der RFC 4122 erstellt wurden.
• PAF exportiert seit Version 5.0 zusätzlich eine Prüfsumme mit 4 hexadezimalen Zeichen, so dass die UUID bei PAF auf 36 Zeichen (18 Byte) kommt. Das Berechnungsverfahren der Prüfsumme ist in GEDCOM Global Unique Identifier als Programm zu finden. Diese Berechnung wurde in programmunabhängiger Form in U2 übernommen und wird auch von anderen Programmen wie z.B. Legacy genutzt.
• PAF ergänzt die Prüfsumme, wenn eine UUID mit 32 hexadezimalen Zeichen angeboten wird.
• PAF verwirft die UUID, wenn die Prüfsumme nicht korrekt ist oder in der Hexadezimaldarstellung kleine Buchstaben verwendet werden. In diesen Fällen erzeugt PAF eine neue UUID.
• PAF unterstützt nur eine UUID je Datensatz (abweichend von den Empfehlungen in GEDCOM Global Unique Identifier). Enthält ein zu importierender Datensatz mehrere UUID, so wird nur die zuletzt aufgeführte UUID importiert.

In der GEDCOM-Liste wurde diskutiert, welche dieser Besonderheiten aus Kompatibilitätsgründen übernommen werden sollten.

Bisherige _UID in den an der Gedcom-L beteiligten Programmen

Da lange Zeit zwar PAF bereits die _UID eingeführt hatte, aber keine entsprechende Standardisierung vorlag, haben diverse Programme in Anlehnung an PAF ihrerseits Universelle Identnummern eingeführt und ebenfalls mit _UID exportiert. Die Vorgehensweise ist dabei nicht einheitlich, die _UID unterscheiden sich insbesondere in der Art der Darstellung. Zum Teil sind sie auch nicht auf 16 Byte Zahlen, sondern frei aufgebaut, auch andere Zeichen als Hexadezimalzeichen und Bindestriche tauchen auf. Je nach Programm wird die Information als 16 Byte Zahl oder als String (dann unter Berücksichtigung der Darstellungsform) aufgenommen und verarbeitet.

Der Berechnungsmodus für die Prüfsummen war nicht bekannt, so dass zum Teil abweichende Verfahren oder ein Auffüllen mit festen Zeichen statt der Prüfbytes erfolgt. Diese Versionen sind zwar eindeutig im Sinne einer UUID, aber nicht kompatibel mit PAF und Legacy. Andere Programme verzichten auf die Prüfsumme und exportieren die Normalform der UUID. Auch das ist nicht kompatibel zu PAF und untereinander.

Eine von den anderen hier beteiligten Programmen abweichende Vorgehensweise hat Ages! eingeführt. Ages! versucht eine empfangene _UID wieder auf eine UUID zurückzuführen und führt intern auf Basis der UUID die Vergleiche zwischen Datensätzen aus. Im Export wandelt Ages! dann die UUID in die Darstellung, wie sie LDS definiert hat um. Damit ändert Ages! in den Fällen den Zeilenwert zu _UID, in denen die UUID nicht nach der LDS-Darstellung, sondern z.B. nach der RFC 4122 dargestellt mit _UID übermittelt wurde. Da die anderen Programme aber den Zeilen_Wert von _UID zum Vergleich heranziehen, ist für diese Programme der Wert der _UID nach Durchlauf durch Ages! verloren. Das ist u.a. der Grund, warum mit U3 (neu: U7) zur Abstimmung gestellt wird, eine importierte _UID unverändert wieder zu exportieren.

Darstellungen von UUID mittels bijektiver Funktionen

Eine bijektive Funktion ist eine Funktion, die aus einem Wert x einen neuen Wert y = F(x) macht und für die es eine Umkehrfunktion F' gibt, die aus dem so erzeugten y genau wieder den Ausgangswert x = F'(y) macht. Nach RFC 4122 (englisch) hergestellte UUID ( 16 Byte- Bitfolgen ) können mittels bijektiver Funktionen in vielfältige Darstellungen überführt werden. Beispiele dafür sind:

• x => y = FN(x), Normaldarstellung der RFC 4122 (englisch) Bitfolge mit Hexadezimaldarstellung in Kleinbuchstaben und an definierten Stellen Bindestriche
• x => y = G32(x), Hexadezimaldarstellung der RFC 4122 (englisch) Bitfolge mit Großbuchstaben
• x => y = G36(x), Hexadezimaldarstellung der RFC 4122 (englisch) Bitfolge mit 2 Prüfbytes und Berechnung nach LDS-Vorschrift, Darstellung mit Großbuchstaben (umgesetzt in PAF).

Die UUID und ihre Darstellung sind aber genau nur dann gegenseitig rückführbar, wenn die verwendete bijektive Funktion bekannt ist. GEDCOM-Dateien sind Textdateien, daher wird die Information in _UID als eine Darstellung transportiert, und nicht die ursprüngliche Bitfolge. Die bijektive Funktion, mit der aus der Bitfolge die Darstellung erzeugt wurde, wird in der GEDCOM-Datei nicht transportiert. Daher ist grundsätzlich aus der _UID in einer GEDCOM-Datei nicht mehr erkennbar, welche UUID ihrer Bildung einmal zugrundelag. Um dennoch auf eine 16-Byte lange Bitfolge zurückzuführen, müßte man eine Annahme über die verwendete bijektive Funktion treffen und mit deren Umkehrfunktion diesen Schritt durchführen. Solche Rückführungen von in GEDCOM-Dateien in _UID transportierten Kennzeichnungen auf Bitfolgen sind daher vom jeweiligen Programm anhängig und stellen keine programmunabhängige Information dar.

Diskussionen zur Umstellung in der Vorgehensweise zu _UID

Die bisherigen Vorgehensweisen sind unter den Programmen nicht kompatibel, so dass es beim GEDCOM-Transfer immer wieder zum Verwerfen und Neuerzeugen von _UID kommt. Mit jeder Neuerzeugung geht die bisherige Information, die die eindeutige Identifizierung eines Datensatzes ermöglicht, verloren. Die Vorgehensweise von PAF, die jede nicht genau nach der Empfehlung der LDS erstellte _UID komplett verwirft, wird inzwischen von keinem Programmautor in der Gedcom-L mehr befürwortet.

Es gibt derzeit zwei Gruppen bei der Diskussion um die weitere Vorgehensweise mit _UID:

• Konsequente Umstellung auf die Erzeugung der UUID gemäß RFC 4122 (englisch) (Version 4) und der Berechnung der Prüfbytes gemäß der GEDCOM-Ergänzung. Darstellung als 16 Byte Wert plus 2 Prüfbytes (Hexadezimaldarstellung mit Großbuchstaben [A-F0-9], LDS-Darstellung). Beim Import abweichende Darstellungen sollen auf die UUID zurückgeführt werden und beim Export in der LDS-Darstellung exportiert werden. Vertreten durch Ages!
• Erzeugung und Exportdarstellung der _UID bleiben Hoheit der Programme, es wird nur festgelegt, dass die _UID unverändert importiert und exportiert werden sollen. Dies ermöglicht die Beibehaltung der bisherigen _UID ( "Altbestand" ). Die Interpretation erfolgt genau so wie in der GEDCOM-Datei dargestellt, d.h. der Wert in _UID wird als String inkl. aller Zeichen behandelt.

Bei der Neuerzeugung von _UID wird empfohlen, eine UUID nach RFC 4122 (englisch) zu erzeugen, diese um 4 Prüfbytes nach LDS-Vorschlag zu erweitern und in der LDS-Darstellung (also ohne Bindestriche, Großbuchstaben A-F neben 0-9) in _UID einzustellen. Mit dieser Empfehlung erzeugte _UID werden nach derzeitigem Wissensstand von allen Programmen akzeptiert.

Keine in der Diskussion gemeinsam getragene Lösung gibt es für die Frage des Umganges mit dem "Altbestand" bzw. von der LDS-Darstellung abweichenden Inhalten der _UID. Der Vorschlag, das Ersetzen fehlerhafter Prüfbytes durch neu berechnete zu erlauben, ist inzwischen abgelehnt worden (U4). Per Abstimmung muss nun entschieden werden, ob der Inhalt der _UID gar nicht verändert werden darf (U7) und die Neuerzeugung eine Empfehlung zur Verwendung der LDS-Darstellung ist (U2). Als Alternative könnte man die LDS-Darstellung bei Neuerzeugung verbindlich machen, und bei Import anderer Darstellungen versuchen, die UUID zu identifizieren und in die LDS-Darstellung umzuwandeln. Zur Abstimmung steht zunächst die von mehr Programmautoren befürwortete, in U2 und U7 beschriebene Vorgehensweise.

_UID auf Ebene 2

Es sind bislang 2 Programme bekannt (mit GEN_DO! davon eines aus dieser Liste), die auch Elemente innerhalb der Datensätze kennzeichnen. Auch diese Kennzeichnung wird mit UUID durchgeführt, wobei unter dem Element auf Ebene 1 die UUID mit einer _UID auf Ebene 2 dargestellt wird. Beispiel:

1 BIRT 
2 DATE 1 AUG 1827
2 _UID 161C15D03ECE47968211BBB2E9EE7F4FA5A6

Vorgeschlagen ist mit U6, für solche _UID auf Ebene 2 dieselben Regeln gelten lassen, wie sie für die Ebene 1 vereinbart werden.

Abweichungen vom Standard bei der Verwendung

_UID ist ein Nutzerdefiniertes Kennzeichen, seine Bedeutung wird über keine im GEDCOM 5.5.1 Standard festgelegte Struktur unterstützt. Somit kann es zu _UID auch keine Abweichungen vom Standard geben.