GEDCOM/HEAD-Tag

Name und Bedeutung

Tag

HEAD

Formelle Bezeichnung

HEADER

Deutsche Bezeichnung

Vorspann

Verwendung

Im Vorspann (Dateikopf) werden die für die gesamte Datei geltenden allgemeinen Aussagen und Festlegungen getroffen.

Formale Beschreibung zulässiger Werte

Aussagen des GEDCOM-Standards

Mit HEAD werden die allgemeingültigen Aussagen und Randbedingungen zur ganzen GEDCOM-Datei dargestellt. Im GEDCOM-Standard ist seine Struktur so beschrieben:

HEADER:=
n HEAD {1:1}
+1 SOUR <APPROVED_SYSTEM_ID> {1:1}
+2 VERS <VERSION_NUMBER> {0:1}
+2 NAME <NAME_OF_PRODUCT> {0:1}
+2 CORP <NAME_OF_BUSINESS> {0:1}
+3 <<ADDRESS_STRUCTURE>> {0:1}
+2 DATA <NAME_OF_SOURCE_DATA> {0:1}
+3 DATE <PUBLICATION_DATE> {0:1}
+3 COPR <COPYRIGHT_SOURCE_DATA> {0:1}
+4 [CONT|CONC]<COPYRIGHT_SOURCE_DATA> {0:M}
+1 DEST <RECEIVING_SYSTEM_NAME> * {0:1}
+1 DATE <TRANSMISSION_DATE> {0:1}
+2 TIME <TIME_VALUE> {0:1}
+1 SUBM @<XREF:SUBM>@ {1:1}
+1 SUBN @<XREF:SUBN>@ {0:1}
+1 FILE <FILE_NAME> {0:1}
+1 COPR <COPYRIGHT_GEDCOM_FILE> {0:1}
+1 GEDC {1:1}
+2 VERS <VERSION_NUMBER> {1:1}
+2 FORM <GEDCOM_FORM> {1:1}
+1 CHAR <CHARACTER_SET> {1:1}
+2 VERS <VERSION_NUMBER> {0:1}
+1 LANG <LANGUAGE_OF_TEXT> {0:1}
+1 PLAC {0:1}
+2 FORM <PLACE_HIERARCHY> {1:1}
+1 NOTE <GEDCOM_CONTENT_DESCRIPTION> {0:1}
+2 [CONC|CONT] <GEDCOM_CONTENT_DESCRIPTION> {0:M}

Der Name des Quellsystems (SOUR) identifiziert dabei, welches System die Daten gesendet hat. Der Name des Zielsystems (DEST) identifiziert dabei, an welches System die Datei ursprünglich übermittelt werden sollte. Das lesende Programm findet die GEDCOM-Version (GEDC.VERS) und die Form (GEDC.FORM). Die Angabe des Zeichensatzes (CHAR) ist zwingend.

Der Datensatz zu HEAD wird einmal in die GEDCOM-Datei eingestellt, er steht immer zu Beginn der Datei als erster Datensatz. Vor der Zeile

• 0 HEAD

darf außer ggfs einem BOM (welches die Zeichenkodierung steuern kann) nichts anderes stehen.

Zu beachten ist, dass die Kennzeichen im Datensatz HEAD zum Teil anders definiert sind und andere Unterstrukturen haben als in anderen Datensätzen. SOUR ist hier z.B. nur als eingebettete Version zulässig und hat eine Unterstruktur, die von der bei Aufruf in anderen Datensätzen abweicht. Auch NOTE kann nur eingebettet verwendet werden, und hat nur eine sehr eingeschränkte Unterstruktur.

Bereits an anderer Stelle sind behandelt: CHAR und SUBM. Weitere Vereinbarungen zum HEADer sind getroffen unter: PLAC (Vorgaben zu FORM) und unter Nutzerdefinierte Kennzeichen (Beschreibung mit _SCHEMA).

Vereinbarungen zum HEAD-Datensatz

Für folgende Kennzeichen wurden eigene Vereinbarungen getroffen, die hier nicht nochmals behandelt werden: CHAR (inkl. BOM zu Beginn der Datei), SUBM, PLAC.FORM, _SCHEMA.

Die folgenden Vereinbarungen H1 bis H6 wurden durch Abstimmung unter den in der Gedcom-L mitarbeitenden Programmautoren entschieden:

H1 Angaben zum erzeugenden Programm

Im Header jeder GEDCOM-Datei müssen Angaben zum Programm gemacht werden, mit welchem diese Datei erzeugt wurde. Die Angaben erfolgen unter SOUR sowie den SOUR untergeordneten Kennzeichen. Die im Standard eigentlich vorgesehene GEDCOM-Registrierung der Programme exitiert nicht. Unter HEAD.SOUR wird daher eine vom Programmautor gewählte, von der aktuellen Programmversion unabhängige Kennung für das Programm exportiert. Diese Kennung sollte möglichst eindeutig das Programm identifizieren. Die Kennung darf keine Leerzeichen enthalten. Eine Trennung von Bestandteilen der Kennung kann statt über Leerzeichen durch den Unterstrich _ erfolgen. Es wird empfohlen, eine maximal 20 Zeichen lange Kennung zu wählen. Die weiteren Kennzeichen unter SOUR sind optional und enthalten die Version des Programmes (SOUR.VERS), den vollständigen Namen des Programmes (SOUR.NAME), den Programmhersteller (SOUR.CORP) sowie dessen Adressangaben in der Adress-Struktur.

H2 Angaben zur Quelle und zum Urheberrecht

Unter SOUR.DATA können Informationen zur Quelle ausgegeben werden, die bei der Erzeugung der Datei ausgewertet wurde. SOUR.DATA darf jedoch maximal einmal ausgegeben werden. Dabei können unter SOUR.DATA.COPR auch Angaben zum Urheberrecht / Copyright der Quelle gemacht werden. Unter HEAD.COPR können Angaben zum Urheberrecht bzw. Copyright zu der Datei eingestellt werden, auch dieses Kennzeichen darf nur maximal einmal ausgegeben werden.

H3 Datum

Das Datum, an dem die Datei erstellt wird, kann unter dem Kennzeichen DATE ausgegeben werden. Dabei muss die im Standard vorgeschriebene Form für exakte Datumsangaben ( Tag Monat Jahr im Format DD MMM JJJJ ) eingehalten werden. Diesem kann die Uhrzeit mit dem Kennzeichen DATE.TIME im Format hh:mm:ss.fs ( Stunden 24h-Format : Minuten : optional Sekunden : optional Nachkommastellen der Sekunden ) zugefügt werden.

H4 HEAD.DEST - das Zielsystem

Unter HEAD.DEST können Angaben zum Zielsystem gemacht werden. Empfohlen wird das insbesondere dann, wenn ein Sonderexport für bestimmte Zwecke gemacht wird (abweichend vom Standardexport).

H5 GEDCOM Version

Laut GEDCOM-Standard muss die GEDCOM-Version angegeben werden. Für alle Exporte, die dem Standard 5.5.1 folgen, muss im HEADER folgende Sequenz enthalten sein:

1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED

H6 Bemerkungen zur Datei

Unter HEAD.NOTE können Bemerkungen zur Datei exportiert werden. Außer den Fortsetzungszeilen CONC/CONT sind keine Unterstrukturen zulässig.

H7 Addendum im HEAD

Es wird vereinbart, die Einfügung von Angaben zu einer Erläuterung der verwendeten nutzerdefinierten Kennzeichen sowie zu Interpretationen von unklaren Aussagen des GEDCOM-Standards (als ADDENDUM bezeichnet) im HEAD zuzulassen. Dafür wird das Kennzeichen _ADDENDUM verwendet, und es wird unter HEAD.GEDC.VERS angeordnet:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_NAME> {0:M}
4 WWW <ADDENDUM_LINK> {0:1}
4 VERS <VERSION_NUMBER> {0:1}

<ADDENDUM_NAME> ist wie folgt definiert: <ADDENDUM_NAME> := {1:80} name of a document where the additional interpretations and definitions of user-defined tags can be found. [in Deutsch: Name eines Dokuments, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind.]

<ADDENDUM_LINK> ist wie folgt definiert: <ADDENDUM_LINK> := {8:120} Link (URL) to the webpage where the additional interpretations and definitions of user-defined tags can be found. [in Deutsch: Link (URL) zur Webseite, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind.]

<VERSION_NUMBER> ist im GEDCOM Standard definiert.

Für Programme, die die Vereinbarungen des GEDCOM-L Addendums verwenden, wird für die derzeit gültige Version dieses Addendums folgende Ausgabe empfohlen:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM GEDCOM-L Addendum
4 VERS R1 (2020-01-01)
4 WWW https://genealogy.net/GEDCOM

Entscheidungsvorschläge (2020, 2. Runde)

Aufgrund der Abstimmungsergebnisse aus der ersten Runde wird H7.5 erneut zur Diskussion gestellt.

H7.5 Bedeutung des _ADDENDUM im HEAD

Wird beim Export einer GEDCOM Datei im HEAD per _ADDENDUM auf ein Addendum hingewiesen, so bedeutet das, dass bei der Erstellung der Datei die im zitierten Addendum vereinbarten Regeln eingehalten werden.

Entscheidungsvorschläge (2020)

Für eine Abstimmungsrunde zu HEAD werden folgende Entscheidungsvorschläge diskutiert. Hinweis: Da die Diskussion eine Reihe von Alternativen ergeben hat, sind die Vorschläge hier zunächst mit H7.n durchnummeriert. Sie können einzeln abgestimmt werden. Falls zu einem Vorschlag eine direkte Alternative zur Abstimmung gestellt werden soll, wird das durch angefügte Buchstaben kenntlich gemacht, z.B. ist H7.1a eine Alternative zu H7.1

Nach der Abstimmung werden angenommene Teile dann zu einer gemeinsamen Vereinbarung H7 redaktionell zusammengefasst, damit die Darstellung übersichtlich bleibt.

Als Erläuterung, wie die redaktionelle Bearbeitung nach der Abstimmung aussehen wird, hier das Beispiel für den Fall, dass H7.1, H7.2 und H7.3 angenommen werden:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_NAME> {0:M}
4 WWW <ADDENDUM_LINK> {0:1}
4 VERS <VERSION_NUMBER> {0:1}
4 DATE <DATE_EXACT> {0:1}

Neben H7.1 (bzw. H7.1a) H7.2 und H7.3 können also auch beide angenommen und umgesetzt werden, oder einer dieser Vorschläge, oder bei entsprechendem Abstimmergebis auch keiner von beiden.

Über die Entscheidungsvorschläge ist zum 23.02.2020 per Abstimmung entschieden worden. Für die Nachvollziehbarkeit beiben sie hier stehen. Das Ergebnis: H7.2 und H7.4 wurden angenommen. H7.3 und H7.5 erhielten keine ausreichende Mehrheit. Die Alternativen H7.1a und H7.1b wurden abgelehnt. H7.1 erhielt deutlich mehr Stimmen, jedoch knapp zu wenig, um als verabschiedet zu gelten. H7.1 wird damit auf die Entscheidungen zu den anderen Punkten angepasst und erneut zur Abstimmung gestellt

H7.1 Aufnahme der Angabe ADDENDUM in den HEAD Datensatz

Es wird vereinbart, die Einfügung von Angaben zu einer Erläuterung der verwendeten nutzerdefinierten Kennzeichen sowie zu Interpretationen von unklaren Aussagen des GEDCOM-Standards (als ADDENDUM bezeichnet) im HEAD zuzulassen. Dafür wird das Kennzeichen _ADDENDUM verwendet, und es wird unter HEAD.GEDC.VERS angeordnet:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_NAME> {0:M}
4 WWW <ADDENDUM_LINK> {0:1}

<ADDENDUM_NAME> ist wie folgt definiert: <ADDENDUM_NAME> := {1:80} name of a document where the additional interpretations and definitions of user-defined tags can be found. [in Deutsch: Name eines Dokuments, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind.] <ADDENDUM_LINK> ist wie folgt definiert: <ADDENDUM_LINK> := {8:120} Link (URL) to the webpage where the additional interpretations and definitions of user-defined tags can be found. [in Deutsch: Link (URL) zur Webseite, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind.]

H7.1a Aufnahme der Angabe ADDENDUM in den HEAD Datensatz

[als Alternative zu H7.1]

Es wird vereinbart, die Einfügung von Angaben zu einer Erläuterung der verwendeten nutzerdefinierten Kennzeichen sowie zu Interpretationen von unklaren Aussagen des GEDCOM-Standards (als ADDENDUM bezeichnet) im HEAD zuzulassen. Dafür wird das Kennzeichen _ADDENDUM verwendet, und es wird unter HEAD.GEDC.VERS angeordnet:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_LINK> {0:M}

<ADDENDUM_LINK> ist wie folgt definiert: <ADDENDUM_LINK> := {8:120} Link (URL) to the webpage where the additional interpretations and definitions of user-defined tags can be found. [in Deutsch: Link (URL) zur Webseite, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind.]

H7.1b Änderung der Anzahl zulässiger Vorkommen von _ADDENDUM und _ADDENDUM.WWW

[Als Modifikation zu H7.1]

Im Fall, dass H7.1 angenommen wird, sollen die Vorgaben für die erlaubte Anzahlen von _ADDENDUM und _ADDENDUM.WWW geändert werden auf:

3 _ADDENDUM <ADDENDUM_NAME> {0:1}
4 WWW <ADDENDUM_LINK> {0:M}

Es soll also einerseits verboten werden, mehrere Erweiterungssysteme des GEDCOM 5.5.1 gleichzeitig mit _ADDENDUM zu zitieren, gleichzeitig aber erlaubt werden, dem einen zitierten Addendum weitere Angaben per Link folgen zu lassen.

H7.2 Versionsangabe zum ADDENDUM

Die Version des ADDENDUMs kann durch die Angabe einer Versionsbezeichnung ergänzt werden. Hierfür wird das Kennzeichen VERS unter _ADDENDUM eingesetzt:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_NAME> {0:M}
4 WWW <ADDENDUM_LINK> {0:1}
4 VERS <VERSION_NUMBER> {0:1}

oder bei H7.1a:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_LINK> {0:M}
4 VERS <VERSION_NUMBER> {0:1}

<VERSION_NUMBER> ist im GEDCOM Standard definiert.

H7.3 Datumsangabe zum ADDENDUM

Optional kann der Angabe des ADDENDUM auch eine Datumsangabe unterstellt werden. Diese wird _ADDENDUM mit dem Kennzeichen DATE unterstellt:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_NAME> {0:M}
4 WWW <ADDENDUM_LINK> {0:1}
4 DATE <DATE_EXACT> {0:1}

bzw. bei H7.1a:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_LINK> {0:M}
4 DATE <DATE_EXACT> {0:1}

<DATE_EXACT> ist im Standard definiert.

H7.4 Empfohlene Ausgabe für _ADDENDUM für Programme, die dem GEDCOM-L ADDENDUM folgen

Für Programme, die die Vereinbarungen des GEDCOM-L Addendums verwenden, wird für die derzeit gültige Version dieses Addendums folgende Ausgabe empfohlen:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM GEDCOM-L Addendum
4 VERS R1 (2020-01-01)
4 WWW https://genealogy.net/GEDCOM

Auf eine Ausgabe von 4 DATE kann in diesem Fall verzichtet werden, da die Versionsnummer bereits das eingeklammerte DAtum beinhaltet.

Sollte statt H7.1 die Alternative H7.1a entschieden werden, so wird empfohlen:

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM https://genealogy.net/GEDCOM
4 VERS R1 (2020-01-01)

H7.5 Bedeutung des _ADDENDUM im HEAD

Wird beim Export einer GEDCOM Datei im HEAD per _ADDENDUM auf ein Addendum hingewiesen, so bedeutet das, dass bei der Erstellung der Datei die im zitierten Addendum vereinbarten Regeln eingehalten werden.

Behandlung/Darstellung schwieriger Situationen

Diskussionsstand in der Arbeitsgruppe der Programmautoren

Vom Anwender mit Inhalt versehene Daten im HEAD

Nach der Verabschiedung der Vorgehensweise zum Addendum im HEAD wurde in der Gedcom-L Liste diskutiert, inwiefern bei einem Transfer importierte Dateninhalte aus dem HEAD für weitere Exporte berücksichtigt werden sollen oder nicht. Große Teile des HEAD sind eine formale Beschreibung der Datei, die mit diesem HEAD eingeleitet wird. Sie sind somit spezifisch für die gerade aktuell übermittelte Datei und verlieren nach der erfolgten Übertragug in ein Empfangsprogramm ihre Bedeutung. Diese Teile, wie z.B. HEAD. SOUR mit untergeordneten Zeilen, HEAD.DEST, HEAD.CHAR usw. haben also nach der erfolgreichen Übertragung der Datei keine weitergehende Bedeutung mehr.

Der GEDCOM Standard beschreibt aber für HEAD.NOTE explizit, dass mit diesem Kennzeichen eine Beschreibung des Anwenders über den Inhalt der Datei übertragen wird. Hier handelt es sich also vom Zweck her für eine Information, die vom Absender für den Empfänger bestimmt ist und nicht um eine nur vom Programm automatisch auszuwertende Information, die nach der Transmission ihre Bedeutung verliert:

HEADER:=
n HEAD {1:1}
...
+1 NOTE <GEDCOM_CONTENT_DESCRIPTION> {0:1}
+2 [CONC|CONT] <GEDCOM_CONTENT_DESCRIPTION> {0:M}

mit der Definition GEDCOM_CONTENT_DESCRIPTION:= {Size=1:248} (GEDCOM Inhaltsbeschreibung) Eine Notiz, die ein Benutzer eingibt, um den Inhalt einer Datei zu beschreiben, wie beispielsweise “Vor- und Nachfahren von”, so dass der Empfänger eine Vorstellung davon bekommt, welche Daten enthalten sind.

Es ist wichtig anzumerken, dass es sich hierbei nicht um eine <<NOTE_STRUCTURE>> handelt: Es sind also weder mehrere NOTE im HEAD zugelassen noch in der <<NOTE_STRUCTURE>> untergeordnete Kennzeichen wie SOUR.

In der Liste wurde festgestellt, dass viele Programme die vom Standard explizit gegebene Möglichkeit nicht nutzen, dem Anwender ein mehrzeiliges Datenfeld bereitzustellen, in dem der Anwender eine Beschreibung des Inhaltes der Datei hinterlegen kann. Einige Programme verwenden das Feld anders, indem sie automatisch vom Programm erzeugte Informationen hinterlegen, oft kommt aber das Kennzeichen nicht vor. Es gibt auch Programme, die beim Import dem Empfänger zwar den Inhalt des Datenfeldes anzeigen, es aber nicht speichern und somit auch nicht zur Überarbeitung für weitere Exporte bereitstellen.

Einige Programme bieten jedoch HEAD.NOTE dem Anwender wie vom Standard vorgesehen als frei editierbares Datenfeld an und erhalten die Inhalte bei Import. Hier können die Informationen also vom Anwender entsprechend seiner Weiterverarbeitung angepaßt werden und dann in der überarbeiteten Form wieder exportiert werden.

Die Liste diskutiert sodann, inwieweit die Daten aus HEAD.NOTE erhalten bleiben sollen, wenn das Datenfeld auch im empfangenden Programm unterstützt wird. Dies entspricht der generellen Grundlinie der Gedcom-L, dass der Import Anwenderdaten nicht verändern soll, sondern dies dem Anwender selber vorbehalten bleibt. Eine Einigkeit zeichnet sich bislang dazu nicht ab.

Der Anwender muss also bei den meisten Fällen damit rechnen, dass die über HEAD.NOTE empfangenen Inhalte beim Import verloren gehen.

Es wird darauf hingewiesen, dass auch mit den Kennzeichen HEAD.COPR sowie HEAD.LANG Informationen transportiert werden, die über die Übertragung der Daten hinaus Bedeutung haben können. Insbesondere bei HEAD.COPR werden Informationen übertragen, deren Nichtbeachtung durch den Empfänger rechtliche Konsequenzen nach sich ziehen können:

COPYRIGHT_GEDCOM_FILE:= {Size=1:90} (Vervielfältigungsrecht, GEDCOM Datei) Eine Aussage, die dafür benötigt wird, die Vervielfältigungsrechte des Verfassers der GEDCOM-Datei zu schützen.

Gedcom-L Kennung

In 2019 wurde die Diskussion für HEAD vor allem mit dem Schwerpunkt wieder aufgenommen, wie im HEAD der Bezug auf unsere Vereinbarungen in der Gedcom-L untergebracht werden kann. Verfolgt werden damit zwei Ziele: - Verweis auf unsere Vereinbarungen mit dem Ziel, den Inhalt insbesondere zu den Nutzerdefinierten Erweiterungen allgemein bereitzustellen - Erhöhung des Bekanntheitsgrades der Vereinbarungen, Ausweitung auf weitere Programme und Einbringung der Ergebnisse in die Diskussionen um zukünftige Standards zum Datenaustausch zwischen Genealogieprogrammen. Unterstützt werden sollen diese Ziele durch die Veröffentlichung einer (englischsprachigen) Zusammenfassung unserer Vereinbarungen, insbesondere zum Umgang mit Widersprüchen im Standard 5.5.1 sowie zu der gemeinsamen Einführung Nutzerdefinierter Kennzeichen.

Schwerpunkt der Diskussion um die Kennzeichnung ist die Betrachtung der Kennzeichen GEDC.VERS und DEST im HEAD-Datensatz. Vorschläge dazu sind z.B.

1 GEDC 
2 VERS 5.5.1 Gedcom-L

1 GEDC 
2 VERS 5.5.1
3 _EXTENDED Gedcom-L

1 DEST 5.5.1 extended by Gedcom-L

Betrachtet wird derzeit, ob die vorgeschlagenen Varianten beim Import in Drittprogramme Probleme bereiten könnten. Wenn z.B.

2 VERS 5.5.1 Gedcom-L

dazu führt, dass einige Programme den Import abbrechen, weil sie einen Standard "5.5.1 Gedcom-L" nicht kennen, dann ist das eine nicht gewollte Beeinträchtigung des Datentransfers. Genau so ist zu klären, ob es Programme gibt, die DEST interpretieren und da bestimmte Inhalte erwarten (der ursprüngliche Einsatz für AncestralFile ist entfallen, daneben sieht der Standard nur für Tempelverordnungen der Mormonen einen genau vorgegebenen Inhalt vor).

In der Diskussion wurde dann herausgearbeitet, dass neben dem Hinweis auf die Gedcom-L auch ein Link im Internet auf die Zusammenfassung unserer Vereinbarungen eingesetzt werden soll. Im Querverweis auf die Aktivitäten der FHISO in Richtung eines neuen Standards wurde eingebracht, dass dort zu jedem verwendeten Kennzeichen ein Internetlink mit der Definition dieses Kennzeichens eingeführt werden soll. Ein Link auf unsere Zusammenfassung der Vereinbarungen wäre ein erster Schritt in diese Richtung. Das Vorgehen wäre mit unseren Vereinbarungen zu _SCHEMA abzugleichen.

Diskussion wegen Kennzeichnung eines verwendeten ADDENDUM (im Jahr 2020)

Nach Veröffentlichung des GEDCOM-L ADDENDUM R1 vom 01.01.2020 wird in der Gruppe diskutiert, ob und wie man bei der Ausgabe einer GEDCOM-Datei im HEAD auf dieses ADDENDUM verweisen kann.

Verfolgt wird damit:

• weitere Verbreitung und Bekanntheit des ADDENDUM weltweit
• Basis für Validatoren, die auch die Einhaltung der Regeln des ADDENDUM prüfen wollen.

Grundsätzlich gibt es dabei zwei Möglichkeiten:

1 GEDC
2 VERS 5.5.1 GEDCOM-L ADDENDUM

oder

1 GEDC
2 VERS 5.5.1
3 _ADDENDUM <ADDENDUM_LINK> {1:M}
4 VERS <ADDENDUM_Version> {1:1}

In der Diskussion wird vorgetragen: In der ersten Version (Eintrag unter 2 VERS) besteht die Gefahr, dass Drittprogramme nur Dateien von ihnen bekannten Versionen des GEDCOM-Standards importieren und aufgrund einer abgeänderten Angabe der Import scheitert. In der zweiten Version ist die Gefahr geringer, dass Drittprogramme den Import nicht schaffen. Aber dabei wird die Datei als 5.5.1 gekennzeichnet, was sie - bei Verwendung einiger Vereinbarungen aus dem ADDENDUM wie SEX X - nicht mehr ist.

Die weitere Diskussion bezieht sich im Wesentlichen auf die Ausgestaltung der zweiten Version, also Angabe mit zusätzlichen Zeilen inklusive Nutzerdefinierten Kennzeichen. Als Konkretisierung wurde eingebracht:

<ADDENDUM_LINK> := {8:120} Link (URL) to the webpage where the additional interpretations and definitions of user-defined tags can be found [in Deutsch: Link (URL) zur Webseite, wo die weitergehenden Interpretationen und Definitionen zu Nutzerdefinierten Kennzeichen hinterlegt sind]

<ADDENDUM_VERSION> := {1:15} An identifier that represents the version of the ADDENDUM, as defined by the emitter of the ADDENDUM [in Deutsch: Eine Angabe, die die Version des ADDENDUMs darstellt, wie vom Herausgeber des ADDENDUMs definiert].

Diese Versionsdefinition für die Ebene 4 ist sehr eng an die des Standards für VERS auf Ebene 2 angelehnt, inkl. der Längendefinition {1:15} des GEDCOM Standards für VERS => VERSIONSNUMBER.

Die angebenen Feldgrößen werden auch in Frage gestellt, der Vorschlag findet in der Diskussion noch keinen allgemeinen Konsens.

Als Alternative wird vorgetragen, auf Ebene 3 nicht den Link, sondern einen einprägsamen Begriff zu nehmen, und dem den Link auf Ebene 4 zu unterstellen, z.B. so:

1 GEDC
2 VERS 5.5.1
3 _ADDEND <ADDENDUM_NAME> {1:M}
4 WWW <ADDENDUM_LINK> {1:1}
4 VERS <ADDENDUM_Version> {1:1}

Weiter wird diskutiert, ob überhaupt eine Version und ein Link verpflichtend ausgegeben werden soll, oder auch

1 GEDC
2 VERS 5.5.1
3 _ADDEND <ADDENDUM_LINK> {1:M}

genommen werden könnte.

Noch eine Variante wird ins Spiel gebracht, bei der mit dem Begriff "EXTENSION" klar gemacht werden soll, dass der Standard 5.5.1 nicht mehr vollständig eingehalten wird, sondern erweitert wurde:

1 GEDC
2 VERS 5.5.1
3 _EXTENSION <EXTENSION _LINK> {1:M}

Die Gruppe ist sich aber einig, dass der Verweis auf den Link https://genealogy.net/GEDCOM des GEDCOM-L ADDENDUM im HEAD auftauchen soll. Völlig offen ist in der Diskussion, wie die offizielle Versionsbezeichnung dieses ADDENDUM ist. Auf der Titelseite steht "2020-01-01" als Version, die Datei ist mit "R1" benamt, weitere Versionen sollen das hochzählen: R2, R3, usw.