GEDCOM/FAM-Tag

Name und Bedeutung

Tag

FAM

Formelle Bezeichnung

Family

Deutsche Bezeichnung

Familie

Verwendung

Rechtliche oder allgemein übliche Verbindung von Mann und Frau und ihrer Kinder (soweit vorhanden) oder eine Verbindung durch die Geburt eines Kindes mit seinen biologischen Eltern

Formale Beschreibung zulässiger Werte

Aussagen des GEDCOM Standards 5.5.1

Für die Familie sieht der GEDCOM Standard einen eigenen Datensatz vor. Seine Struktur ist wie folgt vorgegeben:

FAM_RECORD:=
n @<XREF:FAM>@ FAM {1:1}
+1 RESN <RESTRICTION_NOTICE> {0:1}
+1 <<FAMILY_EVENT_STRUCTURE>> {0:M}
+1 HUSB @<XREF:INDI>@ {0:1}
+1 WIFE @<XREF:INDI>@ {0:1}
+1 CHIL @<XREF:INDI>@ {0:M}
+1 NCHI <COUNT_OF_CHILDREN>10 {0:1}
+1 SUBM @<XREF:SUBM>@ {0:M}
+1 <<LDS_SPOUSE_SEALING>> {0:M}
+1 REFN <USER_REFERENCE_NUMBER> {0:M}
+2 TYPE <USER_REFERENCE_TYPE> {0:1}
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<CHANGE_DATE>> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> 0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}

Der Standard erläutert das weiter wie folgt:

Der Familien-Datensatz wird dazu benutzt, kirchliche und standesamtliche Ehen aufzuzeichnen, sowie Paare die durch gemeinsame Elternschaft entstehen. Es darf nicht mehr als ein Ehemann/Vater (HUSB) und eine Ehefrau/Mutter (WIFE) in einem FAM_RECORD erscheinen.

Wenn beispielsweise ein Mann mehrmals verheiratet war, so würde er in mehreren FAM_RECORDs erscheinen. Die FAM_RECORD Struktur nimmt an, dass der Ehemann (HUSB) männlich ist, und die Ehefrau (WIFE) weiblich.

Die bevorzugte Reihenfolge der Kinder-Zeiger (CHIL) innerhalb des FAMilien-Datensatzes ist die chronologische nach Geburtsdatum der Kinder.

(Zitat Ende)

Laut Standard sind dagegen die Aussagen, um welche Art der Eltern-Kind-Beziehung es sich handelt, nicht im Familien-Datensatz, sondern im Datensatz für die einzelne Person hinterlegt. Dort heißt es:

Die normalen Abstammungsverbindungen werden durch Zeiger von der Person auf eine Familie durch entweder einen FAMC-Kennzeichen oder FAMS-Kennzeichen gezeigt. Das FAMC-Kennzeichen beinhaltet einen Zeiger auf eine Familie, in der die Person Kind ist. Das FAMS-Kennzeichen beinhaltet einen Zeiger auf eine Familie, in der die Person (Ehe-)Partner oder Elternteil ist. Die <<CHILD_TO_FAMILY_LINK>> Struktur enthält einen FAMC-Zeiger, der zwingend notwendig ist, um die Verbindung eines Kindes zu seinen Eltern zu dokumentieren. Die <<CHILD_TO_FAMILY_LINK>> Struktur zeigt zudem, ob es sich um eine biologische Verbindung, Adoption oder Siegelung handelt.

Verbindungen zwischen einem Kind und der Familie, zu der es zum Zeitpunkt eines Ereignisses gehörte, können zusätzlich durch einen FAMC-Zeiger innerhalb der Ereignisstruktur angegeben werden. Beispielsweise kann ein FAMC-Zeiger innerhalb einer Adoption auf die Adoptivfamilie hinweisen. Biologische Eltern können (optional) durch einen zusätzlichen FAMC-Zeiger innerhalb der Geburt angegeben werden.

(Zitat Ende)

Die den Familien zuzuordnenden Ereignisse werden in der beliebig oft im FAM_RECORD zitierbaren <<FAMILY_EVENT_STRUCTURE>> wie folgt detailliert:

FAMILY_EVENT_STRUCTURE:=
[
n [ ANUL | CENS | DIV | DIVF ] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
|
n [ ENGA | MARB | MARC ] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
|
n MARR [Y|<NULL>] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
|
n [ MARL | MARS ] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
|
n RESI {1:1} *1)
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
|
n EVEN [<EVENT_DESCRIPTOR> | <NULL>] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}
]

*1) {1:1} nachgetragen. Fehlt im Original des Standards.

Dabei sind folgende Definitionen im Standard angegeben:

ANUL (Annullierung) Erklärt eine Ehe für vom Anfang an ungültig (sie existierte nie)
CENS (Volkszählung) Das Ereignis einer wiederholten Zählung der Population eines bestimmten Gebietes,
      wie beispielsweise eine nationale Volkszählung.
DIV (Scheidung) Ein Ereignis, dass eine Ehe durch juristische Handlungen auflöst.
DIVF (Einreichen der Scheidung) Ein Ereignis, bei dem ein Ehepartner die Scheidung einleitet.
ENGA (Verlobung) Ein Ereignis der Aufzeichnung oder Bekantmachung, dass zwei Personen heiraten werden.
MARB (Aufgebot) Ein Eregnis, bei dem offiziell bekanntgemacht wird, dass zwei Personen vorhaben zu heiraten.
MARC (Ehevertrag) Ein Ereignis, bei dem ein formale Ehevereinbarung getroffen wird,
     inklusive der vorehelichen Vereinbarung in denen sich die Partner einig werden über Güter einer oder 
     beider Parteien, um diese ihren Kindern zu sichern.
MARR (Heirat) Ein gesetzliches, standesamtliches oder anderes Ereignis, das eine Familie zwischen Mann
     und Frau als Ehemann und Ehefrau erschafft.
MARL (Heiratserlaubnis) Ein Ereignis, bei dem die gesetzliche Erlaubnis erhalten wird, zu heiraten.
MARS (Trennungsvereinbarung) Ein Ereignis, bei dem eine Vereinbarung zwischen zwei Personen getroffen wird,
     die über ein Ende ihrer Ehe nachdenken, und sich zu diesem Zeitpunkt darüber einig werden, Eigentumsrechte
     abzugeben oder zu ändern, die sonst aus der Ehe entstünden.
RESI (Wohnort) Eine Adresse oder Wohnort, an dem eine Person oder Familie wohnhaft war.
EVEN (Ereignis) Eine Person, eine Gruppe oder Organisation betreffendes nennenswertes Ereignis.
     Eine EVEN-Struktur wird normalerweise durch ein untergeordnetes TYPE-Kennzeichen spezifiziert oder klassifiziert.

Das Familienereignis <<FAMILY_EVENT_DETAIL>> unterscheidet sich vom gewöhnlichen Ereignis durch die zusätzlich möglichen Altersangaben für Mann und Frau zum Zeitpunkt des Ereignisses:

FAMILY_EVENT_DETAIL:=
n HUSB {0:1}
+1 AGE <AGE_AT_EVENT> {1:1}
n WIFE {0:1}
+1 AGE <AGE_AT_EVENT> {1:1}
n <<EVENT_DETAIL>> {0:1}

Und schließlich zeigt das gewöhnliche Ereignis <<EVENT_DETAIL>> uns alle Möglichkeiten auf, die wir nun den Ereignissen noch zuordnen können:

EVENT_DETAIL:=
n TYPE <EVENT_OR_FACT_CLASSIFICATION> {0:1}
n DATE <DATE_VALUE> {0:1}
n <<PLACE_STRUCTURE>> {0:1}
n <<ADDRESS_STRUCTURE>> {0:1}
n AGNC <RESPONSIBLE_AGENCY> {0:1}
n RELI <RELIGIOUS_AFFILIATION> {0:1}
n CAUS <CAUSE_OF_EVENT> {0:1}
n RESN <RESTRICTION_NOTICE> {0:1}
n <<NOTE_STRUCTURE>> {0:M}
n <<SOURCE_CITATION>> {0:M}
n <<MULTIMEDIA_LINK>> {0:M}

Vereinbarungen zu FAM

Die folgenden Vereinbarungen wurden aus der Diskussion in der Gedcom-L abgeleitet, sie wurden danach durch Abstimmung unter den beteiligten Programmautoren der Gedcom-L entschieden.

Punkt F7 hat mit 4 Gegenstimmen ( bei 11 JA-Stimmen ) noch Potential zu einer Optimierung. Dies wird bei der weiteren Diskussion zu den noch anstehenden Kennzeichen weiter mit verfolgt und ggfs in einem Gesamtreview gegen Ende des Projektes nochmals aufgerufen.

F1 Abgrenzung der "Familien"

Im FAM-Datensatz werden die Informationen über die Verbindung zwischen zwei Personen als (Ehe-) Paar oder die Beziehungen zwischen Eltern und Kindern dargestellt.

F2 Zusammensetzung der Familie

In einem Familiendatensatz dürfen Mann (HUSB) und Frau (WIFE) maximal je einmal vorhanden sein. Der Export von Familiendatensätzen ohne Mann oder Frau (auch ohne Mann und Frau, also nur mit Kindern) ist zulässig. Der Familie können beliebig viele Kinder zugeordnet sein.

F3 Ereignisse zu einer Familie

Die Verwendung aller im GEDCOM Standard explizit beschriebener Kennzeichen für Ereignisse zu einer Familie ist zulässig. Es wird auch empfohlen, diese Kennzeichen vorrangig vor einer ebenso möglichen Konstruktion mit EVEN plus TYPE einzusetzen, also z.B. möglichst

n ENGA

und nicht:

n EVEN 
n+1 TYPE Verlobung

F4 Standesamtliche und kirchliche Trauung

Das Ereignis MARR beschreibt die Heirat zwischen den (Ehe-) Partnern. Läßt das Programm dem Anwender die Möglichkeit, zu MARR selbst die Art der Heirat bzw. Trauung einzugeben, dann wird diese Angabe mit dem untergeordneten Kennzeichen TYPE wie vom Anwender eingegeben exportiert.

Hat dagegen das Programm feste Datenfelder für standesamtliche und kirchliche Trauungen, wird empfohlen, die standesamtliche Trauung als

n MARR 
n+1 TYPE CIVIL

und die kirchliche Trauung als

n MARR 
n+1 TYPE RELI

zu exportieren. Programme mit nur einem festen Datenfeld für Heirat exportieren dieses als

n MARR

und können dem Anwender die Möglichkeit einräumen, über selbst eingegebene Beschreibungen weitere Trauungen zu beschreiben, was z.B. bei einer kirchlichen Trauung nach einer standesamtlichen Heirat in der Form

n EVEN 
n+1 TYPE kirchliche Trauung

exportiert werden kann.

F5 Eltern-Kind-Beziehungen

Die Art der Verbindung zwischen Eltern und Kind wird im Personendatensatz unter dem Kennzeichen FAMC beschrieben. Es wird vereinbart, diese Information nicht im Familiendatensatz unter CHIL mit nutzerdefinierten Kennzeichen zu exportieren.

F6 Konsistenz der Familien- und Personendatensätze

Innerhalb einer GEDCOM-Datei muss gewährleistet sein, dass zu jedem HUSB, WIFE und CHIL in den Familiendatensätzen der Personendatensatz mit dem zugehörigen Zeiger existiert und in diesem Personendatensatz auf den Familiendatensatz mit dem Kennzeichen FAMS ( für die HUSB, WIFE) bzw. mit FAMC (für die CHIL) verwiesen wird. Umgekehrt müssen zu allen FAMS und FAMC in den Personendatensätzen die entsprechenden Familiendatensätze existieren und die zugehörigen HUSB, WIFE oder CHIL aufweisen.

F7 Verheiratete und nicht verheiratete Partner, Status der Partnerschaft

Im Standard ist vorgegeben, dass die Aussage, dass zwei Personen verheiratet sind, in der Form

n MARR Y

ohne untergeordnete Kennzeichen exportiert werden kann. Nach den Regeln des Standards darf dies dagegen nicht durch ein

n MARR

ohne untergeordnete Kennzeichen erfolgen, da der Export leerer Kennzeichen ohne Folgezeilen unzulässig ist.

Der Standard untersagt explizit, die Aussage "die Personen sind nicht verheiratet" mit einem Negativargument statt des Y zu exportieren. Es wird daher für Programme, die intern Datenfelder wie "nicht verheiratet" oder "nie verheiratet" oder ein Datenfeld Status führen, vereinbart, ein Nutzerdefiniertes Kennzeichen _STAT direkt unter FAM einzuführen:

<STATUS_STRUCTURE> :=
n _STAT <STATUS_TEXT>
+1 DATE <DATE_VALUE> {0:1}
+1 <<PLACE_STRUCTURE>> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}

_STAT kann folgende Werte annehmen:

<STATUS_TEXT> := [NOT MARRIED | NEVER MARRIED | UNKNOWN | <Klartext des Anwenders>]

F8 Gleichgeschlechtliche Partnerschaften

Der Standard geht im Text immer davon aus, dass über HUSB auf einen Mann und über WIFE auf eine Frau verwiesen wird. Eine explizite Regelung für gleichgeschlechtliche Partnerschaften ist im Standard nicht enthalten.

Es wird empfohlen, aus den Kennzeichen HUSB und WIFE nicht auf das Geschlecht der Person zu schließen (dieses wird über das Kennzeichen SEX im Personendatensatz explizit festgelegt oder bleibt bei fehlendem Kennzeichen SEX offen). Damit können im Familiendatensatz auch gleichgeschlechtliche Partnerschaften exportiert werden, indem mit HUSB auch auf eine Frau bzw mit WIFE auch auf einen Mann verwiesen wird.

F9 Mehrere Familiendatensätze zu denselben Personen

Der Standard läßt die Möglichkeit zu, bei mehreren Verbindungen zwischen denselben Personen dies in einem Familien-Datensatz abzubilden oder diese Verbindungen auf mehrere Familien-Datensätze zu verteilen. Auch unverheiratete Eltern eines Kindes können nach Standard in einem gemeinsamen Familiendatensatz oder in getrennten Familiendatensätzen jeweils mit dem Kind exportiert werden. Es wird empfohlen, mehrere Verbindungen zwischen denselben Personen (z.B. Wiederverheiratung nach einer Scheidung) in mehreren Familiendatensätzen sowie unverheiratete Eltern eines Kindes in einem gemeinsamen Familiendatensatz zu exportieren.

F 10 Zeilen_Wert zu RESI

Das Kennzeichen RESI darf auch direkt einen Zeilen_Wert enthalten. Die FAMILY_EVENT_STRUCTURE wird daher zum Kennzeichen RESI wie folgt angepaßt:

n RESI [<RESIDENCE_DESCRIPTOR> | <NULL>] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}

mit einem RESIDENCE_DESCRIPTOR := {1:90} Text, der Informationen über den Wohnsitz der Familie aufnimmt. Dieser Text ergänzt die ggfs. durch die in der FAMILY_EVENT_DETAIL gegebenen Informationen zu DATE, PLAC usw.

Entscheidungsvorschläge (2020)

F7.0 Entfernung von FAM F.7 aus GenWiki sowie aus ADDENDUM 2020

Der 2010 verabschiedete Stand zum Kennzeichen _STAT (dokumentiert in FAM F7 und im Addendum Version R1) wird zurückgezogen und aus den Dokumenten entfernt.

F7.1 Hinzufügen der Länge von <STATUS_TEXT>, Empfehlung zu Klartext

Die bislang fehlende Angabe zur Länge von <STATUS_TEXT> wird auf {1:120} gesetzt:

<STATUS_TEXT> := {1:120} [ NOT MARRIED | NEVER MARRIED | UNKNOWN | <plain text of the user> ]

Es wird empfohlen, den Klartext des Anwenders nicht als Eingabemöglichkeit zu verwenden und den Export von Klartext auf Fälle zu beschränken, wo solcher Inhalt durch einen Import aufgenommen wurde. Als deutsche Übersetzungen der Auswahlmöglichkeiten wird die Verwendung von

• NOT MARRIED : nicht verheiratet
• NEVER MARRIED : nie verheiratet
• UNKNOWN : unbekannt

empfohlen.

F7.2 Entfernen der <<PLACE_STRUCTURE>> aus der Struktur der <STATUS_STRUCTURE>

Dieser Punkt ist zurückgezogen, da FAM._STAT.PLAC in aktiver Nutzung ist.

F7.3 Ergänzung der Häufigkeit von _STAT in der <STATUS_STRUCTURE>

In der <STATUS_STRUCTURE> wird die bislang nicht angegebene Häufigkeit für n _STAT festgesetzt auf n _STAT <STATUS_TEXT> {1:1}

Das bedeutet, dass n _STAT auf jeden Fall in einer solchen Struktur vorkommen muss und nicht alleine die Untertags auftauchen dürfen.

F7.4 Häufigkeit von _STAT im FAM-Datensatz

_STAT darf beliebig oft im Familien-Datensatz verwendet werden. Im Addendum wird im FAM_RECORD die Vorgabe der Häufigkeit der +1 <<STATUS_STRUCTURE>> {0:1} geändert auf +1 <<STATUS_STRUCTURE>> {0:M}

Behandlung/Darstellung schwieriger Situationen

Diskussionen in 2020

Im Jahr 2020 wurde das Thema der Kennzeichnung des Status "nicht verheiratet" (Vereinbarung FAM F 7) noch einmal aufgegriffen.

Hintergrund ist, dass im ADDENDUM der GEDCOM-L Gruppe eine Formalsierung für das Kennzeichen _STAT eingebaut wurde, die so nicht in der Vereinbarung F7 beschrieben ist. Im ADDENDUM steht, dass _STAT im FAM-Datensatz nur einmal {0:1} stehen darf. Diese Beschränkung ist nicht verabschiedet. Hintergrund ist weiter, dass 2010 die Abstimmung vier Gegenstimmen ergab, damit der Punkt zwar vereinbart ist, aber zu einer nochmaligen Diskussion vorgemerkt wurde.

Es wurde weiter die Frage gestellt, was die Angabe "NOT MARRIED" mit einer Ortsangabe unter FAM._STAT.PLAC bedeutet. Dies ist bislang nicht erläutert: Es kann die Aussage sein, dass an dem genannten Ort die Information zu finden war, dass die beiden Personen nicht verheiratet waren. Es kann aber so interpretiert werden, dass sie an dem Ort nicht geheiratet haben, aber es offen ist, ob eine Heirat an einem anderen Ort tsattgefunden hat. Es wird ermittelt, ob FAM._STAT.PLAC überhaupt von Programmen verwendet wird, oder es aus der Vereinbarung gestrichen werden kann. Nachtrag: Das Ergebnis ist, dass FAM._STAT.PLAC in aktiver Nutzung ist und nicht einfach gestrichen werden kann.

Mit dem Ziel, dass ADDENDUM zu FAM auf einen abgestimmten Stand zu bringen, wurden daher Änderungsvorschläge zu FAM 7 als Entscheidungsvorschläge eingestellt.

Angleichung von FAM.RESI an INDI.RESI

In der Vereinbarung INDI E3 ist für RESI festgelegt worden, dass die Zeile 1 RESI selber auch einen Zeilen_Wert beinhalten darf. Diese Vereinbarung wurde durch Abstimmung in 2019 auf den FAM-Datensatz ausgeweitet, damit RESI in beiden Datensatzarten gleich behandelt wird, siehe F10.

Nicht verheiratete Paare

Der Standard läßt die positive Botschaft zu, dass ein Ereignis stattgefunden hat, z.B. für MARR:

1 MARR Y

heißt, dass die in dem Familiendatensatz genannten HUSB bzw WIFE miteinander verheiratet waren. Für die gegenteilige Aussage, dass zwei Personen nicht verheiratet waren, wird derzeit nach einer Standard-konformen Darstellung gesucht. Denn das Weglassen von MARR kann ja auch so interpretiert werden, dass nicht bekannt ist, ob die beiden verheiratet waren. Was eine andere Aussage ist, als z.B. der aus dem Eintrag "unehelich" im KB ablesbare Umstand, dass die Eltern *nicht* verheiratet waren.

Eine umfangreiche Diskussion in der Liste hat sich damit beschäftigt, wie die Aussage "nicht verheiratet" exportiert werden kann.

1 MARR N

verbietet der GEDCOM Standard explizit.

Der Vorschlag:

1 MARR
2 TYPE NOT MARRIED

birgt in sich die Gefahr, dass genau das Gegenteil der gewollten Information herauskommt, wenn das empfangende Programm den TYPE-Wert nicht interpretiert. Der Nachteil ist so gravierend, dass zur Vermeidung des Nachteils auch der Einsatz eines Nutzerdefinierten Kennzeichens in Erwägung gezogen wird.

Daher wurde der Vorschlag in die Liste eingebracht, die Status-Information mit einem Nutzerdefinierten Kennzeichen _STAT auszudrücken. Dies wurde in F7 übernommen.

Als Beispiele für F7 seien hier gezeigt:

Beispiel "nicht verheiratet":

1 _STAT NOT MARRIED

Will man ausdrücken, dass zu einem bestimmten Zeitpunkt (z.B. gemäß einem Kirchenbuch-Eintrag am 18.8.1888) die Partner nicht verheiratet waren, so kann dem der Zeitpunkt hinzugefügt werden:

1 _STAT NOT MARRIED
2 DATE 18 AUG 1888

Ist bekannt, dass die beteiligten Personen nie miteinander verheiratet waren, kann ein Datenfeld "nie verheiratet" als

1 _STAT NEVER MARRIED

exportiert werden. Hier macht natürlich die Angabe eines Zeitpunktes keinen Sinn.

Unterscheidung von standesamtlicher und kirchlicher Heirat

Ab der Einführung der standesamtlichen Trauung als offizielle Heirat gibt es das Thema der Unterscheidung, ob ein Eintrag eine standesamtliche Heirat oder die religiöse Handlung der Trauung war. Oder beide Ereignisse für eine Familie darzustellen.

Diskutiert werden mehrere Möglichkeiten:

Eigenes (nutzerdefiniertes) Kennzeichen für die religiöse Trauung,

Kennzeichnung über TYPE unter MARR

Die Mehrzahl heutiger Programme verwendet die MARR.TYPE Version. Ein Beispiel dafür:

0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 TYPE CIVIL
2 DATE 12 AUG 1889
2 PLAC Kaisersesch,Cochem-Zell,RLP,D
1 MARR
2 TYPE RELI
2 DATE 15 AUG 1889
2 PLAC Hambuch,Cochem-Zell,RLP,D
2 ADDR St. Johannes

Oft wird auch unter TYPE statt CIVIL ein Klartext wie "standesamtlich", "standesamtliche Trauung" sowie statt RELI dann "kirchliche Trauung" ausgegeben. Bei Programmen, die dem Anwender eine Klartexteingabe für TYPE erlauben, bestimmt der Anwender den Text. Für Programme, die feste Datenfelder für Ziviltrauungen und kirchliche Trauungen haben, wird die Verwendung gemeinsam vereinbarter Bezeichnungen unter TYPE vorgeschlagen.

Als eine weitere Variante wird vorgeschlagen, nur die "rechtsgültige" Heirat als MARR zu exportieren und die seit Einführung der verbindlichen standesamtlichen Trauungen nur noch freiwillige kirchliche Trauung nicht unter MARR, sondern als EVEN mit entsprechendem TYPE zu exportieren. Eine solche Vorgabe ist jedoch nicht durchgehend umzusetzen, weil es in vielen Programmen möglich ist, dass der Anwender selber entscheidet, wie er die einer standesamtlichen Heirat folgende kirchliche Trauung einstuft und dementsprechend eingibt. Dann sollen diese Anwender-Vorgaben beim Export respektiert werden und unverändert exportiert werden.

Der Vorschlag, "Zweitheiraten" wie die kirchliche Trauung nach einer standesamtlichen Heirat durch ein eigenes Kennzeichen darzustellen, stößt auf mehrere Probleme, für die noch keine Lösung vorgestellt wurde: Der Anwender hat das Problem, dass er bei Eingabe einer kirchlichen Trauung dann wissen muss, ob dies die "rechtsgültige" Eheschließung war, ggfs muss er später die Daten ändern, wenn er doch noch eine standesamtliche Trauung findet. Das dafür definierte Kennzeichen ist anderen Programmen oft unverständlich, so dass bei einer solchen Vorgehensweise der Datentransfer zu Drittprogrammen nicht sicherzustellen ist. Und formal verstößt der Vorschlag gegen den Grundsatz, nur das über nutzerdefinierte Kennzeichen darzustellen, was im Standard nicht über explizit definierte Strukturen darstellbar ist.

Muss ein Mann und eine Frau im Familien-Datensatz angegeben werden?

In einer vorgezogenen Diskussion wurde in der Liste die Frage gestellt, ob in einem Datensatz zwingend immer ein Mann und eine Frau angegeben werden muss. Einige Programme verlangen das, und der Anwender muss dazu, falls die entsprechende Person unbekannt ist, dennoch eine Person anlegen.

In der Diskussion kam die Liste zum Schluss, dass es sich hierbei um eine programmspezifische Anforderung handelt. Der GEDCOM-Standard läßt mit der Angabe {0:1} sowohl für HUSB als auch für WIFE ausdrücklich zu, dass diese Angaben auch entfallen können.

Programme, die intern also die Vorgabe machen, dass immer ein Mann und eine Frau vorhanden sein muss, müssen beim Import von GEDCOM-Dateien entsprechende Vorkehrungen treffen, um mit Datensätzen umzugehen, bei denen HUSB und/oder WIFE fehlen.