GEDCOM

From Wikipedia, the free encyclopedia

GEDCOM, an acronym for GEnealogical Data COMmunication, is a de facto^[2] specification for exchanging genealogical data between different genealogy software. GEDCOM was developed by The Church of Jesus Christ of Latter-day Saints as an aid to genealogical research^[3].

A GEDCOM file is plain text (usually either ANSEL or ASCII) containing genealogical information about individuals, and meta data linking these records together. Most genealogy software supports importing from and/or exporting to GEDCOM format.^[4] However, some genealogy software programs incorporate the use of proprietary extensions to the GEDCOM format, which are not always recognized by other genealogy programs, for example the GEDCOM 5.5 EL (Extended Locations) specification.^[5][6][7].

[edit] GEDCOM model

GEDCOM uses a lineage-linked data model. This data model is based on the nuclear family and the individual. This contrasts with evidence-based models, where data are structured to reflect the supporting evidence. In the GEDCOM lineage-linked data model, all data are structured to reflect the believed reality, that is, actual (or hypothesized) nuclear families and individuals.

[edit] GEDCOM file structure

A GEDCOM file consists of a header section, records, and a trailer section. Within these sections, records represent people (INDI record), families (FAM records), sources of information (SOUR records), and other miscellaneous records, including notes. Every line of a GEDCOM file begins with a level number where all top-level records (HEAD, TRLR, SUBN, and each INDI, FAM, OBJE, NOTE, REPO, SOUR, and SUBM) begin with a line with level 0, while other level numbers are positive integers.

Although it is theoretically possible to write a GEDCOM file by hand, the format was designed to be used with software and thus is not especially human-friendly. A GEDCOM validator^[8] that can be used to validate the structure of a GEDCOM file is included as part of PhpGedView project, though it is not meant to be a standalone validator. For standalone validation you can use "The Windows GEDCOM Validator" ^[9] or the older unmaintained Gedcheck^[10] from the LDS.

During 2001, The GEDCOM TestBook Project evaluated how well four popular genealogy programs conformed to the GEDCOM 5.5 standard using the Gedcheck program.^[11] Findings showed that a number of problems existed and that The most commonly found fault leading to data loss was the failure to read the NOTE tag at all the possible levels at which it may appear.^[12] In 2005, the Genealogical Software Report Card was evaluated, (by Bill Mumford who participated in the original GEDCOM Testbook Project)^[13] and included testing the GEDCOM 5.5 standard using the Gedcheck program.^[14]

[edit] Example

0 HEAD 
1 SOUR Reunion
2 VERS V8.0
2 CORP Leister Productions
1 DEST Reunion
1 DATE 11 FEB 2006
1 FILE test
1 GEDC 
2 VERS 5.5
1 CHAR MACINTOSH
0 @I1@ INDI
1 NAME Bob /Cox/
1 SEX M
1 FAMS @F1@
1 CHAN 
2 DATE 11 FEB 2006
0 @I2@ INDI
1 NAME Joann /Para/
1 SEX F
1 FAMS @F1@
1 CHAN 
2 DATE 11 FEB 2006
0 @I3@ INDI
1 NAME Bobby Jo /Cox/
1 SEX M
1 FAMC @F1@
1 CHAN 
2 DATE 11 FEB 2006
0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 MARR 
1 CHIL @I3@
0 TRLR

The following is a sample GEDCOM file. The first column indicates an indentation level.

The header (HEAD) includes the source program and version (Reunion, V8.0), the GEDCOM version (5.5), and the character encoding (MACINTOSH), (Which is invalid, as according to the GEDCOM 5.5 specification, valid choices are (ANSEL), (UNICODE) or (ASCII).)

The individual records (INDI) define Bob Cox(ID 1—@I1@), Joann Para (ID 2), and Bobby Jo Cox (ID 3).

The family record (FAM) links the husband (HUSB), wife (WIFE), and child (CHIL) by their ID numbers.

[edit] Versions

The current version of the specification is GEDCOM 5.5, which was released on 12 January 1996. A subsequent draft GEDCOM 5.5.1^[15] specification was issued in 1999, introducing nine new tags, including WWW, EMAIL and FACT, and adding UTF-8 as an approved character encoding. This draft has not been formally approved, but its provisions have been adopted in some part by a number of genealogy programs^[16][17][18] and is used by FamilySearch.org^[19] While PAF 5.2 does support GEDCOM 5.5, PAF 5.2 uses UTF-8 as its internal character set, a feature which was introduced in the GEDCOM 5.5.1 draft, and can output a UTF-8 GEDCOM.^[20][21]

On January 23, 2002 a draft(beta) version of GEDCOM 6.0 was released for developers to study only as it was not a complete specification and recommended not to begin to implement in their software. For example, descriptions of the meaning and expected contents of tags were not included.^[22] GEDCOM 6.0 was to be the first version to store data in XML format, and was to change the preferred character set from ANSEL to Unicode.

Today, lineage-linked GEDCOM is still the deliberate de facto common denominator^[23]. Despite version 5.5 of the GEDCOM standard first being published in 1996, many genealogical software suppliers have yet to support the feature of multilingual Unicode text (instead of the ANSEL character set) introduced with that version of the specification. Uniform use of Unicode would allow for the usage of international character sets. An example is the storage of East Asian names in their original Chinese, Japanese, and Korean (CJK) characters, without which they could be ambiguous and of little use for genealogical or historical research.^[24]

[edit] Release History

[edit] Limitations

This Limitations is in need of attention from an expert on the subject. WikiProject GEDCOM may be able to help recruit one. (February 2009)

This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources (ideally, using inline citations). Unsourced material may be challenged and removed. (February 2009)

One weakness of GEDCOM is that events cannot be shared among multiple individuals except for a few predefined family events such as marriage (MARR).^{[citation needed]} This means that if an event were associated with multiple individuals, the data must be duplicated in each record. For example, if multiple people were listed on a census, the census data (CENS) would need to be duplicated for each of the individuals referenced there. Most genealogy programs would require the user to enter the data multiple times through their user interface.^{[citation needed]}

The way GEDCOM handles places is also considered a weakness of the specification.^{[citation needed]} Places are encoded as strings on the events. An example would look like this following:

1 BIRT
2 PLAC New York City, , New York, USA

Additional references to New York City are represented by additional strings, so changes (for example, to add the county or change spelling) require changing every occurrence throughout the file. This also leads to duplication of information if geo-coding or other subrecords are added to the place.

Sometimes the GEDCOM specification has been made purposefully flexible to support many ways of encoding data, particularly in the area of sources. This flexibility has led to a great deal of ambiguity, and has produced the side effect that some genealogy programs which import GEDCOM do not import all of the data from a file.^{[citation needed]}

GEDCOM does not allow representation of many types of close interpersonal relationships, such as same-sex marriages, domestic partnerships, cohabitation, polyamory, and polygamy, most of which are increasingly recognized in modern Western societies as well as diverse cultures and historical contexts.^{[citation needed]}

[edit] Myths

This Myths is in need of attention from an expert on the subject. WikiProject GEDCOM may be able to help recruit one. (February 2009)

This section does not cite any references or sources. Please help improve this article by adding citations to reliable sources (ideally, using inline citations). Unsourced material may be challenged and removed. (July 2008)

A common myth about GEDCOM is that it doesn't support multi-media^{[citation needed]} such as photos which are often attached to people. GEDCOM actually does support the linking of multi-media items as references to files on the file system. An example would look like this:

0 @I1@ INDI
1 NAME John /Doe/
1 OBJE @O1@
0 @O1@ OBJE
1 FILE johndoe.jpg
2 TITL John Doe at age 50

If this were encoded in a GEDCOM file named "doe.ged" then the file "johndoe.jpg" would need to be in the same directory as the file "doe.ged." The disadvantage with this media encoding comes when you want to transfer this GEDCOM file AND the attached multimedia because you would have to manage the transfer of the files separately. A possible solution is to use a data compression program to archive the GEDCOM and the media into the same file.

Another myth is that GEDCOM does not support multiple opinions^{[citation needed]} or conflicting data^{[citation needed]}. Sometimes in genealogy, it is desirable to record conflicting information. An example of such conflicting information would be a birth certificate listing a birth date as 10 January 1800 and a death certificate listing the birth date as 11 January 1800. Such mistakes are common due to transcription errors or perhaps the relative giving the information forgot. Good practices in genealogy research require that the researcher record both birth records along with the source citation information. GEDCOM does not prevent you from recording two birth (BIRT) records for a single person. In the case of multiple instances of the same record, the preferred record should be listed first in the record. This example encoded in GEDCOM might look like this:

0 @I1@ INDI
1 NAME John /Doe/
1 BIRT
2 DATE 10 JAN 1800
2 SOUR @S1@
3 DATA
4 TEXT Transcription from birth certificate would go here
3 NOTE This birth record is preferred because it comes from the birth certificate
3 QUAY 2
1 BIRT
2 DATE 11 JAN 1800
2 SOUR @S2@
3 DATA
4 TEXT Transcription from death certificate would go here
3 QUAY 2

There is room for improvement in the area of source citations which could be used to make this clearer. The quality of assessment field (QUAY) for example could be extended to use something besides just a numerical level 0-3.^{[citation needed]}

Another myth about GEDCOM is that it does not support internationalization in name support^{[citation needed]}. In the same way that you can have multiple events on a person, GEDCOM allows you to have multiple names for a person.^{[citation needed]} If the GEDCOM were encoded in the unicode or UTF-8 character sets, then you may also record the name in Cyrillic, Hebrew, or any other alphabet.^{[citation needed]} GEDCOM's NAME field also supports a phonetic variation (FONE) and a romanized variation (ROMN) of the name.^{[citation needed]}

[edit] Alternatives to GEDCOM

Commsoft, the authors of the Roots^[58] series of genealogy software and Ultimate Family Tree, defined a version called Event-Oriented GEDCOM (also known as "Event GEDCOM" and originally called InterGED^[59]),^[60] which included events as first class (zero-level) items. Although it is event based, it is still a model built on assumed reality rather than evidence. Event GEDCOM was more flexible, as it allowed some separation between believed events and the participants. However, Event GEDCOM was not widely adopted by other developers due to its semantic differences.^{[citation needed]} With Roots and Ultimate Family Tree no longer available, very few people today are using Event GEDCOM.^[61]

• Event-Oriented GEDCOM specification - Draft Release 1.0 (12 September 1994) (Microsoft Word in a ZIP file)
• GEDC - An XML-Based Standard for Genealogy - originated as an outgrowth of the GEDCOM 6.0 Beta specification and Gentech's Genealogical Data Model (GDM).
• FamilyML based on XML and allows the exchange of genealogical data. Also based on GedML and GEDCOM, but in a more human-readable format.
• GDMUML - Genealogical Data Models in the Unified Modeling Language
• GedML: Genealogical Data in XML - combines the GEDCOM data model with the XML standard.
• Gendatam - genealogical data model
• The GENTECH Genealogical Data Model
  • gdmxml, a RELAX NG Schema to validate XML documents with genealogical information according to the GENTECH Genealogical Data Model.
• GeniML - Genealogical Information Markup Language (pronounced 'jeenie em el') is a data model and XML vocabulary for recording and exchanging genealogical data.
• GenXML is a file format for exchange of data between genealogy programs.
• GREnDL - Genealogical Record Exchange and Description Language - XML specification^[62]
• GEDCOM 5.5 XML - "attempts to be a 100 percent one-to-one translation of GEDCOM 5.5 into XML; it even includes the superfluous (and empty) <TRLR/> element." - By Chad Albers - neomantic.com

[edit] References

[edit] External links

• Specifications (from the FamilySearch website)
  • GEDCOM 5.5 Standard (Executable file in Envoy format)
  • Draft Specification for GEDCOM XML 6.0 (PDF)
  • GEDCOM 5.5 specification (Paul McBride's HTML version with corrections added from the GEDCOM 5.5 Errata Sheet)
  • GEDCOM 5.5 Standard(Unmodified) - Robert Simms Genealogy
  • GEDCOM 5.5.1-5 Draft(Unmodified) - Robert Simms Genealogy
  • GEDCOM 5.5.1-5 Draft(Unmodified) - PhpGedView
• Proprietary extension: GEDCOM 5.5 EL(Extended Locations) specification.
• Commentary
  • Overview of GEDCOM and its uses on Encyclopedia of Genealogy
  • Cyndi's List — GEDCOM
    • Many tools exist to convert GEDCOM files to HTML pages see Cyndi's List — GEDCOM to HTML Conversion
  • Mapping GEDCOM to XML, an article with example software in the C# programming language.
  • on LDS Church's Adoption of the XML Standard

[edit] See also

• FamilySearch
  • Ancestral File Number
  • International Genealogical Index
• GENDEX - Genealogical index
• Genealogical numbering systems
• GNTP - Genealogy Network Transfer Protocol
• Tiny Tafel Format - encoded "ancestor table"