FamilySearch has released GEDCOM 7.0 to the genealogy world in an announcement today:
=======================================================
FamilySearch International is pleased to announce the release of FamilySearch GEDCOM 7.0 (Genealogical Data Communications). The latest version allows zip packaging capabilities for photos and files with genealogical information, plus new tools, and a public GitHub repository for ongoing maintenance. Technical information, specifications, tools, and guides can be found at GEDCOM.io.
At RootsTech 2020, FamilySearch launched an effort to create a new version of GEDCOM based on the 5.5.1 version that would include: 1) new expressivity, flexibility, and compatibility; 2) zip packaging of associated images and other files with the related GEDCOM file; and 3) public access using a GitHub repository. Many industry software providers and key influencers participated, and the initiative concluded May 15, 2021, with the completion of this comprehensive effort.
FamilySearch GEDCOM 7.0 is the outcome of those efforts and includes the following new enhancements:
• Zip packaging capabilities for photos and files have been added.
• Notes have been expanded for more versatile use and styling of text.
• Tools, sample files, sample code, and self-testing guides are included.
• The GEDCOM specification and any code available from FamilySearch based on the specification is subject to the terms and conditions of the Apache License, Version 2.0.
• Ambiguities in the GEDCOM Version 5.5.1 specification have been removed.
• A public GitHub repository generates maintenance requests and on-going discussions about future features.
Users of FamilySearch GEDCOM 7.0 will be able to import files from older GEDCOM versions. However, users of older versions of GEDCOM will not be able to import from FamilySearch GEDCOM 7.0.
============================================
There is more information about GEDCOM 7.0 on the FamilySearch page - https://www.familysearch.org/gedcom/
You can find the technical specification for GEDCOM 7.0 in PDF at https://gedcom.io/specifications/FamilySearchGEDCOMv7.pdf.
The specification lists the Contributors to this effort, which apparently was organized at RootsTech 2020. All of the major family tree "players" were involved. I am glad that there was this much participation and hope that all parties can incorporate this new GEDCOM capability into their programs and websites without destroying the current GEDCOM 5.5 capabilities we've had for the past 20 years.
It will be interesting to see how the new features will be implemented in current software programs and online family trees.
This has been years in the making, since the BetterGEDCOM then FHISO effort from about 2012, FamilySearch building GEDCOM X by themselves, and now, finally, we have an improved GEDCOM standard.
If I recall correctly, one of the anticipated presentations at RootsTech 2021 was unveiling GEDCOM 7.0. It was scrubbed before the online virtual conference began.
=============================================
The URL for this post is: https://www.geneamusings.com/2021/06/the-long-awaited-gedcom-70-is-here.html
Copyright (c) 2021, Randall J. Seaver
Please comment on this post on the website by clicking the URL above and then the "Comments" link at the bottom of each post. Share it on Twitter, Facebook, or Pinterest using the icons below. Or contact me by email at randy.seaver@gmail.com.
8 comments:
I'm curious to see how long it will take the various genealogy software companies to implement this new version of gedcom. More importantly, will Ancestry and the other big genealogy sites do it as well? If they did, it would make the need to sync or TreeShare obsolete, though methinks Ancestry might not want to allow people to include all that media in a gedcom download as it could mean a drop in revenue if people download their docs and don't renew. Then again, people who want just a snapshot, rather than doing continual research are always liable to join, gather what they can in a year, and then never renew.
Interesting indeed...
Randy;
One thing that I wish the GEDCOM 7 Std. had is EVENT tags for entering or leaving a place, but not for the purpose of immigration or emigration. That is; it would be nice to be able to document the many ocean trips that some ancestors took. Right now, one has to create a special event tag, and those don't transfer to other programs. Using the EMIG and IMMI tags gives the wrong impression.
History Hunter:
If those special event tags are written by your program to GEDCOM as: 1 EVEN 2 TYPE xxx and if the 2nd program would read that properly, then the xxx would be the event name in both the first and 2nd program and everything would transfer correctly.
GEDCOM 5.5.1 (and GEDCOM 7.0) already have that capability. The problem is that either your program is not exporting that correctly, or the other problem is not importing that correctly.
It is important that developers understand what is already in GEDCOM and implement it properly. Most of the reason why data doesn't transfer is not GEDCOM. It's the developers.
Thanks for the response, Louis.
I've used an number of the popular programs over the years and no two of them exchange GEDCOM data even close to fully; especially user-defined tags..
There is little incentive for developers to fully handle user-defined tags. As it is; developers only tend to fully handle the pre-defined tags, in order to advertise that they adhere to the GEDCOM standard. Few spend the time to FULLY implement the standard in their software. I suspect that this is because the handling of potentially unusual information from user-defined tags could cause them issues in coding their data-entry screens and formatting and wording generated reports.
This is why, I wish that specific types of information, like that noted in my first post, was issued a pre-defined tag. The noted information is quite prevalent in the research of anyone who had ancestors that travelled for more than immigration and emigration purposes.
History Hunter: There is no problem handling user-defined tags if the developer would just sit down and think about it. They only need an event with a user-defined name. They could handle it the same as any other event, except instead of naming it "Birth", "Census" or "Divorce" because they are 1 BIRT, 1 CENS or 1 DIV tags, they name it "xxx" because they are 1 EVEN 2 TYPE xxx. They will have dates, places, notes, sources just like the other tags and can be processed similarly to a CENS tag for editing or display purposes.
Adding new pre-defined tags serves only to force more effort on programmer to handle the new tags differently, and they will be less receptive to that than to handling all other tags more generally. GEDCOM needs to be kept as simple as possible for developers. New capabilities should only be added to it there is some necessary data that cannot be represented in it. 100 new event tags does not do anyone any good.
The incentive to developers to handle GEDCOM correctly is that people will use their programs BECAUSE they will know they will be able to get their data in AND out again.
when considering the adoption of GEDCOM 7 by the big sites, such as Ancestry etc., then it will be interesting to see if changes to user data are factored into their estimates for the necessary changes.
Everyone who has tried to process a GEDCOM files exported from such sites is aware that end-users have been allowed to enter virtually anything they like into a DATE field. Developers such as myself have to jump through hoops to try and make sense of what appears in the files.
My point is that although they can give an estimate for software changes, testing, and documentation, unless users' data is cleansed then it is impossible for them to export data conforming to the v7 specification. This will be a huge change, and it cannot be blamed on the users and left to them to fix; poor UIs allowed the entry of bad dates, and it will need some software support to help fix them.
Tony;
I tend to agree that data-entry validation is almost non-existent, or at least the criteria are far too loose, in many genealogical programs. It's the old garbage-in...garbage out situation. As long as the program authors are focused on adding bells and whistles, rather than making existing capabilities more bullet-proof, the situation for GEDCOM import/export is not likely to get any better.
Re: "...import/export is not likely to get any better", that would be sad for several reasons; one being that GEDCOM 7 has validation options, but these sites will NEVER be able to generate a compliant file without the data-cleansing.
As a long-standing developer, I still find it hard to believe that these sites found themselves in such a position. Better validation -- or, preferably, controls that only admit valid dates -- is not exactly a new concept. I sometimes wonder whether there was a software design at all. You see what the user enters, and what they see displayed, have little to do with GEDCOM. As long as the software understands what was entered then it can easily be converted to GEDCOM format when necessary. In other words, the end-user could enter valid dates and see valid dates without even knowing the name GEDCOM.
However, when it comes to data standards and specifications then it's unforgivable to just any old stuff in the file and claim, 'yeah, we do GEDCOM export'.
Post a Comment