Monday, November 01, 2010

Build a BetterGEDCOM


Ancestry Insider mentions today in Mailbox Monday: GEDCOM that genealogy bloggers who met with FamilySearch on the 21st of October 2010 expressed frustration by the lack of support for GEDCOM, last updated in 1996. What the Ancestry Insider perhaps didn't know was that the email he received was due to recent activity on the GEDCOM-L Mailing List instigated by Greg Lamberson as part of a project he and other interested parties are developing, including Ol' Myrt here who has been Frustrated by GEDCOM incompatibilities.

I had waited to blog about this new "layman's" (read that non-FamilySearch) Build a  BetterGEDCOM project, which will be officially announced in a day or so, but now I simply must speak up.

  • If genealogy software programmers in Norway can agree to follow an advanced file-sharing format, then why not make these and other improvements universal?
  • If FamilySearch isn't supporting GEDCOM anymore, then why hold on to it?
  • How can average Joe researchers, like Ol' Myrt, here share info with a new-found cousin if GEDCOM files are stripping out notes, links to source documents, etc.?

During the 1st Annual FamilySearch Bloggers Day Event on 21 Oct 2010, Gordon Clarke responded to Ol' Myrt's pointed questions about the outdated GEDCOM file format. Gordon stated that GEDCOM was used by folks to upload their genealogy databases to newFamilySearch and that APIs would eventually replace the need for GEDCOM with FamilySearch.

Later as we toured FamilySearch offices in the Joseph Smith Memorial Building, there were a number of  desks devoted to what Gordon called "GEDCOM". However, when my ears perked up and I looked inquisitively, Gordon explained they handled "GEDCOM upload issues".

Since newFamilySearch will become the defacto mega-lineage database at FamilySearch, it would seem a priority to not only facilitate better data communications between FamilySearch and various FamilySearch users' software programs (being accomplished through the FamilySearch developers network), but to extend that model for better data communications across the board. This would help researchers like Ol' Myrt here, who primarily uses RootsMagic and her husband Mr. Myrt, who uses The Master Genealogist.

WHY leave the "little guy users" of different genealogy software programs in the dust?

FamilySearch requires certification for software programs such as RootsMagic to integrate with the "newFamilySearch" mega-lineage database now being advanced beta-tested by LDS Church members. (Believe me, from what I've heard, programmers spent months modifying and remodifying their individual genealogy software programs to comply with FamilySearch requirements. Other genealogy software programmers have opted out of the FamilySearch compatability altogether.)

There seems no reliable data communications exchange among genealogy software programs that takes into account data fields, multi-media files and hyperlinks not considered in the last GEDCOM update. 1996 was light-years ago from a technology standpoint.

FamilySearch's parent organization instituted GEDCOM and worked toward unification of data exchange. Since FamilySearch has stepped back and has not updated GEDCOM for 14 years, then can't others step forward to facilitate seamless data exchange among researchers? 

This is the day and age of open-source software. 

To facilitate my attendance at the Bloggers Day Event, FamilySearch provided lunch and dinner,  round-trip plane fare and hotel room for two nights.

Don't get me wrong -- I love FamilySearch. Much valuable original document research can be accomplished using existing and emerging FamilySearch resources. Having a mega-lineage database of ancestors can help avoid duplication in LDS Church temple work.

No genealogy website or program should follow a model that precludes individual users from exchanging databases seamlessly.

It is long past time to build a BetterGEDCOM.

I've been working with a group including Greg Lamberson and Russ Worthington to create a wiki for discussion. We're about 24 hours away from releasing the workspace so that discussions and sandbox work can take place outside the Gedcom-L mailing list. Unfortunately, the mailing list model doesn't permit a number of options provided by newer technology in a wiki format.

Our Build a BetterGEDCOM idea to get the discussion out in the open included not wishing to have any big time commercial website or commercial software producer sponsoring the space. Since I don't create or sell software or membership to my site, I decided to take the plunge.

I'll let my techie-readers know when the wiki is ready to go live. We're 99% there.

Happy family tree climbing!

Myrt     :)
Your friend in genealogy.


  1. Fascinating goings-on in the genealogy world! And surprisingly timely following on the heels of a topic on (, which delves into GEDCOM and data exchange at some length.

    Jumping the gun a bit on the wiki, my thought is that an XML adaption of GEDCOM would be a likely candidate for discussion, although a file format per se would be only part of that conversation. Import/export APIs and various other standards would no doubt be pieces of the puzzle.

    I have not heard about the activities of Norwegian genealogy programmers, and hope to read about that and more when the wiki opens its doors for public access. Thank you for once again drawing the user community into the discussion of standards in genealogy practice.

  2. My assignment from the BetterGEDCOM group was to inquire of FamilySearch about updating GEDCOM. Indeed, among the attendees at the 2010 FamilySearch Bloggers Day Event were the Ancestry Insider, Dick Eastman and Genealogy's Star James Tanner. James also wrote on the topic:

    I particularly liked his comment "It is well known (by those who care) that the GEDCOM standard allows for far more tags than were implemented in PAF [Personal Ancestral File] Version 5.2 and that many software programs have implemented non-GEDCOM extensions."

  3. I was just wondering about this being new to genealogy and had just ran across the following on the Gramps website: ''Gramps uses Gramps XML which is considered a superior format to GEDCOM by the Gramps developers. Although Gramps should be able to import most data from GEDCOM through its GEDCOM Import module, many of the Gramps features are not supported by the GEDCOM standard and so GEDCOM Export from a Gramps Family Tree or Gramps XML is a lossy operation. This page shall list all the information that is lost on a GEDCOM export from Gramps, so that users may choose to restrain their Gramps use to those features that GEDCOM can handle. Gramps recognizes the relevance of GEDCOM and attempts to offer the best compatibility possible. ''

    So why don't programs just switch accross to Gramps XML?

  4. Your suggestion is a good one.

    I believe that all genealogy programmers should be in on the decision, hence the need for the wiki to expand this discussion.