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 RFC4122 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 RFC4122 beschrieben nicht erfüllt.

Entscheidungsempfehlungen für Vereinbarungen zu _UID

U1 Kennzeichen für UUID

Für den GEDCOM-Export von UUID wird das Kennzeichen _UID verwendet. Dieses Kennzeichen darf beliebig oft {0:M} in jedem Datensatz verwendet werden, es steht dabei auf der Ebene 1 direkt dem Datensatz zugeordnet.

U2 Format der UUID

Die UUID 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 darf eine 2 Bytes lange Prüfsumme in Hexadezimaldarstellung angehängt werden, 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 UUID bei Import/Export

Sofern ein Programm UUIDs unterstützt, müssen importierte UUIDs im Export erhalten bleiben. Werden mehrere UUID pro Datensatz unterstützt, muss auch die importierte Reihenfolge der UUID erhalten bleiben. Wird nur eine UUID je Datensatz unterstützt, so wird die zuerst aufgeführte UUID des Datensatzes importiert und die anderen werden verworfen.

U4 Umgang mit UUID, die nicht U2 entsprechen

Werden beim Import UUID vorgefunden, die nicht den Vorgaben von U2 entsprechen, so wird folgende Vorgehensweise empfohlen:

• Ist die Länge der UUID weder 32 noch 36 Zeichen, oder treten andere Zeichen als 0-9, A-F, a-f oder der Bindestrich auf, so darf die UUID verworfen werden (Abweichung von U3), sie darf durch eine neu erzeugte UUID ersetzt werden. Es wird empfohlen, dass Programme, die mehr als eine UUID pro Datensatz unterstützen, den bisherigen Inhalt unter _UID vollständig erhalten und zusätzlich eine neue _UID erzeugen, die sie als erste _UID des Datensatzes exportieren.
• Ist die Länge der UUID entweder 32 oder 36 Zeichen, und sind alle Zeichen aus dem Umfang 0-9, A-F, a-f oder Bindestrich, so wird die UUID unverändert übernommen und wieder exportiert. Es bleibt dem Programm freigestellt, intern bei der Verarbeitung der UUID Bindestriche zu entfernen oder Kleinbuchstaben in Großbuchstaben zu verwandeln. Dies darf aber die exportierte UUID nicht verändern.
• Besteht die UUID aus 36 hexadezimalen Zeichen, aber die letzten 4 Zeichen stellen keine der Berechnungsvorschrift U2 entsprechende Prüfsumme dar, so werden die ersten 32 Zeichen als signifikant gewertet und die letzten 4 Zeichen dürfen durch eine nach U2 neu berechnete Prüfsumme ersetzt oder gelöscht werden.

U5 Empfehlungen zur Erzeugung und Verwendung der UUID

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

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 RCF 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 RFC4122 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 RCF 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 RCF 4122 Bitfolge mit Hexadezimaldarstellung in Kleinbuchstaben und an definierten Stellen Bindestriche x => y = G32(x), Hexadezimaldarstellung der RCF 4122 Bitfolge mit Großbuchstaben x => y = G36(x), Hexadezimaldarstellung der RCF 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.

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äß RCF 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 RCF 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 -