GEDCOM/INDI-Tag

Name und Bedeutung

Tag

INDI

Formelle Bezeichnung

INDIVIDUAL

Deutsche Bezeichnung

Person

Verwendung

Mit INDI wird ein Personendatensatz gekennzeichnet

Formale Beschreibung zulässiger Werte

Aussagen des GEDCOM Standards 5.5.1

Ein Personendatensatz wird im Standard als INDIVIDUAL RECORD bezeichnet und wie folgt definiert:

INDIVIDUAL_RECORD:= 
n @XREF:INDI@ INDI {1:1} 
+1 RESN <RESTRICTION_NOTICE> {0:1} 
+1 <<PERSONAL_NAME_STRUCTURE>> {0:M} 
+1 SEX <SEX_VALUE> {0:1} 
+1 <<INDIVIDUAL_EVENT_STRUCTURE>> {0:M} 
+1 <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> {0:M} 
+1 <<LDS_INDIVIDUAL_ORDINANCE>> {0:M} 
+1 <<CHILD_TO_FAMILY_LINK>> {0:M} 
+1 <<SPOUSE_TO_FAMILY_LINK>> {0:M} 
+1 SUBM @<XREF:SUBM>@ {0:M} 
+1 <<ASSOCIATION_STRUCTURE>> {0:M} 
+1 ALIA @<XREF:INDI>@ {0:M} 
+1 ANCI @<XREF:SUBM>@ {0:M} 
+1 DESI @<XREF:SUBM>@ {0:M} 
+1 RFN <PERMANENT_RECORD_FILE_NUMBER> {0:1} 
+1 AFN <ANCESTRAL_FILE_NUMBER> {0:1} 
+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 Personendatensatz (INDIVIDUAL_RECORD) ist eine Sammlung von bekannten oder ermittelten Fakten zu einer Person. Manchmal stammen die Fakten aus unterschiedlichen Quellen. Diese Form erlaubt die Dokumentation der jeweiligen Quelle, in der ein Fakt entdeckt wurde.

Folgende Elemente hiervon sind in anderen Artikeln beschrieben: ALIA, <<ASSOCIATION_STRUCTURE>>, <<PERSONAL_NAME_STRUCTURE>>, SEX, <<CHILD_TO_FAMILY_LINK>>, <<NOTE_STRUCTURE>>, <<SOURCE_CITATION>>

Weitere Artikel werden folgen zu SUBM, RESN, ANCI, DESI, RFN, AFN, REFN, RIN, <<SPOUSE_TO_FAMILY_LINK>>, <<CHANGE_DATE>>, <<MULTIMEDIA_LINK>>.

In diesem Artikel werden beschrieben: Personenereignisse <<INDIVIDUAL_EVENT_STRUCTURE>> und Personeneigenschaften <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.

Beschreibungen von Ereignissen zu einer Person

Ereignisse zu einer Person wie z.B. Geburt, Taufe, Tod, Beerdigung werden in den <<INDIVIDUAL_EVENT_STRUCTURE>> beschrieben:

INDIVIDUAL_EVENT_STRUCTURE:= 
[ 
n [ BIRT | CHR ] [Y|<NULL>] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
+1 FAMC @<XREF:FAM>@ {0:1} 
| 
n DEAT [Y|<NULL>] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n [ BURI | CREM ] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n ADOP {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
+1 FAMC @<XREF:FAM>@ {0:1} 
+2 ADOP <ADOPTED_BY_WHICH_PARENT> {0:1} 
| 
n [ BAPM | BARM | BASM | BLES ] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n [ CHRA | CONF | FCOM | ORDN ] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n [ NATU | EMIG | IMMI ] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n [ CENS | PROB | WILL] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n [ GRAD | RETI ] {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
| 
n EVEN {1:1} 
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1} 
]

ACHTUNG: Die {0:1} in dieser Darstellung darf nicht zu der Annahme verleiten, in einem Personendatensatz dürften diese Ereignisse jeweils nur einmal auftauchen. Die INDIVIDUAL_EVENT_STRUCTURE darf {0:M} mal im Personendatensatz vorkommen, also darf auch jedes der hier aufgeführten Ereignis-Kennzeichen beliebig oft in einem Personendatensatz vorkommen.

Weiter zu beachten: Nur die Kennzeichen BIRT, CHR und DEAT dürfen direkt in der Zeile mit einem Y ergänzt werden, um die Aussage zu machen, dass eine Person geboren ist, getauft wurde oder gestorben ist. Hinter allen anderen Ereignis-Kennzeichen DARF KEINE INFORMATION in derselben Zeile stehen, diese wird ausschließlich dann über die untergeordneten Zeilen transportiert. Mit Ausnahme dieser Besonderheit ist ansonsten der Aufbau eines Personenereignisses sehr einheitlich im Standard geregelt.

Beschreibungen von Eigenschaften einer Person

Eigenschaften zu einer Person wie Beruf, Wohnsitz usw werden mit <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> beschrieben:

INDIVIDUAL_ATTRIBUTE_STRUCTURE:=
[
n CAST <CASTE_NAME> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n DSCR <PHYSICAL_DESCRIPTION> {1:1}
+1 [CONC | CONT ] <PHYSICAL_DESCRIPTION> {0:M}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n EDUC <SCHOLASTIC_ACHIEVEMENT> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n IDNO <NATIONAL_ID_NUMBER> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n NATI <NATIONAL_OR_TRIBAL_ORIGIN> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n NCHI <COUNT_OF_CHILDREN>14 {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n NMR <COUNT_OF_MARRIAGES> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n OCCU <OCCUPATION> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n PROP <POSSESSIONS> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n RELI <RELIGIOUS_AFFILIATION> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n RESI /* Wohnort */ {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n SSN <SOCIAL_SECURITY_NUMBER> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n TITL <NOBILITY_TYPE_TITLE> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}
|
n FACT <ATTRIBUTE_DESCRIPTOR> {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>> {0:1}
]

Details zu Personenereignissen und -eigenschaften

Die Folgezeilen eines Personenereignisses oder einer Personeneigenschaft sind wie folgt aufgebaut:

INDIVIDUAL_EVENT_DETAIL:= 
n <<EVENT_DETAIL>> {1:1} 
n AGE <AGE_AT_EVENT> {0:1}

Der Unterbau zu den einzelnen Ereignissen ist fast derselbe wie im Bereich der Familiendatensätze. Einzig statt des HUSB und WIFE, dass bei den Familiendatensätzen zusätzlich auftauchen konnte, kann hier das Alter der Person zum Zeitpunkt des Ereignisses ( AGE ) eingesetzt werden.

Diese Struktur darf unter jedem Ereignis im Personendatensatz stehen. Völlig gleich mit der Definition für Familienereignisse sind diese Details:

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}

Bis auf NOTE, SOUR und OBJE dürfen die anderen Kennzeichen bzw. Strukturen immer nur genau einmal unter dem Ereigniskennzeichen vorkommen.

Vereinbarungen zu INDI

Die nachstehenden Vereinbarungen sind aus der Disksusion der Gedcom-L entwickelt und dann per Abstimmung unter den an der Liste beteiligten Autoren entschieden worden.

E1 Ereignisse in Personendatensätzen

Alle im GEDCOM-Standard explizit genannten Kennzeichen für Ereignisse ( EVENT ) dürfen genutzt werden. In der Zeile nach dem Kennzeichen darf kein weiterer Zeileninhalt stehen. Ausnahme sind die Kennzeichen BIRT, CHR und DEAT, denen ein Y folgen darf als Information, dass dieses Ereignis stattgefunden hat.

E2 Zeileninhalt nach EVEN

Der GEDCOM-Standard macht widersprüchliche Angaben, ob im Personendatensatz dem Kennzeichen EVEN ein Zeileninhalt folgen darf. Es wird hier vereinbart, dass ergänzend zu E1 auch im Personendatensatz dem Kennzeichen EVEN ein Klartext-Inhalt folgen darf. Damit wird EVEN hier genau so behandelt wie im Familiendatensatz.

E3 Eigenschaften in Personendatensätzen

Alle im GEDCOM-Standard explizit genannten Kennzeichen für Eigenschaften ( ATTRIBUTE ) dürfen genutzt werden. Alle diese Kennzeichen dürfen auch direkt einen Zeileninhalt anführen. Dies wird hier auch für das Kennzeichen RESI (Wohnsitz) vereinbart, wo dies im GEDCOM-Standard nicht explizit genannt ist.

E4 Umgang mit TYPE

Alle Kennzeichen für Ereignisse und Eigenschaften können durch ein untergeordnetes Kennzeichen TYPE näher beschrieben werden. Für die Kennzeichen EVEN, FACT und IDNO muss eine Beschreibung mit TYPE exportiert werden.

E5 Alternativen bei Ereignissen und Eigenschaften

Ereignisse können oft durch ein explizites Kennzeichen oder durch eine EVEN, TYPE Kombination in GEDCOM dargestellt werden. Hierzu wird vereinbart:

• Es wird empfohlen, den Export von Ereignissen in der Struktur vorzunehmen, die dem exportierenden Programm entspricht.
• Es ist zulässig, ein explizites Ereignis-Kennzeichen durch eine EVEN , TYPE Darstellung mit einem entsprechenden Klartext unter TYPE zu ersetzen. Dies kann vor allem bei Exporten für Programme in Frage kommen, die das explizite Kennzeichen nicht verarbeiten können.
• Bei Programmen, die intern nur eine dieser Alternativen für Ereignisse abbilden, wird empfohlen, beim Import eingehende Informationen mit der anderen Darstellung nach Möglichkeit in die eigene Darstellung zu überführen und somit eine Struktur als Ereignis zu erhalten. In Fällen, wo dies nicht möglich ist, wird die Überführung in eine Bemerkung empfohlen.

Analog wird für Eigenschaften vereinbart:

• Es wird empfohlen, den Export von Eigenschaften in der Struktur vorzunehmen, die dem exportierenden Programm entspricht.
• Es ist zulässig, ein explizites Eigenschafts-Kennzeichen durch eine FACT , TYPE Darstellung mit einem entsprechenden Klartext unter TYPE zu ersetzen. Dies kann vor allem bei Exporten für Programme in Frage kommen, die das explizite Kennzeichen nicht verarbeiten können.
• Bei Programmen, die intern nur eine dieser Alternativen für Eigenschaften abbilden, wird empfohlen, beim Import eingehende Informationen mit der anderen Darstellung nach Möglichkeit in die eigene Darstellung zu überführen und somit eine Struktur als Eigenschaft zu erhalten. In Fällen, wo dies nicht möglich ist, wird die Überführung in eine Bemerkung empfohlen.

Behandlung/Darstellung schwieriger Situationen

Alternativen bei Ereignissen und Eigenschaften

Der GEDCOM-Standard läßt bei Ereignissen, denen ein explizit definiertes Kennzeichen zugeordnet ist, zwei Alternativen der Darstellung zu. Dies sei hier am Beispiel der Erstkommunion gezeigt:

1 FCOM
...
1 EVEN
2 TYPE Erstkommunion

Die erste Version entspricht meist einem festen Datenfeld im Programm für die Erstkommunion, die zweite Version wird verwendet, wenn das Programm ein allgemeines Ereignis dem Anwender anbietet, für das der Anwender selber als Klartext-Angabe die Art des Ereignisses (hier: Erstkommunion) eingibt.

In der Gedcom-L wird diskutiert, ob Programme, die bei bestimmten Ereignissen nur eine dieser Versionen anbieten, beim Import von GEDCOM-Dateien aber die andere Version vorfinden, eine Überführung in die im Programm verwendete Form möglich ist. Findet das Programm die erste Version, also das explizit dem Ereignis zugeordnete Kennzeichen vor, verwendet intern aber nur Datenfelder mit Klartext-Angaben entsprechend TYPE, so ist die Übertragung eindeutig möglich. Umgekehrt gilt das nicht, da der Anwender unter TYPE auch andere Texte als Erstkommunion eintragen kann, wie z.B. Kommunion, first communion und anderes. Daher wird es dann nicht immer gelingen, eine Übertragung in fest definierte Kennzeichen wie FCOM vorzunehmen.

Genau analog gilt diese Diskussion auch für Eigenschaften und die Kombination FACT mit TYPE.

Widerspruch im GEDCOM Standard zu EVEN unter INDI

Ein Beispiel wird im Standard explizit angegeben: EVENT_DESCRIPTOR:= {Size=1:90} (Ereignis, Bezeichner) Text, der ein die Person oder Familie betreffendes bestimmtes Ereignis beschreibt. Dieser Wert wird normalerweise dem EVEN-Kennzeichen zugeordnet. Die Klassifizierung, die dieses Ereignis von anderen EVEN-Kennzeichen unterscheidet (oder mit diesen gruppiert), wird durch ein untergeordnetes TYPE-Kennzeichen der <EVENT_DETAIL>-Struktur angegeben. Beispiel:

1 EVEN Ernennung zum Vorsitzenden des Bebauungsplankomitees
2 TYPE Städtische Ernennungen
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Stadtentwicklungsbehörde

Das Regelwerk sagt dagegen für EVEN unter INDI:

n EVEN					 {1:1}
+1 <<INDIVIDUAL_EVENT_DETAIL>>* {0:1}

Laut Regel darf also hinter EVEN überhaupt kein Text stehen. Das Beispiel dagegen setzt genau dort Text ein und gibt eine empfohlene Mindestlänge von 90 Zeichen dafür an.

Sehen wir uns das gleiche Kennzeichen im Familiendatensatz an:

n EVEN [<EVENT_DESCRIPTOR> | <NULL>] {1:1}
+1 <<FAMILY_EVENT_DETAIL>> {0:1}

Wie im Beispiel zu Personen ist hier direkt hinter dem Kennzeichen EVEN der <EVENT_DESCRIPTOR> zugelassen!!

Folgende Handlungsweisen dazu werden in der Gedcom-L diskutiert: - dem strengen Regelwerk folgen und hinter EVEN keine Inhalte? Dafür aber TYPE bindend vorschreiben? - oder die Regeln weglassen, dem Beispiel folgen, und mit dem Vorgehen in FAM vereinheitlichen? - oder beides zulassen??

Abweichungen vom Standard bei der Verwendung

- noch nicht besetzt