Genealogy apps should always follow the GEDCOM standard, right? You’d be justified in thinking that if you’ve read many of my articles, and generally speaking, apps should follow the standard, especially 5.5.1, since GEDCOM 5.5 is obsolete. However, what should apps do when there are mistakes in the standard? Should they import, export, and/or validate GEDCOM files strictly according to the standard, or according to how the standard should have been? This is a letter versus spirit of the law question, and the answer depends on the mistake in question and the purpose of the app.
To make this question concrete, let’s take the example of the Event structure, used for both family and individual events and beginning with the tag EVEN in a GEDCOM file. The GEDCOM standard contains specific structures for many events, such as birth, marriage, death, etc. However, for events not covered by these specific definitions, many apps use their own product-specific tags. The GEDCOM standard allows this, calling them NEW_TAGs, and they’re supposed to begin with an underscore, but several apps incorrectly omit the underscore. The main problem with product-specific tags is that they’re product-specific, meaning data you share with other people or transfer to a different application can be misinterpreted or ignored. Some apps try to play nice and correctly read other apps’ product-specific tags, even though the standard does not and cannot require them to.
But there’s a better way to specify events that aren’t specifically defined in the standard, and that’s to use the Event structure. (There’s also a structure for attributes not defined in the standard, the Fact structure, but I won’t get into that in this article). The partially expanded structure for a Family Event is as follows (you can find the full definition on pages 32 and 48 of the GEDCOM 5.5.1 standard):
n EVEN [<EVENT_DESCRIPTOR> | <NULL>]
+1 HUSB
+2 AGE <AGE_AT_EVENT>
+1 WIFE
+2 AGE <AGE_AT_EVENT>
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
You would think that, with the exception of the HUSB and WIFE elements, the Individual Event structure would be the same, but from the partially expanded structure that follows, we can see one crucial difference:
n EVEN
+1 TYPE <EVENT_OR_FACT_CLASSIFICATION>
+1 DATE <DATE_VALUE>
+1 <<PLACE_STRUCTURE>>
The crucial difference is that the Individual Event structure lacks the EVENT_DESCRIPTOR. Now why would this be? Clearly it was an oversight on the part of the authors and editors of the standard, because on page 48 of the standard, the following example is provided for an EVENT_DESCRIPTOR on an Individual Event:
1 EVEN Appointed Zoning Committee Chairperson
2 TYPE Civic Appointments
2 DATE FROM JAN 1952 TO JAN 1956
2 PLAC Cove, Cache, Utah
2 AGNC Cove City Redevelopment
The definition of EVENT_DESCRIPTOR even states that it is “Text describing a particular event pertaining to the individual or family” (emphasis added). So it should be obvious that omitting “[<EVENT_DESCRIPTOR> | <NULL>]” from the Individual Event structure was an oversight. Which brings me back to my original question, what should apps do about this mistake? The answer depends on whether the apps are importing, exporting, or validating GEDCOM files. The best practice for each case is as follows:
Importing GEDCOM Files
Read the EVENT_DESCRIPTOR for both family and individual events and, if the data are to be stored in the app’s own database, import the data into the corresponding field. Apps that ignore these data, especially without any warning, do users a disservice by discarding data. It is not even a good practice to import the data into a note attached to the event; just import it into the EVENT_DESCRIPTOR where it belongs. This practice ensures the maximum amount of data is imported.
Exporting GEDCOM Files
Include an EVENT_DESCRIPTOR field in the app’s design and export it to the EVEN tag for both family and individual events. Use the Event structure for common events not defined in the standard, such as Employment, Military Service, Marital Separation, etc., instead of product-specific tags, as well as user-defined events. This practice ensures the maximum amount of data can be read by other applications.
Validating GEDCOM Files
GEDCOM validators must validate files according to the GEDCOM version specified in the header, even when the standard is mistaken (and there are many other mistakes in addition to the missing EVENT_DESCRIPTOR, as Tamura Jones has identified). However, validators should caveat error statements about an EVENT_DESCRIPTOR on an Individual Event in GEDCOM 5.5.1 files with a comment like this: “The GEDCOM 5.5.1 standard, page 35, does not allow an EVENT_DESCRIPTOR on an Individual Event, but that was clearly a mistake, since it is included in both the definition and example for “EVENT_DESCRIPTOR” on page 48.” This practice ensures that both the letter and intent of the standard are validated.
Of the 13 apps I reviewed in my Family Tree Software Alternatives Series, nine both imported and exported EVENT_DESCRIPTOR correctly: Family Tree Maker 3 (for Mac) and 2017, RootsMagic 7, Legacy Family Tree 8, Ancestral Quest 14, Family Historian 6, Gramps 4, MacFamilyTree 8 (but not 7), Family Tree Builder 7, and GEDitCOM II. The following four apps failed to import and/or export EVENT_DESCRIPTOR correctly: Reunion 11, Heredis 2015, iFamily for Mac, and Brother’s Keeper 7. Reunion and Heredis have released major new versions, which I will test in the future, but genealogy apps seldom change with respect to GEDCOM handling. I have also tested two GEDCOM validators, although I haven’t reviewed them yet: Chronoplex and GED-inline. The Chronoplex validator produces the warning statement, “Line value for tag ‘EVEN’ not expected.” GED-inline produces a similar warning statement: “Tag EVEN has non empty content.” It would be better if they caveated this warning by pointing out the mistake in the standard.
The GEDCOM Event Structure is an elegant way of handling events that aren’t defined by the standard, and genealogy app developers would do well to use it instead of their own product-specific tags. They should also allow users to add their own events, to include the EVENT_DESCRIPTOR for both family and individual events, even though it was mistakenly omitted from the structure for individual events. As I explained in “How to Scrub Your Data,” users would do well to convert product-specific fields such as Employment and Military Service to Event fields. In Family Tree Maker, for example, they’re called “Custom Facts,” but they’re exported correctly using the Event Structure. All good apps have this same ability but may call it different things. In the end, the goal is to allow users the flexibility to record their genealogical data while ensuring the data is compatible with other apps.
Note: Software developer Tim Forsythe wrote about the EVENT_DESCRIPTOR, after I brought it to his attention, in an article called “A New GEDCOM 5.5.1 Wrinkle” (GigaTrees Blog, 22 Dec 2015, no longer available).
Leave a Reply