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.

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.

Neuer Entscheidungsvorschlag

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.

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 _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)

U3 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. 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.

Behandlung/Darstellung schwieriger Situationen

LDS: Regelung für GUID

Von der LDS (Mormonen) wird auf der Seite der GEDCOM Spezifikationen auch eine Empfehlung gezeigt, wie eine GUID (UUID) erzeugt und angewendet werden sollte. 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.

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. Ein UUID besteht aus einer 16-Byte-Zahl, die hexadezimal notiert und in fünf Gruppen unterteilt wird. In ihrer Normalform sieht eine UUID beispielsweise so aus:

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

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 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.

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 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 Bitfolge mit Hexadezimaldarstellung in Kleinbuchstaben und an definierten Stellen Bindestriche
• x => y = G32(x), Hexadezimaldarstellung der RFC 4122 Bitfolge mit Großbuchstaben
• x => y = G36(x), Hexadezimaldarstellung der RFC 4122 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. Es gibt derzeit zwei Gruppen bei der Diskussion um die weitere Vorgehensweise mit _UID:

• Konsequente Umstellung auf die Empfehlungen aus der GEDCOM-Erweiterung zu GUID inkl. der Erzeugung der UUID gemäß RFC 4122 (Version 4) und der Berechnung der Prüfbytes gemäß der GEDCOM-Ergänzung. Interpretation als 16 Byte Wert plus 2 Prüfbytes, Export in der Darstellung wie PAF. Diese Gruppe geht so weit, dass bislang abweichende erzeugte oder dargestellte _UID verworfen werden sollen, also die bislang vorhandene Information komplett neu aufgebaut werden soll.
• 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.

Es wird versucht, zwischen diesen Positionen einen gemeinsamen Weg zu finden. Insbesondere wird erwogen, die Erzeugung neuer UUID nach RFC 4122 und ihre Darstellung in GEDCOM inkl. Prüfbytes wie in der GEDCOM-Ergänzungsdokumentation (kompatibel zu PAF) zu empfehlen. Keine in der Diskussion gemeinsam getragene Lösung gibt es für die Frage des Umganges mit dem "Altbestand", in den zunächst entwickelten Entscheidungsvorschlägen wurde in U4 ein weitgehendes Erhalten der bisherigen _UIDs, aber auch die wahlweise Neuerzeugung bei größeren Abweichungen von den neuen Standards vorgeschlagen. "Invalide" Prüfsummen sollen durch die gemäß der GEDCOM-Ergänzung vorgegebenen Prüfsummen ersetzt werden dürfen. Dieser Vorschlag hat in der Phase vor der Abstimmung zu weiterhin sehr kontroversen Diskussionen geführt.

Abweichungen vom Standard bei der Verwendung

- derzeit nicht besetzt -