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}

Behandlung/Darstellung schwieriger Situationen

Unterscheidung von standesamtlicher und kirchlicher Heirat

Ab der Einführung der standesamtlichen Traung als offizielle Heirat gibt es das Thema zu unterschieden, 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 Drittprogarmmen 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.

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

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.