Prev
There are hundreds of genealogy programs and almost all of them use GEDCOM to for importing and exporting their data. GEDCOM (which stands for GEnealogical Data COMmunications) was developed near the beginning of time and the last revision (5.5.1) was drafted about 15 years ago. It provides a data definition to allow transferring about 98% of the basic data and sources and notes between genealogy programs.
In developing Behold, I have become quite familiar with the way various programs export their data. Behold attempts to read any and every one of them, and pull out all their data - even if they don’t follow all the standards and have their own quirks. My experience is that for the most part, GEDCOM does a decent job.
I think GEDCOM only needs a few tweaks: maybe convert it to XML and make it Unicode. Add Places and Citations at the record level. And update its handling of media files. But there are some people that think that it needs more.
A new site has been created called BetterGEDCOM and its at bettergedcom.wikispaces.com. This is where a number of interested people in the genealogical community have decided to get GEDCOM updated and include what they think is missing. It is in a Wiki format, so anyone can contribute. There is a lot of discussion going on, and to tell the truth, a lot of it is even beyond me. They are trying to do everything from including an Evidence-Hypothesis-Conclusion model, to adding roles, tasks, groups, templates - you name it - into GEDCOM. They’ve brought up 6 different genealogy data models from the past and have proposed several new ones already.
The discussion is overwhelming. To be honest, I don’t see how it is going to come together. There are a lot of very smart people there and several expert programmers and genealogists who seem to be having a great time just enjoying the act of discussing and dissecting all the parts. I have participated fairly actively on basic concepts which I feel strongly about, but the interest seems to be in the stuff that’s a little bit more abstract and a little less practical.
I really hope they come back to earth and accomplish something. I’ve suggested that they concentrate on developing a formal document. Maybe they can start with the GEDCOM 6.0 XML draft and fix what’s wrong with it and add what absolutely needs to be there. They can come out with a GEDCOM 6.1 and propose it to the genealogy community. That, I believe, will have a chance. Anything more (which I compare to a GEDCOM 10.0) would be too far removed from existing GEDCOM to make it easy to get developers to convert to.
If BetterGEDCOM starts to get somewhere, it will be interesting to follow and to be a contributor to. This will be a real test to see if the Wiki model for communal development does work. Will it converge to something that becomes the accepted successor to GEDCOM? Or will it fade out into nothingness as frustrations over the progress or lack thereof results in waning interest and people leaving the initiative.
It’s still too early to tell, but the participants had better start producing something tangible soon.
RSS
Trackback
Permalink
Leave a Comment
Joined: Tue, 14 Oct 2008
20 blog comments, 0 forum posts
Posted: Wed, 8 Dec 2010
Just wondering, Louis. What holds you back to implement the conversion of GEDCOM data into XML or even JSON format yourself? From a programmer’s perspective, it should be fairly easy.
http://www.progdigy.com/?page_id=6
http://xml.coverpages.org/genealogy.html#gedML
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Wed, 8 Dec 2010
Uwe: It’s not just a matter of converting GEDCOM to XML. For years, there are many that have said that GEDCOM needs to be improved. This is their chance to do that. The real challenge will be to give the 200 or so authors of genealogy programs a good reason to adopt the new standard and implement it.
Joined: Tue, 14 Oct 2008
20 blog comments, 0 forum posts
Posted: Wed, 8 Dec 2010
Understood. I was just asking myself why you don’t grab the chance and implement whatever draft is the latest (or makes the most sense), while the others are still waiting for an endless discussion to end. If someone takes the first step, the others might follow quickly. Competition is fierce nowadays. IMHO, it doesn’t hurt to offer different options like GEDCOM, XML or JSON at the same time, even if some are not fully mature standards.
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Wed, 8 Dec 2010
I don’t see any real benefits personally in a new standard. I am actually quite happy having Behold read in all the flavors of GEDCOM as now exist. If a new standard came about, then I’d support it as well. I haven’t added Behold’s export yet. But there’s no use exporting anything but GEDCOM if that’s all other programs will read. GEDCOM, after all, has the main purpose of transferring data between programs. It could be used for data storage, but you need to do a few non-standard tricks if you want to store all types of data - and few programs would read those extras.
I don’t mind helping a bit with BetterGEDCOM, but I’d sooner spend most of my time concentrating on Behold. I’m still not even at version 1 yet, and I should have been there 5 years ago! But I’m not unhappy. I have been having a great time along the way.
Joined: Thu, 9 Dec 2010
1 blog comment, 0 forum posts
Posted: Thu, 9 Dec 2010
Louis,
Thanks for both your blog posting about BetterGEDCOM and your participation there. As you probably know, I am one of the organizers of BetterGEDCOM. Today is in fact BetterGEDCOM’s one month anniversary of going public. We’ve set a big task, and you’re right to say that there’s a lot going on, and it might not all be that practical. But for me, one month in, that’s not a problem. It’s good that we have so many people with such interesting ideas that are contributing. It can be more than a little chaotic, but we’re certainly aware of the need to concentrate our efforts on really getting something done.
We’re discussing a lots of issues related to organization, focus and other critical aspects to moving forward. Right now, the question on the table seems to be whether we actually use a data model that embraces the research process or sets a path for doing so as opposed to patching GEDCOM. Since we are primarily concerned with faithfully housing genealogy data as found in today’s software applications in an XML-based file format, we’ll simply delay addressing the research process if we cannot devise a resolution between the incongruent conclusion and evidence models.
Given how far along we are, I think we’re doing fine. We are certainly focused on results, however, so stay tuned to see what happens next.
Joined: Sun, 9 Mar 2003
288 blog comments, 245 forum posts
Posted: Thu, 9 Dec 2010
Thanks for posting a comment to my blog, Greg. I give you a lot of credit for pulling this BetterGEDCOM endeavor along. I get encouraged by progress, and the recent page added on Formulation of the BetterGEDCOM Data Model is a big step in the right direction.
The “Research Model” is a theoretically nice idea. Even if it can be incorporated into a new GEDCOM model, I’m not sure the masses will accept it. It may just remain something that an elite few will take hold of. Because of this, I feel strongly that BetterGEDCOM needs to incorporate that research model as an “optional component”, and not be intertwined with the genealogy data to the extent that it is mandatory.
But that is just one opinion (mine) and the endeavor has many opinions to sort through and make decisions on. As you say, the goal must be to stay focused on results.