GEDCOM/Spezifikation555

Name und Bedeutung

Spezifikation 5.5.5

In diesem Artikel wird untersucht, was die Spezifikation 5.5.5 (veröffentlicht am 02.10.2019 von Tamura Jones) für die Programme bedeutet, die den Vereinbarungen der Gedcom-L Gruppe zum GEDCOM Standard 5.5.1 folgen.

Formelle Bezeichnung

GEDCOM 5.5.5 Specification with Annotations

Deutsche Bezeichnung

GEDCOM 5.5.5 Spezifikation mit Anmerkungen

Veröffentlichung

Die Spezifikation 5.5.5 wurde am 02.10.2019 auf gedcom.org veröffentlicht.

Legitimation

Es ist nicht erkennbar, wer den Auftrag für diese Spezifikation gegeben hat. Als Editor wird Tamura Jones genannt. Die genannten 10 Personen, die angeblich mitgearbeitet haben, durften nur zu Entwürfen eine Stellungnahme einreichen, hatten aber keinerlei Einfluss auf die Berücksichtigung der Stellungnahmen und auf den Inhalt der Spezifikation. Es ist unklar, wer außer dem Editor Tamura Jones überhaupt an Entscheidungen beteiligt war.

Es wird ausdrücklich festgestellt, dass alle wesentlichen Stellungnahmen, die seitens der Gedcom-L Gruppe eingereicht wurden, keine Berücksichtigung fanden.

Am 15.11.2019 hat Family Search den bereits 1999 als Entwurf veröffentlichten GEDCOM Standard 5.5.1 als offiziellen Standard zum Einsatz in Programmen freigegeben. Family Search weist dabei darauf hin, dass sie der Copyright Inhaber am GEDCOM-Standard sind. Family Search selber hatte zwar bereits kurz nach der Veröffentlichung des GEDCOM 5.5.1 Entwurfs diesen selbst in seinem Genealogieprogramm PAF genutzt. Dem sind die meisten Programme gefolgt, wodurch 5.5.1 in der Praxis bereits der "de-facto-Standard" war. Dass jetzt - etwa 6 Wochen nach der Veröffentlichung von "5.5.5" durch Tamura Jones - Family Search den seit 20 Jahren benutzten Entwurf 5.5.1 offiziell zum Standard erhebt, ist ein deutliches Indiz, dass sie mit der Vorgehensweise von Tamura Jones nicht einverstanden sind.

Verwendung

Bislang sind keine Programme bekannt, die diese Spezifikation einsetzen wollen.

Vereinbarungen zum Umgang mit der Spezifikation 5.5.5

Vorbemerkung

Die Gedcom-L Gruppe ist der Zusammenschluss von ursprünglich 23, heute 25 Programmautoren, die seit 2009 gemeinsam an der Optimierung des Datenaustausches zwischen Genealogieprogrammen auf der Basis des GEDCOM Standards 5.5.1 arbeiten. Vereinbarungen werden durch Abstimmungen getroffen, bei denen eine 75% Mehrheit erreicht werden muss. Diese Gruppe bereitet derzeit eine abgestimmte Stellungnahme zur Spezifikation 5.5.5 vor.

Die Gedcom-L Gruppe hat sich mit der Frage beschäftigt, wie mit der am 02.10.2019 veröffentlichten Gedcom Spezifikation 5.5.5 umgegangen werden soll. Dazu wurden die folgenden Vereinbarungen getroffen:

S1 Standardexport bleibt bei GEDCOM Standard 5.5.1

Der Standardexport wird nicht auf die Spezifikation 5.5.5 umgestellt. Grund: Von den Anwendern genutzte und von den Programmen unterstützte Datenfelder, zu denen in der Gedcom-L Vereinbarungen über den Export getroffen wurden, können nicht in eine GEDCOM-Datei gemäß 5.5.5 exportiert werden. Basis des Standardexports bleibt somit der GEDCOM Standard 5.5.1 zusammen mit den in der Gedcom-L Gruppe getroffenen Vereinbarungen.

S2 Import von Dateien nach Spezifikation 5.5.5

Werden beim Import Dateien gemäß Spezifikation 5.5.5 vorgefunden, so werden diese gemäß GEDCOM Standard 5.5.1 importiert. Dabei kann auch auf Ergänzungen zu GEDCOM 5.5.1 zurückgegriffen werden, die in der Gedcom-L Gruppe vereinbart wurden.

S3 Anforderungen an GEDCOM Standards nach 5.5.1

Ein Nachfolge-Standard, der GEDCOM 5.5.1 ablösen soll, muss die in GEDCOM 5.5.1 möglichen Datenstrukturen ebenfalls zulassen. Weiter sollte er die mit Hilfe von Nutzerdefinierten Kennzeichen in der Gedcom-L Gruppe definierten Strukturen vorzugsweise in direkt definierte Strukturen des neuen Standards überführen, anderenfalls aber auf jeden Fall die bisherigen Strukturen mit den Nutzerdefinierten Kennzeichen weiterhin zulassen. Insbesondere sollen die mit _LOC, _RUFNAME, _NAME, _POST, _ASSO, _GODP, _WITN, _GOV gebildeten Strukturen als Erweiterungen mit diesen Kennzeichen (ohne vorangestellten Unterstrich) realisiert werden.

Behandlung/Darstellung von Problemen in der Spezifikation 5.5.5

Vorbemerkung

In der Spezifikation 5.5.5 wird als Ziel angegeben, Widersprüche des GEDCOM 5.5.1 Standards aufzulösen und die GEDCOM Strukturen zu vereinfachen, um eine einfachere Umsetzung in Programmen zu erreichen. Zu diesem Zweck werden auch eine ganze Reihe von im GEDCOM Standard zulässigen Kennzeichen in der Spezifikation 5.5.5 entfernt. Erweiterungen gegenüber dem GEDCOM Standard 5.5.1 sind nicht vorgesehen und sollen späteren Spezifikationen vorbehalten bleiben.

Bei dieser Zielstellung ist kritisch zu prüfen, ob die mit bereits vereinbarten Erweiterungen eingeführten Datenstrukturen auch unter einer Spezifikation 5.5.5 zwischen den Programmen ausgetauscht werden können. Insbesondere stellt die Gedcom-L Gruppe die Anforderung, dass die in ihren Vereinbarungen eingeführten Datenstrukturen auch von einem möglichen Nachfolge-Standard unterstützt werden.

Vor diesem Hintergrund werden in den folgenden Abschnitten diejenigen Teile der Spezifikation 5.5.5 diskutiert, die den erreichten gemeinsamen Stand des Datenaustausches der Gedcom-L Gruppe gefährden oder gar ausschließen würden. Als vorläufiges Fazit ergibt sich, dass die Einführung der Spezifikation 5.5.5 in Programmen den Datenaustausch verkomplizieren würde und neue Probleme beim Datenaustausch auftreten. Die Spezifikation 5.5.5 ist nicht geeignet, den bereits erreichten Umfang an austauschbaren Datenstrukturen zu unterstützen. Die Programmhersteller in der Gedcom-L Gruppe rechnen daher bei einem Einsatz der Spezifikation 5.5.5 mit erhöhter Arbeit wegen der dann zu erwartenden zahlreichen Anwenderbeschwerden und –rückfragen.

Nutzerdefinierte Kennzeichen

Die Spezifikation 5.5.5 verbietet ohne erkennbaren Grund, Nutzerdefinierte Kennzeichen einzuführen, die sich von explizit definierten Kennzeichen nur um den vorgestellten Unterstrich unterscheiden (S. 54): <zitat>It is illegal to define a user-defined tags that equals a predefined tag with an underscore in front.</zitat> Die Gedcom-L hat dagegen als Grundprinzip umgesetzt, dass sich solche nur durch den Unterstrich unterscheidende Nutzerdefinierte Kennzeichen bewusst benutzt werden, um sie an Stellen einzusetzen, wo sie explizit nicht erlaubt wären (notwendige Funktionserweiterung gegenüber GEDCOM 5.5.1). Beispiel ist _ASSO unter Ereignissen in INDI und FAM. Damit werden Datenstrukturen zum Austausch von in Programmen vorhandenen Daten in GEDCOM 5.5.5 untersagt, ohne dass die Spezifikation 5.5.5 eine andere Alternative anbietet.

Kennzeichen _ASSO

In der Spezifikation 5.5.5 wird die Gedcom-L damit zitiert, sie habe eine fehlerhafte Zuordnung von Zeugen über das Kennzeichen _ASSO eingeführt, weil Trauzeugen einer Heirat und nicht dem Familiendatensatz zugeordnet werden müssten. Diese Aussage ist falsch, da die Gedcom-L _ASSO auch unter allen Ereignissen (für INDI und FAM) eingeführt hat. Die Gedcom-L Vereinbarungen bieten also eine Lösung für die Referenzierung von Personendatensätzen als Zeugen zu Ereignissen, die auch genutzt wird. Die Spezifikation 5.5.5 untersagt die Gedcom-L Lösung wegen der Vorschriften zu Nutzerdefinierten Kennzeichen, bietet aber keine Lösung. Der in der Erläuterung der Spezifikation 5.5.5 dazu gegebene Hinweis auf _WITN hilft nicht, da _WITN laut Vereinbarung Freitexte transportiert, _ASSO aber Zeiger auf INDI Datensätze.

Kennzeichen SUBM

Die Spezifikation 5.5.5 untersagt jeden Querverweis auf SUBM (Submitter, Einreicher) Datensätze (außer einem nicht mehr empfohlenen im HEAD). Nach der Spezifikation 5.5.5 darf die GEDCOM Datei nur noch einen SUBM Datensatz enthalten, der implizit als Einreicher der Datei definiert wird. Die Möglichkeit des GEDCOM Standards 5.5.1, in jedem Datensatz beliebig viele Einreicher über INDI.SUBM unter Programmen auszutauschen, wird damit explizit verboten. Diese von der Gedcom-L benutzte und sogar zur Erweiterung auf Kennzeichnung unter Ereignissen und Quellenzitaten diskutierte Übertragung von bisher an der Erstellung der Daten beteiligter Einreicher wird also durch die Spezifikation 5.5.5 verboten. Ein Ersatz wird nicht angeboten, weil angeblich die Funktionalität nicht benötigt würde.

Kennzeichen CONC/CONT im HEADER

S. 51: <zitat>A form header may contain CONC or CONT records, but this is strongly discommended.</zitat> Durch das faktische Verbot von CONC und CONT im HEADER ("discommended") können nach der Spezifikation 5.5.5 keine NOTE mit mehr als 248 Zeichen und keine Zeilenumbrüche in der NOTE und in der Adress-Struktur im HEADER mehr dargestellt werden. Damit wird eine in der Praxis verwendete Struktur ohne Ersatz verboten. Darüber hinaus ist das Verbot ein formaler Widerspruch in der Spezifikation 5.5.5: NOTE in HEAD gehört zu den GEDCOM form, und zu diesen sagt die Spezifikation wörtlich (S. 41): <zitat>The CONC & CONT records are defined as part of the GEDCOM grammar. They are always available for use with any line value of any record in any GEDCOM form.</zitat> Also ist CONC / CONT immer und überall in den GEDCOM form erlaubt! Diese uneingeschränkte Aussage wird dann bei den Vorgaben zum HEADER anders dargestellt.

Kennzeichen RESN

Das Kennzeichen RESN zur Steuerung eingeschränkter Nutzbarkeit der damit gekennzeichneten Datensätze wird laut Spezifikation 5.5.5 ausschließlich von Ancestral File genutzt und sei daher obsolet. Die Aussage ist falsch. Dass das Auftreten von RESN in öffentlich zugänglichen Dateien selten ist, liegt daran, dass darüber vor einer Veröffentlichung gefiltert wird und Datensätze mit RESN dann nicht mehr auftauchen. Sehr wohl aber tauchen sie in internen Arbeitskreisen bzw. innerhalb von Familieninternen Forschungen auf, in denen mehr Daten bearbeitet werden als öffentlich gezeigt werden. Die in der Spezifikation 5.5.5 vorgesehene ersatzlose Streichung führt also zum ersatzlosen Verbot genutzter Datenstrukturen.

Kennzeichen ALIA

Ebenso falsch ist die Aussage der Spezifikation 5.5.5. dass das Kennzeichen ALIA nie wie im GEDCOM Standard 5.5.1 vorgesehen zur Kennzeichnung möglicher Dubletten genutzt werde. Die Spezifikation 5.5.5 schlägt vor, bei Bedarf mögliche Dubletten mittels ASSO und ASSO.RELA possible-duplicate zu exportieren. Dieser Vorschlag ist ungeeignet, da ASSO.RELA ein Freitextfeld ist und eine Auswertung von Klartextfeldern keinen Sinn macht (was an anderer Stelle in der Spezifikation 5.5.5 ausgeführt wird). INDI.ALIA muss also wie im GEDCOM Standard 5.5.1 erhalten bleiben, um Zeiger auf die XREF einer möglicherweise mit der aktuellen Person gleichen Person zu exportieren.

LDS-Kennzeichen

Die LDS-spezifischen Kennzeichen werden auch von Programmen der Gedcom-L genutzt, unabhängig von AncestralFile. Die Spezifikation 5.5.5 verbietet mit der Entfernung dieser Kennzeichen genutzte Datenfelder. Für die als Ersatz empfohlene Lösung mit EVEN und EVEN.TYPE gilt dieselbe Kritik wie für die Ersatz"lösung" für ALIA: Das Klartextfeld EVEN.TYPE kann vom Programm nicht eindeutig interpretiert werden, eine sichere Zuordnung solcher Konstrukte zu den durch die LDS-spezifischen Kennzeichen definierten Datenfeldern ist nicht möglich.

Import ("5.5.5 reader")

Die Spezifikation 5.5.5 versucht auf rigide Weise, Importroutinen als sog. "5.5.5 reader" durchzusetzen, die nur Dateien lesen können, die in jeder Einzelheit mit der Spezifikation 5.5.5 übereinstimmen. Bei jeder Abweichung wird Abbruch des Importes und Ausgabe der den Abbruch begründenden Fehlerbeschreibung vorgeschrieben. Das geht aus Sicht der Gedcom-L Gruppe völlig am Nutzerinteresse vorbei. Sollten Abweichungen und Fehler auftreten, so sind sie zwar als Meldung auszugeben, aber die weitere Entscheidung sollte dem Nutzer überlassen werden, ob er den Import dennoch akzeptiert. Die Autoren der Gedcom-L verfolgen auch bei Abweichungen von einem erklärten Standard das Ziel, dem Nutzer einen möglichst vollständigen Import an die Hand zu geben und ihn über aufgetretene Probleme sauber zu informieren. Der Einsatz eines "5.5.5 readers" widerspricht damit dem grundsätzlichen Vorgehen in der Gedcom-L Gruppe.

_LOC Datensätze der Gedcom-L

Die Gedcom-L hat frühere, als Gedcom 5.5 EL bezeichnete Ansätze zu eigenständigen Ortsdatensätzen auf Ebene 0 (Kennzeichen _LOC) ersetzt durch eine Vorgehensweise, die konform ist zum GEDCOM Standard 5.5.1. In der Spezifikation 5.5.5 wird aber weiter trotz der dort dokumentierten Hinweise auf die Gedcom-L weiterhin der obsolete _LOC Ansatz aus GEDCOM 5.5 EL und nicht die Gedcom-L Version zitiert. Die Webseite der GEDCOM 5.5 EL selber weist diese Version als "deprecated" aus. Die Programmautoren erwarten von einem neuen Standard klare Umsetzungsschritte in Richtung Ortsdatensätze, und nicht fehlerhafte Zitate.

Fehlerhafte Aussagen zu Drittprogrammen

Es fällt zunächst auf, dass so gut wie keine Aussagen zu deutschsprachigen Programmen in die Spezifikation 5.5.5 mit ihren Anmerkungen aufgenommen wurden. Damit wird der in der Gedcom-L zusammengeschlossenen Verbund an Programmen inkl. der von ihnen erzeugten GEDCOM-Dateien weitgehend ignoriert.

Falsch sind die Aussagen in der Spezifikation 5.5.5 zur Erkennung der Kodierung einer GEDCOM-Datei. Angeblich beweist die Nutzung von UTF-8, dass die Datei dem GEDCOM 5.5.1 Standard folge und nicht der älteren Veresion GEDCOM 5.5. Das ist nicht so, es gibt Programme, die die völlig fehlerhaften Vorgaben zur Kodierung der GEDCOM-Dateien (die auch in der Spezifikation 5.5.5 aufgelistet und bemängelt werden) schlicht ignorieren und erklärtermaßen auf Basis GEDCOM 5.5 mit UTF-8 exportieren. UTF-8 ist also in der Praxis kein Hinweis auf GEDCOM 5.5.1, sondern kann einfach eine logische Umsetzung an einer im Standard GEDCOM 5.5 fehlerhaften Stelle sein (Aussage der Entwickler von TNG).

Erweiterungen gegenüber dem GEDCOM Standard 5.5.1

Die Spezifikation 5.5.5 hat grundsätzlich nicht zum Ziel, Erweiterungen zum GEDCOM Standard 5.5.1 einzuführen. Davon gibt es wenige, explizit genannte Ausnahmen.

SEX: Neue Inhalte zugelassen

Die Spezifikation 5.5.5 erlaubt in Erweiterung der Vorgaben für das Kennzeichen SEX (Geschlecht) auch folgende Werte:

X für "Intersex"

N für "nicht angegeben"

Aufgrund der gesellschaftlichen und rechtlichen Entwicklungen ist hier Handlungsbedarf: Auch die Gedcom-L Gruppe hat inzwischen entschieden, das bereits an mehreren Stellen im Einsatz befindliche

X für "Intersex", deutsch: "divers"

als zusätzlich erlaubten Wert unter dem Kennzeichen SEX zuzulassen. Dagegen wurde die von 5.5.5 angebenene weitere Möglichkeit, mit N den Status "nicht angegeben" zu transportieren, von der Gedcom-L verworfen: Der Unterschied zu U ( = "unbekannt" ) ist sehr gering und kaum verständlich, und darüberhinaus erlaubt der GEDCOM 5.5.1 Standard auch, bei nicht angegebenen Geschlecht das Kennzeichen SEX ganz im Personendatensatz entfallen zu lassen. Falls bei einem Import der Wert N zu SEX angeliefert wird, empfiehlt die Gedcom-L Gruppe die Umwandlung in U (unbekannt).

AGE: Altersangabe Jahre

Tamura Jones reklamiert, dass das Alter im GEDCOM Standard 5.5.1 nur eine zweistellige Zahl für die Jahre zulässt, aber für Angaben ab 100 Jahre drei Stellen benötigt werden. Der GEDCOM Standard 5.5.1 beschränkt aber nirgends die Zahl der Stellen der Jahre in der Altersangabe. Die Altersangabe erfolgt als YYy, wobei YY laut Standard definiert ist als "Anzahl der vollen Jahre", eine Beschränkung der Stellen ist nicht aufgeführt. Wenn man wie GEDCOM 5.5.5 aber die zulässige Zahl der Ziffern für YY genau definieren will, muss man natürlich auch dreistellige Angaben zulassen, genauso wie einstellige und zweistellige. Offensichtlich interpretiert Tamura Jones YY als "maximal zweistellige" Zahl und leitet daraus dann ein Problem des Standards ab. In Wirklichkeit ist es ein Problem seiner zu engen Interpretation.

Klärungen zu Widersprüchen im GEDCOM Standard 5.5.1

Viele der in der Spezifikation 5.5.5 festgehaltenen Klärungen zu widersprüchlichen Angaben sind bereits zuvor von der Gedcom-L Gruppe vereinbart worden. Das gilt auch für die in der Spezifikation 5.5.5 aufgeführte Vorgehensweise zu gleichgeschlechtlichen Partnerschaften: Die Verwendung von HUSB und WIFE im Familiendatensatz wird in keiner Weise als Aussage zum Geschlecht des Partners betrachtet, sondern das Geschlecht wird einzig durch INDI.SEX bestimmt.