Wednesday, June 5, 2013

GEDCOM X Matures into the FamilySearch API

Ryan Heaton had a post yesterday on the GEDCOM X blog titled "GEDCOM X Milestone 1" stating:

"After over two years of collaboration and active development, we're excited to announce the first stable milestone release of the core GEDCOM X specification set."


"The purpose of the milestone release is to stabilize the specification set so we can move to the next phase of development. The focus of the next phase will be specifically on documentation and developer tools. This includes 'non-normative' tutorials, use cases, and recipes as well as the development of open-source libraries for the most popular platforms."

Over the past week, Tamura Jones has published several analyses of GEDCOM X on his Modern Software Experience website:

*  GEDCOM X 1.0.0 M1 (4 June 2013)

Tamura has tested the code (perhaps the only non-FS person who has, and written publicly about it), has determined that some GEDCOM features (like NOTES) are not yet included, and concludes that "GEDCOM X is not related to GEDCOM, but to the FamilySearch Family Tree API."  

I think he's right.  The FamilySearch Developer Network  Forum called it the "FamilySearch API" in "FamilySearch API Release" on 31 May 2013.

FamilySearch has developed GEDCOM X independently from the other efforts to improve the GEDCOM capability to transfer genealogical data from one program or website to another.  The GEDCOM X API can, apparently, be used to perform these tasks so that genealogy software programs can interface with the FamilySearch Family Tree and transfer data to and from the Family Tree.  

Why is it called GEDCOM X?  I guess that it got a name early on because someone at FamilySearch said "We really need to improve the current GEDCOM Standard to incorporate modern genealogy software features," funding the project, and then while thinking that through, the need for the New FamilySearch API arose, and that morphed into FamilySearch Family Tree and someone at FamilySearch said "Let's make GEDCOM X do both functions, and maybe it will become the standard for the industry."

Will GEDCOM X be a standard?  It will be if the genealogy data providers (e.g., Ancestry, MyHeritage, FindMyPast, etc.), the online family tree providers, and genealogy software providers adopt and use the API for competitive and commercial reasons.  If they want to interface with the FamilySearch Family Tree, they will have to adopt it.  I can see all genealogy providers being able to handle both the current GEDCOM file structure and the GEDCOM X structure to transfer family tree information from one platform to another.  This is truly and example of "Build it, and they will come!"

The big issue for me, and for many others, is how the accuracy, completeness and format of genealogical data will be transferred between platforms.  I think that the most difficult issue is source citations, since each software company and online family tree site has created their own custom fields for source citations using the Evidence! Explained models, and reading those from one platform to another using GEDCOM often creates a mess that is not easily rectified.  I think that most of the other GEDCOM issues are more easily resolved.

My conclusion is that FamilySearch has created a de facto standard for transferring genealogical data from one platform to another, and that the other genealogical industry entities will accept that standard and use it.  Hopefully, FamilySearch will be open to suggestions and modifications suggested by companies and researchers to add features and resolve problems as they arise.

The URL for this post is:

Copyright (c) 2013, Randall J. Seaver


Dan Stone said...

Finally! Now things will get very interesting. I hope this will become universally adopted, although I agree that the transfer of sources between programs/platforms presents a huge challenge. Even so, if the rest of one's data can be moved intact between programs/platforms, that would be a monumental step forward.

Sven-Ove Westberg said...

You are right Randy the citations will be the problem. Evidence Explained need to be transferred to a standard format such as MARC 21 or MARCXML that is supported by the Library of Congress. This should then be included in the GEDCOM X standard.

Louis Kessler said...


I disagree with you that a new GEDCOM should transfer citations.

Only the source information to identify the source needs to be transferred. Citations are like formatting. Once you have the source information, you can create the citation.

And each program should be allowed to create the citation any way they want. If they use Evidence Explained, then so be it. They may interpret EE differently than another program, and they should be allowed to do so their own way, and display it their own way. They may even give you, if they want, other options, e.g. Richard Lackey or even bibliographic methods such as APA or Chicago. Again, it should be up to the program, and not up to the standard to force it to one interpretation of one methodology.

The important thing is that your source data can be transferred. And GEDCOM does that reasonably.


Geolover said...

The FamilySearch-FamilyTree code for the so-called "GEDCOM X" is still quite limited. At least, as Tamura Jones noted, the designers of the misnamed "GEDCOM X" have settled on one of the three programming options they were using.

The current version is far from being able to be any 'standard'. It is yet to be seen whether future design will ably integrate evidentiary citations with events.

Dan Stone said...

After reading Louis and Sven's comments, and pondering the issue a bit more, it would be nice if there was a universal standard for source elements (such as 'title', 'author', 'publisher', etc.). With such a standard in place, these source elements could then be seamlessly transferred between programs/platforms, but the resulting ordering and formatting of the elements could be decided by the receiving program/platform. That way I could display my footnote in Evidence Explained style, and someone else could display the footnote in Richard Lackey style, yet we could exchange our database back and forth because the underlying elements that make up the source, footnote and bibliography listing were identical.