GEDCOM 5.5.2

Editor:
John Cardinal (Family History Hosting, LLC)

Contents

Document Information

Abstract

GEDCOM 5.5.2 is a minor revision to GEDCOM 5.5.1. GEDCOM 5.5.2 corrects flaws and resolves ambiguities in GEDCOM 5.5.1 to improve interoperability and reduce compliance barriers.

Document Status

This document is a Draft. Feedback and comments on this specification are welcome. You may create a pull-request to propose and collaborate on changes to the document. A future version of this document will remove its Draft status.

GitHub Project
GEDCOM-5.5.2
Public URL of Document
https://jfcardinal.github.io/GEDCOM-5.5.2/gedcom-5.5.2.html
Associated documents
https://jfcardinal.github.io/GEDCOM-5.5.2

Document Conventions

Introduction

The GEDCOM STANDARD DRAFT Release 5.5.1 ("GEDCOM 5.5.1") dated 2 October 1999 and prepared by the Family History Department of The Church of Jesus Christ of Latter-day Saints describes the most recent, widely-adopted specification for the interchange of data between genealogy applications using GEDCOM.

There are several flaws and ambiguous statements in the GEDCOM 5.5.1 specification, and the specification has been abandoned by its creators.

Even though the specification document was labeled "DRAFT" and included an instruction that it "must not be used for programming of genealogical software while in draft", GEDCOM 5.5.1 was implemented in software programs shortly after its release. In the many years since the release of the GEDCOM 5.5.1 specification, most popular genealogy programs have implemented some or all of its features.

Due to the issues in the specification and other factors, many programs do not comply with the GEDCOM 5.5.1 specification. Some programs export GEDCOM 5.5.1 documents with minor or even major compliance issues. Others export GEDCOM 5.5 documents that include GEDCOM 5.5.1 subrecords or values. Non-compliance increases the difficulty of implementing software to read GEDCOM documents and introduces unnecessary challenges for users of genealogy software.

GEDCOM 5.5.2 corrects flaws and ambiguities in GEDCOM 5.5.1. Its goal is to reduce compliance barriers without introducing significant changes.

With a relatively small set of exceptions, a GEDCOM 5.5.2 document uses a subset of the rules for a GEDCOM 5.5.1 document. The exceptions are listed in the Changes section.

Any change may be controversial and all changes represent work for software authors. For those and other reasons, some software authors may ignore GEDCOM 5.5.2 as they have ignored all prior attempts to replace or extend GEDCOM, version 5.5.1 or otherwise. Time will tell.

Changes in GEDCOM 5.5.2

When compared to the GEDCOM 5.5.1 specification, the GEDCOM 5.5.2 specificiation has Changes, Inconsequential Changes, and Documentation Changes.

Changes includes the removal of obsolete features and minor changes to resolve errors and ambiguities. Because GEDCOM 5.5.1 features have been removed, a valid GEDCOM 5.5.1 document that uses those features is not a valid GEDCOM 5.5.2 document.

Because the changes are minor, GEDCOM readers can typically support GEDCOM 5.5.2 with relatively minor changes. Software authors should review the Implementation Notes for details.

GEDCOM writers must not specify 5.5.2 in the HEAD.GEDC.VERS subrecord unless they make the requisite changes to ensure they meet the specification.

When wide support for GEDCOM 5.5.2 is attained, GEDCOM readers can optimize their software to read 5.5.2 documents without special handling required by GEDCOM 5.5.1 and GEDCOM 5.5.

Change Categories

The changes in GEDCOM 5.5.2 relative to GEDCOM 5.5.1 fall into these categories:

Changes

Inconsequential Changes

These changes relate to theoretical constructs defined or partially-defined in GEDCOM 5.5.1 (and prior) but never used.

Documentation Changes

These changes describe modifications to the specification document that do not apply to the specification itself, but rather to changes between the GEDCOM 5.5.1 specification document and this document.

GEDCOM Summary

A GEDCOM 5.5.2 document is a structured UTF-8 text document that contains an ordered set of gedcom_lines.

The document must begin with the UTF-8 Byte Order Mark prefix (U+00EF, U+00BB, U+00BF).

gedcom_lines include a level number. The level numbers define a hierarchy. gedcom_lines with level set to zero are records and gedcom_lines with level greater than zero are subrecords. A subrecord with level N+1 is a child of, and subordinate to, a record or subrecord with level N.

A record logically includes the subordinate subrecords that follow it up to the next record. In this document, the term "record" usually refers to the level 0 gedcom_line only unless otherwise specified.

A subrecord may refer to a record using a pointer to the record's ID. The purpose or meaning of the relationship defined by the pointer depends on the tag name and the context.

Informally, records and subrecords are often identified using a tag_name. For example, a DATE subrecord is often called a "DATE tag".

Example

gedcom_line Explanation
0 HEAD HEAD (header) record
1 CHAR UTF-8 HEAD.CHAR subrecord specifies character encoding UTF-8
1 GEDC HEAD.GEDC subrecord
2 VERS 5.5.2 HEAD.GEDC.VERS subrecord specifies GEDCOM version 5.5.2
0 @I1@ INDI INDI (individual) record with ID "I1"
1 NAME John /Doe/ INDI.NAME subrecord specifies name of individual
0 TRLR TRLR (trailer) record

GEDCOM Syntax

gedcom_line Syntax

A gedcom_line is constructed from the following components in the order shown:

The level, tag_name, and line_terminator components are required in all gedcom_lines. The ID and line_value components are required for some tags in some contexts.

Space Handling

A valid gedcom_line must not begin with any characters preceding the level component, white-space or otherwise.

Components must be separated by a single space character (" ", U+0020). Other space characters are significant: any space character that is not a delimiter between components is part of a component.

Multiple spaces must not appear between the level, ID, and tag_name components. Those components must not begin or end with space characters.

If the ID component is not present, there must be a single space between the level and tag_name components.

If there are two or more space characters after the tag_name component, the second and subsequent space characters are the initial characters in the line_value: leading spaces in the line_value must not be trimmed.

Trailing space characters prior to the line_terminator are part of the line_value: trailing spaces must not be trimmed.

Line Length

The total length of a gedcom_line including all components, including the line_terminator, must not exceed 255 characters. See the line_value description for rules associated with long values and values that include line-ending characters that conflict with line_terminator characters.

Empty Lines

GEDCOM documents must not include empty lines. All lines in the document must be valid gedcom_lines according to the specifications in this document.

Best Practice Recommendations

  • GEDCOM documents often exceed the maximum gedcom_line length.

    • GEDCOM readers should issue an error message or warning message for gedcom_lines that exceed the maximum gedcom_line length.

      An error message is appropriate if the GEDCOM reader cannot process (or chooses not to process) a given gedcom_line that exceeds the maximum length.

      A warning message is appropriate if the GEDCOM reader can process a given gedcom_line that exceeds the maximum length.

gedcom_line Components

gedcom_line components are defined in this section in the sequence they appear in a gedcom_line.

level

Definition

The level number indicates the depth in the subrecord hierarchy. A line at any level L is enclosed by and pertains directly to the nearest preceding line at level L-1. The level may increase by 1 at most compared to the level of the preceding gedcom_line.

The enclosed subordinate gedcom_lines at level L are said to be in the context of the enclosing superior gedcom_lines at level L-1: the meaning of a subrecord is influenced by the enclosing gedcom_line(s) and not solely by the tag_name in the subrecord.

For example:

0 INDI
1 BIRT
2 DATE 12 MAY 1920
1 DEAT
2 DATE 1960

In this example, the expression DATE 12 MAY 1920 is interpreted within the INDI.BIRT (individual, birth) context, representing the individual's birth date. The second DATE is interpreted within the INDI.DEAT (individual, death) context. The complete meaning of DATE depends on the context.

In this document, a subrecord's context may be described using the tag_name sequence separated by periods.

Syntax

The level number component must be the first character(s) in the gedcom_line text.

The level number must consist solely of the digits 0 to 9 (U+0030 to U+0039). Level numbers must not begin with leading zeroes. For example, level one must be specified as 1, not 01.

Level numbers must be in the range 0 to 99.

ID

Definition

The ID defines a identifier for a Record. An ID may only be defined once in a GEDCOM document, i.e., the ID value must be unique within the document.

The ID may or may not be retained in the receiving system.

Syntax

The ID component must begin and end with the at-sign character ("@", U+0040).

The first character after the initial @ must be one of the alphabetic, digit, or underscore characters using the definitions in the ID Character Classes table. The remaining characters may include any of the characters in the table below.

The minimum length of the ID value is three characters which includes the leading and trailing at signs and one other character.

The maximum length of the ID value is 24 characters which includes the leading and trailing at-signs and 22 other characters.

ID Character Classes

Character ClassCharacter(s)
Alphabetic
  • A to Z (U+0041 to U005A)
  • a to z (U+0061 to U007A)
Digit
  • 0 to 9 (U+0030 to U0039)
Underscore
  • _ (U+005F)
Other
  • # (U+0023)
  • - (U+002D)

Best Practice Recommendations

  • Many GEDCOM writers use a prefix before a numeric value as the value for an ID. Commonly-used prefixes for several Records are shown below. Using these prefixes will help others navigate and understand GEDCOM documents.

    • GEDCOM writers should use the prefixes below when assigning ID values for the given records.

      RecordPrefix
      INDII
      FAMF
      NOTEN
      OBJEO or M
      REPOR
      SOURS

  • Many GEDCOM readers assign id numbers in the receiving system by deriving values from GEDCOM record ids.

    • When possible, GEDCOM writers should derive GEDCOM ids from ids that are visible in the sending system.
    • A simple derivation is to concatenate the sending system ID to the record prefix described above.

  • Many GEDCOM writers derive GEDCOM ids from values that are visible in the sending system.

    • When possible, GEDCOM readers should derive user-visible id numbers from the ids specified for the GEDCOM Records.
tag_name

Definition

A tag_name indicates the meaning of the gedcom_line within the context of the enclosing subrecords, and contributes to the meaning of the enclosed subordinate gedcom_lines. The presence of a tag_name together with a value represents an assertion made by the author or editor of the content. A tag_name has roughly the same purpose as a field name in a database.

Valid combinations of specific tag_names, line_values, IDs, and pointers are constrained by definitions provided in the Record and Subrecord Grammar section and subsections.

A subrecord with a tag_name but without a line_value does not represent an assertion. A subrecord with no line_value must have subordinate records to represent an assertion.

If a Record or Subrecord is absent, no assertion is made. Asserting that an event did not occur must be expressed using a subrecord that is defined for that purpose, or using a general-purpose subrecord, such as a NOTE.

Syntax

A tag_name consists of a variable length sequence of characters. The valid characters are listed in the table below.

The first character in the tag_name must be an uppercase alphabetic character or an underscore ("_", U+005F). The remaining characters must consist of characters described in the table below.

The first character in a standard tag name must be an uppercase alphabetic character. Standard tag names are defined in the Standard Reecords and Subrecords section.

The first character in a <Custom Tag Name> must be an underscore ("_", U+005F).

The minimum length of a tag_name is three characters.

The maximum length of a tag_name is 31 characters, but the first 15 characters of each tag_name must define a unique value.

tag_name Character Classes

Character ClassCharacter(s)
Uppercase Alphabetic Any Unicode code point in the uppercase letter category.
Digit
  • 0 to 9 (U+0030 to U+0039)
Underscore
  • _ (U+005F)
Other
  • # (U+0023)
  • - (U+002D)

Best-Practice Recommendations

  • As described above, alphabetic characters in tag_names are restricted to uppercase characters. Prior versions of the GEDCOM specification include contradictory information where syntax entries indicate tag_names may include lowercase letters but prose indicates they should be all uppercase. To avoid possible issues:

    • GEDCOM writers should ensure that all letters in tag_names are uppercase.
    • GEDCOM readers should use case-insensitive comparisons when processing tag_names.

  • GEDCOM 5.5.1 tag_name size limits are ambiguous.

    The GEDCOM 5.5.1 specification sets the maximum length of a tag_name to 31 characters, but further specifies that the first 15 characters must be unique. All standard tag names are 3 to 5 characters, so only custom tag names may fall in the range 6 to 31. However, the NEW_TAG definition on page 49 of the GEDCOM 5.5.1 specification set the size limits to 1:15.

    • GEDCOM writers should use 3 to 15 character Custom Tag Names, including the leading underscore ("_", U+005F).
line_value

Definition

The line_value defines a value whose meaning depends on the tag_name and the hierarchical context of the supporting gedcom_lines. The context is defined by record and subrecord definitions in the Records and Subrecords sections, respectively.

With the exception of the TRLR_RECORD, all gedcom_lines have a line_value unless the gedcom_line has subordinate gedcom_lines. The presence of a level number and a tag_name alone should not be used to assert data. For example, 1 DEAT Y asserts that a person has died whereas 1 DEAT does not unless there are subordinate subrecords.

Syntax

The line_value may include one or more Unicode characters except for line_terminator characters.

The line_value is required for some subrecords and optional for others.

When a line_value is provided, the minimum length is one character and the maximum length is unlimited. In practice, GEDCOM readers may not be able to read extremely long values, and the Record and Subrecord grammar defines additional limits on line_value length and content.

If a line_value appended after the tag_name component in a gedcom_line will cause the total length of the gedcom_line to exceed the maximum length allowed for a gedcom_line, the GEDCOM writer must use one or more CONC subrecords to avoid exceeding the limit. See the Continuations section for details.

Values that include any of the line_terminator characters must use a subordinate CONT subrecord. See the Continuations section for details.

The line_value may be set to a pointer, and if so, the pointer must be the only content in the line_value and the line_value must follow the syntax rules for a pointer.

An at sign ("@", U+0040) followed by a pound sign ("#", U+0023) in a line_value introduces an escape_sequence value. See the description of the escape_sequence value for more details.

An at sign ("@", U+0040) that appears in a line_value that is not a pointer and does not introduce an escape_sequence must be doubled. So, for example, 1 EMAIL Smith@@example.com is valid, 1 EMAIL Smith@example.com is invalid.

All controlled line_value choices are case insensitive. For example, a conforming GEDCOM reader must consider the following example records as equivalent:

2 FORM jpg
2 FORM JPG
2 FORM Jpg
pointer

Definition

A pointer refers to a Record identified by the matching ID. A pointer and ID combine to establish a relationship between two records.

The pointer must match a corresponding unique ID within the document. Pointers may use forward references to Records which appear later in the document or backward references to Records that appear earlier in the document.

Syntax

A pointer is a special instance of a line_value.

A pointer and an ID share the same syntax rules. See the ID description for the definition of those rules.

A pointer occurs after the tag_name whereas an ID occurs before.

escape_sequence

Definition

The escape_sequence is a character sequence used to indicate special processing. The only escape_sequences in GEDCOM 5.5.2 are used to indicate a calendar in a DATE value.

Syntax

An escape_sequence is contained within a line_value.

It must begin with an at sign ("@", U+0040) followed by a pound sign ("#", U+0023). The escape_sequence ends at the next at sign.

The trailing at sign ("@", U+0040) should be followed by a space (" ", U+0020). GEDCOM readers should discard any space character which follows the escape_sequence's closing at-sign. If the character following the escape_sequence's closing at-sign is not a space character then it should be kept as a part of the text following the escape_sequence. GEDCOM writers should always output a space character following the escape_sequence.

An escape_sequence must include at least one character that is not one of the delimiters. For that reason, "@#@ " is invalid.

line_terminator

Definition

The line_terminator indicates the end of the gedcom_line.

Syntax

A GEDCOM document must use one of the following character sequences as its line_terminator:

SequenceSymbolDescription
U+000DCRcarriage return
U+000ALFline feed
U+000D U+000ACRLFcarriage return + line feed
U+000A U+000DLFCRline feed + carriage return

All gedcom_line records in a single document must end with the same line_terminator sequence, i.e., the line_terminator must not vary within a single document.

Typically, a GEDCOM writer will use the line_terminator sequence that matches the newline sequence most common on its platform:

New Line Sequences
SequenceSymbolPlatform
U+000ALFLinux
U+000ALFMacintosh (OS X)
U+000DCRMacintosh (Mac OS)
U+000D, U+000ACRLFWindows

Continuations (CONT and CONC)

GEDCOM includes two continuation subrecords. The CONT and CONC subrecords logically append their line_value to the line_value of their parent subrecord.

The CONT subrecord appends its value to the line_value of its parent subrecord after adding a newline sequence.

The CONC subrecord appends its value to the line_value of its parent subrecord without adding a newline sequence.

CONT and CONC may be used separately or together.

Syntactically, it is valid to use CONT and/or CONC as a subrecord of any parent subrecord that supports a line_value, subject to two exceptions noted below. Semantically, some line_values are not allowed to contain newline sequences, so using a CONT is not valid there. Also, CONT and/or CONC must not be used to create values that are longer than allowed by the specification for the parent subrecord.

CONT and CONC must not be used as subrecords of HEAD.CHAR or HEAD.GEDC.VERS. Those exceptions allow GEDCOM readers to preview those values with components that do not support continuation subrecords.

CONT

When a value to be included in the line_value of a gedcom_line includes one or more newline sequences, the newline sequences must be replaced by CONT subrecords that are logically inserted into the value in their place.

The first CONT subrecord for the value must be assigned level N+1, i.e., it must be assigned a level number one greater than the parent record.

Any subsequent CONT subrecord(s) for the same value must be assigned the same level as the first CONT subrecord.

For example, to write the following text in a NOTE subrecord:

Line oneCRLFLine twoCRLFLine three

Use these GEDCOM subrecords:

1 NOTE Line one
2 CONT Line two
2 CONT Line three

Any GEDCOM line_terminator in the value must be replaced, even if the sequence is not used as a newline sequence on the platform of the program writing the GEDCOM document.

If the current platform uses a line feed (U+000A) as its newline sequence, but the value includes carriage return characters (U+0000D), the carriage return characters must be converted into CONT records as described above. Given the following text:

Line oneLFLine twoCRLine three

The GEDCOM subrecords must be the same as the example above:

1 NOTE Line one
2 CONT Line two
2 CONT Line three

CONC

When a value to be included in the line_value of a gedcom_line causes the total length of the gedcom_line to exceed its maximum length, the value must be converted into multiple subrecords where CONC subrecords are logically inserted into the value to create multiple subrecords where no subrecord's gedcom_line exceeds the maximum length.

The first CONC subrecord for the value must be assigned level N+1, i.e., it must be assigned a level number one greater than the parent record.

Any subsequent CONC subrecord(s) for the same value must be assigned the same level as the first CONC subrecord.

CONT and CONC Combined

When a long value includes newline sequences, the value should first be split into multiple "CONT" segments where the newline sequences occur. Any "CONT" segments that are too long to make a valid gedcom_line should then be split into a "CONT" segment followed by as many "CONC" segments as required to create valid gedcom_lines.

Best Practice Recommendations

  • Prior versions of the GEDCOM specifications were inconsistent or unclear with respect to using the CONC subrecord.

    • For maximum compatibility, GEDCOM writers should split long text values in the middle of a word, i.e., avoid splitting the value just before or just after a space.

      When it is not possible to split a long value in the middle of a word, split the value before a space so the line_value on the subsequent CONC subrecord begins with a space.

  • Prior GEDCOM specifications included explicit references to CONT and CONC subrecords in selected contexts only, such as HEAD.NOTE, SOUR.AUTH., and others.

    • GEDCOM readers should implement CONT and CONC processing prior to evaluating the line_value in a gedcom_line so that CONT and CONC can be used with any subrecord. GEDCOM readers should validate the line_value after processing continuation subrecords.

    • GEDCOM writers should avoid using CONC with controlled values and when it is unnecessary because a long value will not overflow the maximum length of the gedcom_line.

Record and Subrecord Grammar

This section describes the tag_name, line_value, and pointer combinations used for exchanging genealogical information in the GEDCOM format.

GEDCOM Document Sequence

A GEDCOM document must consist of Records and Subrecords in the following sequence:

Organization

A description of the Record and Subrecord Grammar is presented in the following subsections:

The following symbols are used in the Record and Subrecord Grammar subsections listed above:

Double Angle Brackets: << and >>

<<record name>>
or
<<subrecord name>>

A record name or subrecord delimited by double angle brackets indicates a GEDCOM record or subrecord is to be substituted in place of the line containing the text enclosed in double angle brackets. Records and subrecords are found in the Records and Subrecords sections, respectively.

Single Angle Brackets: < and >

<primitive-element>

Text delimited by single angle brackets indicates the name of the Primitive Element that defines the syntax and meaning of the appropriate value for the GEDCOM subrecord.

Braces: { and }

{minimum:maximum}

Values in braces define the range of minimum to maximum occurrences allowed for a Record or Subrecord.

The minimum to maximum range is relative to the parent record or subrecord. This means that a required line (minimum = 1) is not required if the parent is not present. Similarly, a subrecord limited to one instance (maximum = 1) may occur multiple times as long as each occurs only once under its own multiple-occurring parent.

Braces are also used in Primitive Element definitions to indicate the minimum and maximum size range, in characters, of text values.

Square Brackets and Vertical Bars: [, |, and ]

[ option 1 | option 2 | ... ]

Indicates a choice of one or more options. Square brackets delimit the set of options. Vertical bars separate the options.

Italic Character n

An "n" in place of a level number indicates a level number one greater than the superior record or subrecord that establishes the context for the current subrecord.

Plus Sign Followed by a digit: +1, +2, ...

A +1 in place of a 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.

Record and Subrecord Usage

Records

Structure Overview

A HEAD_RECORD and a TRLR_RECORD are required. Any number of data records may appear between the HEAD_RECORD and the TRLR_RECORD.

Subrecords that are required within a structure have tag_names that appear like THIS. Note that some records and subrecords are not required but if they are present one or more of their subordinate subrecords may be required.

0 <<HEAD_RECORD>> 1:1
0 <<RECORD_STRUCTURE>> 0:M
0 <<TRLR_RECORD>> 1:1
HEAD_RECORD

The HEAD_RECORD with its subrecords provides information about the GEDCOM document.

n HEAD1:1
+1 CHAR <CHARACTER_ENCODING> 1:1
+1 GEDC 1:1
+2 VERS <VERSION_NUMBER> 1:1
+2 FORM <GEDCOM_FORM> 0:1
+1 SOUR <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
+3 <<CONTACT_STRUCTURE>> 0:M
+2 DATA <NAME_OF_SOURCE_DATA> 0:1
+3 DATE <PUBLICATION_DATE> 0:1
+3 COPR <COPYRIGHT_SOURCE_DATA> 0:1
+1 DEST <SYSTEM_ID> 0:1
+1 DATE <DOCUMENT_DATE> 0:1
+2 TIME <TIME_VALUE> 0:1
+1 SUBM @<ID_SUBM>@ 0:1
+1 FILE <FILE_NAME> 0:1
+1 COPR <COPYRIGHT_GEDCOM_FILE> 0:1
+1 LANG <LANGUAGE_ID> 0:1
+1 PLAC 0:1
+2 FORM <PLACE_HIERARCHY> 1:1
+1 NOTE <CONTENT_DESCRIPTION> 0:1

A program reading a GEDCOM document must read the GEDC.VERS value to verify it is capable of reading the GEDCOM version written by the source program.

The CHAR subrecord is required.

The SOUR subrecord's SYSTEM_ID identifies which system wrote the data. Many GEDCOM readers inspect the SYSTEM_ID to determine how to interpret custom records and subrecords written by the system indicated by the SYSTEM_ID.

RECORD_STRUCTURE
[
n <<FAM_RECORD>> 1:1
|
n <<INDI_RECORD>> 1:1
|
n <<OBJE_RECORD>> 1:1
|
n <<NOTE_RECORD>> 1:1
|
n <<REPO_RECORD>> 1:1
|
n <<SOUR_RECORD>> 1:1
|
n <<SUBM_RECORD>> 1:1
]
FAM_RECORD

The FAM_RECORD is used to record marriages and family unions caused by two people becoming the parents of a child.

n @<ID_FAM>@ FAM 1:1
+1 <<FAMILY_EVENT_STRUCTURE>> 0:M
+1 HUSB @<ID_INDI>@ 0:1
+1 WIFE @<ID_INDI>@ 0:1
+1 CHIL @<ID_INDI>@ 0:M
+1 NCHI <COUNT_OF_CHILDREN> 0:1
+1 REFN <USER_REFERENCE_NUMBER> 0:M
+2 TYPE <USER_REFERENCE_TYPE> 0:1
+1 RESN <RESTRICTION_NOTICE> 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

There can be no more than one HUSB and one WIFE listed in each FAM_RECORD. If, for example, a man participated in more than one family union, then he would appear in more than one FAM_RECORD.

The FAM_RECORD structure assumes, but does not require, that the HUSB is male and the WIFE is female.

The preferred order of the CHIL (child) subrecords within a FAM_RECORD is chronological by birth.

INDI_RECORD

The INDI_RECORD is a set of assertions about an individual.

n @ID_INDI@ INDI 1: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 <<CHILD_TO_FAMILY_LINK>> 0:M
+1 <<SPOUSE_TO_FAMILY_LINK>> 0:M
+1 <<ASSOCIATION_STRUCTURE>> 0:M
+1 ALIA @<ID_INDI>@ 0:M
+1 ANCI @<ID_SUBM>@ 0:M
+1 DESI @<ID_SUBM>@ 0:M
+1 REFN <USER_REFERENCE_NUMBER> 0:M
+2 TYPE <USER_REFERENCE_TYPE> 0:1
+1 RESN <RESTRICTION_NOTICE> 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
OBJE_RECORD

The OBJE_RECORD describes a multimedia file.

n @ID_OBJE@ OBJE 1:1
+1 FILE <MULTIMEDIA_FILE_REFERENCE> 1:M
+2 FORM <MULTIMEDIA_FORMAT> 1:1
+3 TYPE <SOURCE_MEDIA_TYPE> 0:1
+2 TITL <DESCRIPTIVE_TITLE> 0:1
+1 REFN <USER_REFERENCE_NUMBER> 0:M
+2 TYPE <USER_REFERENCE_TYPE> 0:1
+1 RIN <AUTOMATED_RECORD_ID> 0:1
+1 <<NOTE_STRUCTURE>> 0:M
+1 <<SOURCE_CITATION>> 0:M
+1 <<CHANGE_DATE>> 0:1
NOTE_RECORD

A NOTE_RECORD contains text that is referenced by one or more subrecords. The <<NOTE_STRUCTURE>> references the NOTE_RECORD.

n @<ID_NOTE>@ NOTE <NOTE_TEXT> 1:1
+1 REFN <USER_REFERENCE_NUMBER> 0:M
+2 TYPE <USER_REFERENCE_TYPE> 0:1
+1 RIN <AUTOMATED_RECORD_ID> 0:1
+1 <<SOURCE_CITATION>> 0:M
+1 <<CHANGE_DATE>> 0:1
REPO_RECORD

A REPO_RECORD describes a repository. The <<SOURCE_REPOSITORY_CITATION>> structure references the REPO_RECORD.

n @<ID_REPO>@ REPO 1:1
+1 NAME <NAME_OF_REPOSITORY> 1:1
+1 <<ADDRESS_STRUCTURE>> 0:1
+1 <<CONTACT_STRUCTURE>> 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 REPO_RECORD structure describes the place where an item of source material is stored.

The repository addresses is stored in the <<ADDRESS_STRUCTURE>>.

The REPO_RECORD structure is used for formal and informal repositories. Public libraries and civil archives are examples of formal archives. A personal collection is an example of an informal repository.

SOUR_RECORD

The SOUR_RECORD provides a bibliographic description of a cited source. The <<SOURCE_CITATION>> structure references the SOUR_RECORD.

n @<ID_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
+1 TITL <SOURCE_DESCRIPTIVE_TITLE> 0:1
+1 ABBR <SOURCE_FILED_BY_ENTRY> 0:1
+1 PUBL <SOURCE_PUBLICATION_FACTS> 0:1
+1 TEXT <TEXT_FROM_SOURCE> 0:1
+1 <<SOURCE_REPOSITORY_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
+1 <<NOTE_STRUCTURE>> 0:M
+1 <<MULTIMEDIA_LINK>> 0:M
SUBM_RECORD

The SUBM_RECORD specifies the individual or organization that contributed information contained in the GEDCOM document.

n @<ID_SUBM>@ SUBM 1:1
+1 NAME <NAME_OF_SUBMITTER> 1:1
+1 <<ADDRESS_STRUCTURE>> 0:1
+1 <<CONTACT_STRUCTURE>> 0:M
+1 <<MULTIMEDIA_LINK>> 0:M
+1 LANG <LANGUAGE_ID> 0:3
+1 RFN <SUBMITTER_REGISTERED_RFN> 0:1
+1 RIN <AUTOMATED_RECORD_ID> 0:1
+1 <<NOTE_STRUCTURE>> 0:M
+1 <<CHANGE_DATE>> 0:1
TRLR_RECORD

The TRLR_RECORD indicates the end of the GEDCOM document.

0 TRLR 1:1

The TRLR_RECORD is mandatory. It must not have a line_value.

Subrecords

ADDRESS_STRUCTURE

The ADDRESS_STRUCTURE describes the elements of a mailing address.

n ADDR <ADDRESS_VALUE> 1:1
+1 CONT <ADDRESS_VALUE> 1:3
+1 ADR1 <ADDRESS_LINE> 0:1
+1 ADR2 <ADDRESS_LINE> 0:1
+1 ADR3 <ADDRESS_LINE> 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

The ADDRESS_STRUCTURE contents should be formed as an address would appear on a mailing label using the ADDR and CONT subrecords to form the mailing address.

The ADDR subrecord and at least one subordinate CONT subrecord are required.

The additional subordinate address subrecords such as STAE and CTRY are intended to be used by systems that have structured their addresses for indexing and sorting. For backward compatibility these subrecords are not to be used in lieu of the required ADDR and CONT subrecords.

Subrecords that were included in the ADDRESS_STRUCTURE in previous versions of the GEDCOM standard are now defined in the <CONTACT_STRUCTURE>.

See:

ASSOCIATION_STRUCTURE

The ASSOCIATION_STRUCTURE associates the current INDI_RECORD to the INDI_RECORD with the given <ID_INDI>.

n ASSO @<ID_INDI>@ 1:1
+1 RELA <RELATION_IS_DESCRIPTOR> 1:1
+1 <<SOURCE_CITATION>> 0:M
+1 <<NOTE_STRUCTURE>> 0:M

The ASSO subrecord defines an association or relationship between the two individuals.

The RELA subrecord classifies the relationship using the <RELATION_IS_DESCRIPTOR> value.

See: <<INDI_RECORD>>

CHANGE_DATE

The CHANGE_DATE structure defines the last date and (optionally) time of a change to the parent record.

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

See:

The CHILD_TO_FAMILY_LINK structure provides a pointer to a family where this person is a child.

n FAMC @<ID_FAM>@ 1:1
+1 PEDI <PEDIGREE_LINKAGE_TYPE> 0:1
+1 STAT <CHILD_LINKAGE_STATUS> 0:1
+1 <<NOTE_STRUCTURE>> 0:M

See: <<INDI_RECORD>>

CONTACT_STRUCTURE

The CONTACT_STRUCTURE describes elements used to contact an individual or organization.

[
n PHON <PHONE_NUMBER> 1:3
|
n EMAIL <ADDRESS_EMAIL> 1:3
|
n FAX <PHONE_NUMBER_FAX> 1:3
|
n WWW <ADDRESS_WEB_PAGE> 1:3
]

See:

EVENT_OR_FACT_DETAIL

The EVENT_OR_FACT_DETAIL structure describes common data elements used with individual events, individual attributes, and family events.

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 <<CONTACT_STRUCTURE>> 0:M
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

See:

FAMILY_EVENT_DETAIL
n HUSB 0:1
+1 AGE <AGE_AT_EVENT> 1:1
n WIFE 0:1
+1 AGE <AGE_AT_EVENT> 1:1
n <<EVENT_OR_FACT_DETAIL>> 0:1

See: <<FAMILY_EVENT_STRUCTURE>>

FAMILY_EVENT_STRUCTURE
[
n [ ANUL | CENS | DIV | DIVF ] 1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
|
n [ ENGA | MARB | MARC ] 1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
|
n MARR [ Y | <NULL> ] 1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
|
n [ MARL | MARS ] 1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
|
n RESI1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
|
n EVEN [ <EVENT_DESCRIPTOR> | <NULL> ] 1:1
+1 <<FAMILY_EVENT_DETAIL>> 0:1
]

See: <<FAM_RECORD>>

INDIVIDUAL_ATTRIBUTE_STRUCTURE
[
n CAST <CASTE_NAME>1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n DSCR <PHYSICAL_DESCRIPTION> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n EDUC <SCHOLASTIC_ACHIEVEMENT> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n IDNO <NATIONAL_ID_NUMBER> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:12
|
n NATI <NATIONAL_OR_TRIBAL_ORIGIN> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n NCHI <COUNT_OF_CHILDREN> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n NMR <COUNT_OF_MARRIAGES> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n OCCU <OCCUPATION> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n PROP <POSSESSIONS> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n RELI <RELIGIOUS_AFFILIATION> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n RESI1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n SSN <SOCIAL_SECURITY_NUMBER> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n TITL <NOBILITY_TYPE_TITLE> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:11
|
n FACT <ATTRIBUTE_DESCRIPTOR> 1:1
+1 <<EVENT_OR_FACT_DETAIL>> 0:12
]

Notes

  1. The TYPE subrecord may be used with this subrecord to provide an <EVENT_OR_FACT_CLASSIFICATION>.
  2. The TYPE subrecord must be used with this subrecord to provide an <EVENT_OR_FACT_CLASSIFICATION>.

See: <<INDI_RECORD>>

INDIVIDUAL_EVENT_DETAIL
n <<EVENT_OR_FACT_DETAIL>> 1:1
n AGE <AGE_AT_EVENT> 0:1

See: <<INDIVIDUAL_EVENT_STRUCTURE>>

INDIVIDUAL_EVENT_STRUCTURE
[
n [ BIRT | CHR ] [Y|<NULL>] 1:1
+1 <<INDIVIDUAL_EVENT_DETAIL>> 0:1*
+1 FAMC @<ID_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 @<ID_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 [ <EVENT_DESCRIPTOR> | <NULL> ] 1:1
+1 <<INDIVIDUAL_EVENT_DETAIL>> 0:1*
]

Events are things that happen on a specific date.

The EVEN subrecord in this structure is for recording general events that are not shown in the above <<INDIVIDUAL_EVENT_STRUCTURE>>. See the EVEN subrecord definition for more details.

The occurrence of an event is asserted by the presence of either a DATE subrecord or a PLAC subrecord in the event structure. When neither the date nor the place are known then a Y (yes) value on the parent subrecord is required to assert that the event happened.

For example each of the following GEDCOM structures assert that a death happened:

1 DEAT Y
1 DEAT
2 DATE 2 OCT 1937
1 DEAT
2 PLAC Cove, Cache, Utah

It is invalid to use a N value with an event subrecord to infer that the event did not happen.

See: <<INDI_RECORD>>

[
n OBJE @<ID_OBJE>@ 1:1
|
n OBJE
+1 FILE <MULTIMEDIA_FILE_REFERENCE> 1:M
+2 FORM <MULTIMEDIA_FORMAT> 1:1
+3 MEDI <SOURCE_MEDIA_TYPE> 0:1
+1 TITL <DESCRIPTIVE_TITLE> 0:1
]

  • The specification allows a single MULTIMEDIA_LINK to include more than one MULTIMEDIA_FILE_REFERENCE, but many applications can only support one MULTIMEDIA_FILE_REFERENCE per MULTIMEDIA_LINK.

    • GEDCOM writers should write a MULTIMEDIA_LINK for each MULTIMEDIA_FILE_REFERENCE.

    • GEDCOM readers for receiving systems that support only one MULTIMEDIA_FILE_REFERENCE per MULTIMEDIA_LINK should issue an error message if a MULTIMEDIA_LINK includes more than one MULTIMEDIA_FILE_REFERENCE.

See:

NOTE_STRUCTURE
[
n NOTE @<ID_NOTE>@ 1:1
|
n NOTE [<NOTE_TEXT> | <NULL>] 1:1
]

See:

PERSONAL_NAME_PIECES
n NPFX <NAME_PIECE_PREFIX> 0:1
n GIVN <NAME_PIECE_GIVEN> 0:1
n NICK <NAME_PIECE_NICKNAME> 0:1
n SPFX <NAME_PIECE_SURNAME_PREFIX> 0:1
n SURN <NAME_PIECE_SURNAME> 0:1
n NSFX <NAME_PIECE_SUFFIX> 0:1
n <<NOTE_STRUCTURE>> 0:M
n <<SOURCE_CITATION>> 0:M

See: <<PERSONAL_NAME_STRUCTURE>>

PERSONAL_NAME_STRUCTURE
n NAME <NAME_PERSONAL> 1:1
+1 TYPE <NAME_TYPE> 0:1
+1 <<PERSONAL_NAME_PIECES>> 0:1
+1 FONE <NAME_PHONETIC_VARIATION> 0:M
+2 TYPE <PHONETIC_TYPE> 1:1
+2 <<PERSONAL_NAME_PIECES>> 0:1
+1 ROMN <NAME_ROMANIZED_VARIATION> 0:M
+2 TYPE <ROMANIZED_TYPE> 1:1
+2 <<PERSONAL_NAME_PIECES>> 0:1

The TYPE <NAME_TYPE> subrecord is used to indicate the type of the PERSONAL_NAME_STRUCTURE, for example, a married name, or some particular type of alternate name.

See: <<INDI_RECORD>>

PLACE_STRUCTURE
n PLAC <PLACE_NAME> 1:1
+1 FORM <PLACE_HIERARCHY> 0:1
+1 FONE <PLACE_PHONETIC_VARIATION> 0:M
+2 TYPE <PHONETIC_TYPE> 1:1
+1 ROMN <PLACE_ROMANIZED_VARIATION> 0:M
+2 TYPE <ROMANIZED_TYPE> 1:1
+1 MAP 0:1
+2 LATI <PLACE_LATITUDE> 1:1
+2 LONG <PLACE_LONGITUDE> 1:1
+1 <<NOTE_STRUCTURE>> 0:M

See: <<EVENT_OR_FACT_DETAIL>>

SOURCE_CITATION

Structure when using a pointer to a SOUR_RECORD:

n SOUR @<ID_SOUR>@ 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
+1 <<MULTIMEDIA_LINK>> 0:M
+1 <<NOTE_STRUCTURE>> 0:M
+1 QUAY <CERTAINTY_ASSESSMENT> 0:1

Structure when not using a pointer to a SOUR_RECORD:

n SOUR <SOURCE_DESCRIPTION> 1:1
+1 TEXT <TEXT_FROM_SOURCE> 0:M
+1 <<MULTIMEDIA_LINK>> 0:M
+1 <<NOTE_STRUCTURE>> 0:M
+1 QUAY <CERTAINTY_ASSESSMENT> 0:1

The data provided in the <<SOURCE_CITATION>> structure is source-related information specific to the data being cited. Systems that do not use a SOUR_RECORD must use the non-preferred second SOURCE_CITATION structure option.

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

  • The pointer to the SOUR_RECORD, which contains a more general description of the source used for the data being cited.
  • Information, such as a page number, to help the user find the cited data within the referenced source. This is stored in the ".SOUR.PAGE" subrecord.
  • Actual text from the source that was used in making assertions, for example a date phrase as actually recorded in the source, or significant notes written by the recorder, or an applicable sentence from a letter. This is stored in the ".SOUR.DATA.TEXT" subrecord.

  • 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 data that would help determine how much time from the date of the asserted fact and when the source was actually recorded, what type of event was cited, and what type of role did this person have in the cited source.

    • Date when the entry was recorded in source document is stored in the ".SOUR.DATA.DATE" subrecord.
    • The type of event that initiated the recording is stored in the "SOUR.EVEN" subrecord. The value used is the event code taken from the table of choices shown in the EVENT_TYPE_CITED_FROM primitive.
    • The role of this person in the event is stored in the "SOUR.EVEN.ROLE" context.

See:

SOURCE_REPOSITORY_CITATION

A SOURCE_REPOSITORY_CITATION links a SOUR_RECORD to a REPO_RECORD.

n REPO [ @<ID_REPO>@ | <NULL>] 1:1
+1 <<NOTE_STRUCTURE>> 0:M
+1 CALN <SOURCE_CALL_NUMBER> 0:M
+2 MEDI <SOURCE_MEDIA_TYPE> 0:1

For repositories that use call numbers, that value should be recorded using a subordinate CALN subrecord.

See: <<SOUR_RECORD>>

The SPOUSE_TO_FAMILY_LINK subrecord provides a pointer to a FAM_RECORD where this person is a spouse and/or parent.

n FAMS @<ID_FAM>@ 1:1
+1 <<NOTE_STRUCTURE>> 0:M

See: <<INDI_RECORD>>

Primitive Elements

The elements defined in this section represent values used in Record and Subrecord definitions.

Primitive elements used with dates are in the Primitive Elements for Dates section.

Most element definitions include the minimum and maximum length, in characters, of the associated value using the "Size=minimum:maximum" notation.

When the size is not specified, the element follows the same syntax as a "Same as" original element, and the size is defined in the original element. A link to the original element appears in place of the size. For example, <DOCUMENT_DATE> is the same as <DMY_EXACT>.

The "Same as" links reduce the number of definitions in the specification and ensure that rules are defined in the specification only once.

Many elements include a list of refernces that indicate the record and subrecord context where the element's definition applies. The lists are non-normative because they may not be complete. They are provided primarily to help navigate the document.

ADDRESS_CITY {Size=1:60}

The name of the city used in the address. Isolated for sorting or indexing.

See: <<ADDRESS_STRUCTURE>>.ADDR.CITY

ADDRESS_COUNTRY {Size=1:60}

The name of the country used in the address. Isolated for sorting or indexing.

See: <<ADDRESS_STRUCTURE>>.ADDR.CTRY

ADDRESS_EMAIL {Size=5:120}

An email address. See the Syntax section of the line_value component for considerations related to using the at sign ("@", U+0040) character in values.

See: <<CONTACT_STRUCTURE>>.EMAIL

ADDRESS_LINE {Size=1:60}

ADDRESS_LINE represents one line of an address used for indexing.

The ADDRESS_LINE value is used to specify the initial components of an address, such as the addressee or street address, with up to three values as specified via the ADR1, ADR2, and ADR3 subrecords.

See:

ADDRESS_POSTAL_CODE {Size=1:10}

The postal code of the address. Isolated for sorting or indexing.

See: <<ADDRESS_STRUCTURE>>.ADDR.POST

ADDRESS_STATE {Size=1:60}

The name of the state in the address. Isolated for sorting or indexing.

See: <<ADDRESS_STRUCTURE>>.ADDR.STAE

ADDRESS_VALUE {Size=1:240}

ADDRESS_VALUE defines a mailing address of an individual when used subordinate to a RESI (resident) subrecord. When it is used subordinate to an event subrecord it is the address of the place where the event took place. The ADDRESS_VALUE usually contains the addressee's name and other street and city information so that it forms an address that meets mailing requirements.

The ADDRESS_VALUE should be specified using one or more CONT subrecords so there will be multiple lines in the resulting value.

See:

ADDRESS_WEB_PAGE {Size=5:120}

The world wide web page address.

See: <<CONTACT_STRUCTURE>>.WWW

ADOPTED_BY_WHICH_PARENT {Size=1:4}

A code which shows which parent in the associated FAM_RECORD adopted this person.

where

  • HUSB = The HUSB (husband) in the associated family adopted this person.
  • WIFE = The WIFE in the associated family adopted this person.
  • BOTH = Both HUSB (husband) and WIFE adopted this person.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.ADOP.FAMC.ADOP

AGE_AT_EVENT {Size=1:13}

AGE_AT_EVENT is a value that indicates the age of the principal at the time of the associated event.

The value may be expressed using a number of years, months, and/or days, and such a value may begin with an optional < or > character to indicate "less than" or "greater than", respectively.

When using the years, months, and/or days format, each number must include a suffix character, y for years, m for months, and d for days.

The allowable formats when using years, months, and/or days are as follows:

Format Description
YYyYears only
YYy MMmYears and months
YYy MMm DDdYears, months, and days
YYy DDDdYears, and days
MMmMonths
MMm DDdMonths and days
DDDdDays

where

  • YY is a one-, two-, or three-digit number of full years
  • MM is a one-, two-digit number of full months
  • DD is a one-, or two-digit number of days
  • DDD is a one-, two-, or three-digit number of days

The value may also be expressed using one of the following keywords:

ChoiceDescription
CHILDMeans "age < 8 years"
INFANTMeans "age < 1 year"
STILLBORNMeans "died just prior, at, or near birth, 0 years"

Examples

< 10y
10y 8m 22d
> 10y 8m 22d
CHILD

See:

ATTRIBUTE_DESCRIPTOR {Size=1:90}

Text describing a particular characteristic or attribute assigned to an individual. This attribute value is assigned to the FACT subrecord. The classification of this specific attribute or fact is specified by the value of the subordinate TYPE subrecord.

For example, if you were classifying the skills a person had obtained:

1 FACT Woodworking
2 TYPE Skills

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.FACT

ATTRIBUTE_TYPE {Size=1:4}

A code used to indicate the type of attribute. The definition is the same as the corresponding attribute tag_name defined in the Standard Records and Subrecords section. The choices are:

  • CAST
  • EDUC
  • NATI
  • OCCU
  • PROP
  • RELI
  • RESI
  • TITL
  • FACT

See: <EVENT_ATTRIBUTE_TYPE>

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 for reconciling differences in data between two interfacing systems.

See:

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.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.CAST

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.

See: <<EVENT_OR_FACT_DETAIL>>.CAUS

CERTAINTY_ASSESSMENT {Size=1:1}

The CERTAINTY_ASSESSMENT conveys the submitter's quantitative evaluation of the credibility of a piece of information.

The choices are:

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

See: <<SOURCE_CITATION>>.SOUR.QUAY

CHANGE_DATE Same as DMY_EXACT

The date that this data was changed.

See: <<CHANGE_DATE>>.CHAN.DATE

CHARACTER_ENCODING {Size=5:5}

The CHARACTER_ENCODING is a keyword value that indicates the character encoding used to encode the current GEDCOM document.

The CHARACTER_ENCODING must be set to UTF-8.

See:

CHILD_LINKAGE_STATUS {Size=6:10}

CHILD_LINKAGE_STATUS is a keyword indicating the user's opinion of the status of a <<CHILD_TO_FAMILY_LINK>>. The choices are:

  • challenged = Linking this child to this family is suspect, but the linkage has been neither proven nor disproven.
  • disproven = There has been a claim by some that this child belongs to this family, but the linkage has been disproven.
  • proven = There has been a claim by some that this child does not belongs to this family, but the linkage has been proven.

See: <<CHILD_TO_FAMILY_LINK>>.FAMC.STAT

CONTENT_DESCRIPTION Same as TEXT

A <TEXT> value that describes the contents of the GEDCOM document.

See: <<HEAD_RECORD>>.HEAD.NOTE

COPYRIGHT_GEDCOM_FILE is a copyright statement used to protect the copyrights of the submitter of this GEDCOM document.

See: <<HEAD_RECORD>>.HEAD.COPR

COPYRIGHT_SOURCE_DATA is a copyright statement required by the owner of data from which this information was downloaded.

See: <<HEAD_RECORD>>.HEAD.SOUR.DATA.COPR

COUNT_OF_CHILDREN {Size=1:3}

The number of known children of an individual or a couple.

The value must be one to three digits.

See:

COUNT_OF_MARRIAGES {Size=1:3}

COUNT_OF_MARRIAGES is 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.

The value must be one to three digits.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.NMR

CUSTOM_TAG {Size=2:15}

A CUSTOM_TAG is a tag_name that is not defined in the Standard Records and Subrecords section of this document. GEDCOM writers should include CUSTOM_TAGs to include data that cannot be represented with standard subrecords and would be lost otherwise.

The CUSTOM_TAG value must begin with an underscore (_).

The remaining characters must follow the rules for the tag_name component.

Example:

1 _SDATE 17 FEB 1928

See the GEDC.SOUR and GEDC.DEST section for related information.

See: tag_name

DESCRIPTIVE_TITLE Same as TEXT

A <TEXT> value that specifies the title of a work, record, item, or object.

See:

DIGIT {Size=1:1}

A single digit, 0 to 9 (U+0030 to U+0039).

See:

DOCUMENT_DATE Same as <DMY_EXACT>

The date that the current GEDCOM document was created.

See: <<HEAD_RECORD>>.HEAD.DATE

ENTRY_RECORDING_DATE Same as <DATE_VALUE>

The date that this event data was entered into the original source document.

See: <<SOURCE_CITATION>>.SOUR.DATA.DATE

EVENT_ATTRIBUTE_TYPE {Size=1:15}

EVENT_ATTRIBUTE_TYPE is a code that classifies the principal event or happening that caused the source record entry to be created. If the event or attribute is not represented by one of the available codes, the sending system may specify a custom value specified by the user.

The available codes are the union of the codes described in these entries:

EVENT_ATTRIBUTE_TYPE may be set to a single value from one of the three sets listed above.

See:

EVENT_DESCRIPTOR {Size=1:90}

The EVENT_DESCRIPTOR is text that describes or classifies a particular individual or family event.

For example, to record an appointment to a civic committee, use the TYPE subrecord to describe the general activity and use the EVENT_DESCRIPTOR to describe the specific appointment, such as "Appointed Zoning Committee Chairperson":

1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointment
2 DATE 3 JAN 1952
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment

See:

EVENT_OR_FACT_CLASSIFICATION {Size=1:90}

A descriptive word or phrase that classifies the parent event or attribute subrecord. This must be present with either of the generic EVEN or FACT subrecords.

For example, if the attribute being defined was one of the person's skills, such as woodworking, the FACT subrecord would have a line_value of "Woodworking", followed by a subordinate TYPE subrecord with the value "Skills".

1 FACT Woodworking
2 TYPE Skills

This groups the fact into a generic skills attribute, and in particular this entry records the fact that this individual possessed the skill of woodworking.

Using a TYPE subrecord with any non-generic event structure clarifies the meaning of the parent subrecord but does not change the basic meaning. For example, a MARR subrecord could be described with a TYPE subrecord to spefict a "Common Law" marriage:

1 MARR
2 TYPE Common Law

Other examples are "stillborn" as a qualifier to BIRT or "Tribal Custom" as a qualifier to MARR.

See:

EVENT_TYPE_CITED_FROM Same as <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.

See: <<SOURCE_CITATION>>.SOUR.EVEN

EVENT_TYPE_FAMILY {Size=3:4}

A code used to indicate a type of family event. The definition is the same as the corresponding event tag_name defined in the Standard Records and Subrecords section. The choices are:

  • ANUL
  • CENS
  • DIV
  • DIVF
  • ENGA
  • MARR
  • MARB
  • MARC
  • MARL
  • MARS
  • EVEN

See: <EVENT_ATTRIBUTE_TYPE>

EVENT_TYPE_INDIVIDUAL {Size=3:4}

A code used to indicate a type of family event. The definition is the same as the corresponding event tag_name defined in the Standard Records and Subrecords section. The choices are:

  • ADOP
  • BIRT
  • BAPM
  • BARM
  • BASM
  • BLES
  • BURI
  • CENS
  • CHR
  • CHRA
  • CONF
  • CREM
  • DEAT
  • EMIG
  • FCOM
  • GRAD
  • IMMI
  • NATU
  • ORDN
  • RETI
  • PROB
  • WILL
  • EVEN

See: <EVENT_ATTRIBUTE_TYPE>

EVENTS_RECORDED {Size=1:90}

EVENTS_RECORDED is a comma-separated list of the different kinds of events that were recorded in a particular source.

EVENTS_RECORDED may be set to one or more values from the types enumerated in the <EVENT_ATTRIBUTE_TYPE> element.

Each value is separated by a comma. A value for a parish register of births, deaths, and marriages would be BIRT, DEAT, MARR.

See: <<SOUR_RECORD>>.SOUR.DATA.EVEN

FILE_NAME {Size=1:90}

The name of the GEDCOM document file.

See: <<HEAD_RECORD>>.HEAD.FILE

GEDCOM_FORM {Size=14:14}

The GEDCOM form used to construct the document. GEDCOM 5.5.2 supports the "LINEAGE-LINKED" form only. The GEDC.FORM subrecord is not required in GEDCOM 5.5.2 and is allowed for backwards-compatibility only.

See the example in the Best Practice section under the HEAD record.

Best Practice Recommendations

  • Some GEDCOM writers specify incorrect values on the GEDC.FORM subrecord.

    • GEDCOM readers should issue an error message for incorrect values.

    • GEDCOM readers should assume that any GEDCOM document with HEAD.VERS set to 5.5.2 uses the lineage-linked form.

See: <<HEAD_RECORD>>.HEAD.GEDC.FORM

ID_FAM Same as ID

A pointer to a FAM_RECORD or an ID of a FAM_RECORD.

See:

ID_INDI Same as ID

A pointer to a INDI_RECORD or an ID of a INDI_RECORD.

See:

ID_NOTE Same as ID

A pointer to a NOTE_RECORD or an ID of a NOTE_RECORD.

See:

ID_OBJE Same as ID

A pointer to a OBJE_RECORD or an ID of a OBJE_RECORD.

See:

ID_REPO Same as ID

A pointer to a REPO_RECORD or an ID of a REPO_RECORD.

See:

ID_SOUR Same as ID

A pointer to a SOUR_RECORD or an ID of a SOUR_RECORD.

See:

ID_SUBM Same as ID

A pointer to a SUBM_RECORD or an ID of a SUBM_RECORD.

See:

LANGUAGE_ID {Size=1:15}

The LANGUAGE_ID identifies a language.

The Family History Department (now FamilySearch) specified LANGUAGE_ID values in GEDCOM 5.5.1. Those values are shown below. More recent standards and systems use language codes, such as IETF language tags, not language names.

Family History Department Languages

The Family History Department identified the following languages as "valid" as of GEDCOM 5.5.1 in 1999.

  • 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

The Family History Department described the following languages as "not supported until UNICODE" as of GEDCOM 5.5.1 in 1999.

  • 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

See:

MULTIMEDIA_FILE_REFERENCE {Size=1:1024}

A MULTIMEDIA_FILE_REFERENCE is the complete path to a local or remote file that contains the multimedia object to be linked to the GEDCOM context.

See:

MULTIMEDIA_FORMAT {Size=3:4}

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.

The choices are:

  • bmp
  • gif
  • jpg
  • ole
  • pcx
  • tif
  • wav

See:

NAME_OF_BUSINESS {Size=1:90}

Name of the business, corporation, or person that produced or commissioned the product.

See: <<HEAD_RECORD>>.HEAD.SOUR.CORP

NAME_OF_PRODUCT {Size=1:90}

The name of the software product that wrote this document.

See: <<HEAD_RECORD>>.HEAD.SOUR.NAME

NAME_OF_REPOSITORY {Size=1:90}

The official name of the archive in which the stated source material is stored.

See: <<REPO_RECORD>>.REPO.NAME

NAME_OF_SOURCE_DATA {Size=1:90}

The name of the electronic data source that was used to obtain the data in this document. For example, the data may have been obtained from a CD-ROM disc that was named "U.S. 1880 CENSUS CD-ROM vol. 13."

See: <<HEAD_RECORD>>.HEAD.SOUR.DATA

NAME_OF_SUBMITTER {Size=1:60}

The name of the submitter formatted for display and address generation.

See: <<SUBM_RECORD>>.SUBM.NAME

NAME_PERSONAL {Size=1:120}

NAME_PERSONAL is a person's name entered in the line_value of a NAME subrecord.

The name value is formed in the manner the name is normally spoken. The surname of an individual, if known, is enclosed between two slash ("/", U+002F) characters. The order of the name parts should be the order that the person would have used when giving it to a recorder.

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:

  • Given name only or surname not known:
    1 NAME William Lee
  • Surname only:
    1 NAME /Parry/
  • Given name and surname:
    1 NAME William Lee /Parry/
  • Surname and suffix:
    1 NAME /Parry/ Jr.
  • Given name, surname, and suffix:
    1 NAME William Lee /Parry/ Jr.

The <<PERSONAL_NAME_PIECES>> structure defines subrecords you may use to define a name via component parts. Even when specifying name pieces, the NAME_PERSONAL line_value must be included.

See:

NAME_PHONETIC_VARIATION {Size=1:120}

NAME_PHONETIC_VARIATION indicates a phonetically-written name value. The phonetically-written variatnon should be written in the same form as the name used in the superior <NAME_PERSONAL> primitive, but transformed using the method indicated by a subordinate TYPE subrecord.

See: <<PERSONAL_NAME_STRUCTURE>>.NAME.FONE

NAME_PIECE_GIVEN {Size=1:120}

NAME_PIECE_GIVEN is the given name.

See: <<PERSONAL_NAME_PIECES>>.GIVN

NAME_PIECE_NICKNAME {Size=1:30}

NAME_PIECE_NICKNAME is a descriptive or familiar name used in connection with the proper name.

See: <<PERSONAL_NAME_PIECES>>.NICK

NAME_PIECE_PREFIX {Size=1:30}

NAME_PIECE_PREFIX is a non-indexing name piece that appears preceding the given name and surname parts.

Multiple prefixes are separated by a comma.

See: <<PERSONAL_NAME_PIECES>>.NPFX

NAME_PIECE_SUFFIX {Size=1:30}

NAME_PIECE_SUFFIX is a non-indexing name piece that appears after the given name and surname parts.

Multiple suffixes are separated by a comma.

See: <<PERSONAL_NAME_PIECES>>.NSFX

NAME_PIECE_SURNAME {Size=1:120}

NAME_PIECE_SURNAME is the surname or family name.

Multiple surnames are separated by a comma.

See: <<PERSONAL_NAME_PIECES>>.SURN

NAME_PIECE_SURNAME_PREFIX {Size=1:30}

NAME_PIECE_SURNAME_PREFIX is a surname prefix or article used in a family name.

See: <<PERSONAL_NAME_PIECES>>.SPFX

NAME_ROMANIZED_VARIATION {Size=1:120}

The romanized variation of the name is written in the same form prescribed for the name used in the superior <NAME_PERSONAL> context. The method used to romanize the name is indicated by the line_value of the TYPE <ROMANIZED_TYPE> subrecord.

See: <<PERSONAL_NAME_STRUCTURE>>.NAME.ROMN

NAME_TEXT {Size=1:120}
<TEXT> excluding slashes ("/", U+002F).

See: <NAME_PERSONAL>

NAME_TYPE {Size=5:30}

NAME_TYPE indicates the type of a name where the choices are:

ChoiceDescription
akaAlso known as, alias, etc.
birthName given on birth certificate.
immigrantName assumed at the time of immigration.
maidenMaiden name, name before first marriage.
marriedName was persons previous married name.
user-definedOther text that defines the name type.

See: <<PERSONAL_NAME_STRUCTURE>>.NAME.TYPE

NATIONAL_ID_NUMBER {Size=1:30}

NATIONAL_ID_NUMBER is a nationally-controlled number assigned to an individual.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.IDNO

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.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.NATI

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.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.TITL

NOTE_TEXT {Size=1:M}

Comments from the submitter composed of any valid character from the Unicode character set but subject to the syntax rules for the line_value component.

See: <<NOTE_STRUCTURE>>.NOTE

NULL {Size=0:0}

A convention used to describe the absence of data.

See:

OCCUPATION {Size=1:90}

The kind of activity that an individual does for a job, profession, or principal activity.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.OCCU

PEDIGREE_LINKAGE_TYPE {Size=5:7}

A code used to indicate the child to family relationship for pedigree navigation purposes. The choices are:

ChoiceDescription
adoptedindicates adoptive parents.
birthindicates birth parents.
fosterindicates child was included in a foster or guardian family.

See: <<CHILD_TO_FAMILY_LINK>>.FAMC.PEDI

PHONE_NUMBER {Size=1:25}

A telephone number.

See: <<CONTACT_STRUCTURE>>.PHON

PHONE_NUMBER_FAX {Size=5:60}

A FAX telephone number appropriate for sending data facsimiles.

PHONETIC_TYPE {Size=4:30}

A code or text value that indicates the method used in transforming text to a phonetic variation. The choices are:

ChoiceDescription
hangulPhonetic method for sounding Korean glifs.
kanaHiragana and/or Katakana characters were used in sounding the Kanji character used by japanese
user-definedName or description of method used to arrive at the phonetic variation of the name.

For example, if hiragana was used to provide a phonetic variation of a name originally written in kanji, then the PHONETIC_TYPE value would be kana.

See:

PHYSICAL_DESCRIPTION Same as TEXT

A <TEXT> value specifying a comma-separated list of the attributes that describe the physical characteristics of an individual.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.DSCR

PLACE_HIERARCHY {Size=1:120}

PLACE_HIERARCHY describes the geographic hierarchy of a place name. The elements of the hierarchy are separated by commas, with the lowest (most specific) element first, followed by higher, less specific elements.

For example, the place element names for an address in the United States might be specified as:

1 PLAC
2 FORM Addressee,Detail,City,County,State,Country

A PLACE_HIERARCHY may be provided in two contexts:

  • When a PLAC.FORM structure is included in the HEAD_RECORD, the PLACE_HIERARCHY applies to all PLAC subrecords except PLAC subrecords that include a PLAC.FORM subrecord.
  • When a PLAC.FORM structure is subordinate to an event, the PLACE_HIERARCHY applies to the PLAC value for that event only and overrides a PLACE_HIERARCHY supplied in the HEAD_RECORD, if any.

When a PLACE_HIERARCHY applies to a PLAC value, the PLAC value must include the same number of elements as the PLAC.FORM. The value must use commas to indicate missing or unknown elements in the hierarchical value.

For example, given the PLACE_HIERARCHY "Addressee,Detail,City,County,State,Country", a PLAC record with missing Addressee and Country elements would appear as follows:

2 PLAC ,1 Main Street,Ames,Story,Iowa,

See:

PLACE_LATITUDE {Size=2:10}

PLACE_LATITUDE is the value specifying the latitudinal coordinate of a place. The latitude coordinate is the direction north or south from the equator in degrees and fraction of degrees.

The value must start with a direction letter, "N" for north or "S" for south.

The remaining characters must specify a decimal degree value ranging from 0 to 89.999999 degrees.

Decimal degrees are an alternative to using degrees, minutes, and seconds.

For example: 18 degrees, 9 minutes, and 3.4 seconds north would be formatted as N18.150944. Minutes and seconds are converted by dividing the minutes value by 60 and the seconds value by 3600 and adding the results together. This sum becomes the fractional part of the degree's value.

The shortest possible value is two characters: "N0" or "S0". The longest possible value is ten characters: one character for direction (N, S), two digits before the decimal point, the decimal point, and six digits after the decimal point. For example, "N89.123456".

See the MAP subrecord for other map-related details.

See: <<PLACE_STRUCTURE>>.PLAC.MAP.LATI

PLACE_LONGITUDE {Size=2:11}

PLACE_LONGITUDE is the value specifying the longitudinal coordinate of a place. The longitude coordinate is the direction east or west from the Prime Meridian in degrees and fraction of degrees.

The value must start with a direction letter, "E" for east or "W" for west.

The remaining characters must specify a decimal degree value ranging from 0 to 179.999999 degrees.

Decimal degrees are an alternative to using degrees, minutes, and seconds.

For example: 168 degrees, 9 minutes, and 3.4 seconds east would be formatted as E168.150944. Minutes and seconds are converted by dividing the minutes value by 60 and the seconds value by 3600 and adding the results together. This sum becomes the fractional part of the degree's value.

The shortest possible value is two characters: "E0" or "W0". The longest possible value is eleven characters: one character for direction (E, W), three digits before the decimal point, the decimal point, and six digits after the decimal point. For example, "E179.123456".

See the MAP subrecord for other map-related details.

See: <<PLACE_STRUCTURE>>.PLAC.MAP.LONG

PLACE_NAME {Size=1:120}

PLACE_NAME is the name of the place where the event took place. Textual elements of the place hierarchy are separated by commas, for example, "Cove, Cache, Utah, USA".

PLACE_NAME is specified in one of the following formats:

See:

PLACE_PHONETIC_VARIATION {Size=1:120}

The phonetic variation of the place name is written in the same form as was the place name used in the superior <PLACE_NAME> primitive, but phonetically written using the method indicated by the subordinate <PHONETIC_TYPE> value, for example if hiragana was used to provide a reading of a name written in kanji, then the <PHONETIC_TYPE> value would indicate kana. (See <PHONETIC_TYPE>)

See: <<PLACE_STRUCTURE>>.PLAC.FONE

PLACE_ROMANIZED_VARIATION {Size=1:120}

The romanized variation of the place name is written in the same form prescribed for the place name used in the superior <PLACE_NAME> context. The method used to romanize the name is indicated by the line_value of the subordinate <ROMANIZED_TYPE>, for example if romaji was used to provide a reading of a place name written in kanji, then the <ROMANIZED_TYPE> subordinate to the ROMN tag would indicate "romaji". (See <ROMANIZED_TYPE>)

See: <<PLACE_STRUCTURE>>.PLAC.ROMN

PLACE_TEXT {Size=1:120}

PLACE_TEXT is a <TEXT> value excluding commas (",", U+002C).

See: <PLACE_NAME>

POSSESSIONS Same as TEXT

POSSESSIONS is a <TEXT> value containing a list of possessions (real estate or other property) belonging to this individual.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.PROP

PUBLICATION_DATE Same as DMY_EXACT

The date this source was published or created.

See: <<HEAD_RECORD>>.HEAD.SOUR.DATA.DATE

RELATION_IS_DESCRIPTOR {Size=1:25}

A word or phrase that describes the relationship or association between two individuals.

See: <<ASSOCIATION_STRUCTURE>>.ASSO.RELA

RELIGIOUS_AFFILIATION {Size=1:90}

A name of the religion with which this person, event, or record was affiliated.

See:

RESPONSIBLE_AGENCY {Size=1:120}

The organization, institution, corporation, person, or other entity that has responsibility for 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.

See:

RESTRICTION_NOTICE {Size=6:12}

The RESTRICTION_NOTICE indicates a restriction on the use of the data associated with the superior subrecord. The choices are:

ChoiceDescription
confidentialThis data was marked as confidential by the user. In some systems data marked as confidential will be treated differently, for example, there might be an option that would stop confidential data from appearing on printed reports or would prevent that information from being exported.
lockedThis data was marked as locked by the user. A lock indicates that the sending system is requesting that the data be treated as read-only.
privacyIndicates that data has been marked private by the user and is not present.

See:

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.

See: <ROLE_IN_EVENT>

ROLE_IN_EVENT {Size=1:15}

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.

See: <<SOURCE_CITATION>>.SOUR.EVEN.ROLE

ROMANIZED_TYPE {Size=5:30}

A keyword or text value that describes the method used in transforming text to a romanized variation. The choices are:

  • pinyin
  • romaji
  • wadegiles
  • user-defined

See:

SCHOLASTIC_ACHIEVEMENT Same as TEXT

A <TEXT> value specifying a scholastic or educational achievement or pursuit.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.EDUC

SEX_VALUE {Size=1:1}

A code that indicates the sex of the individual where the choices are:

ChoiceDescription
MMale
FFemale
UUndetermined from available records and quite sure that it can't be.

See: <<INDI_RECORD>>.INDI.SEX

SOCIAL_SECURITY_NUMBER {Size=9:11}

A number assigned to a person in the United States for identification purposes.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.SSN

SOURCE_CALL_NUMBER {Size=1:120}

An identification or reference description used to file and retrieve items from the holdings of a repository.

See: <<SOURCE_REPOSITORY_CITATION>>.REPO.CALN

SOURCE_DESCRIPTION Same as TEXT

A <TEXT> value used to describe the source from which information was obtained.

This text 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 the 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 <<SOUR_RECORD>> method of reporting bibliographic reference descriptions.

See: <<SOURCE_CITATION>>.SOUR

SOURCE_DESCRIPTIVE_TITLE Same as TEXT

A <TEXT> value specifying 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.

See: <<SOUR_RECORD>>.SOUR.TITL

SOURCE_FILED_BY_ENTRY {Size= 1:60}

SOURCE_FILED_BY_ENTRY is a short title used for sorting, filing, and retrieving source records.

See: <<SOUR_RECORD>>.SOUR.ABBR

SOURCE_JURISDICTION_PLACE {Size=1:120}
<PLACE_NAME>

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.

See: <<SOUR_RECORD>>.SOUR.DATA.EVEN.PLAC

SOURCE_MEDIA_TYPE {Size=1:15}

A code that indicates the type of material in which the referenced source is stored. The choices are:

  • audio
  • book
  • card
  • electronic
  • fiche
  • film
  • magazine
  • manuscript
  • map
  • newspaper
  • photo
  • tombstone
  • video

See:

SOURCE_ORIGINATOR Same as TEXT

A <TEXT> value specifying 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.

See: <<SOUR_RECORD>>.SOUR.AUTH

SOURCE_PUBLICATION_FACTS Same as TEXT

A <TEXT> value specifying when and where the record was created.

For a published work, it 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.

See: <<SOUR_RECORD>>.SOUR.PUBL

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.

See: <<SUBM_RECORD>>.SUBM.RFN

SYSTEM_ID {Size=1:60}

A name that identifies a sending (HEAD.SOUR) or receiving (HEAD.DEST) system.

Names must be unique, but there is no central authority to manage SYSTEM_IDs, so it is up to system implementers to use values that avoid collisions.

Spaces (" ", U+0020) within the name must be substituted with an underscore ("_", U+005F) to create a value with no spaces.

See:

TEXT {Size=1:248}

A sequence of characters composed of any valid character from the Unicode character set but subject to the syntax rules for the line_value component.

See:

TEXT_FROM_SOURCE Same as 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 to the researcher's interpretation. The word TEXT, in this case, means from the text which appeared in the source record including labels.

See:

TIME_VALUE {Size=5:11}

The time of a specific event, in the pattern "hh:mm:ss.ff", where:

  • hh is the hour, a two-digit value from "00" to "24".
  • : is a separator.
  • mm = is the minute, a two digit value from "00" to "59".
  • : is a separator; omit this separator if the "ss" component is not supplied.
  • ss = is the second, an optional two-digit value from "00" to "59".
  • . is a separator; omit this separator if the "ff" component is not supplied.
  • ff = is the fractional second, an optional two-digit value from "00" to "99". "ff" must be omitted if "ss" is omitted.

All the components must be specified as two digits, i.e., leading zeroes are required for the values zero to nine.

See:

USER_REFERENCE_NUMBER {Size=1:20}

A user-defined identifier that the submitter uses to identify a record.

For example, 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.

See:

USER_REFERENCE_TYPE {Size=1:40}

A user-defined label or definition of the <USER_REFERENCE_NUMBER>.

See:

VERSION_NUMBER {Size=1:15}

An identifier that describes the version of a software system or specification.

See:

WHERE_WITHIN_SOURCE Same as TEXT

A <TEXT> value that describes a specific location within 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 or microfilmed works, this could be a film or sheet number, page number, frame number, etc. A census record might have an enumerating district, page number, line number, dwelling number, and family number.

The data in this field should be in the form of a label and value pair, such as Label1: value, Label2: value, with each pair being separated by a comma. For example, Film: 1234567, Frame: 344, Line: 28.

See: <<SOURCE_CITATION>>.SOUR.PAGE

Primitive Elements for Dates

The elements in this section define the syntax for date text. See the Primitive Elements section for definitions of other primitive elements and for a description of the conventions used to define the entries.

The elements are in alphabetical sequence except for <DATE_VALUE> which is first because it is the top-level element describing date text.

Element names with the prefix "DMY_" define elements related to the day, month, and year components of a date. All other element names have the prefix "DATE_".

DATE_VALUE {Size=3:35}

A DATE_VALUE is a date or partial date in text format. The text may include optional keywords. The day, month, and year may be expressed using one of several <DMY_CALENDARs>.

Through its subordinate primitives, a DATE_VALUE may express exact dates, partial dates, approximate dates, calculated dates, date ranges, date periods, estimated dates, and interpreted dates.

Summary

This summary is non-normative. The date-related Primitive Elements define the actual syntax.

The date syntax includes the following components:

  • An optional keyword to modify the meaning of the date.

    • <DATE_APPROXIMATED> keywords indicate an approximate, calculated, or estimated date.
    • <DATE_PERIOD> keywords indicate an attribute, condition, or state existed for the given time period.
    • <DATE_RANGE> keywords indicate an event occurred on a single date within the given range..
    • <DATE_INTERPRETED> keyword indicates the given date was derived from the associated <DATE_PHRASE>.
  • An optional <DMY_CALENDAR_ESCAPE> to indicate which calendar is in use. If no DMY_CALENDAR_ESCAPE is present, the <DMY_GREGORIAN> calendar is used.
  • An optional <DMY_DAY> number.
  • An optional <DMY_MONTH> abbreviation. The valid month abbreviations vary according to the calendar in use.
  • A <DMY_YEAR> number. The year is a required component of all dates except for a date that is composed of a <DATE_PHRASE> only.
  • An optional <DATE_PHRASE>

The <DATE_PERIOD> and <DATE_RANGE> keywords allow two dates to be provided in order to form a date range.

Examples

The table below shows example dates with a description that enumerates the components.

line_value Explanation
2018 Year: 2018
NOV 2018 Month: November
Year: 2018
18 NOV 2018 Day: 18
Month: November
Year: 2018
@#DGREGORIAN@ 22 FEB 1732 Calendar: <DMY_GREGORIAN>
Day: 22
Month: February
Year: 1732
@#DJULIAN@ 11 FEB 1731 Calendar: <DMY_JULIAN>
Day: 11
Month: February
Year: 1731
BEF 2018 Modifier: <BEF> (before)
Year: 2018
AFT NOV 2018 Modifier: <AFT> (after)
Month: November
Year: 2018
BET 1927 AND 1928 Modifier: <BET/AND> (between)
Year 1: 1927
Year 2: 1928

Syntax

A GEDCOM date must be described by one of the following date primitives:

See:

DATE_APPROXIMATED {Size=4:35}

DATE_APPROXIMATED uses a keyword to describe an approximate date. The format choices are as follows:

where

  • ABT before a <DMY> indicates the date is not exact.
  • CAL before a <DMY> indicates the date was calculated mathematically, for example, from an event date and age.
  • EST before a <DMY> indicates the date was estimated based on an algorithm using some other event date.

See:

DATE_INTERPRETED {Size=11:35}

A DATE_INTERPRETED primitive asserts that an event happened on a date whose value has been interpreted from knowledge about the given <DATE_PHRASE> text.

The DATE_INTERPRETED primitive is assembled from the INT keyword and two primitive components:

INT <DMY> <DATE_PHRASE>

All three primitive components are required.

See:

DATE_PERIOD {Size=7:35}

A DATE_PERIOD asserts that a condition, state, or attribute existed during the given period and is intended for use with the INDIVIDUAL_ATTRIBUTE_STRUCTURE.

In contrast, a <DATE_RANGE> asserts that an event happened on a single date somewhere in a given range.

The DATE_PERIOD is specified in one of the following formats:

where

  • FROM before a <DMY> indicates the beginning date, inclusive.
  • TO before a <DMY> indicates the ending date, inclusive.

Examples:

FROM 1904 to 1915 The state of some attribute existed from 1904 to 1915, inclusive.
FROM 1904 The state of some attribute began in 1904 and the ending date is unknown.
TO 1915 The state of some attribute ended in 1915 and the beginning date is unknown.

See:

DATE_PHRASE {Size=3:35}

A DATE_PHRASE is text offered as a date which gives information about when an event occurred.

The text must begin with a left parenthesis ("(", U+0028) and end with a right parenthesis (")", U+0029).

When the DATE_PHRASE is the only component of a <DATE_VALUE>, DATE_PHRASE is limited to 35 characters, including 33 characters of date text and the "(" and ")" delimiters.

When the DATE_PHRASE is used with the INT keyword of the <DATE_INTERPRETED> primitive, the DATE_PHRASE length limit is reduced by the length of the other characters in the <DATE_VALUE> For example, the "phrase" portion of INT 22 FEB 1731 (phrase) is limited to 17 characters because the INT portion uses 16 characters and the phrase delimiters require 2 characters (35 - (16+2) = 17).

An acceptable alternative to using a DATE_PHRASE is to use a <DATE_APPROXIMATED> keyword with an appropriate day, month, and year, and then include the date phrase value as a NOTE value subordinate to the DATE subrecord.

See:

DATE_RANGE {Size=8:35}

A DATE_RANGE asserts that an event happened on a single date somewhere in the given range.

In contrast, a <DATE_PERIOD> asserts that a condition, state, or attribute existed during a given period.

The DATE_PERIOD is specified in one of the following formats:

where

  • AFT before a <DMY> indicates the event happened after the given date.

  • BEF before a <DMY> indicates the event happened before the given date.

  • BET indicates the event happened some time between the two <DMY>s.

    For example, BET 1927 AND 1928 indicates that the event state (perhaps a single day) existed somewhere between 1927 and 1928 inclusive.

The following are equivalent and interchangeable:

Short FormLong Form
1852BET 1 JAN 1852 AND 31 DEC 1852
1852BET 1 JAN 1852 AND DEC 1852
1852BET JAN 1852 AND 31 DEC 1852
1852BET JAN 1852 AND DEC 1852
JAN 1920BET 1 JAN 1920 AND 31 JAN 1920

See:

DMY {Size=1:35}

DMY combines the day, month, and year parts of a date with an optional <DMY_CALENDAR_ESCAPE> to override the default <DMY_GREGORIAN>calendar.

The syntax choices for DMY are:

  • <DMY_GREGORIAN>
    If no calendar is specified, the day, month, and year are assumed to be Gregorian.

  • @#DGREGORIAN@ <DMY_GREGORIAN>
    The Gregorian calendar may be specified explicitly.

  • @#DJULIAN@ <DMY_JULIAN>
    The Julian calendar may be specified explicitly.

  • @#DHEBREW@ <DMY_HEBREW>
    The Hebrew calendar may be specified explicitly.

  • @#DFRENCH R@ <DMY_FRENCH>
    The French Republic calendar may be specified explicitly.

See:

DMY_BC {Size=4:4}

DMY_BC is the literal text "B.C.". Adding "B.C." indicates a "Before Common Era" date.

"B.C." is added immediately after the last digit in the year with no intervening space(s).

Using "B.C." as a suffix is an option when the value includes a year only.

Example: 44B.C.

Best Practice Recommendations

  • Users may key variations in place of B.C. and may enter a space before the value.

    • GEDCOM readers should accept the following variations and issue a warning message.

      • 44BC
      • 44BCE

    • GEDCOM readers should accept a space before one of the variations and issue a warning message.

      • 44 B.C.
      • 44 BC
      • 44 BCE

See:

DMY_CALENDAR {Size=4:35}

The DMY_CALENDAR options listed below define day, month and year values using the indicated calendar. The supported calendars are:

See:

DMY_CALENDAR_ESCAPE {Size=4:15}

The DMY_CALENDAR_ESCAPE is an escape_sequence that identifies a <DMY_CALENDAR>. The DMY_CALENDAR_ESCAPE choices are:

Escape SequenceCalendar
@#DGREGORIAN@<DMY_GREGORIAN>
@#DJULIAN@<DMY_JULIAN>
@#DHEBREW@<DMY_HEBREW>
@#DFRENCH R@<DMY_FRENCH>

See:

DMY_DAY {Size=1:2}

DMY_DAY is the day of the month specified using one-digit or two-digits whose value is within the valid range of the days for the associated calendar month. For example, in the Gregorian calendar, the DMY_DAY value for September must be in the range 1 to 30.

A two-digit number whose first digit is zero ("0", U+0030) is valid if the second digit is not zero.

See:

DMY_EXACT {Size=10:11}

An exact date using the Gregorian calendar in the following format:

<DMY_DAY> <DMY_MONTH> <DMY_YEAR_GREGORIAN>

See:

DMY_FRENCH {Size=4:35}

DMY_FRENCH is a date represented using the French calendar in one of the following formats:

See:

DMY_GREGORIAN {Size=4:35}

DMY_GREGORIAN is a date represented using the Gregorian calendar in one of the following formats:

See:

DMY_HEBREW {Size=4:35}

DMY_HEBREW is a date represented using the Hebrew calendar in one of the following formats:

See:

DMY_JULIAN {Size=4:35}

DMY_JULIAN is a date represented using the Julian calendar in one of the following formats:

See:

DMY_MONTH {Size=3}

DMY_MONTH is a three-character abbreviation indicating a month of the year where the choices are:

ChoiceDescription
JANJanuary
FEBFebruary
MARMarch
APRApril
MAYMay
JUNJune
JULJuly
AUGAugust
SEPSeptember
OCTOctober
NOVNovember
DECDecember

Best Practice Recommendations

  • Some GEDCOM dates may use month abbreviations that are not all-uppercase.

    • GEDCOM readers should use case-insensitve comparisons for month abbreviations. Any combination of uppercase, lowercase, and mixed case should be accepted for month abbreviatins.

See:

DMY_MONTH_FRENCH {Size=4}

DMY_MONTH_FRENCH is a four-character abbreviation indicating a month of the year where the choices are:

ChoiceDescription
VENDVENDEMIAIRE
BRUMBRUMAIRE
FRIMFRIMAIRE
NIVONIVOSE
PLUVPLUVIOSE
VENTVENTOSE
GERMGERMINAL
FLORFLOREAL
PRAIPRAIRIAL
MESSMESSIDOR
THERTHERMIDOR
FRUCFRUCTIDOR
COMPJOUR_COMPLEMENTAIRS

Best Practice Recommendations

  • Some GEDCOM dates may use month abbreviations that are not all-uppercase.

    • GEDCOM readers should use case-insensitve comparisons for month abbreviations. Any combination of uppercase, lowercase, and mixed case should be accepted for month abbreviatins.

See: <DMY_FRENCH>

DMY_MONTH_HEBREW {Size=3}

DMY_MONTH_HEBREW is a three-character abbreviation indicating a month of the year where the choices are:

ChoiceDescription
TSHTishri
CSHCheshvan
KSLKislev
TVTTevet
SHVShevat
ADRAdar
ADSAdar Sheni
NSNNisan
IYRIyar
SVNSivan
TMZTammuz
AAVAv
ELLElul

Best Practice Recommendations

  • Some GEDCOM dates may use month abbreviations that are not all-uppercase.

    • GEDCOM readers should use case-insensitve comparisons for month abbreviations. Any combination of uppercase, lowercase, and mixed case should be accepted for month abbreviatins.

See: <DMY_HEBREW>

DMY_YEAR {Size=3:4}

DMY_YEAR is a three-digit or four-digit number indicating the year in which an event occurred.

The three-digit minimum length may have been specified to differentiate day numbers from year numbers. To specify one and two digit years, add leading zeroes. For one-digit years, add two leading zeroes so the length of the year number is three digits. For two-digit years, add one leading zero so the length of the year number is three digits.

Some syntactically valid numbers may not be valid in the current calendar.

See:

DMY_YEAR_GREGORIAN {Size=3:7}

DMY_YEAR_GREGORIAN is a three-digit or four-digit number indicating the year in which an event occurred in the Gregorian calendar.

The three-digit minimum length may have been specified to differentiate day numbers from year numbers. To specify one and two digit years, add leading zeroes. For one-digit years, add two leading zeroes so the length of the year number is three digits. For two-digit years, add one leading zero so the length of the year number is three digits.

The year number may be followed by a slash ("/", U+002F) and an alternate-year number with one or two digits. This is used for the possible date alternatives for pre-1752 dates brought about by a changing the beginning of the year from MAR to JAN in the English calendar change of 1752, for example, 11 FEB 1731/2.

See:

Standard Records and Subrecords

Introduction

The Records and Subrecords listed below by their tag_names are used in a hierarchical structure to describe genealogy-related data.

The entries define the meaning of the Record or Subrecord that uses the given tag_name and must be placed in the context(s) shown in the Subrecords section. Some tag_names are used in multiple contexts, so some entries include multiple definitions.

Many tag_names are abbreviations. The definitions include the full name. The full names cannot be used in place of the official tag_names.

Definitions

ABBR Abbreviation

The ABBR subrecord specifies an abbreviated name or title of a source via its <SOURCE_FILED_BY_ENTRY> line_value.

See: <<SOUR_RECORD>>.SOUR.ABBR <SOURCE_FILED_BY_ENTRY>

ADDR Address

The ADDR subrecord specifies a contemporary place as required for postal purposes via its <ADDRESS_VALUE> value.

The ADDR subrecord's <ADDRESS_VALUE> line_value should be specified using one or more CONT subrecords to specify multiple lines in the resulting value.

See: <<ADDRESS_STRUCTURE>>.ADDR <ADDRESS_VALUE>

ADR1 Address1

The ADR1 subrecord specifies the first line of an address via its <ADDRESS_LINE> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.ADR1 <ADDRESS_LINE>

ADR2 Address2

The ADR2 subrecord specifies the second line of an address via its <ADDRESS_LINE> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.ADR2 <ADDRESS_LINE>

ADR3 Address3

The ADR3 subrecord specifies the third line of an address via its <ADDRESS_LINE> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.ADR3 <ADDRESS_LINE>

ADOP Adoption

The ADOP subrecord describes a legal event that creates a child-parent relationship that does not exist biologically, such as an adoption.

See:

AGE Age

The AGE subrecord specifies the age of the individual at the time an event occurred, or the age listed in the document, via its <AGE_AT_EVENT> line_value.

See:

AGNC Agency

The AGNC subrecord specifies the name of an institution or individual having authority and/or responsibility to manage or govern via its <RESPONSIBLE_AGENCY> line_value.

See:

ALIA Alias

The ALIA subrecord links another INDI record to the current INDI record via its <ID_INDI> line_value and indicates that the two records may refer to the same person.

An ALIA record must not be used to define an alternate name. To define alternate names, use NAME subrecords.

Unfortunately, led astray by popular—but incorrect—programs, some programs misuse the ALIA subrecord and use it to specify an alternate name.

Best Practice Recommendations

  • Some programs use ALIA to specify an alternate name.

    • GEDCOM writers should not use ALIA to write alternate names.

    • GEDCOM readers should validate the ALIA line_value. If it is not a syntactically-valid pointer, the GEDCOM reader should treat the value as a name.

      Attempting to process names in ALIA records is error-prone. Misused ALIA records usually do not delimit the surname with "/" characters, and it is not advisable to try and detect a surname automatically.

See: <<INDI_RECORD>>.INDI.ALIA <ID_INDI>

ANCI Ancestor Interest

The ANCI subrecord indicates an interest in additional research on ancestors of the current individual.

Interest in descendants is indicated via the DESI subrecord.

See: <<INDI_RECORD>>.INDI.ANCI <ID_SUBM>

ANUL Annulment

The ANUL subrecord describes an annulment event, i.e., declaring a marriage void as if it never existed.

See: <<FAMILY_EVENT_STRUCTURE>>.ANUL

ASSO Association

The ASSO subrecord describes an association between the current INDI_RECORD and the INDI record with the ID given in the ASSO subrecord's <ID_INDI> line_value.

The ASSO.RELA subrecord classifies the relationship.

For example, you would read the following as "Fred Smith's godfather is the person described by the INDI_RECORD with ID @I2@:

0 @I1@ INDI
1 NAME Fred /Smith/
1 ASSO @I2@
2 RELA godfather

See: <<ASSOCIATION_STRUCTURE>>.ASSO <ID_INDI>

AUTH Author

The AUTH subrecord specifies the name of the individual who created or compiled information via its <SOURCE_ORIGINATOR> line_value.

See: <<SOUR_RECORD>>.SOUR.AUTH <SOURCE_ORIGINATOR>

BAPM Baptism

The BAPM subrecord describes the event of baptism.

See also CHR.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BAPM

BARM Bar Mitzvah

The BARM subrecord describes a Bar Mitzvah event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BARM

BASM Bas Mitzvah

The BASM subrecord describes a Bas Mitzvah/Bat Mitzvah event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BASM

BIRT Birth

The BIRT subrecord describes a birth event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BIRT <NULL>

BLES Blessing

The BLES subrecord describes a religious event of bestowing a blessing, sometimes given in connection with a naming ceremony.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BLES

BURI Burial

The BURI subrecord describes a burial event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.BURI

CALN Call Number

The CALN subrecord indicates the number used by a repository to identify the specific items in its collections via its <SOURCE_CALL_NUMBER> line_value.

See: <<SOURCE_REPOSITORY_CITATION>>.REPO.CALN <SOURCE_CALL_NUMBER>

CAST Caste

The CAST subrecord specifies the name of an individual's hereditary rank or status via its <CASTE_NAME> line_value.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.CAST <CASTE_NAME>

CAUS Cause

The CAUS subrecord describes the cause of the associated event or fact, such as the cause of death, via its <CAUSE_OF_EVENT> line_value.

See: <<EVENT_OR_FACT_DETAIL>>.CAUS <CAUSE_OF_EVENT>

CENS Census

The CENS event describes the enumeration of an individual or family in a periodic count of a population, such as a national or state census.

See:

CHAN Change

The CHAN subrecord indicates the date of the last change, correction, or modification to its parent record.

See: <<CHANGE_DATE>>.CHAN

CHAR Character Encoding

The CHAR subrecord specifies the character encoding of the GEDCOM document via its <CHARACTER_ENCODING> line_value.

The only valid character encoding is UTF-8. UTF-8 is defined by the Unicode® Standard which is maintained by the Unicode Technical Committee. As of January 1, 2019, the current version of the Unicode® Standard is 11.0.0.

GEDCOM readers must reject GEDCOM 5.5.2 documents that specify any value other than "UTF-8" in HEAD.CHAR.

GEDCOM readers must reject GEDCOM 5.5.2 documents that use any character encoding other than UTF-8.

GEDCOM writers must use UTF-8 character encoding when writing a GEDCOM 5.5.2 document.

The Byte Order Mark for UTF-8 (U+00EF, U+00BB, U+00BF) must? must not? should? should not? be the first content in GEDCOM documents.

The CHAR subrecord should be one of the first subrecords under the HEAD record.

The CHAR subrecord should appear before any text in the document that is outside the ASCII range (0x00 to 0x7F).

Example:

0 HEAD
1 CHAR UTF-8

See:

CHIL Child

The CHIL subrecord is used in the context of a <<FAM_RECORD>> to specify a pointer to an <<INDI_RECORD>> for a person who is a child in the family.

See: <<FAM_RECORD>>.FAM.CHIL <ID_INDI>

CHR Christening

The CHR subrecord describes the religious event of baptizing and/or naming a child.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.CHR <NULL>

CHRA Adult Christening

The CHRA subrecord describes the religious event of baptizing and/or naming an adult person.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.CHRA

CITY City

The CITY subrecord specifies the name of the village, town, city, or similar political division in an <<ADDRESS_STRUCTURE>> via its <ADDRESS_CITY> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.CITY <ADDRESS_CITY>

CONC Concatenation

The CONC subrecord adds additional text to the parent line_value.

See the Continuations section for details.

See: CONT and CONC Change

CONF Confirmation

The CONF subrecord describes the religious event of confirmation.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.CONF

CONT Continuation

The CONT subrecord adds additional text to the parent line_value.

See the Continuations section for details.

See:

COPR Copyright

A COPR subrecord specifies a copyright statement.

See:

CORP Corporate

A CORP subrecord specifies the name of an agency, company, corporation, or institution.

See: <<HEAD_RECORD>>.HEAD.SOUR.CORP <NAME_OF_BUSINESS>

CREM Cremation

A CREM subrecord describes a cremation event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.CREM

CTRY Country

The CTRY subrecord specifies the name of a country in an <<ADDRESS_STRUCTURE>> via its <ADDRESS_COUNTRY> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.CTRY <ADDRESS_COUNTRY>

DATA Data

The DATA subrecord is used in multiple contexts.

When used under a source record (<<SOUR_RECORD>>.SOUR), a DATA subrecord describes metadata about a source.

When used under a source citation (<<SOURCE>_CITATION>>.SOUR), a DATA subrecord describes the text drawn from the source and/or its entry date via its TEXT or DATE subrecords.

When used under the HEAD.SOUR context, the DATA subrecord specifies the name of the GEDCOM document's electronic data source via its <NAME_OF_SOURCE_DATA> line_value.

See:

DATE Date

The DATE subrecord specifies when an event occurred. It is used in several contexts.

Context and line_value
CHAN.DATE <CHANGE_DATE>
HEAD.DATE <DOCUMENT_DATE>
HEAD.SOUR.DATA.DATE <PUBLICATION_DATE>
<<EVENT_OR_FACT_DETAIL>>.DATE <DATE_VALUE>
<<SOURCE_CITATION>>.SOUR.DATA.DATE <ENTRY_RECORDING_DATE>
<<SOUR_RECORD>>.SOUR.DATA.EVEN.DATE <DATE_PERIOD>

<CHANGE_DATE>, <DOCUMENT_DATE> and <PUBLICATION_DATE> are all the same as <DMY_EXACT>.

<ENTRY_RECORDING_DATE> is the same as <DATE_VALUE>.

See:

DEAT Death

The DEAT subrecord describes a death event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.DEAT <NULL>

DESI Descendant Interest

The DESI subrecord indicates an interest in additional research on descendants of the current individual.

Interest in ancestors is indicated via the ANCI subrecord.

See: <<INDI_RECORD>>.INDI.DESI <ID_SUBM>

DEST Destination

The DEST subrecord identifies the system intended to receive the data via its <SYSTEM_ID> line_value.

For important information about using the DEST subrecord, see the HEAD.SOUR and HEAD.DEST section.

See: <<HEAD_RECORD>>.HEAD.DEST <SYSTEM_ID>

DIV Divorce

A DIV subrecord describes a divorce event.

See: <<FAMILY_EVENT_STRUCTURE>>.DIV

DIVF Divorce Filed

A DIVF subrecord describes the event of filing for divorce.

See: <<FAMILY_EVENT_STRUCTURE>>.DIVF

DSCR Physical Description

The DSCR subrecord describes the physical characteristics of a person via its <PHYSICAL_DESCRIPTION> line_value.

Example:

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

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.DSCR <PHYSICAL_DESCRIPTION>

EDUC Education

The EDUC subrecord describes an educational achievement.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.EDUC <SCHOLASTIC_ACHIEVEMENT>

EMAIL Email

The EMAIL subrecord specifies an electronic mail address via its <ADDRESS_EMAIL>

See: <<CONTACT_STRUCTURE>>.EMAIL <ADDRESS_EMAIL>

EMIG Emigration

The EMIG subrecord describes an emigration event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.EMIG

ENGA Engagement

The ENGA subrecord describes an engagement event.

See: <<FAMILY_EVENT_STRUCTURE>>.ENGA

EVEN (Generic Event)

An EVEN subrecord in the context of <<FAMILY_EVENT_STRUCTURE>> or <<INDIVIDUAL_EVENT_STRUCTURE>> describes a noteworthy happening related to an individual or family.

An EVEN subrecord must be qualified by a subordinate TYPE subrecord to classify the event.

For example, the INDI record for a person that signed a lease for land dated October 2, 1837 and a lease for equipment dated November 4, 1837 would include the following subrecords:

1 EVEN
2 TYPE Land Lease
2 DATE 2 OCT 1837
1 EVEN
2 TYPE Equipment Lease
2 DATE 4 NOV 1837

For more information, see the TYPE subrecord.

See:

EVEN (Event Types)

An EVEN subrecord in the context of a SOUR.DATA subrecord indicates the event types that were recorded in a particular source via its <EVENTS_RECORDED> value.

An EVEN subrecord in the context of a <<SOURCE_CITATION>> indicates the event type which was responsible for the source entry being recorded via its <EVENT_TYPE_CITED_FROM> value.

See:

FACT Fact

A FACT subrecord describes a noteworthy attribute of an individual. A FACT subrecord must be qualified by a subordinate TYPE subrecord to classify the fact.

For more information, see the TYPE tag.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.FACT <ATTRIBUTE_DESCRIPTOR>

FAM Family

The FAM record describes a family via the subrecords defined for the <<FAM_RECORD>>. An <ID_FAM> pointer is required.

The subrecords of the <<FAM_RECORD>> identify the couple and their children (if any) and events shared by the couple.

See: <<FAM_RECORD>>.FAM <ID_FAM>

FAMC Family Child

The FAMC subrecord identifies a family in which an individual appears as a child via its <ID_FAM> line_value.

See:

FAMS Family Spouse

The FAMS subrecord identifies the family in which an individual appears as a member of a couple via its <ID_FAM> line_value.

See: <<SPOUSE_TO_FAMILY_LINK>>.FAMS <ID_FAM>

FAX Facimilie

The FAX subrecord specifices a telephone number used for facsimile transmission via its <PHONE_NUMBER_FAX> line_value.

See: <<CONTACT_STRUCTURE>>.FAX

FCOM First Communion

The FCOM subrecord describes the First Communion religious event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.FCOM

FILE File

The FILE subrecord is used in several contexts.

  1. When used under the HEAD record, the FILE subrecord specifies the name of the GEDCOM document via its <FILE_NAME> line_value.

  2. When used under the OBJE subrecord, the FILE subrecord specifies the path to a multimedia file via its <MULTIMEDIA_FILE_REFERENCE> line_value.

See:

FORM Format

The FORM subrecord is used in several contexts.

  1. When used uder the HEAD.GEDC subrecord, the FORM subrecord specifies the GEDCOM FORM via its <GEDCOM_FORM> line_value.

  2. When used under the ><<HEAD_RECORD>>.HEAD.PLAC or <<PLACE_STRUCTURE>>.PLAC contexts, the FORM subrecord describes the geographic hierarchy of a place name via its <PLACE_HIERARCHY> line_value.

  3. When used under the OBJE.FILE context, the FORM subrecord specifices the format of a multimedia file via its <MULTIMEDIA_FORMAT> line_value.

See:

FONE Phonetic

The FONE subrecord specifies a phonetic variation of a superior text string.

See:

GEDC GEDCOM

The GEDC subrecord describes the use of GEDCOM in the document via the FORM and VERS subrecords.

The GEDC subrecord should be one of the first subrecords under the HEAD record.

The GEDC subrecord should appear before any text in the document that is outside the ASCII range (0x00 to 0x7F).

Example:

0 HEAD
1 CHAR UTF-8
1 GEDC
2 VERS 5.5.2
2 FORM LINEAGE-LINKED

See: <<HEAD_RECORD>>.HEAD.GEDC

GIVN Given Name

The GIVN subrecord specifies the given name of an individual.

The example below indicates that the given name for "Lt. Cmndr. Joseph Allen, Jr." is "Joseph":

1 NAME Lt. Cmndr. Joseph /Allen/ Jr.
2 NPFX Lt. Cmdr.
2 GIVN Joseph
2 SURN Allen
2 NSFX Jr.

See: <<PERSONAL_NAME_PIECES>>.GIVN <NAME_PIECE_GIVEN>

GRAD Graduation

A GRAD subrecord describes a graduationn event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.GRAD

HEAD Header

The HEAD record defines metadata for the GEDCOM document.

Best Practice Recommendations

  • GEDCOM readers need to inspect the HEAD.CHAR value and the HEAD.GEDC.VERS value to determine information that is critical to understanding the GEDCOM document.

    • GEDCOM writers should write HEAD.CHAR and HEAD.GEDC as the first subrecords in the HEAD_RECORD.

      0 HEAD
1 CHAR UTF-8
1 GEDC
2 VERS 5.5.2
2 FORM LINEAGE-LINKED

See: <<HEAD_RECORD>>.HEAD

HUSB Husband

The HUSB subrecord is used in the context of a <<FAM_RECORD>> to specify a pointer to an <<INDI_RECORD>> for a person who is the husband and/or father in the family.

See:

IDNO Identification Number

The IDNO subrecord specifies a nationally-controlled number assigned to an individual via its <NATIONAL_ID_NUMBER> line_value.

The IDNO subrecord requires a subordinate TYPE tag to identify what kind of number is being stored. For example:

0 @I1@ INDI
1 IDNO 43-456-1899
2 TYPE Canadian Health Registration

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.IDNO <NATIONAL_ID_NUMBER>

IMMI Immigration

The IMMI subrecord describes an immigratiion event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.IMMI

INDI Individual

The INDI record describes an individual via the subrecords defined for the <<INDI_RECORD>>. An <ID_INDI> pointer is required.

See: <<INDI_RECORD>>.INDI <ID_INDI>

LANG Language

The LANG subrecord is used in several contexts to identify a human language via its <LANGUAGE_ID> line_value.

  1. When used under the HEAD record, the LANG subrecord specifies the language in which the data in the document is normally read or written.
  2. When used under the SUBM record, the LANG subrecord specifies the language preference of the submitter: the language in which the submitter prefers to communicate. To indicate multiple language preferences, specify multiple LANG subrecords in order of priority/preference.

See:

LATI Latitude

The LATI subrecord specifies a latitude via its <PLACE_LATITUDE> line_value. Latitude is a geographic coordinate that specifies the north–south position of a point on the Earth's surface.

See:

LONG Longitude

The LONG subrecord specifies a longitude via its <PLACE_LONGITUDE> line_value. Longitude is a geographic coordinate that specifies the east-west position of a point on the Earth's surface.

See:

MAP Map

The MAP subrecord defines a geographical location using latitude and longitude using the MAP.LATI and MAP.LONG subrecords.

Some existing systems specify MAP.LATI and MAP.LONG values using a non-conforming format: decimal degrees without a direction indicator. Rather than specifying direction with a letter, positive values for latitude are north, and negative values are south. Similarly, positive values for longitude are east, and negative values are west.

Best Practice Recommendations

  • Some existing systems specify MAP.LATI and MAP.LONG values using decimal degrees without a direction indicator.

    • GEDCOM readers should convert latitude and longitude values without a direction indicator and assume positive latitude values are north and positive longitude values are east.

      GEDCOM readers should issue a warning message for a LATI (latitude) value that does not have a direction indicator but the value is a valid decimal degrees value in the range -89.999999 to 89.999999.

      GEDCOM readers should issue an error message for a LATI (latitude) value that does not follow the format specification and is not a valid decimal degrees value in the range -79.999999 to 79.999999.

      GEDCOM readers should issue a warning message for a LONG (longitude) value that does not have a direction indicator but the value is a valid decimal degrees value in the range -179.999999 to 179.999999.

      GEDCOM readers should issue an error message for a LONG (longitude) value that does not follow the format specification and is not a valid decimal degrees value in the range -179.999999 to 179.999999.

See: <<PLACE_STRUCTURE>>.PLAC.MAP

MARB Marriage Bann

The MARB subrecord describes a marriage bann event where public notice is given that two people intend to marry.

See: <<FAMILY_EVENT_STRUCTURE>>.MARB

MARC Marriage Contract

The MARC subrecord describes a marriage contract event where a couple enters into a legal agreement of marriage, such as a prenuptial agreement.

See: <<FAMILY_EVENT_STRUCTURE>>.MARC

MARL Marriage License

The MARL subrecord describes a marriage license event where a couple obtains a legal license to marry.

See: <<FAMILY_EVENT_STRUCTURE>>.MARL

MARR Marriage

A MARR subrecord describes a marriage event.

See: <<FAMILY_EVENT_STRUCTURE>>.MARR <NULL>

MARS Marriage Settlement

A MARS subrecord describes a marriage settlement event where a couple enters into a legal agreement of creating an agreement between two people contemplating marriage, at which time they agree to release or modify property rights that would otherwise arise from the marriage.

See: <<FAMILY_EVENT_STRUCTURE>>.MARS

MEDI Media

The MEDI subrecord identifies the type of media in which the referenced material is stored via its <SOURCE_MEDIA_TYPE> line_value.

See:

NAME Name

The NAME subrecord defines a name. It is used in several contexts.

  1. When used under the <<PERSONAL_NAME_STRUCTURE>>, i.e., INDI.NAME, the NAME subrecord defines an individual's name. If the individual has more than one name, the first NAME subrecord defines the primary/preferred name. Subsequent NAME subrecords define alternate names.
  2. When used under the HEAD.SOUR context, the NAME subrecord identifies the name of the software system that wrote the GEDCOM document via its <NAME_OF_PRODUCT> line_value.
  3. When used under the REPO context, the NAME subrecord specifies the name of the repository via its <NAME_OF_REPOSITORY> line_value.
  4. When used under the SUBM context, the NAME subrecord specifies the name of the submitter via its <NAME_OF_SUBMITTER> line_value.

See:

NATI Nationality

The NATI subrecord specifies the heritage of the individual via its <NATIONAL_OR_TRIBAL_ORIGIN> line_value.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.NATI <NATIONAL_OR_TRIBAL_ORIGIN>

NATU Naturalization

The NATU subrecord describes a naturalization event where an individual obtains legal citizenship.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.NATU

NCHI Number of Children

The NCHI subrecord is used in several contexts.

  1. When used under the <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>, the NCHI subrecord specifies the total number of known children of the current individual including all spouses or partners.
  2. When used under the FAM record, the NCHI subrecord specifies the number of known children shared by the parents specified in the family. The number may or may not match the number of CHIL subrecords under the FAM record.

See:

NICK Nickname

The NICK subrecord specifies a nickname: a familiar name used instead of, or in addition to, the individual's proper name.

The example below indicates that the nickname for "John 'Jack' Smith" is "Jack":

1 NAME John "Jack" /Smith/
2 GIVN John
2 NICK Jack
2 SURN Smith

See: <<PERSONAL_NAME_PIECES>>.NICK <NAME_PIECE_NICKNAME>

NMR Number of Marriages

The NMR subrecord specifies the number of times the individual has participated in a family as a spouse or parent via its <COUNT_OF_MARRIAGES> line_value.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.NMR <COUNT_OF_MARRIAGES>

NOTE Note

The NOTE record and subrecord are used in several contexts.

  1. When used under the <<NOTE_STRUCTURE>>, the NOTE subrecord may use one of two forms:

    1. The NOTE subrecord may specify additional comments or details about the enclosing subrecord via a <NOTE_TEXT> line_value.
    2. The NOTE subrecord may refer to additional comments or details about the enclosing subrecord via a pointer to a NOTE record via a <ID_NOTE> line_value.
  2. When used as a level 0 record, the NOTE record specifies additional comments or details that are referenced via a pointer from one or more NOTE subrecords. (See 1.1 above.)
  3. When used under the HEAD record, the NOTE subrecord describes the content of the GEDCOM document via its <CONTENT_DESCRIPTION> line_value.

See:

NPFX Name Prefix

The NPFX subrecord specifies a prefix that appears before the given and surname parts of a name.

The example below indicates that the name prefix for "Lt. Cmndr. Joseph Allen, Jr." is "Lt. Cmdr.":

1 NAME Lt. Cmndr. Joseph /Allen/ Jr.
2 NPFX Lt. Cmdr.
2 GIVN Joseph
2 SURN Allen
2 NSFX Jr.

See: <<PERSONAL_NAME_PIECES>>.NPFX <NAME_PIECE_PREFIX>

NSFX Name Suffix

The NSFX subrecord specifies a suffix which appears after the given and surname parts of a name.

The example below indicates that the name suffix for "Lt. Cmndr. Joseph Allen, Jr." is "Jr.":

1 NAME Lt. Cmndr. Joseph /Allen/ Jr.
2 NPFX Lt. Cmdr.
2 GIVN Joseph
2 SURN Allen
2 NSFX Jr.

See: <<PERSONAL_NAME_PIECES>>.NSFX <NAME_PIECE_SUFFIX>

OBJE Object

The OBJE subrecord describes an external object, usually a multimedia object such as a digital image, an audio recording, or another digital asset.

See:

OCCU Occupation

The OCCU subrecord specifies the type of work or profession of the individual via its <OCCUPATION> line_value.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.OCCU <OCCUPATION>

ORDN Ordination

The ORDN subrecord describes an ordination event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.ORDN

PAGE Page

The PAGE subrecord specifies a number or description to identify where information can be found in a referenced work via its <WHERE_WITHIN_SOURCE> line_value.

See: <<SOURCE_CITATION>>.SOUR.PAGE <WHERE_WITHIN_SOURCE>

PEDI Pedigree

The PEDI subrecord specifies a code to classify the child to family relationship via its <PEDIGREE_LINKAGE_TYPE> line_value.

See: <<CHILD_TO_FAMILY_LINK>>.FAMC.PEDI <PEDIGREE_LINKAGE_TYPE>

PHON Phone

The PHON subrecord specifices a telephone number via its <PHONE_NUMBER> line_value.

See: <<CONTACT_STRUCTURE>>.PHON <PHONE_NUMBER>

PLAC Place

The PLAC subrecord is used in several contexts.

  1. When used under the <<PLACE_STRUCTURE>>, the PLAC subrecord specifies the name of a place via its <PLACE_NAME> line_value.
  2. When used under the <<HEAD_RECORD>>, the PLAC subrecord is the parent record of the FORM subrecord that specifies the default PLACE_HIERARCHY for the GEDCOM document.
  3. When used under the <<SOUR_RECORD>>.SOUR.DATA.EVEN context, the PLAC subrecord specifies the name of the lowest jurisdiction that encompasses all lower-level places named in a source via its <SOURCE_JURISDICTION_PLACE> line_value.

See:

POST Postal Code

The POST subrecord specifies the postal code for an address via its <ADDRESS_POSTAL_CODE> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.POST <ADDRESS_POSTAL_CODE>

PROB Probate

The PROB subrecord describes a probate event where the estate of a deceased individual is legally settled.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.PROB

PROP Property

The PROP subrecord specifies a list of an individual's possessions via its <POSSESSIONS> line_value.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.PROP <POSSESSIONS>

PUBL Publication

The PUBL subrecord specifies when and where a source record was published or created via its <SOURCE_PUBLICATION_FACTS> line_value.

See: <<SOUR_RECORD>>.SOUR.PUBL <SOURCE_PUBLICATION_FACTS>

QUAY Quality of Data

The QUAY subrecord indicates the submitter's quantitative evaluation of the credibility of the source data identified in the parent <<SOURCE_CITATION>> via its <CERTAINTY_ASSESSMENT> line_value.

The credibility is relative to the data to which the source citation applies. So, for example, when citing a marriage record for the marriage date, the QUAY value would typically be higher than when citing the marriage record for the bride or groom's birth date estimated from an age value in the marriage record.

See: <<SOURCE_CITATION>>.SOUR.QUAY <CERTAINTY_ASSESSMENT>

REFN Reference Number

The REFN subrecord specifies a number or description used to identify an item via its <USER_REFERENCE_NUMBER> line_value.

See:

RELA Relationship

The RELA subrecord specifies the relationship between two individuals via its <RELATION_IS_DESCRIPTOR> line_value.

See the ASSO subrecord for more details.

See: <<ASSOCIATION_STRUCTURE>>.ASSO.RELA <RELATION_IS_DESCRIPTOR>

RELI Religion

The RELI subrecord is used in several contexts.

  1. When used under an INDI subrecord as part of an <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>, the RELI subrecord describes a religious affiliation. The religous denomination is specified via its <RELIGIOUS_AFFILIATION> line_value. Subrecords describe other aspects of the affiliation.
  2. When used under the <<EVENT_OR_FACT_DETAIL>> context, the RELI subrecord specifies a religious denomination associated with the parent record via its <RELIGIOUS_AFFILIATION> line_value. No further subrecords are allowed in this context.

See:

REPO Repository

The REPO subrecord is used in several contexts.

  1. When used as a level 0 record, the <<REPO_RECORD>> describes a repository. The <<REPO_RECORD>> is referenced by REPO subrecords with an <ID_REPO> pointer line_value.
  2. When used in a <<SOURCE_REPOSITORY_CITATION>> under a <<SOUR_RECORD>>, the REPO subrecord describes a repository or links to a <<REPO_RECORD>> that describes a repository.

See:

RESI Residence

The RESI subrecord describes a residence as an attribute of an individual or family.

See:

RESN Restriction

The RESN subrecord indicates a processing restriction for its parent record via its <RESTRICTION_NOTICE> line_value.

See:

RETI Retirement

The RETI subrecord describes a retirement event.

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.RETI

RFN Record File Number

The RFN subrecord specifies a record file number that uniquely identifies a <<SUBM_RECORD>> via its <SUBMITTER_REGISTERED_RFN>.

See: <<SUBM_RECORD>>.SUBM.RFN <SUBMITTER_REGISTERED_RFN>

RIN Record ID Number

The RIN subrecord specifies an identification number assigned to a record via its <AUTOMATED_RECORD_ID> line_value. The value is assigned by an originating system and can be used by a receiving system to report results pertaining to that record.

See:

ROLE Role

The ROLE subrecord specifies a name given to a role played by an individual in connection with an event. The role is specified via the ROLE subrecord's <ROLE_IN_EVENT> line_value.

See: <<SOURCE_CITATION>>.SOUR.EVEN.ROLE <ROLE_IN_EVENT>

ROMN Romanized

The ROMN subrecord specifies a romanized variation of a superior name or place.

See:

SEX Sex

The SEX subrecord indicates the gender of an individual via its <SEX_VALUE> line_value.

See: <<INDI_RECORD>>.INDI.SEX <SEX_VALUE>

SOUR Source

The SOUR record and subrecord are used in several contexts:

  1. When used under the HEAD record, the SOUR subrecord identifies the system that wrote the GEDCOM document via its <SYSTEM_ID> line_value.

    The HEAD.SOUR line_value should not include the version number of the sending system. The version number of the sending system should be specified in the HEAD.SOUR.VERS line_value only.

    The HEAD.SOUR line_value should be unique from any other product. There is no central authority for assigning <SYSTEM_IDs>, so it is not possible to ensure uniqueness. Software authors should review the list of SYSTEM_IDs in the Source Applications document to avoid using a SYSTEM_ID that is already used by another system.

  2. When used as a <<SOUR_RECORD>> or <<SOURCE_CITATION>>, the SOUR record defines the initial or original material from which information was obtained.

See:

SPFX Surname Prefix

The SPFX subrecord specifies a name piece used as a non-indexing prefix of a surname via its <NAME_PIECE_SURNAME_PREFIX> line_value.

The example below indicates the surname prefix for "Paul van Heusen" is "van":

1 NAME Paul van Heusen
2 GIVN Paul
2 SPFX van
2 SURN Heusen

See: <<PERSONAL_NAME_PIECES>>.SPFX <NAME_PIECE_SURNAME_PREFIX>

SSN Social Security Number

The SSN subrecord specifies a number assigned to an individual by the United States Social Security Administration.

See: <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>>.SSN <SOCIAL_SECURITY_NUMBER>

STAE State

The STAE subrecord specifies the name of a geographical division of a larger jurisdictional area, such as a state within the United States of America, via its <ADDRESS_STATE> line_value.

See: <<ADDRESS_STRUCTURE>>.ADDR.STAE <ADDRESS_STATE>

STAT Status

The STAT subrecord specifies an assessment of a <<CHILD_TO_FAMILY_LINK>> via its <CHILD_LINKAGE_STATUS> line_value.

See: <<CHILD_TO_FAMILY_LINK>>.FAMC.STAT <CHILD_LINKAGE_STATUS>

SUBM Submitter

The SUBM record and subrecord are used in several contexts:

  1. When used as a level 0 record, the <<SUBM_RECORD>> describes the submitter, editor, or compiler of the GEDCOM document. The <<SUBM_RECORD>> is referenced by SUBM subrecords with an <ID_SUBM> pointer line_value.
  2. When used as a subrecord, the SUBM subrecord links a <<SUBM_RECORD>> to the parent record.

See:

SURN Surname

The SURN subrecord specifies the family name used by members of a family.

The example below indicates that the surname for "Lt. Cmndr. Joseph Allen, Jr." is "Allen":

1 NAME Lt. Cmndr. Joseph /Allen/ Jr.
2 NPFX Lt. Cmdr.
2 GIVN Joseph
2 SURN Allen
2 NSFX Jr.

See: <<PERSONAL_NAME_PIECES>>.SURN <NAME_PIECE_SURNAME>

TEXT Text

The TEXT subrecord specifies the exact wording found in an original source document via its <TEXT_FROM_SOURCE> line_value.

See:

TIME Time

The TIME subrecord specifies a time via its <TIME_VALUE> line_value.

See:

TITL Title

The TITL subrecord is used in several contexts.

  1. When used under the <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> context, the TITL subrecord specifies an individual's title via its <NOBILITY_TYPE_TITLE> line_value.
  2. When used under the OBJE record or subrecord, the TITL subrecord specifies the title of the media object via its <DESCRIPTIVE_TITLE> line_value.
  3. When used under the <<SOUR_RECORD>> context, the TITL subrecord specifies the title of a source via its <SOURCE_DESCRIPTIVE_TITLE> line_value.

See:

TRLR TRAILER

The TRLR record indicates the end of a GEDCOM document.

See: <<TRLR_RECORD>>.TRLR

TYPE (Event or Fact)

The TYPE subrecord in the context of an <<EVENT_OR_FACT_DETAIL>> subrecord provides a label to qualify the event type.

The TYPE subrecord is required with the FAM.EVEN, INDI.EVEN, INDI.FACT, and INDI.IDNO subrecords. For example:

1 EVEN
2 TYPE Land Lease

When used with a non-generic event type, the TYPE subrecord clarifies the meaning of the parent subrecord without changing the basic meaning. For example:

1 MARR
2 TYPE Common Law

See: <<EVENT_OR_FACT_DETAIL>>.TYPE <EVENT_OR_FACT_CLASSIFICATION>

TYPE (Media)

The TYPE subrecord in the context of a FORM subrecord indicates the type of material in which the referenced source is stored via its SOURCE_MEDIA_TYPE line_value.

See: <<OBJE_RECORD>>.OBJE.FILE.FORM.TYPE <SOURCE_MEDIA_TYPE>

TYPE (Name)

The TYPE subrecord in the context of a NAME subrecord provides a label to qualify the name type via its <NAME-TYPE> line_value.

See: <<PERSONAL_NAME_STRUCTURE>>.NAME.TYPE <NAME_TYPE>

TYPE (REFN)

The TYPE subrecord in the context of a REFN subrecord describes or classifies a <USER_REFERENCE_NUMBER>.

See:

TYPE (Transform)

The TYPE subrecord in the context of a FONE or ROMN subrecord indicates a method to transform a name value via its line_value.

See:

VERS Version

The VERS subrecord specifies a version number. It is used in several contexts.

  1. When used under the HEAD.GEDC context, the VERS subrecord specifies the version of the GEDCOM specification that applies to the current document via its <VERSION_NUMBER> line_value.

    For GEDCOM 5.5.2, the line_value must equal "5.5.2".

    Example:

    0 HEAD
1 CHAR UTF-8
1 GEDC
2 VERS 5.5.2
2 FORM LINEAGE-LINKED

  2. When used under the HEAD.SOUR context, the VERS subrecord specifies the version of the software system that wrote the GEDCOM document via its <VERSION_NUMBER> line_value.

    The content and meaning of the HEAD.SOUR.VERS line_value is defined by the authors of the sending system.

    The HEAD.SOUR.VERS line_value should not include the name of the sending system. The name of the sending system should be in the HEAD.SOUR line_value only.

See:

WIFE Wife

The WIFE subrecord is used in the context of a <<FAM_RECORD>> to specify a pointer to an <<INDI_RECORD>> for a person who is the wife and/or mother in the family.

See:

WILL Will

The WILL subrecord describes the event of creating or authorizing a will.

See also PROB (probate).

See: <<INDIVIDUAL_EVENT_STRUCTURE>>.WILL

WWW Web

The WWW subrecord specifies the URI of a World Wide Web page.

See: <<CONTACT_STRUCTURE>>.WWW <ADDRESS_WEB_PAGE>

Example GEDCOM Document

The example document below includes genealogical information about three individuals who are members of the same family including a father, mother, and child. The example demonstrates several GEDCOM conventions and techniques, including the use of pointers.

Example:

0 HEAD
1 CHAR UTF-8
1 GEDC
2 VERS 5.5.2
2 FORM Lineage-Linked
1 SOUR EXAMPLE_SOURCE
2 VERS 1.7
0 @I1@ INDI
1 NAME Robert Eugene /Williams/
1 SEX M
1 BIRT
2 DATE 02 OCT 1822
2 PLAC Weston, Madison, Connecticut
2 SOUR @S1@
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 @F1@
1 FAMS @F2@
0 @I2@ INDI
1 NAME Mary Ann /Wilson/
1 SEX F
1 BIRT
2 DATE BEF 1828
2 PLAC Connecticut
1 FAMS @F1@
0 @I3@ INDI
1 NAME Joe /Williams/
1 SEX M
1 BIRT
2 DATE 11 JUN 1861
2 PLAC Idaho Falls, Bonneville, Idaho
1 FAMC @F1@
1 FAMC @F2@
2 PEDI Adopted
1 ADOP
2 FAMC @F2@
2 DATE 16 MAR 1864
0 @F1@ FAM
1 MARR
2 DATE DEC 1859
2 PLAC Rapid City, South Dakota
1 HUSB @I1@
1 WIFE @I2@
1 CHIL @I3@
0 @F2@ FAM
1 HUSB @I1@
1 CHIL @I3@
0 @S1@ SOUR
1 DATA
2 EVEN BIRT, DEAT, MARR
3 DATE FROM Jan 1820 TO DEC 1825
3 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 @R1@
2 CALN 13B-1234.01
3 MEDI Microfilm
0 @R1@ REPO
1 NAME Family History Library
1 ADDR 35 N West Temple Street
2 CONT Salt Lake City, Utah
2 CONT UT 84150
0 TRLR

Customizations

This section provides information on known customizations and related topics.

HEAD.SOUR and HEAD.DEST

Of HEAD.SOUR and HEAD.DEST, which value should determine how a GEDCOM reader interprets values that may be specific to a particular system?

The recommendations in this section are derived from the rule-of-thumb that a sending system should write what it knows. A sending system is unlikely to know all the rules of a destination system, and the rules of the destination system may change after the sending system is implemented.

An additional factor is the HEAD.DEST subrecord does not support a HEAD.DEST.VERS subrecord, so the sending system cannot specify which version of the destination system's rules it intends to use.

Best Practice Recommendations

  • GEDCOM customizations, such as specific custom subrecord names, are not defined in the GEDCOM specification.

    • GEDCOM readers should ignore the HEAD.DEST value.

    • If a GEDCOM reader attempts to understand the meaning of custom subrecords or other customized values in the current GEDCOM document, the GEDCOM reader should assume the context of the customizations is established by the HEAD.SOUR and HEAD.SOUR.VERS subrecords.

    • GEDCOM writers should either (A) not create a HEAD.DEST value, or (B) should specify a HEAD.DEST value that is the same as the HEAD.SOUR value.

    • GEDCOM writers should create accurate, conforming HEAD.SOUR and HEAD.SOUR.VERS subrecords.

    • GEDCOM writers should only use self-defined customizations that are required to provide the complete dataset.

    • GEDCOM writers should not attempt to predict the rules or customizations of the destination system.

Index

Top - Index