- First and foremost, the UTF-8 character encoding, which enables encoding of most written characters, was not available until GEDCOM 5.5.1, so if an app is to export a GEDCOM with UTF-8, it must label its GEDCOMs as 5.5.1. GEDCOM 5.5 allowed Unicode, but in 1996, “Unicode” would have referred to UTF-16, not both UTF-16 and UTF-8. UTF-8 barely existed in 1995, having been presented only in 1993. UTF-8 wasn’t widely adopted until much later, and the Family History Department certainly was not an early adopter. UTF-8 wasn’t even included in the Unicode Standard until Unicode 3.0 published in 2000. So GEDCOM 5.5 could not have referred to UTF-8.
- GEDCOM 5.5 had two ways of including multimedia: an embedded form using a binary object (called a blob) and a linked form including the full path and name of the multimedia file; notably, the linked form could not use cross-references, meaning every time a multimedia object was referenced, the complete file information, including title and format, had to be repeated. As far as I know, only two apps can currently embed binary objects in GEDCOMs, Family Historian 6 and Ancestral Quest 14; Ancestral Quest cannot read Family Historian blobs, so there is a problem with compatibility. In any event, GEDCOM 5.5.1 eliminated the embedded form, leaving only the linked form. It also changed the structure of multimedia records to allow cross-references. So if an app is to export a GEDCOM with multimedia cross-references and file links, it must use GEDCOM 5.5.1 and label the file accordingly.
- In 1995, the World Wide Web was still in its infancy, so it’s not surprising that GEDCOM 5.5 doesn’t even contain tags for email or web addresses. GEDCOM 5.5.1 added tags for these, as well as fax number and latitude and longitude coordinates and a few other things. For apps to use these standard tags, they must use GEDCOM 5.5.1 and label their files accordingly; otherwise, they must use custom tags that may not be recognized by other apps.
- As Tamura Jones explains, GEDCOM 5.5.1 is not a draft, because FamilySearch hasn’t treated it as such since at least 16 Feb 2000: “For at least the near future, the Family History Department [FamilySearch] is using The GEDCOM Standard version 5.5.1.”
All GEDCOM files have a GEDCOM version tag so that the apps that process them can interpret them correctly, since there are differences in structure among the various versions. Genealogy apps that use any of the features listed above must offer GEDCOM 5.5.1 export, and as far as I know, all currently developed apps offer the UTF-8 character encoding. Therefore, all apps must offer 5.5.1. All apps must be able to correctly import 5.5.1 GEDCOMs, as well, since many apps export files labelled version 5.5.1.
Apps that fail to import and export GEDCOM 5.5.1 files correctly are doing their users a disservice, since at least some data will be lost, altered, or stored in a hard-to-reach location. People who use genealogy apps entrust their hard-earned information to those apps, and they don’t want to have to worry about their information when exchanging it with other people, uploading it to websites, or changing applications. App developers owe it to them to release apps that at least comply with the two most commonly used standards. As far as I’m concerned, apps that don’t support GEDCOM 5.5.1 deserve a “Fail” on a pass-fail test, and I do not recommend them. I’ve tested how well 14 desktop and web apps handle GEDCOM. Seven of those apps can at least label their GEDCOMs as version 5.5.1: Family Tree Maker 2019, Family Tree Builder 8 (but not 7), GEDitCOM II, Gramps 4 & 5, Legacy Family Tree 8, MacFamilyTree 7, and RootsMagic 7 & 8. That means seven of them fail outright: Ancestral Quest 14, Ancestry.com Family Trees, Brother’s Keeper 7, Family Historian 6, Heredis 2015, iFamily for Mac, and Reunion 11. Fig 1 summarizes the results. All of these apps offer UTF-8 as an option; some of them offer tags like EMAIL and FAX; others use GEDCOM 5.5.1 multimedia record structures. If any of these features are in an exported GEDCOM labelled 5.5, then, as Tamura Jones says, they’re lying about it, or the third digit in the version number got truncated. For more details about how well apps comply with the GEDCOM standard, see the respective reports below and my GEDCOM Crosswalk table.
Is GEDCOM 5.5.1 perfect? Of course not; it contains errors, inconsistencies, and contradictions that FamilySearch never corrected before they abandoned it. But there are solutions for these problems based on logic and common sense. For developers who may not be aware, Tamura Jones has published several articles listing best practices for GEDCOM readers, writers, and validators (that covers all apps that purport to handle GEDCOM). Some of these best practices address the problems in the GEDCOM standards, and as a whole they are good practices to follow.
I don’t mean to frighten users of the nine failing apps I named above; most of them just need to make minor changes. But users should be concerned about the integrity of their data—as Ben has pointed out before on this blog, your data are at risk. At a minimum, you should avoid using the fields highlighted in red or yellow for those apps in the crosswalk table, and if possible, copy existing data to other fields. You definitely should demand that the app developers support GEDCOM 5.5.1 and fix the compliance issues that I identified (there may be others). For your convenience, I’ve listed their support contacts below. I’ve contacted all of them about my findings; some have responded, but some haven’t. Some gave flimsy excuses for not supporting 5.5.1, some ignored the issue, and some committed to supporting it (including Family Tree Maker). Some said they would support it if there was a demand for it, so let’s demand it.
Genealogy Application Support Contacts
Ancestral Quest: support [at] ancquest.com
Ancestry.com: support [at] ancestry.com
Brother’s Keeper: Brothers_Keeper [at] msn.com
Family Historian: support [at] family-historian.co.uk
Family Tree Builder: support [at] myheritage.com
Family Tree Maker: http://www.mackiev.com/familytreemaker/ftm3/ftm_feedback.html?type=bugreport&ext=yes
GEDitCOM: support [at] geditcom.com
Gramps: https://gramps-project.org/bugs/my_view_page.php (registration required)
Heredis: http://www.heredis.com/en/forums/viewforum.php?f=6 (registration required)
iFamily: support [at] ifamilyformac.com
Legacy Family Tree: support [at] legacy.com
MacFamilyTree: macfamilytree [at] syniumsoftware.com
Reunion: help [at] leisterpro.com
RootsMagic: support [at] rootsmagic.com
The Complete Genealogy Products: http://www.tcgr.bufton.org/tcgpsupp.htm
Note: GEDCOM 5.6 was essentially 5.5.1 with the addition of an XML-based structure. It wasn’t even a publicly released draft, as 5.5.1 was. Although the document was dated 2000, it wasn’t leaked to the public until 2011. There was also a GEDCOM replacement based completely on XML, inappropriately named GEDCOM 6, which never proceeded past the beta stage and was not widely adopted. Since 5.6 added little of value other than the XML structure, and GEDCOM XML was completely based on XML and therefore totally different from previous versions, there is little to be gained by apps implementing either of these standards. Apps have a hard enough time complying with 5.5.1—that should be enough until a replacement is adopted by all app developers.
Acknowledgment: Tamura Jones reviewed an earlier draft of this article and made substantive corrections and suggestions. Any errors, however, are my own, which I will gladly correct if they are pointed out.
Updates:
20 Apr 2016: Removed the “beta” designation from Family Tree Maker.
29 Apr 2016: Changed GEDitCOM II from 5.5 to 5.5.1 due to its ability to change the GEDCOM version from within the app.
12 Dec 2021: Changed Family Tree Builder from 5.5 to 5.5.1 due to version 8 reporting the correct GEDCOM version.
The Family Tree Software Alternatives Series
Part 1: How to Scrub Your Data
Part 2: How to Get Your Tree out of FTM
Part 3: RootsMagic 7
Part 4: Reunion 11
Part 5: MacFamilyTree 8
Part 6: Family Tree Builder 8
Part 7: Heredis 2015
Part 8: Gramps 5
Part 9: iFamily for Mac
Part 10: GEDitCOM II
Part 11: Legacy Family Tree 8
Part 12: Ancestral Quest 14
Part 13: Family Historian 6
Part 14: Should You Stick with Family Tree Maker?
Part 15: Brother’s Keeper 7
Part 16: RootsMagic 8
How Well Does Ancestry.com Handle GEDCOM?
Family Tree Maker to GEDCOM to Other Apps Crosswalk
The Perils of Following the GEDCOM Standard
Why All Genealogy Apps Should Support GEDCOM 5.5.1
I’m fairly new to all this, but I’ve spent most of my life working with data and databases and the craziness that’s the GEDCOM standard flabbergasts me. Other than the fact that there’s no 800 lb gorilla in the genealogy world other than the LDS gang, therefore there’s no one to enforce a true data format standard on the community, why not get behind something like these new XML-based definitions? I’ve worked with XML on and off since it appeared on the scene, and while it’s got it’s own problems and quirks there are tons of tools already available for making sure that a file is following an XML-defined standard, and lots of software packages that can do all sorts of things with XML data files.
Jim, you hit the nail on the head when you said, “Other than the fact that there’s no 800 lb gorilla in the genealogy world other than the LDS gang, therefore there’s no one to enforce a true data format standard on the community.” GEDCOM isn’t even a true standard, in the sense of an ANSI or ISO standard. It’s what Tamura Jones calls a de facto standard, because it has been widely accepted by the industry. The LDS Church owns GEDCOM but for whatever reason have abandoned it. They’re supposed to be developing GEDCOM X as an open-specification replacement, but it seems to be moving very slowly. They actually released a beta of an XML version called GEDCOM 6 in 2002, but it wasn’t widely adopted, and FamilySearch abandoned it, too. There’s also the Family History Information Standards Organisation (FHISO), “a community-driven organisation established for the purpose of developing genealogy and family history information standards” (http://fhiso.org), but they’re progressing at a glacial pace. Tamura Jones has lots of information about GEDCOM on his website, http://tamurajones.net.
Much of the information I have on GEDCOM came from Tarmura’s website. I suspect that even if a group like FHISO puts together a good consistent format it will never go anywhere because the various software vendors have no incentive to output in a standardized format. That’s how you lose customers if your product lags in development, and if Harvard Business School teaches you anything, it’s that you want to hang on to your customers even if you have to chain them in place!
That’s what I’m trying to do with my GEDCOM test reports: encourage people to demand that their app of choice comply with 5.5.1, or threaten to adopt a different app.
An interesting article and it is impossible to disagree with the suggestion that genealogy apps should be able to reliably import/export their data in GEDCOM (or indeed any other standard format) but given the length of time that we have all been waiting for this it is hard to see why it should happen now.
Threatening to move to another application is hardly likely to produce results. I for one did not choose my main application on the sole basis of its GEDCOM import/export facilities and I will not be changing if they don’t ‘improve’ (Family Historian 6.2)
I think if enough users demand 5.5.1 support, Calico Pie will offer it. But if everyone remains silent, they will have no incentive to do anything. That’s usually the way things work. As things stand, FH6 already exports 5.5.1 files if you don’t embed media and/or select UTF-8 encoding – it just mislabels them as 5.5. How hard can it be to properly label the HEAD.GEDC.VER tag with 5.5.1 if the UTF-8 encoding and full paths to media records are selected?
hello, please check your link for: GEDCOM Crosswalk table. it does not seem to work. very interesting and helpful article.
I updated the link, thanks