The GEDCOM Standard Release 5.5

Chapter 2

Lineage-Linked Grammar

Introduction

This chapter describes the specific tag, value, and pointer combinations used for exchanging family-based lineage-linked genealogical information in the GEDCOM format. Lineage-linked data pertains to individuals linked in family relationships across multiple generations. The chapter also addresses specific compatibility issues pertaining to previous Lineage-Linked GEDCOM Form releases and contains a sample lineage-linked GEDCOM transmission.

The Lineage-Linked GEDCOM Form defined in this chapter is based on the general framework of the GEDCOM data representation grammar defined in Chapter 1. Commercial genealogical software systems are invited to use the Lineage-Linked GEDCOM Form to exchange data. It is the only form approved for exchanging data with Ancestral File, TempleReady and other Family History resource files maintained for this purpose.

Organization

The basic description of the Lineage-Linked GEDCOM Form's grammar is presented in the following three major sections:

"Record Structures of the Lineage-Linked Form"
"Substructures of the Lineage-Linked Form"
"Primitive elements of the Lineage-Linked Form"

The definition of the tags used in defining the lineage-linked structures are contained in Appendix A.

Symbols Used in Chapter 2

The following symbols are used in Chapter 2:

<< double_angle bracket >>
Indicates a subordinate GEDCOM structure pattern of a record, structure, or substructure is to be substituted in place of the enclosing double angle brackets. The substitute structure pattern is found subordinate to the LINEAGE_LINKED_GEDCOM for record pattern definition or in alphabetical order under the "Substructures of the Lineage-Linked Form" section.

< Single_angle bracket >
Indicates the name of the appropriate value for this GEDCOM line% <Primitive >. The specific definition of this value is found in alphabetical order in "Primitive Elements of the Lineage-Linked Form".

{ braces }
Indicates the minimum to maximum occurrences allowed for this structure or line% { Minimum:Maximum } . Note that minimum and maximum occurrence limits are defined relative to the enclosing superior line. This means that a required line (minimum = 1) is not required if the optional enclosing superior line is not present. Similarly, a line occurring only once (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple-occurring superior line.

[ Square brackets ]
Indicates a choice of one or more options% [ Choice of ] .

| vertical bar |
Separates the multiple choices, for example [Choice 1 | Choice 2].

n level number
A level number which assumes the level number of the line which referenced the substructure name.

+1 , +2 ...
A +1 level number is 1 greater than the level number assumed by the superior n level. A +2 level number is 2 greater, and so forth.

0xHH
Indicates an allowable hexadecimal character value where HH is that value, for example, 0x20 (decimal 32) indicates the space character.

Lineage-Linked Form Usage Conventions

The order in which GEDCOM lines are written to a GEDCOM file is controlled by the context and level number. When the lines are of equal level number but have a different tag name then the order is not significant. The occurrence of equal level numbers and equal tags within the same context imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the least preferred data listed in subsequent lines by order decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or preferred items last.

Systems that support multiple fields or structures should allow their users to indicate their preference opinion. Systems that only store single value structures should use the preferred information (the first occurrence listed) and store the remaining information as an exception, preferably within an appropriate NOTE field or in some way that the patron has ready access to the less-preferred data when viewing the record.
Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event.
The Lineage-Linked GEDCOM Form uses the TYPE tag to further classify its superior tag for the viewer. The value portion given by the TYPE tag is not intended to inform a computer program how to process the data. The difference between this value and a note value is that displaying systems should always display the type value when they display the data from the associated context. This gives the user some flexibility in further describing the informationprovided but does not require the software to recognize and respond to the large variety qualifiers that might be used. For example:
```
    1 EVEN
      2 TYPE Awarded BSA Eagle Rank
      2 DATE 1980
```
For compatibility, support of multiple calendars using the (#D) escape sequence is still part of the GEDCOM 5.5 Lineage-Linked Form. Multiple calendar support is not satisfactory and should be addressed in future GEDCOM releases. As a possible future direction, simplification could be obtained by converting from a day in a given source calendar to a specific sequential day number based on some beginning point in time. The receiving system would then convert from that day number to the calendar day of their choice. The Julian day system is based on a sequential day beginning from the first day of 4713 years B.C. The Julian day system with an extension that allows imprecise dates. Later versions of GEDCOM may consider this approach. This approach would also introduce the idea of the evidence date being shared in the DATE tag and the universal day number would be passed under a separate tag.
All controlled line_value choices should be considered as case insensitive.
This means that the values should be converted to all uppercase or all lowercase prior to comparing. The terms UPPERCASE and UpperCase are considered equal. TAGS are always UPPERCASE.

Record Structures of the Lineage-Linked Form

LINEAGE_LINKED_GEDCOM: =
This is a model of the lineage-linked GEDCOM structure for submitting data to other lineage-linked GEDCOM processing systems. A header and a trailer record are required, and they can enclose any number of data records. Tags from Appendix A must be used in the same context as shown in the following form. User defined tags (see <NEW_TAG>) are discouraged but when used must begin with an under-score.

0 <<HEADER>> {1:1}
0 <<SUBMISSION_RECORD>> {0:1}
0 <<RECORD>> {1:M}
0 TRLR {1:1}

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}
    +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 [CONT|CONC] <GEDCOM_CONTENT_DESCRIPTION>  {0:M}

* NOTE:
Submissions to the Family History Department for Ancestral File submission or for clearing temple ordinances must use a DESTination of ANSTFILE or TempleReady .

The header structure provides information about the entire transmission. The SOURce system name identifies which system sent the data. The DESTination system name identifies the intended receiving system.

Additional GEDCOM standards will be produced in the future to reflect GEDCOM expansion and maturity. This requires the reading program to make sure it can read the GEDC.VERS and the GEDC.FORM values to insure proper readability. The CHAR tag is required. All character codes greater than 0x7F must be converted to ANSEL . (See Chapter 3.)

RECORD: =
[
n <<FAM_RECORD>> {1:1}
|
n <<INDIVIDUAL_RECORD>> {1:1}
|
n <<MULTIMEDIA_RECORD>> {1:M}
|
n <<NOTE_RECORD>> {1:1}
|
n <<REPOSITORY_RECORD>> {1:1}
|
n <<SOURCE_RECORD>> {1:1}
|
n <<SUBMITTER_RECORD>> {1:1}
]

FAM_RECORD: =

  n @<XREF:FAM>@  FAM   {1:1}
    +1 <<FAMILY_EVENT_STRUCTURE>>  {0:M}
      +2 HUSB      {0:1}
        +3 AGE <AGE_AT_EVENT>  {1:1}
      +2 WIFE      {0:1}
        +3 AGE <AGE_AT_EVENT>  {1:1}
    +1 HUSB @<XREF:INDI>@  {0:1}
    +1 WIFE @<XREF:INDI>@  {0:1}
    +1 CHIL @<XREF:INDI>@  {0:M}
    +1 NCHI <COUNT_OF_CHILDREN>  {0:1}
    +1 SUBM @<XREF:SUBM>@  {0:M}
    +1 <<LDS_SPOUSE_SEALING>>  {0:M}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<MULTIMEDIA_LINK>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {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}

The FAMily record is used to record marriages, common law marriages, and family unions caused by two people becoming the parents of a child. There can be no more than one HUSB/father and one WIFE/mother listed in each FAM_RECORD. If, for example, a man participated in more than one family union, then he would appear in more than oneFAM_RECORD. The family record structure assumes that the HUSB/father is male and WIFE/mother is female.

The preferred order of the CHILdren pointers within a FAMily structure is chronological by birth.

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 <<SOURCE_CITATION>>  {0:M}
    +1 <<MULTIMEDIA_LINK>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {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}

The individual record is a compilation of facts, known or discovered, about an individual. Sometimes these facts are from different sources. This form allows documentation of the source where each of the facts were discovered.

The normal lineage links are shown through the use of pointers from the individual to a family through either the FAMC tag or the FAMS tag. The FAMC tag provides a pointer to a family where this person is a child. The FAMS tag provides a pointer to a family where this person is a spouse or parent. The <<CHILD_TO_FAMILY_LINK>> structure contains a FAMC pointer which is required to show any child to parent linkage for pedigree navigation. The <<CHILD_TO_FAMILY_LINK>> structure also indicates whether the pedigree link represents a birth lineage, an adoption lineage, or a sealing lineage.

Linkage between a child and the family they belonged to at the time of an event can also optionally be shown by a FAMC pointer subordinate to the appropriate event. For example, a FAMC pointer subordinate to an adoption event would show which family adopted this individual. Biological parent or parents can be indicated by a FAMC pointer subordinate to thebirth event. The FAMC tag can also optionally be used subordinate to an ADOPtion, or BIRTh event to differentiate which set of parents were related by adoption, sealing, or birth.

Other associations or relationships are represented by the ASSOciation tag. The person's relation or association is the person being pointed to . The association or relationship is stated by the value on the subordinate RELA line. For example:

      0 @I1@ INDI
        1 NAME Fred/Jones/
        1 ASSO @I2@
          2 RELA Godfather

MULTIMEDIA_RECORD: =

  n @XREF:OBJE@ OBJE  {1:1}
    +1 FORM <MULTIMEDIA_FORMAT>  {1:1}
    +1 TITL <DESCRIPTIVE_TITLE>  {0:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}
    +1 BLOB        {1:1}
      +2 CONT <ENCODED_MULTIMEDIA_LINE>  {1:M}
    +1 OBJE @<XREF:OBJE>@     /* chain to continued object */  {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}

Large whole multimedia objects embedded in a GEDCOM file would break some systems. For this purpose, large multimedia files should be divided into smaller multimedia records by using the subordinate OBJE tag to chain to the next <MULTIMEDIA_RECORD> fragment. This will allow GEDCOM records to be maintained below the 32K limit for use in systems with limited resources.

NOTE_RECORD: =

  n  @<XREF:NOTE>@ NOTE <SUBMITTER_TEXT>  {1:1}
    +1 [ CONC | CONT] <SUBMITTER_TEXT>  {0:M}
    +1 <<SOURCE_CITATION>>  {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}

REPOSITORY_RECORD: =

  n  @<XREF:REPO>@ REPO  {1:1}
    +1 NAME <NAME_OF_REPOSITORY>   {0:1}
    +1 <<ADDRESS_STRUCTURE>>  {0:1}
    +1 <<NOTE_STRUCTURE>>  {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}

SOURCE_RECORD: =

  n  @<XREF:SOUR>@ SOUR  {1:1}
    +1 DATA        {0:1}
      +2 EVEN <EVENTS_RECORDED>  {0:M}
        +3 DATE <DATE_PERIOD>  {0:1}
        +3 PLAC <SOURCE_JURISDICTION_PLACE>  {0:1}
      +2 AGNC <RESPONSIBLE_AGENCY>  {0:1}
      +2 <<NOTE_STRUCTURE>>  {0:M}
    +1 AUTH <SOURCE_ORIGINATOR>  {0:1}
      +2 [CONT|CONC] <SOURCE_ORIGINATOR>  {0:M}
    +1 TITL <SOURCE_DESCRIPTIVE_TITLE>  {0:1}
      +2 [CONT|CONC] <SOURCE_DESCRIPTIVE_TITLE>  {0:M}
    +1 ABBR <SOURCE_FILED_BY_ENTRY>  {0:1}
    +1 PUBL <SOURCE_PUBLICATION_FACTS>  {0:1}
      +2 [CONT|CONC] <SOURCE_PUBLICATION_FACTS>  {0:M}
    +1 TEXT <TEXT_FROM_SOURCE>  {0:1}
      +2 [CONT|CONC] <TEXT_FROM_SOURCE>  {0:M}
    +1 <<SOURCE_REPOSITORY_CITATION>>  {0:1}
    +1 <<MULTIMEDIA_LINK>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {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}

Source records are used to provide a bibliographic description of the source cited. (See the <<SOURCE_CITATION>> structure, which contains the pointer to this source record.)

SUBMISSION_RECORD: =

  n  @XREF:SUBN@ SUBN  {1:1]
    +1 SUBM @XREF:SUBM@  {0:1}
    +1 FAMF <NAME_OF_FAMILY_FILE>  {0:1}
    +1 TEMP <TEMPLE_CODE>  {0:1}
    +1 ANCE <GENERATIONS_OF_ANCESTORS>  {0:1}
    +1 DESC <GENERATIONS_OF_DESCENDANTS>  {0:1}
    +1 ORDI <ORDINANCE_PROCESS_FLAG>  {0:1}
    +1 RIN <AUTOMATED_RECORD_ID>  {0:1}

The sending system uses a submission record to send instructions and information to the receiving system. TempleReady processes submission records to determine which temple the cleared records should be directed to. The submission record is also used for communication between Ancestral File download requests and TempleReady. Each GEDCOM transmissionfile should have only one submission record. Multiple submissions are handled by creating separate GEDCOM transmission files.

SUBMITTER_RECORD: =

  n  @<XREF:SUBM>@  SUBM {1:1}
    +1 NAME <SUBMITTER_NAME>  {1:1}
    +1 <<ADDRESS_STRUCTURE>>  {0:1}
    +1 <<MULTIMEDIA_LINK>>  {0:M}
    +1 LANG <LANGUAGE_PREFERENCE>  {0:3}
    +1 RFN <SUBMITTER_REGISTERED_RFN>  {0:1}
    +1 RIN <AUTOMATED_RECORD_ID>  {0:1}
    +1 <<CHANGE_DATE>>  {0:1}

The submitter record identifies an individual or organization that contributed information contained in the GEDCOM transmission. All records in the transmission are assumed to be submitted by the SUBMITTER referenced in the HEADer, unless a SUBMitter reference inside a specific record points at a different SUBMITTER record.

Substructures of the Lineage-Linked Form

ADDRESS_STRUCTURE: =

  n  ADDR <ADDRESS_LINE>  {0:1}
    +1 CONT <ADDRESS_LINE>  {0:M}
    +1 ADR1 <ADDRESS_LINE1>  {0:1}
    +1 ADR2 <ADDRESS_LINE2>  {0:1}
    +1 CITY <ADDRESS_CITY>  {0:1}
    +1 STAE <ADDRESS_STATE>  {0:1}
    +1 POST <ADDRESS_POSTAL_CODE>  {0:1}
    +1 CTRY <ADDRESS_COUNTRY>  {0:1}
  n  PHON <PHONE_NUMBER>  {0:3}

The address structure should be formed as it would appear on a mailing label using the ADDR and ADDR.CONT lines. These lines are required if an ADDRess is present. Optionally, additional structure is provided for systems that have structured their addresses for indexing and sorting.

ASSOCIATION_STRUCTURE: =

  n  ASSO @<XREF:INDI>@  {0:M}
    +1 TYPE <RECORD_TYPE>  {1:1}
    +1 RELA <RELATION_IS_DESCRIPTOR>  {1:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}
    +1 <<SOURCE_CITATION>>  {0:M}

CHANGE_DATE: =

  n  CHAN          {1:1}
    +1 DATE <CHANGE_DATE>  {1:1}
      +2 TIME <TIME_VALUE>  {0:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}

The change date is intended to only record the last change to a record. Some systems may want to manage the change process with more detail, but it is sufficient for GEDCOM purposes to indicate the last time that a record was modified.

CHILD_TO_FAMILY_LINK: =

  n  FAMC @<XREF:FAM>@  {1:1}
    +1 PEDI <PEDIGREE_LINKAGE_TYPE>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}

EVENT_DETAIL: =

  n  TYPE <EVENT_DESCRIPTOR>  {0:1}
  n  DATE <DATE_VALUE>  {0:1}
  n  <<PLACE_STRUCTURE>>  {0:1}
  n  <<ADDRESS_STRUCTURE>>  {0:1}
  n  AGE <AGE_AT_EVENT>  {0:1}
  n  AGNC <RESPONSIBLE_AGENCY>  {0:1}
  n  CAUS <CAUSE_OF_EVENT>  {0:1}
  n  <<SOURCE_CITATION>>  {0:M}
  n  <<MULTIMEDIA_LINK>>  {0:M}
  n  <<NOTE_STRUCTURE>>  {0:M}

FAMILY_EVENT_STRUCTURE: =

  [
  n [ ANUL | CENS | DIV | DIVF ] [Y|<NULL>]  {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n [ ENGA | MARR | MARB | MARC ] [Y|<NULL>]  {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n [ MARL | MARS ] [Y|<NULL>]  {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  EVEN          {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  ]

INDIVIDUAL_ATTRIBUTE_STRUCTURE: =

  [
  n  CAST <CASTE_NAME>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  DSCR <PHYSICAL_DESCRIPTION>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  EDUC <SCHOLASTIC_ACHIEVEMENT>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  IDNO <NATIONAL_ID_NUMBER>   {1:1}*
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  NATI <NATIONAL_OR_TRIBAL_ORIGIN>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  NCHI <COUNT_OF_CHILDREN>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  NMR <COUNT_OF_MARRIAGES>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  OCCU <OCCUPATION>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  PROP <POSSESSIONS>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  RELI <RELIGIOUS_AFFILIATION>   {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  RESI           {1:1}  
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  SSN <SOCIAL_SECURITY_NUMBER>   {0:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  |
  n  TITL <NOBILITY_TYPE_TITLE>  {1:1}
    +1 <<EVENT_DETAIL>>  {0:1}
  ]

* Note: The usage of IDNO requires that the subordinate TYPE tag be used to define what kind of number is assigned to IDNO.

INDIVIDUAL_EVENT_STRUCTURE: =

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

The EVEN tag in this structure is for recording general events or attributes that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>. The general event or attribute type is declared by using a subordinate TYPE tag to show what event or attribute is recorded. For example, a candidate for state senate in the 1952 election could be recorded:

    1 EVEN
      2 TYPE Election
      2 DATE 07 NOV 1952
      2 NOTE Candidate for State Senate.

The TYPE tag is also optionally used to modify the basic understanding of its superior event and is usually provided by the user. For example:

    1 ORDN
      2 TYPE Deacon

The presence of a DATE tag and/or PLACe tag makes the assertion of when and/or where the event took place, and therefore that the event did happen. The absence of both of these tags require a Y(es) value on the parent TAG line to assert that the event happened. Using this convention protects GEDCOM processors which may remove (prune) lines that have no value and no subordinate lines. It also allows a note or source to be attached to the event context without implying that the event occurred.

It is not proper to use a N(o) value with an event tag to infer that it did not happen. Inferring that an event did not occur would require a different tag. A symbol such as using an exclamation mark (!) preceding an event tag to indicate an event is known not to have happened may be defined in the future.

LDS_INDIVIDUAL_ORDINANCE: =

  [
  n  [ BAPL | CONL ]  {1:1}
    +1 STAT <LDS_BAPTISM_DATE_STATUS>  {0:1}
    +1 DATE <DATE_LDS_ORD>  {0:1}
    +1 TEMP <TEMPLE_CODE>  {0:1}
    +1 PLAC <PLACE_LIVING_ORDINANCE>  {0:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  |
  n  ENDL          {1:1}
    +1 STAT <LDS_ENDOWMENT_DATE_STATUS>  {0:1}
    +1 DATE <DATE_LDS_ORD>  {0:1}
    +1 TEMP <TEMPLE_CODE>  {0:1}
    +1 PLAC <PLACE_LIVING_ORDINANCE>  {0:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  |
  n  SLGC          {1:1}
    +1 STAT <LDS_CHILD_SEALING_DATE_STATUS>  {0:1}
    +1 DATE <DATE_LDS_ORD>  {0:1}
    +1 TEMP <TEMPLE_CODE>  {0:1}
    +1 PLAC <PLACE_LIVING_ORDINANCE>  {0:1}
    +1 FAMC @<XREF:FAM>@  {1:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  ]

LDS_SPOUSE_SEALING: =

  n  SLGS          {1:1}
    +1 STAT <LDS_SPOUSE_SEALING_DATE_STATUS>  {0:1}
    +1 DATE <DATE_LDS_ORD>  {0:1}
    +1 TEMP <TEMPLE_CODE>  {0:1}
    +1 PLAC <PLACE_LIVING_ORDINANCE>  {0:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}

MULTIMEDIA_LINK: =

  [          /* embedded form*/
  n  OBJE @<XREF:OBJE>@  {1:1}
  |          /* linked form*/
  n  OBJE           {1:1}
    +1 FORM <MULTIMEDIA_FORMAT>  {1:1}
    +1 TITL <DESCRIPTIVE_TITLE>  {0:1}
    +1 FILE <MULTIMEDIA_FILE_REFERENCE>  {1:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  ]

This structure provides two options in handling the GEDCOM multimedia interface. The first alternative (embedded) includes all of the data, including the multimedia object, within the transmission file. The embedded method includes pointers to GEDCOM records that contain encoded image or sound objects. Each record represents a multimedia object or object fragment. An object fragment is created by breaking the multimedia files into several multimedia object records of 32K or less. These fragments are tied together by chaining from one multimedia object fragment to the next in sequence. This procedure will help manage the size of a multimedia GEDCOM record so that existing systems which are not expecting large multimedia records may discard the records without crashing due to the size of the record. Systems which handle embedded multimedia can reconstitute the multimedia fragments by decoding the object fragments and concatenating them to the assigned multimedia file.

The second method allows the GEDCOM context to be connected to an external multimedia file. This process is only managed by GEDCOM in the sense that the appropriate file name is included in the GEDCOM file in context, but the maintenance and transfer of the multimedia files are external to GEDCOM.

NOTE_STRUCTURE: =

  [
  n  NOTE @<XREF:NOTE>@  {1:1}
    +1 <<SOURCE_CITATION>>  {0:M}
  |
  n  NOTE [SUBMITTER_TEXT> | <NULL>]  {1:1}
    +1 [ CONC | CONT ] <SUBMITTER_TEXT>  {0:M}
    +1 <<SOURCE_CITATION>>  {0:M}
  ]

PERSONAL_NAME_STRUCTURE: =

  n NAME <NAME_PERSONAL>  {1:1}
    +1 NPFX <NAME_PIECE_PREFIX>  {0:1}
    +1 GIVN <NAME_PIECE_GIVEN>  {0:1}
    +1 NICK <NAME_PIECE_NICKNAME>  {0:1}
    +1 SPFX <NAME_PIECE_SURNAME_PREFIX>  {0:1}
    +1 SURN <NAME_PIECE_SURNAME>  {0:1}
    +1 NSFX <NAME_PIECE_SUFFIX>  {0:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}

The name value is formed in the manner the name is normally spoken, with the given name and family name (surname) separated by slashes (/). (See <NAME_PERSONAL>.) Based on the dynamic nature or unknown compositions of naming conventions, it is difficult to provide more detailed name piece structure to handle every case. The NPFX, GIVN, NICK, SPFX, SURN, and NSFX tags are provided optionally for systems that cannot operate effectively with less structured information. For current future compatibility, all systems must construct their names based on the <NAME_PERSONAL> structure. Those using the optional name pieces should assume that few systems will process them, and most will not provide the name pieces. Future GEDCOM releases (6.0 and later) will likely apply a very different strategy to resolve this problem, possibly using a sophisticated parser and a name-knowledge database.

PLACE_STRUCTURE: =

  n PLAC <PLACE_VALUE>  {1:1}
    +1 FORM <PLACE_HIERARCHY>  {0:1}
    +1 <<SOURCE_CITATION>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}

SOURCE_CITATION: =

  [  
  n SOUR @<XREF:SOUR>@    /* pointer to source record */  {1:1}
    +1 PAGE <WHERE_WITHIN_SOURCE>  {0:1}
    +1 EVEN <EVENT_TYPE_CITED_FROM>  {0:1}
      +2 ROLE <ROLE_IN_EVENT>  {0:1}
    +1 DATA        {0:1}
      +2 DATE <ENTRY_RECORDING_DATE>  {0:1}
      +2 TEXT <TEXT_FROM_SOURCE>  {0:M}
        +3 [ CONC | CONT ] <TEXT_FROM_SOURCE>  {0:M}
    +1 QUAY <CERTAINTY_ASSESSMENT>  {0:1}
    +1 <<MULTIMEDIA_LINK>>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  |              /* Systems not using source records */
  n SOUR <SOURCE_DESCRIPTION>  {1:1}
    +1 [ CONC | CONT ] <SOURCE_DESCRIPTION>  {0:M}
    +1 TEXT <TEXT_FROM_SOURCE>  {0:M}
       +2 [CONC | CONT ] <TEXT_FROM_SOURCE>  {0:M}
    +1 <<NOTE_STRUCTURE>>  {0:M}
  ]

The data provided in the <<SOURCE_CITATION>> structure is source-related information specific to the data being cited. (See GEDCOM examples.) Systems that do not use SOURCE_RECORDS must use the second SOURce citation structure option. When systems which support SOURCE_RECORD structures encounter source citations which do not contain pointers to source records, that system will need to create a SOURCE_RECORD and store the <SOURCE_DESCRIPTION> information found in the non-structured source citation in either the title area of that SOURCE_RECORD, or if the title field is not large enough, place a "(See Notes)" text in the title area, and place the unstructured source description in the source record's note field.

The information intended to be placed in the citation structure includes:

A pointer to the SOURCE_RECORD, which contains a more general description of the source.
Information, such as a page number, on how to find the cited data within the source.
Actual text from the source that was used in making assertions, for example a date phrase as actually recorded or an applicable sentence from a letter, would be appropriate.
Data that allows an assessment of the relative value of one source over another for making the recorded assertions (primary or secondary source, etc.). Data needed for this assessment is how much time from the asserted fact and when the source event was recorded, what type of event was cited, and what was the role of this person in the cited event.
```
    -Date when the entry was recorded in source document, ".SOUR.DATA.DATE."
    -Event that initiated the recording, ".SOUR.EVEN."
    -Role of this person in the event, ".SOUR.EVEN.ROLE".
```

SOURCE_REPOSITORY_CITATION: =

  [
  n REPO @XREF:REPO@  {1:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}
    +1 CALN <SOURCE_CALL_NUMBER>  {0:M}
       +2 MEDI <SOURCE_MEDIA_TYPE>  {0:1}

This structure is used within a source record to point to a name and address record of the holder of the source document. Formal and informal repository name and addresses are stored in the REPOSITORY_RECORD. Informal repositories include owner's of an unpublished work or of a rare published source, or a keeper of personal collections. An example would be the owner of a family Bible containing unpublished family genealogical entries. More formal repositories, such as the Family History Library, should show a call number of the source at that repository. The call number of that source should be recorded using a subordinate CALN tag. Systems which do not structure a repository name and address interface should store the information about where the source record is stored in the <<NOTE_STRUCTURE>> of this structure.

SPOUSE_TO_FAMILY_LINK: =

  n FAMS @<XREF:FAM>@  {1:1}
    +1 <<NOTE_STRUCTURE>>  {0:M}

Primitive Elements of the Lineage-Linked Form

The field sizes show the minimum recommended field length within a database that is constrained to fixed length fields. The field sizes are in addition to the GEDCOM level and tag overhead. GEDCOM lines are limited to 255 characters. However, the CONCatenation or CONTinuation tags can be used to expand a field beyond this limit. CONT line implies that a new line should appear to preserve formatting. CONC implies concatenation to the previous line without a new line. This is used so that a text note or description can be processed (word wrapped) in a text window without fixed carriage returns. The CONT and CONC tags are being used to extend specified textual values.

ADDRESS_CITY: = {Size=1:60}
The name of the city used in the address. Isolated for sorting or indexing.

ADDRESS_COUNTRY: = {Size=1:60}
The name of the country that pertains to the associated address. Isolated by some systems for sorting or indexing. Used in most cases to facilitate automatic sorting of mail.

ADDRESS_LINE: = {Size=1:60}
Address information that, when combined with NAME and CONTinuation lines, meets requirements for sending communications through the mail.

ADDRESS_LINE1: = {Size=1:60}
The first line of the address used for indexing. This corresponds to the ADDRESS_LINE value of the ADDR line in the address structure.

ADDRESS_LINE2: = {Size=1:60}
The second line of the address used for indexing. This corresponds to the ADDRESS_LINE value of the first CONT line subordinate to the ADDR tag in the address structure.

ADDRESS_POSTAL_CODE: = {Size=1:10}
The ZIP or postal code used by the various localities in handling of mail. Isolated for sorting or indexing.

ADDRESS_STATE: = {Size=1:60}
The name of the state used in the address. Isolated for sorting or indexing.

ADOPTED_BY_WHICH_PARENT: = {Size=1:4}
[ HUSB | WIFE | BOTH ]
A code which shows which parent in the associated family record adopted this person.
Where:
HUSB =The HUSBand in the associated family adopted this person.
WIFE =The WIFE in the associated family adopted this person.
BOTH =Both HUSBand and WIFE adopted this person.

AGE_AT_EVENT: = {Size=1:12}
[ < | > | <NULL>]
[ YYy MMm DDDd | YYy | MMm | DDDd |
YYy MMm | YYy DDDd | MMm DDDd |
CHILD | INFANT | STILLBORN ]
]
Where :
> = greater than indicated age
< = less than indicated age
y = a label indicating years
m = a label indicating months
d = a label indicating days
YY = number of full years
MM = number of months
DDD = number of days
CHILD = age < 8 years
INFANT = age < 1 year
STILLBORN = died just prior, at, or near birth, 0 years

A number that indicates the age in years, months, and days that the principal was at the time of the associated event. Any labels must come after their corresponding number, for example; 4y 8m 10d.

ANCESTRAL_FILE_NUMBER: = {Size=1:12}
A unique permanent record number of an individual record contained in the Family History Department's Ancestral File.

APPROVED_SYSTEM_ID: = {Size=1:20}
A system identification name which was obtained through the GEDCOM registration process. This name must be unique from any other product. Spaces within the name must be substituted with a 0x5F (underscore _) so as to create one word.

ATTRIBUTE_TYPE: = {Size=1:4}
[ CAST | EDUC | NATI | OCCU | PROP | RELI | RESI | TITL ]
An attribute which may have caused name, addresses, phone numbers, family listings to be recorded. Its application is in helping to classify sources used for information.

AUTOMATED_RECORD_ID: = {Size=1:12}
A unique record identification number assigned to the record by the source system. This number is intended to serve as a more sure means of identification of a record between two interfacing systems.

CASTE_NAME: = {Size=1:90}
A name assigned to a particular group that this person was associated with, such as a particular racial group, religious group, or a group with an inherited status.

CAUSE_OF_EVENT: = {Size=1:90}
Used in special cases to record the reasons which precipitated an event. Normally this will be used subordinate to a death event to show cause of death, such as might be listed on a death certificate.

CERTAINTY_ASSESSMENT: = {Size=1:1}
[ 0 | 1 | 2 | 3 ]
The QUAY tag's value conveys the submitter's quantitative evaluation of the credibility of a piece of information, based upon its supporting evidence. Some systems use this feature to rank multiple conflicting opinions for display of most likely information first. It is not intended to eliminate the receiver's need to evaluate the evidence for themselves.

0 =Unreliable evidence or estimated data
1 =Questionable reliability of evidence (interviews, census, oral genealogies, or potential for bias for example, an autobiography)
2 =Secondary evidence, data officially recorded sometime after event
3 =Direct and primary evidence used, or by dominance of the evidence

CHANGE_DATE: = {Size=10:11}
<DATE_EXACT>
The date that this data was changed.

CHARACTER_SET: = {Size=1:8}
[ ANSEL | UNICODE | ASCII ]
A code value that represents the character set to be used to interpret this data. The default character set is ANSEL, which includes ASCII as a subset. UNICODE is not widely supported by most operating systems; therefore, GEDCOM produced using the UNICODE character set will be limited in acceptance for some time. See Chapter 3. ASCII contains the character set from 0x0 to 0xFF.

Note:The IBMPC character set is not allowed. This character set cannot be interpreted properly without knowing which code page the sender was using.

COPYRIGHT_GEDCOM_FILE: = {Size=1:90}
A copyright statement needed to protect the copyrights of the submitter of this GEDCOM file.

COPYRIGHT_SOURCE_DATA: = {Size=1:90}
A copyright statement required by the owner of data from which this information was down- loaded. For example, when a GEDCOM down-load is requested from the Ancestral File, this would be the copyright statement to indicate that the data came from a copyrighted source.

COUNT_OF_CHILDREN: = {Size=1:3}
The known number of children of this individual from all marriages or, if subordinate to a family record, the reported number of children known to belong to this family, regardless of whether the associated children are represented in the corresponding structure. This is not necessarily the count of children listed in a family structure.

COUNT_OF_MARRIAGES: = {Size=1:3}
The number of different families that this person was known to have been a member of as a spouse or parent, regardless of whether the associated families are represented in the GEDCOM file.

DATE: = {Size=4:35}
[ <DATE_CALENDAR_ESCAPE> | <NULL>]
<DATE_CALENDAR>

DATE_APPROXIMATED: = {Size=4:35}
[
ABT <DATE> |
CAL <DATE> |
EST <DATE>
]
Where :
ABT =About, meaning the date is not exact.
CAL =Calculated mathematically, for example, from an event date and age.
EST =Estimated based on an algorithm using some other event date.

DATE_CALENDAR: = {Size=4:35}
[ <DATE_GREG> | <DATE_JULN> | <DATE_HEBR> | <DATE_FREN> |
<DATE_FUTURE> ]

The selection is based on the <DATE_CALENDAR_ESCAPE> that precedes the <DATE_CALENDAR> value immediately to the left. If <DATE_CALENDAR_ESCAPE> doesn't appear at this point, then @#DGREGORIAN@ is assumed. No future calendar types will use words (e.g., month names) from this list: FROM, TO, BEF, AFT, BET, AND, ABT, EST, CAL, or INT. When only a day and month appears as a DATE value it is considered a date phrase and not a valid date form.

  Date Escape    Syntax Selected
  -----------    -------------
  @#DGREGORIAN@  <DATE_GREG>
  @#DJULIAN@     <DATE_JULN>
  @#DHEBREW@     <DATE_HEBR>
  @#DFRENCH R@   <DATE_FREN>
  @#DROMAN@      for future definition
  @#DUNKNOWN@    calendar not known

DATE_CALENDAR_ESCAPE: = {Size=4:15}
[ @#DHEBREW@ | @#DROMAN@ | @#DFRENCH R@ | @#DGREGORIAN@ |
@#DJULIAN@ | @#DUNKNOWN@ ]
The date escape determines the date interpretation by signifying which <DATE_CALENDAR> to use. The default calendar is the Gregorian calendar.

DATE_EXACT: = {Size=10:11}
<DAY> <MONTH> <YEAR_GREG>

DATE_FREN: = {Size=4:35}
[ <YEAR> | <MONTH_FREN> <YEAR> | <DAY> <MONTH_FREN> <YEAR> ]
See <MONTH_FREN>

DATE_GREG: = {Size=4:35}
[ <YEAR_GREG> | <MONTH> <YEAR_GREG> | <DAY> <MONTH> <YEAR_GREG> ]
See <YEAR_GREG>.

DATE_HEBR: = {Size=4:35}
[ <YEAR> | <MONTH_HEBR> <YEAR> | <DAY> <MONTH_HEBR> <YEAR> ]
See <MONTH_HEBR>.

DATE_JULN: = {Size=4:35}
[ <YEAR> | <MONTH> <YEAR> | <DAY> <MONTH> <YEAR> ]

DATE_LDS_ORD: = {Size=4:35}
<DATE_VALUE>
LDS ordinance dates use only the Gregorian date and most often use the form of day, month, and year. Only in rare instances is there a partial date. The temple tag and code should always accompany temple ordinance dates. Sometimes the LDS_(ordinance)_DATE_STATUS is used to indicate that an ordinance date and temple code is not required, such as when BIC is used. (See LDS_(ordinance)_DATE_STATUS definitions.)

DATE_PERIOD: = {Size=7:35}
[
FROM <DATE> |
TO <DATE> |
FROM <DATE> TO <DATE>
]
Where:DATE>
FROM =Indicates the beginning of a happening or state.
TO =Indicates the ending of a happening or state.

Examples:
FROM 1904 to 1915
=The state of some attribute existed from 1904 to 1915 inclusive.
FROM 1904
=The state of the attribute began in 1904 but the end date is unknown.
TO 1915
=The state ended in 1915 but the begin date is unknown.

DATE_PHRASE: = {Size=1:35}
(<TEXT>)
Any statement offered as a date when the year is not recognizable to a date parser, but which gives information about when an event occurred. The date phrase is enclosed in matching parentheses.

DATE_RANGE: = {Size=8:35}
[
BEF <DATE> |
AFT <DATE> |
BET <DATE> AND <DATE>
]

Where :
AFT =Event happened after the given date.
BEF =Event happened before the given date.
BET =Event happened some time between date 1 AND date 2. For example, bet 1904 and 1915 indicates that the event state (perhaps a single day) existed somewhere between 1904 and 1915 inclusive.

The date range differs from the date period in that the date range is an estimate that an event happened on a single date somewhere in the date range specified.

The following are equivalent and interchangeable:

  Short form  Long Form
  ----------  ---------
  1852        BET 1 JAN 1852 AND 31 DEC 1852
  1852        BET 1 JAN 1852 AND DEC 1852
  1852        BET JAN 1852 AND 31 DEC 1852
  1852        BET JAN 1852 AND DEC 1852
  JAN 1920    BET 1 JAN 1920 AND 31 JAN 1920

DATE_VALUE: = {Size=1:35}
[
<DATE> |
<DATE_PERIOD> |
<DATE_RANGE>
<DATE_APPROXIMATED> |
INT <DATE> (<DATE_PHRASE>) |
(<DATE_PHRASE>)
]

The DATE_VALUE represents the date of an activity, attribute, or event where:
INT =Interpreted from knowledge about the associated date phrase included in parentheses.

An acceptable alternative to the date phrase choice is to use one of the other choices such as <DATE_APPROXIMATED> choice as the DATE line value and then include the <DATE_PHRASE> as a NOTE value subordinate to the DATE line.

The date value can take on the date form of just a date, an approximated date, between a date and another date, and from one date to another date. The preferred form of showing date imprecision, is to show, for example, MAY 1890 rather than ABT 12 MAY 1890. This is because limits have not been assigned to the precision of the prefixes such as ABT or EST.

DAY: = {Size=1:2}
dd
Day of the month, where dd is a numeric digit whose value is within the valid range of the days for the associated calendar month.

DESCRIPTIVE_TITLE: = {Size=1:248}
The title of a work, record, item, or object.

DIGIT: = {Size=1:1}
A single digit (0-9).

ENCODED_MULTIMEDIA_LINE: = {Size=1:87}
A line from a multimedia object which has been ENCODED. Each 54 characters of the multimedia object is encoded and stored in a 72 byte value. The encoding algorithm is used to convert binary objects into legal ASCII values which can be transmitted. See the encoding and decoding algorithms that are defined in Appendix E.

ENTRY_RECORDING_DATE: = {Size=1:90}
<DATE_VALUE>
The date that this event data was entered into the original source document.

EVENT_ATTRIBUTE_TYPE: = {Size=1:15}
[ <EVENT_TYPE_INDIVIDUAL> |
<EVENT_TYPE_FAMILY> |
<ATTRIBUTE_TYPE> ]
A code that classifies the principal event or happening that caused the source record entry to be created. If the event or attribute doesn't translate to one of these tag codes, then a user supplied code is expected, but will be considered as the generic tag EVEN for source certainty evaluation.

EVENT_DESCRIPTOR: = {Size=1:90}
A descriptor that should be used whenever the EVEN tag is used to define the event being cited. For example, if the event was a purchase of a residence, the EVEN tag would be followed by a subordinate TYPE tag with the value "Purchased Residence." Using this descriptor with any of the other defined event tags basically classifies the basic definition of the associated tag but does not change its basic process. The form of using the TYPE tag with defined event tags has not been used by very many products. The MARR tag could be subordinated with a TYPE tag and EVENT_DESCRIPTOR value of Common Law. Other possible descriptor values might include "Childbirth%unmarried," "Common Law," or "Tribal Custom," for example. The event descriptor should use the same word or phrase and in the same language, when possible, as was used by the recorder of the event. Systems that display data from the GEDCOM form should be able to display the descriptor value in their screen or printed output.

EVENT_TYPE_CITED_FROM: = {SIZE=1:15}
[ <EVENT_ATTRIBUTE_TYPE> ]
A code that indicates the type of event which was responsible for the source entry being recorded. For example, if the entry was created to record a birth of a child, then the type would be BIRT regardless of the assertions made from that record, such as the mother's name or mother's birth date. This will allow a prioritized best view choice and a determination of the certainty associated with the source used in asserting the cited fact.

EVENT_TYPE_FAMILY: = {Size=3:4}
[ ANUL | CENS | DIV | DIVF | ENGA | MARR |
MARB | MARC | MARL | MARS | EVEN ]

A code used to indicate the type of family event. The definition is the same as the corresponding event tag defined in Appendix A.

EVENT_TYPE_INDIVIDUAL: = {Size=3:4}
[ ADOP | BIRT | BAPM | BARM | BASM |
BLES | BURI | CENS | CHR | CHRA |
CONF | CREM | DEAT | EMIG | FCOM |
GRAD | IMMI | NATU | ORDN |
RETI | PROB | WILL | EVEN ]

A code used to indicate the type of family event. The definition is the same as the corresponding event tag defined in Appendix A.

EVENTS_RECORDED: = {Size=1:90}
[<EVENT_ATTRIBUTE_TYPE> |
<EVENTS_RECORDED>, <EVENT_ATTRIBUTE_TYPE>]
An enumeration of the different kinds of events that were recorded in a particular source. Each enumeration is separated by a comma. Such as a parish register of births, deaths, and marriages would be BIRT, DEAT, MARR.

FILE_NAME: = {Size=1:90}
The name of the GEDCOM transmission file. If the file name includes a file extension it must be shown in the form (filename.ext).

GEDCOM_CONTENT_DESCRIPTION: = {Size=1:248}
A note that a user enters to describe the contents of the lineage-linked file in terms of "ancestors or descendants of" so that the person receiving the data knows what genealogical information the transmission contains.

GEDCOM_FORM: = {Size=14:20}
[ LINEAGE-LINKED ]
The GEDCOM form used to construct this transmission. There maybe other forms used such as CommSoft's "EVENT_LINEAGE_LINKED" but these specifications define only the LINEAGE-LINKED Form. Systems will use this value to specify GEDCOM compatible with these specifications.

GENERATIONS_OF_ANCESTORS: = {Size=1:4}
The number of generations of ancestors included in this transmission. This value is usually provided when FamilySearch programs build a GEDCOM file for a patron requesting a download of ancestors.

GENERATIONS_OF_DESCENDANTS: = {Size=1:4}
The number of generations of descendants included in this transmission. This value is usually provided when FamilySearch programs build a GEDCOM file for a patron requesting a download of descendants.

LANGUAGE_ID: = {Size=1:15}
A table of valid latin language identification codes.
[Afrikaans | Albanian | Anglo-Saxon | Catalan | Catalan_Spn | Czech | Danish | Dutch | English | Esperanto | Estonian | Faroese | Finnish | French | German | Hawaiian | Hungarian | Icelandic | Indonesian | Italian | Latvian | Lithuanian | Navaho | Norwegian | Polish | Portuguese | Romanian | Serbo_Croa | Slovak | Slovene | Spanish | Swedish | Turkish | Wendic ]

Other languages not supported until UNICODE
[Amharic | Arabic | Armenian | Assamese | Belorusian | Bengali | Braj | Bulgarian | Burmese | Cantonese | Church-Slavic | Dogri | Georgian | Greek | Gujarati | Hebrew | Hindi | Japanese | Kannada | Khmer | Konkani | Korean | Lahnda | Lao | Macedonian | Maithili | Malayalam | Mandrin | Manipuri | Marathi | Mewari | Nepali | Oriya | Pahari | Pali | Panjabi | Persian | Prakrit | Pusto | Rajasthani | Russian | Sanskrit | Serb | Tagalog | Tamil | Telugu | Thai | Tibetan | Ukrainian | Urdu | Vietnamese | Yiddish ]

LANGUAGE_OF_TEXT: = {Size=1:15}
[ <LANGUAGE_ID> ]
The human language in which the data in the transmission is normally read or written. It is used primarily by programs to select language-specific sorting sequences and phonetic name matching algorithms.

LANGUAGE_PREFERENCE: = {Size=1:90}
[ <LANGUAGE_ID> ]

The language in which a person prefers to communicate. Multiple language preference is shown by using multiple occurrences in order of priority.

LDS_BAPTISM_DATE_STATUS: = {Size=5:10}
[ CHILD | CLEARED | COMPLETED | INFANT | PRE-1970 |
QUALIFIED | STILLBORN | SUBMITTED | UNCLEARED ]

A code indicating the status of an LDS baptism and confirmation date where:

CHILD =Died before eight years old.
CLEARED = Baptism has been cleared for temple ordinance.
COMPLETED =Completed but the date is not known.
INFANT =Died before less than one year old, baptism not required.
QUALIFIED =Ordinance request qualified by authorized criteria.
PRE-1970 =Ordinance is likely completed, another ordinance for this person was converted from temple records of work completed before 1970, therefore this ordinance is assumed to be complete until all records are converted.
STILLBORN =Stillborn, baptism not required.
SUBMITTED =Ordinance was previously submitted.
UNCLEARED =Data for clearing ordinance request was insufficient.

LDS_CHILD_SEALING_DATE_STATUS: = {Size=5:10}
[ BIC | CLEARED | COMPLETED | DNS | PRE-1970 |
QUALIFIED | STILLBORN | SUBMITTED | UNCLEARED ]

BIC =Born in the covenant receiving blessing of child to parent sealing.
CLEARED = Sealing has been cleared for temple ordinance.
COMPLETED =Completed but the date is not known.
DNS =This record is not being submitted for this temple ordinances.
QUALIFIED =Ordinance request qualified by authorized criteria.
PRE-1970 = (See pre-1970 under LDS_BAPTISM_DATE_STATUS.)
STILLBORN =Stillborn, not required.
SUBMITTED =Ordinance was previously submitted.
UNCLEARED =Data for clearing ordinance request was insufficient.

LDS_ENDOWMENT_DATE_STATUS: = {Size=5:10}
[ CHILD | CLEARED | COMPLETED | INFANT | PRE-1970 |
QUALIFIED | STILLBORN | SUBMITTED | UNCLEARED ]

A code indicating the status of an LDS endowment ordinance where:

CHILD =Died before eight years old.
CLEARED = Endowment has been cleared for temple ordinance.
COMPLETED =Completed but the date is not known.
INFANT =Died before less than one year old, baptism not required.
QUALIFIED =Ordinance request qualified by authorized criteria.
PRE-1970 = (See pre-1970 under LDS_BAPTISM_DATE_STATUS.)
STILLBORN =Stillborn, ordinance not required.
SUBMITTED =Ordinance was previously submitted.
UNCLEARED =Data for clearing ordinance request was insufficient.

LDS_SPOUSE_SEALING_DATE_STATUS: = {Size=3:10}
[ CANCELED | CLEARED | COMPLETED | DNS | DNS/CAN | PRE-1970 |
QUALIFIED | SUBMITTED | UNCLEARED ]

CANCELED =Canceled and considered invalid.
CLEARED = Sealing has been cleared for temple ordinance.
COMPLETED =Completed but the date is not known.
DNS =This record is not being submitted for this temple ordinances.
DNS/CAN =This record is not being submitted for this temple ordinances.
QUALIFIED =Ordinance request qualified by authorized criteria.
PRE-1970 = (See pre-1970 under LDS_BAPTISM_DATE_STATUS.)
SUBMITTED =Ordinance was previously submitted.
UNCLEARED =Data for clearing ordinance request was insufficient.

MONTH: = {Size=3}
[ JAN | FEB | MAR | APR | MAY | JUN |
JUL | AUG | SEP | OCT | NOV | DEC ]
Where :
JAN = January
FEB = February
MAR = March
APR = April
MAY = May
JUN = June
JUL = July
AUG = August
SEP = September
OCT = October
NOV = November
DEC = December

MONTH_FREN: = {Size=4}
[ VEND | BRUM | FRIM | NIVO | PLUV | VENT | GERM |
FLOR | PRAI | MESS | THER | FRUC | COMP ]

Where:
VEND = VENDEMIAIRE
BRUM = BRUMAIRE
FRIM = FRIMAIRE
NIVO = NIVOSE
PLUV = PLUVIOSE
VENT = VENTOSE
GERM = GERMINAL
FLOR = FLOREAL
PRAI = PRAIRIAL
MESS = MESSIDOR
THER = THERMIDOR
FRUC = FRUCTIDOR
COMP = JOUR_COMPLEMENTAIRS

MONTH_HEBR: = {Size=3}
[ TSH | CSH | KSL | TVT | SHV | ADR | ADS |
NSN | IYR | SVN | TMZ | AAV | ELL ]

Where:
TSH = Tishri
CSH = Cheshvan
KSL = Kislev
TVT = Tevet
SHV = Shevat
ADR = Adar
ADS = Adar Sheni
NSN = Nisan
IYR = Iyar
SVN = Sivan
TMZ = Tammuz
AAV = Av
ELL = Elul

MULTIMEDIA_FILE_REFERENCE: = {Size=1:30}
A complete local or remote file reference to the auxiliary data to be linked to the GEDCOM context. Remote reference would include a network address where the multimedia data may be obtained.

MULTIMEDIA_FORMAT: = {Size=3:4}
[ bmp | gif | jpeg | ole | pcx | tiff | wav ]
Indicates the format of the multimedia data associated with the specific GEDCOM context. This allows processors to determine whether they can process the data object. Any linked files should contain the data required, in the indicated format, to process the file data. Industry standards will emerge in this area and GEDCOM will then narrow its scope.

NAME_OF_BUSINESS: = {Size=1:90}
Name of the business, corporation, or person that produced or commissioned the product.

NAME_OF_FAMILY_FILE: = {Size=1:120}
Name under which family names for ordinances are stored in the temple's family file.

NAME_OF_PRODUCT: = {Size=1:90}
The name of the software product that produced this transmission.

NAME_OF_REPOSITORY: = {Size=1:90}
The official name of the archive in which the stated source material is stored.

NAME_OF_SOURCE_DATA: = {Size=1:90}
The name of the electronic data source that was used to obtain the data in this transmission. For example, the data may have been obtained from a CD-ROM disc that was named "U.S. 1880 CENSUS CD-ROM vol. 13."

NAME_PERSONAL: = {Size=1:120}
[
<TEXT> |
/<TEXT>/ |
<TEXT> /<TEXT>/ |
/<TEXT>/ <TEXT> |
<TEXT> /<TEXT>/ <TEXT>
]
The surname of an individual, if known, is enclosed between two slash (/) characters. The order of the name parts should be the order that the person would, by custom of their culture, have used when giving it to a recorder. Early versions of Personal Ancestral File ^® and other products did not use the trailing slash when the surname was the last element of the name. If part of name is illegible, that part is indicated by an ellipsis (...). Capitalize the name of a person or place in the conventional manner%capitalize the first letter of each part and lowercase the other letters, unless conventional usage is otherwise. For example: McMurray.

Examples :
William Lee (given name only or surname not known)
/Parry/ (surname only)
William Lee /Parry/
William Lee /Mac Parry/ (both parts (Mac and Parry) are surname parts
William /Lee/ Parry (surname imbedded in the name string)
William Lee /Pa.../

NAME_PIECE: = {Size=1:90}
The piece of the name pertaining to the name part of interest. The surname part, the given name part, the name prefix part, or the name suffix part.

NAME_PIECE_GIVEN: = {Size=1:120}
[ <NAME_PIECE> | <NAME_PIECE_GIVEN>, <NAME_PIECE> ]
Given name or earned name. Different given names are separated by a comma.

NAME_PIECE_NICKNAME: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_NICKNAME>, <NAME_PIECE> ]
A descriptive or familiar name used in connection with one's proper name.

NAME_PIECE_PREFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_PREFIX>, <NAME_PIECE> ]
Non indexing name piece that appears preceding the given name and surname parts. Different name prefix parts are separated by a comma.
For example :
Lt. Cmndr. Joseph /Allen/ jr.
In this example Lt. Cmndr. is considered as the name prefix portion.

NAME_PIECE_SUFFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_SUFFIX>, <NAME_PIECE> ]
Non-indexing name piece that appears after the given name and surname parts. Different name suffix parts are separated by a comma.
For example :
Lt. Cmndr. Joseph /Allen/ jr.
In this example jr. is considered as the name suffix portion.

NAME_PIECE_SURNAME: = {Size=1:120}
[ <NAME_PIECE> | <NAME_PIECE_SURNAME>, <NAME_PIECE> ]
Surname or family name. Different surnames are separated by a comma.

NAME_PIECE_SURNAME_PREFIX: = {Size=1:30}
[ <NAME_PIECE> | <NAME_PIECE_SURNAME_PREFIX>, <NAME_PIECE> ]
Surname prefix or article used in a family name. Different surname articles are separated by a comma, for example in the name "de la Cruz", this value would be "de, la".

NATIONAL_ID_NUMBER: = {Size=1:30}
A nationally-controlled number assigned to an individual. Commonly known national numbers should be assigned their own tag, such as SSN for U.S. Social Security Number. The use of the IDNO tag requires a subordinate TYPE tag to identify what kind of number is being stored.
For example :

  n IDNO 43-456-1899
    +1 TYPE Canadian Health Registration

NATIONAL_OR_TRIBAL_ORIGIN: = {Size=1:120}
The person's division of national origin or other folk, house, kindred, lineage, or tribal interest. Examples: Irish, Swede, Egyptian Coptic, Sioux Dakota Rosebud, Apache Chiricawa, Navajo Bitter Water, Eastern Cherokee Taliwa Wolf, and so forth.

NEW_TAG: = {Size=1:15}
A user-defined tag that is contained in the GEDCOM current transmission. This tag must begin with an underscore (_) and should only be interpreted in the context of the sending system.

NOBILITY_TYPE_TITLE: = {Size=1:120}
The title given to or used by a person, especially of royalty or other noble class within a locality.

NULL: = {Size=0:0}
A convention that indicates the absence of any 8-bit ASCII character in the value including the null character (0x00) which is prohibited.

NUMBER: =
[<DIGIT> | <NUMBER>+<DIGIT>]

OCCUPATION: = {Size=1:90}
The kind of activity that an individual does for a job, profession, or principal activity.

ORDINANCE_PROCESS_FLAG: = {Size=2:3}
[ yes | no ]
A flag that indicates whether submission should be processed for clearing temple ordinances.

PEDIGREE_LINKAGE_TYPE: = {Size=5:7}
[ adopted | birth | foster | sealing ]
A code used to indicate the child to family relationship for pedigree navigation purposes.
Where:
adopted = indicates adoptive parents.
birth = indicates birth parents.
foster = indicates child was included in a foster or guardian family.
sealing = indicates child was sealed to parents other than birth parents.

PERMANENT_RECORD_FILE_NUMBER: = {Size=1:90}
<REGISTERED_RESOURCE_IDENTIFIER>:<RECORD_IDENTIFIER>
The record number that uniquely identifies this record within a registered network resource. The number will be usable as a cross-reference pointer. The use of the colon (:) is reserved to indicate the separation of the "registered resource identifier" (which precedes the colon) and the unique "record identifier" within that resource (which follows the colon). If the colon is used, implementations that check pointers should not expect to find a matching cross-reference identifier in the transmission but would find it in the indicated database within a network. Making resource files available to a public network is a future implementation.

PHONE_NUMBER: = {Size=1:25}
A phone number.

PHYSICAL_DESCRIPTION: = {Size=1:248}
An unstructured list of the attributes that describe the physical characteristics of a person, place, or object. Commas separate each attribute.
Example:

  1 DSCR Hair Brown, Eyes Brown, Height 5 ft 8 in
    2 DATE 23 JUL 1935

PLACE_HIERARCHY: = {Size=1:120}
This shows the jurisdictional entities that are named in a sequence from the lowest to the highest jurisdiction. The jurisdictions are separated by commas, and any jurisdiction's name that is missing is still accounted for by a comma. When a PLAC.FORM structure is included in the HEADER of a GEDCOM transmission, it implies that all place names follow this jurisdictional format and each jurisdiction is accounted for by a comma, whether the name is known or not. When the PLAC.FORM is subordinate to an event, it temporarily overrides the implications made by the PLAC.FORM structure stated in the HEADER. This usage is not common and, therefore, not encouraged. It should only be used when a system has over-structured its place-names.

PLACE_LIVING_ORDINANCE: = {Size=1:120}
<PLACE_VALUE>
The locality of the place where a living LDS ordinance took place. Usually only a living LDS baptism place is recorded in this field.

PLACE_VALUE: = {Size=1:120}
[
<TEXT> |
<TEXT>, <PLACE_VALUE>
]
The jurisdictional name of the place where the event took place. Jurisdictions are separated by commas, for example, "Cove, Cache, Utah, USA." If the actual jurisdictional names of these places have been identified, they can be shown using a PLAC.FORM structure either in the HEADER or in the event structure. (See <PLACE_HIERARCHY>.)

POSSESSIONS: = {Size=1:248}
A list of possessions (real estate or other property) belonging to this individual.
PUBLICATION_DATE: = {Size=10:11}
<DATE_EXACT>
The date this source was published or created.

RECEIVING_SYSTEM_NAME: = {Size=1:20}
The name of the system expected to process the GEDCOM-compatible transmission. The registered RECEIVING_SYSTEM_NAME for all GEDCOM submissions to the Family History Department must be one of the following names:

"ANSTFILE" when submitting to Ancestral File.
"TempleReady" when submitting for temple ordinance clearance.

RECORD_IDENTIFIER: = {Size=1:18}
An identification number assigned to each record within a specific database. The database to which the RECORD_IDENTIFIER pertains is indicated by the REGISTERED_RESOURCE_NUMBER which precedes the colon (:). If the RECORD_IDENTIFIER is not preceded by a colon, it is a reference to a record within the current GEDCOM transmission.

RECORD_TYPE: = {Size=3:4}
[ FAM | INDI | NOTE | OBJE | REPO | SOUR | SUBM | SUBN ]
An indicator of the record type being pointed to or used. For example if in an ASSOciation, an INDIvidual record were to be ASSOciated with a FAM record then:

      0 INDI
        1 ASSO @F1@
          2 TYPE FAM   /* ASSOCIATION is with a FAM record.
          2 RELA Witness at marriage

REGISTERED_RESOURCE_IDENTIFIER: = {Size=1:25}
This is an identifier assigned to a resource database that is available through access to a network. This is for future GEDCOM releases.

RELATION_IS_DESCRIPTOR: = {Size=1:25}
A word or phrase that states object 1's relation is object 2. For example you would read the following as "Joe Jacob's great grandson is the submitter pointed to by the @XREF:SUBM@":

  0 INDI
    1 NAME Joe /Jacob/
    1 ASSO @<XREF:SUBM>@
      2 TYPE great grandson

RELIGIOUS_AFFILIATION: = {Size=1:90}
A name of the religion with which this person, event, or record was affiliated.

RESPONSIBLE_AGENCY: = {Size=1:120}
The organization, institution, corporation, person, or other entity that has authority or control interests in the associated context. For example, an employer of a person of an associated occupation, or a church that administered rites or events, or an organization responsible for creating and/or archiving records.

RESTRICTION_NOTICE: = {Size=6:7}
[ locked | privacy ]
The restriction notice is defined for Ancestral File usage. Ancestral File download GEDCOM files may contain this data.
Where :
locked =Some records in Ancestral File have been satisfactorily proven by evidence, but because of source conflicts or incorrect traditions, there are repeated attempts to change this record. By arrangement, the Ancestral File Custodian can lock a record so that it cannot be changed without an agreement from the person assigned as the steward of such a record. The assigned steward is either the submitter listed for the record or Family History Support when no submitter is listed.

privacy =Information concerning this record is not present due to rights of or an approved request for privacy.

ROLE_DESCRIPTOR: = {Size=1:25}
A word or phrase that identifies a person's role in an event being described. This should be the same word or phrase, and in the same language, that the recorder used to define the role in the actual record.

ROLE_IN_EVENT: = {Size=1:15}
[ CHIL | HUSB | WIFE | MOTH | FATH | SPOU | ( <ROLE_DESCRIPTOR> ) ]
Indicates what role this person played in the event that is being cited in this context. For example, if you cite a child's birth record as the source of the mother's name, the value for this field is "MOTH." If you describe the groom of a marriage, the role is "HUSB." If the role is something different than one of the six relationship role tags listed above then enclose the role name within matching parentheses.

SCHOLASTIC_ACHIEVEMENT: = {Size=1:248}
A description of a scholastic or educational achievement or pursuit.

SEX_VALUE: = {Size=1:7}
A code that indicates the sex of the individual:
M = Male
F = Female

SOCIAL_SECURITY_NUMBER: = {Size=9:11}
A number assigned to a person in the United States for identification purposes.

SOURCE_CALL_NUMBER: = {Size=1:120}
An identification or reference description used to file and retrieve items from the holdings of a repository.
SOURCE_DESCRIPTION: = {Size=1:248}
A free form text block used to describe the source from which information was obtained. This text block is used by those systems which cannot use a pointer to a source record. It must contain a descriptive title, who created the work, where and when it was created, and where is source data stored. The developer should encourage users to use an appropriate style for forming this free form bibliographic reference. Developers are encouraged to support the SOURCE_RECORD method of reporting bibliographic reference descriptions.

SOURCE_DESCRIPTIVE_TITLE: = {Size=1:248}
The title of the work, record, or item and, when appropriate, the title of the larger work or series of which it is a part.

For a published work, a book for example, might have a title plus the title of the series of which the book is a part. A magazine article would have a title plus the title of the magazine that published the article.

For An unpublished work, such as:

A letter might include the date, the sender, and the receiver.
A transaction between a buyer and seller might have their names and the transaction date.
A family Bible containing genealogical information might have past and present owners and a physical description of the book.
A personal interview would cite the informant and interviewer.

SOURCE_FILED_BY_ENTRY: = {Size= 1:60}
This entry is to provide a short title used for sorting, filing, and retrieving source records.

SOURCE_JURISDICTION_PLACE: = {Size=1:120}
<PLACE_VALUE>
The name of the lowest jurisdiction that encompasses all lower-level places named in this source. For example, "Oneida, Idaho" would be used as a source jurisdiction place for events occurring in the various towns within Oneida County. "Idaho" would be the source jurisdiction place if the events recorded took place in other counties as well as Oneida County.

SOURCE_MEDIA_TYPE: = {Size=1:15}
[ audio | book | card | electronic | fiche | film | magazine |
manuscript | map | newspaper | photo | tombstone | video ]
A code, selected from one of the media classifications choices above, that indicates the type of material in which the referenced source is stored.

SOURCE_ORIGINATOR: = {Size=1:248}
The person, agency, or entity who created the record. For a published work, this could be the author, compiler, transcriber, abstractor, or editor. For an unpublished source, this may be an individual, a government agency, church organization, or private organization, etc.

SOURCE_PUBLICATION_FACTS: = {Size=248}
When and where the record was created. For published works, this includes information such as the city of publication, name of the publisher, and year of publication.

For an unpublished work, it includes the date the record was created and the place where it was created. For example, the county and state of residence of a person making a declaration for a pension or the city and state of residence of the writer of a letter.
SUBMITTER_NAME: = {Size=1:60}
The name of the submitter formatted for display and address generation.

SUBMITTER_REGISTERED_RFN: = {Size=1:30}
A registered number of a submitter of Ancestral File data. This number is used in subsequent submissions or inquiries by the submitter for identification purposes.

SUBMITTER_TEXT: = {Size=1:248}
Comments or opinions from the submitter.

TEMPLE_CODE: = {Size=4:5}
An abbreviation of the temple in which LDS temple ordinances were performed. (See Appendix C)

TEXT: = {Size=1:248}
A string composed of any valid character from the GEDCOM character set.
TEXT_FROM_SOURCE: = {Size=1:248}
<TEXT>
A verbatim copy of any description contained within the source. This indicates notes or text that are actually contained in the source document, not the submitter's opinion about the source. This should be, from the evidence point of view, "what the original record keeper said" as opposed tothe researcher's interpretation. The word TEXT, in this case, means from the text which appeared in the source record including labels.

TIME_VALUE: = {Size=1:12}
[ hh:mm:ss.fs ]
The time of a specific event, usually a computer-timed event, where:
hh =hours on a 24-hour clock
mm =minutes
ss =seconds (optional)
fs =decimal fraction of a second (optional)

TRANSMISSION_DATE: = {Size=10:11}
<DATE_EXACT>
The date that this transmission was created.

USER_REFERENCE_NUMBER: = {Size=1:20}
A user-defined number or text that the submitter uses to identify this record. For instance, it may be a record number within the submitter's automated or manual system, or it may be a page and position number on a pedigree chart.

USER_REFERENCE_TYPE: = {Size=1:40}
A user-defined definition of the USER_REFERENCE_NUMBER.

VERSION_NUMBER: = {Size=1:15}
An identifier that represents the version level assigned to the associated product. It is defined and changed by the creators of the product.

WHERE_WITHIN_SOURCE: = {Size=1:248}
Specific location with in the information referenced. For a published work, this could include the volume of a multi-volume work and the page number(s). For a periodical, it could include volume, issue, and page numbers. For a newspaper, it could include a column number and page number. For an unpublished source, this could be a sheet number, page number, frame number, etc. A census record might have a line number or dwelling and family numbers in addition to the page number.

XREF: = {Size=1:22}
Either a pointer or an unique cross-reference identifier. If this element appears before the tag in a GEDCOM line, then it is a cross-reference identifier. If it appears after the tag in a GEDCOM line, then it is a pointer. The method of delimiting a pointer or cross-reference identifier is to enclose the pointer or cross-reference identifier within at signs (@), for example, @I123@. A XREF may not begin with a number sign (#). This is to avoid confusion with an escape sequence prefix (@#). The use of a colon (:) in the XREF is reserved for creating future network cross-references and the use of an exclamation (!) is reserved for intra-record pointers. Uniqueness of the cross-reference identifier is required within the transmission file.

XREF:FAM: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a fam_record.

XREF:INDI: = {Size=1:22}
A pointer to, or a cross-reference identifier of, an individual record.

XREF:NOTE: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a note record.

XREF:OBJE: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a multimedia object.

XREF:REPO: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a repository record.

XREF:SOUR: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a SOURce record.

XREF:SUBM: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a SUBMitter record.

XREF:SUBN: = {Size=1:22}
A pointer to, or a cross-reference identifier of, a SUBmissioN record.

YEAR: = {Size=3:4}
A numeric representation of the calendar year in which an event occurred.

YEAR_GREG: = {Size=3:7}
[ <NUMBER> | <NUMBER>/<DIGIT><DIGIT> ]
The slash "/" <DIGIT><DIGIT> a year modifier which shows the possible date alternatives for pre-1752 date brought about by a changing the beginning of the year from MAR to JAN in the English calendar change of 1752, for example, 15 APR 1699/00. A (B.C.) appended to the <YEAR> indicates a date before the birth of Christ.

Compatibility with Other GEDCOM Versions

GEDCOM compatibility is measured on a per tag basis, and depends on how similar the data models are for the two different communicating products and on how consistently they understood and complied with the GEDCOM Standard. A few inconsistencies in the use of specific tags also crept into different releases of the standard itself, due to lack of foresight or inadvertent errors. Within these limits, GEDCOM compatible products can exchange data based on GEDCOM 2.0, 3.0, 4.0, and 5.x. Of course, newer GEDCOM releases significantly extend the data model for which the newer tag contexts will not be supported by older products. Some products have introduced their own variations into their GEDCOM form. This will likely provide unique problems with compatibility.

The following are areas in which incompatibilities may arise:

Source Structure :
The SOURce structure was not supported by GEDCOM in versions before 5.x. However, some products, prior to GEDCOM 5.x, developed a SOURce structure for citing sources. These structures varied from product to product, which affects how source citations are interpreted. Products based on 5.x GEDCOM, prior to GEDCOM 5.4, may have used the more detailed source structure suggested by the previous 5.x versions. Older systems already handling sources will need to be modified. GEDCOM 5.x draft products are encouraged to update their programs to The GEDCOM Standard 5.5 as soon as possible.
FAMC Pointer :
The INDI.FAMC structure has been modified a lot since GEDCOM 4.0. In previous GEDCOM 5.x versions the FAMC structure may contain subordinate adoption events and/or LDS sealing to parent events. See the compatibility implications concerning the LDS sealing to parent event treated in the "LDS Ordinances Dates" in the next paragraph.
LDS Ordinance Dates :
The structure for LDS sealing of child to parent was changed in previous GEDCOM 5.x draft versions from the FAM.CHIL.SLGC structure to the INDI.FAMC.SLGC structure. This was to allow access to child sealing information without having to follow a pointer to the family record. Personal Ancestral File 2.31 writes the sealing date in the FAM.CHIL.SLGC structure but reads this information from either format. A new major release of Personal Ancestral File will change to the newer approach.

GEDCOM 5.4 places the sealing of child to parent event at the same level as all of the other events that are subordinate to the INDIvidual tag. If a system is keeping track of which family the individual is sealed to, then a FAMC pointer is additionally inserted subordinate to the SLGC event tag that points to the sealed-to-family.

To accommodate previous GEDCOM imports, systems handling the LDS ordinance events should look for the child sealing information in either INDI.SLGC (see LDS_INDIVIDUAL_ORDINANCE , INDI.FAMC.SLGC or FAM.CHIL.SLGC structures. Ancestral File exports did not separate the temple code from the ordinance date. Ordinance dates down-loaded from Ancestral File may contain an ordinance date followed by a two digit temple code rather than a separate temple code line.

GEDCOM 4.x systems used certain key words as part of the ordinance dates. GEDCOM 5.x separated these codes from the dates and specified that they should be values of a subordinate STATus tag. Previous GEDCOM 5.x implementations may have implemented this feature using a TYPE tag instead of the STATus tag. (See <LDS_(ordinance)_DATE_STATUS>.)
Adoption Events :
In GEDCOM 5.x, the ADOPtion event was moved from the FAM.CHIL structure to the INDI.FAMC.ADOP structure, it also appears in the INDI.ADOP structure. In GEDCOM 5.4 the ADOPtion event appears only as an individual event which optionally contains a FAMC pointer to the adoptive family. Subordinate to this pointer is another ADOPtion tag which indicates whether the HUSB or WIFE in the pointed at family was the adoptive parent (see <ADOPTED_BY_WHICH_PARENTS> primitive). Pedigree navigation is provided only by <<CHILD_TO_FAMILY_LINK>> structure.
Codes in Event Date :
Some applications, such as Personal Ancestral File, pass key words as part of certain event dates. Some of these key words were INFANT, CHILD, STILLBORN, etc. These have to do with being an approximate age at an event.

In this version of GEDCOM, the information has been removed from the date value and specified by an <AGE_AT_EVENT> key word value which indicates a descriptive age value at the time of the enclosing event. (See <AGE_AT_EVENT>.) For example:
```
    1 DEAT
      2 DATE 13 MAY 1984
      2 AGE STILLBORN
```
meaning this person died at age approximately 0 days old.
```
    1 DEAT
      2 DATE 13 MAY 1984
      2 AGE INFANT
```
meaning this person died at age less than 1 year old.
Multiple Names :
GEDCOM 5.x requires listing different names in different NAME structures, with the preferred instance first, followed by less preferred names. However, Personal Ancestral File and other products that only handle one name may use only the last instance of a name from a GEDCOM transmission. This causes the preferred name to be dropped when more than one name is present. The same thing often happens with other multiple-instance tags when only one instance was expected by the receiving system. PAF and other products that handle one name only may drop the preferred name under this arrangement.
Alias Names :
One or two systems used the ALIAs tag for representing multiple names. This form is not supported in the GEDCOM Standard version 5.5.
Event Structure :
The address structure, as part of the place structure, provided more detail than desired for the PLACe structure. Therefore it was removed from beneath the place structure and added to the <<EVENT_DETAIL>> structure at the same level as PLACe. The SITE tag was alsoeliminated from the PLACe structure since the site of an event is really part of an address, such as Primary Children's Hospital, 100N Medical Drive, Salt Lake City, Utah.
Supplemental Attributes or Facts :
Sometimes other attributes or facts are used to describe an individual's actions, physical description, employment, education, places of residence, etc. These are not generally thought of as events. However, they are often described like events because they were observed at a particular time and/or place. GEDCOM 5.x lists these attributes under the <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> and allows them to be recorded in the same way as events. The attribute definition allows a value on the same line as the attribute tag. In addition, it allows a subordinate date period, place and/or address, etc. to be transmitted, just as the events are. Previous versions, which handled just a tag and value, can be read as usual by handling the subordinate attribute detail as an exception.

Packaging the GEDCOM Transmission File

The GEDCOM transmission is normally created on a DOS or Macintosh^® compatible diskette. The DOS filename extension is (.GED). Macintosh filenames do not use file extensions.

When the GEDCOM file is too large to fit on a single diskette, the file is divided after any whole-line (last character is the terminator ), and the DOS filename extension becomes (G##) where (##) is (00) for the second disk, (01) for the third, and so forth. For Macintosh filenames, append the two digits to the subsequent filenames in parentheses. (See the example below.) This allows the receiving software to ensure that disks are read in the correct sequence.

Given that the user-supplied portion of the file name is SMITH, then the complete filenames for a three-disk transmission would be:

Disk DOS Filename Macintosh Filename
 1   SMITH.GED    SMITH
 2   SMITH.G00    SMITH(00)
 3   SMITH.G01    SMITH(01)

The required GEDCOM HEADer record appears only on the first disk and the required TRLR (trailer) record appears only on the last disk and must be followed by the terminator.

User-Defined Tags
We do not encourage the use of user-defined GEDCOM tags. Applications requiring the use of non-standard tags should define them with a leading underscore so that they will not conflict with future GEDCOM standard tags. Systems that read user-defined tags must consider that they have meaning only with respect to a system contained in the HEAD.SOUR context.

Escape Sequence Format for the Lineage-Linked Form
The Lineage-Linked GEDCOM Form no longer uses the escape sequence feature provided in the GEDCOM grammar.

Sample Lineage-Linked GEDCOM Transmission
The example below shows how some of these value types appear in a valid GEDCOM lineage-linked transmission. The example is a sample transmission of genealogical information about three individuals who are members of the same family%father, mother, and child. In the example, "Joe/Williams/" is the value specified by the tag NAME under the INDI tag for the record (@3@). Other values in other lines, such as the birth date and place, provide additional information about Joe Williams. The value (@4@) specified by the FAMC tag is a pointer to the FAM_RECORD (@4@) of which Joe Williams is a child. Included also in this transmission example are three other record types: a source record, a submitter record, and a repository record. These records are pointed to from within other records in the transmission. This shows how pointer values can be used in creating Lineage-Linked GEDCOM Form.

Example: ( Indentation and bolding are added for readability only.)

  0 HEAD
    1 SOUR PAF
      2 VERS  2.1
    1 DEST  ANSTFILE
    1 SUBM  @5@
    1 SUBN  @8@
    1 GEDC
      2 VERS  5.4
      2 FORM  Lineage-Linked
    1 CHAR  ANSEL
  0 @1@ INDI
    1 NAME  Robert Eugene/Williams/
    1 SEX  M
    1 BIRT
      2 DATE  02 OCT 1822
      2 PLAC  Weston, Madison, Connecticut
      2 SOUR  @6@
        3 PAGE  Sec. 2, p. 45
        3 EVEN  BIRT 
          4 ROLE  CHIL
    1 DEAT
      2 DATE  14 APR 1905
      2 PLAC  Stamford, Fairfield, CT
    1 BURI
      2 PLAC  Spring Hill Cem., Stamford, CT
    1 RESI
      2 ADDR  73 North Ashley
        3 CONT  Spencer, Utah UT84991
      2 DATE  from 1900 to 1905
    1 FAMS  @4@
    1 FAMS  @9@
  0 @2@ INDI
    1 NAME  Mary Ann/Wilson/
    1 SEX  F
    1 BIRT
      2 DATE  BEF 1828
      2 PLAC  Connecticut
    1 FAMS  @4@ 
  0 @3@ INDI
    1 NAME  Joe/Williams/
    1 SEX  M
    1 BIRT
      2 DATE  11 JUN 1861
      2 PLAC  Idaho Falls, Bonneville, Idaho
    1 FAMC  @4@
    1 FAMC  @9@
      2 PEDI  Adopted
    1 ADOP
      2 FAMC  @9@
      2 Date  16 MAR 1864
    1 SLGC
      2 FAMC  @9@
      2 DATE  2 OCT 1987
      2 TEMP  SLAKE
  0 @4@ FAM
    1 MARR
      2 DATE  DEC 1859
      2 PLAC  Rapid City, South Dakota
    1 SLGS
      2 DATE  14 JUN 1975
      2 TEMP  SLAKE
    1 HUSB  @1@
    1 WIFE  @2@
    1 CHIL  @3@
  0 @5@ SUBM
    1 NAME  Reldon /Poulson/
    1 ADDR  1900 43rd Street West
      2 CONT  Billings, MT 68051
    1 PHON  (406) 555-1232
  0 @6@ SOUR
    1 DATA
      2 EVEN  BIRT, DEAT, MARR
        3 DATE  FROM Jan 1820 TO DEC 1825
      2 PLAC  Madison, Connecticut
      2 AGNC  Madison County Court, State of Connecticut
    1 TITL  Madison County Birth, Death, and Marriage Records 
    1 ABBR  VITAL RECORDS
    1 REPO  @7@
      2 CALN  13B-1234.01
      2 MEDI  Microfilm
  0 @7@ REPO
    1 NAME  Family History Library
    1 ADDR  35 N West Temple Street
      2 CONT  Salt Lake City, Utah
      2 CONT  UT 84150
  0 @8@ SUBN
    1 SUBM @5@
    1 FAMF  Reg Poulson Family
    1 TEMP  SLAKE
  0 @9@ FAM
    1 HUSB  @1@
    1 CHIL  @3@
  0 TRLR

The following is an example of a SOURCE_CITATION subordinate to the birth event being cited that does not contain a pointer to a SOURCE_RECORD. (This is not encouraged.)

  0 INDI
    1 NAME Fred /Jones/
    1 BIRT
      2 DATE 14 MAY 1812
      2 PLAC Tonbridge, Kent, England
      2 SOUR Waters, Henry F., Genealogical Gleanings in England: Abstracts of
        3 CONC Wills Relating to Early American Families. 2 vols., reprint 1901, 1907.
        3 CONC Baltimore: Genealogical Publishing Co., 1981.
        3 CONC Stored in Family History Library book 942 D2wh; films 481,057-58
        3 CONC Vol 2, page 388.