Introduction

GEDCOM was developed by the Family History Department of the Church of Jesus Christ of Latter-day Saints to provide a flexible uniform format for exchanging computerized genealogical data. GEDCOM is an acronym for GEnealogical Data Communication. GEDCOM is provided to foster the sharing of genealogical information and the development of a wide range of inter-operable software products to assist genealogists, historians, and other researchers.

Purpose and Content of This Document

The higher level is known as a GEDCOM form. A GEDCOM form is defined for each kind of data that uses the GEDCOM data format. The only GEDCOM form presented in this document is called the Lineage-linked GEDCOM form. Other GEDCOM forms have been used for other kinds of data, including several that are not related to genealogy. The Lineage-linked GEDCOM form is defined in chapter 2 and is the form used by commercial genealogical software systems for exchanging compiled, linked information about individuals with accompanying source citations and evidence records. The other forms of GEDCOM are not publicly exchanged at this time, and are not discussed in this document.

Changes in Version 5.x

This GEDCOM draft version (5.x) includes the first standard definition of the Lineage-linked form of GEDCOM and also includes the first major expansion of the Lineage-linked form since its initial use in GEDCOM 3.0. The existing registered GEDCOM-compatible systems should still be able to exchange most data with newer systems that use this version and will still be considered GEDCOM-compatible for submitting information to the Family History Department. See chapter 2, Compatibility with previous GEDCOM releases, for compatibility detail. There are several purposes for version 5.x of GEDCOM:

• Re-define the description of the GEDCOM data representation grammar in a shorter, more precise format, for ease of understanding (see chapter 1). The GEDCOM format remains the same, even though the description of it is changed.
• Define the combinations of tags, values, and pointers allowed in the Lineage-linked form (see chapter 2). This is the form of GEDCOM currently exchanged by commercial genealogical software systems, and it remains unchanged except for new tags and upward-compatible structural extensions listed below. (The Lineage-linked form should not be confused with other forms of GEDCOM, which apply the basic GEDCOM data format with different tag, value, and pointer combinations for other purposes.)
• Define representations for support information such as source citations, and or notes. (See chapter 2 for suggested source citation structure in the Lineage-linked grammar.)
• Define additional EVENt and Role tags.
• Define user-defined ASSOciations with INDIviduals including direct family relationships.
• Require SOURce VERSion (product version) and GEDCom VERSion information in the HEADer record.
• Define DATE modifier (ABT, BEF, AFT, BET) and a more rigorously defined regular date format.

• An address structure was defined to provide consistency to the addresses used in the many different structures. The Phone number is now subordinate to address.
• A new tag for marrital status (MSTAT) at the time of an event was used added to the event structure.
• A mechanism for creating user-defined tags. These are defined in a SCHEMA definition in the header record.
• The inclusion of the Unicode standard (ISO 10646) as an additional character set standard (see chapter 3).
• A MULTI_MEDIA_LINK structure was introduced to provide links to digitized video and sound files.
• The NAME tag used in the SOURCE_STRUCTURE was changed back to the TITLe tag to be used with the title of a book or article.
• The SOURCE_STRUCTURE was changed. Compatibility may affect 5.x systems that was using the CPLR, XLTR, AUTH, INFT tags in substructures within the source structure. See originator (ORIG) substructure for handling the name of the originator of the source data.
• Relocated all tags from the SUPPORT_INFO structure to the various structures where they specifically apply.
• Added the use of the FORM {FORMAT} tag in both the HEADER and PLACE_STRUCTURE. The FORM tag in the header record subordinate to the PLAC tag indicates that all of the locality names are specified in a consistent hiarchy as specified by the value of the FORM. For example; 2 FORM City, County, State. GEDCOM 5.2 used the TYPE tag subordinate to the PLAC tag for this purpose.

Developers of GEDCOM-compatible products using the Lineage-linked form of GEDCOM (see chapter 2) should register their product by submitting the following information to the GEDCOM coordinator:

• A diskette containing a small sample of GEDCOM output from the product being registered. This should be data which represents all of the fields managed by your system and that can be used for testing compatibility with other developer's systems.
• A proposed unique SOURce name in the GEDCOM header record to identify the product (not the company). This name can be up to 40 characters long, allowing mixed upper and lower case, with no embedded spaces. Use an underscore (_) to connect multiple words instead of spaces or a combination of upper and lower case letters i.e. FamilyRecords or Family_Records. Family History reserves the right to require uniqueness within the first 10 characters of this name.
• An optional text file containing relevant technical documentation about the product's GEDCOM implementation.