GEDCOM Should NOT Allow Extensions - Mon, 18 Jan 2021

The GEDCOM standard for transferring genealogical data has been in use basically unchanged for over 20 years now. Just about every genealogy software program can export (some of) its family data to a GEDCOM file, and can import (some of) the family data in a GEDCOM file into its database.

The issue is the “(some of)” qualifier that I put in.

We want our programs to export all their family data so that a user can transfer that data to another program or website. For the most part, the basic name-birth-marriage-death-date-place information transfers reliably. It’s everything else, facts, events, sources, repositories and even notes that often don’t make the crossing.

The blame is usually put solely on GEDCOM, accusing it of being unable to represent the data.

I disagree. I put just 10% of the blame on GEDCOM, and 90% of the blame on the programmers of genealogy software who have, for whatever reason, decided not to use some of the GEDCOM tags and constructs but rather use their own inventions instead.

Why Data Doesn’t Transfer

Several obvious reasons:

1. The exporting program doesn’t export some of its data. You can’t import what’s not there.
2. The exporting program sometimes exports its own custom GEDCOM tag or construct rather than use what’s in GEDCOM. An importing program can’t import what it doesn’t understand.
3. The exporting program exports some of GEDCOM incorrectly. Hard to import anything that isn’t correctly exported.
4. The importing program doesn’t import everything. Usually it won’t import what it doesn’t export.
5. The importing program doesn’t recognize certain standard GEDCOM tags and constructs when it uses its own custom GEDCOM tags and constructs in their place for its own export. So for these tags and constructs, it will only import its own data again.
6. The importing program imports some of GEDCOM incorrectly. It may lose some data as a result.
7. GEDCOM does not have a construct for storing a certain type of data, so it can’t be transferred. Many people think this is a worse problem than it is. There’s not much family data that GEDCOM cannot transfer.
8. GEDCOM allows developers to use their own custom tags or extensions, so the developers do use their own. Other programs will not understand anything a developer does that’s not in the standard unless they do custom programming specifically to handle that developer’s custom tags and extensions. Allowing this was a mistake.

What is the Problem?

The number one problem is that developers for whatever reason, are not taking the time to ensure that they understand the GEDCOM standard and try to export their data the way GEDCOM is telling them to.

Too often, they are jumping to the conclusion that there is no way to export their data to GEDCOM, so they take what they think is the easy way out, and they invent their own tags and constructs for their data.

What harm in that? – they think. After all, their program will export their data, and their program will be able to import it again. Do they really care if another program can?  (They should, but I won’t get into that in this article.)

An Example

I recently had an online conversation with a very experienced genealogy software developer who was wondering how strict a genealogy program should be with respect to GEDCOM support.

He gave this example of how he wanted to export information extracted from a marriage licence and add it as part of the MARL (marriage license) tag in GEDCOM.  

The MARL tag is valid. GROO, BRID and RECR are not. Source information is being included in an MARL fact under the GROO and BRID tags, when it should be in GEDCOM’s SOURCE_CITATION structure instead.

Other than the program creating this, no genealogy program will be able to read and load this data as intended into its database.

So how should this case be handled?  This was my answer:

Converting your MARL event to valid GEDCOM (adding illegal indentation for clarity) would give this:

The birth places and ages could also be documented, but they shouldn’t be done under the marriage license event. They should be under the individual’s birth event:

What GEDCOM is saying regarding Evidence and Conclusions is this: Evidence should be in the DATA portion of the SOURCE_CITATION. Conclusions are the Events/Facts that you enter.

The TEXT information can be included as it is in the document and needn’t have to be pigeonholed into real or imaginary tags like GROO or RECR

Conclusion

As I see it, two very bad things happen when developers do not follow GEDCOM as intended:

1. They will export GEDCOM that other programs will not understand.

2. They will not bother to implement some GEDCOM constructs that they are not using, so their program will not be able to import and properly interpret those valid GEDCOM constructs from other programs.

People think GEDCOM is the main reason why data doesn’t completely transfer between programs. False. It is the inconsistent implementation of GEDCOM for both import and export that is the primary cause of data loss.

Future enhancements to GEDCOM should require that only GEDCOM tags and constructs be used. No developer tags or constructs should be allowed.

Requiring compliance with no exceptions is the only hope we will ever have for all our genealogy data to one day be able to transfer correctly from program to program.

Further Reading

From 2015: Complete Genealogy Data Transfer
From 2015: Is GEDCOM Good For Sources?
From 2013: Nine Necessities in a GEDCOM Replacement