Login to participate
  
       
Register   Lost ID/password?

Louis Kessler’s Behold Blog

From Ancient GEDCOM to Prehistoric GEDCOM - 3 days, 13 hrs ago

A few hours ago, I posted an article wondering if I may have found the world’s oldest GEDCOM file. Tamura Jones in response emailed me one that he thought may be older.

image

Instead of beginning with a 0 HEAD record as all GEDCOMs do, this file begins with a 0HH record (no space between the 0 and the HH). It is followed by lines with a single number, a two character tag and a value. The tag for INDI records is II and the tag for FAM records is FI. The file ends with a 0ND record. It definitely looks like it might be the creature that preceded the GEDCOM file I had earlier found.

Then when I looked at the data in this file, I was even more surprised. It proves to be a file created by Phillip Brown’s Family History System which is especially apparent because Phillip’s own data is in the sample file.

It just so happens that Family History System was the first genealogy program I ever purchased back in 1993. I loved its Relative Report which was the inspiration for my Everything Report in Behold. But I never did use it for my own genealogy because its data input was not to my liking. A few years later I got Reunion for Windows for my data entry.

I no longer have the Family History System program on my current computer (it was a DOS-based program) … BUT … I still happened to have the Family History System user manual in hardcopy form! To my surprise, the manual not only talks about the Export/Import Utility, but it provides a full six page description of the Transfer Dataset Format. At the beginning of that, it says:

“The TRANSFER datasets used in the Export/Import processes of the Family History System Extension were designed using the original guidelines developed by the LDS Genealogical Department for representing genealogical information in standard character format. The name that is being used to describe this format is GEDCOM (for GEnealogical Data COMmunication format). The format that was used in the GEDCOM implementation of the LDS Personal Ancestor File (PAF) 2.0 software differed significantly from this original description.”

Since PAF 2.0 used GEDCOM 2.0, which we believe is the file I had found earlier today, FHS must have been exporting using GEDCOM 1.0.

There is an Import/Export utility that was also supplied with the FHS. The documentation there stated:

“The format of the transfer dataset follows closely the original GEDCOM format proposed by the LDS Genealogical Dept. and advocated by the quarterly journal, “Genealogical Computing”. … The formats of the transfer datasets implemented by releases 2.0 and 2.1 of the Personal Ancestor File (PAF) software distributed by the LDS Family History Dept. differed from the original guidelines and so are not compatible with the format used by this program. A separate FHS export/import program, compatible with the PAF software is now a part of the basic set of programs.”

In other words, FHS exported/imported GEDCOM 1.0 via it’s built-in transfer program. It used a separate export/import program for GEDCOM 2.0 (PAF 2.0) and GEDCOM 3.0 (PAF 2.1). So the file that Tamura showed me was indeed GEDCOM 1.0 as produced by Family History System. 

Will I support GEDCOM 1.0 in Behold? Well I could. But I doubt if anyone has any files of that format lying around that they really need to extract the data from. Let me know if you do.

p.s. I started subscribing to Genealogical Computing in 1992 – Volume 12. By then, GEDCOM was already up to version 5.0. I have all the issues from 1992 until they stopped publishing in 2005. It’s a fantastic historical documentation about early genealogy software. Does anyone out there have copies of volumes 1 to 11?

The World’s Oldest GEDCOM File? - 3 days, 17 hrs ago

While preparing my presentation of Reading Wrong GEDCOM Right for the Gaenovium Conference, I wanted to see if I had in my collection of over 600 test GEDCOM files some early GEDCOMs from the pre-GEDCOM 5.0 era.

I searched my files for some of the pre-GEDCOM 5.0 tags outlined by Tamura Jones in his GEDCOM Tags article. I didn’t have any such files. So I searched the web. I was surprised to find just one single file, It was among the collection of GEDCOMs at the now abandoned Genealogy Forum site.

The file I found was gedr6127.ged and the start of it looks like this:

image

The file information for this file at Genealogy Forum states that it was uploaded by Jean Hudson Masco on April 21, 1997. This is well past the introduction of the GEDCOM 5.0 draft in December 1991. The file header states that it was created with PAF, so the file must have been created by what in 1997 was a very old version of PAF. The VERS tag is not given in the HEAD section of this GEDCOM, so the version of PAF cannot be identified, nor can the version of GEDCOM that this file represents.

This was a very exciting find for me, sort of like an archaeological dig unearthing an ancient unknown language. I don’t know anyone who has a specification of GEDCOM prior to version 5.3 (if anyone does, please let me know), so now became a matter of interpreting the text and seeing if I could translate.

As it is, the current version of Behold cannot display the people and individuals in this file correctly. The first problem is that on the 0 INDI record lines, there is no space between the end of the identifier, i.e. @242@, and the tag, i.e. INDI.

This also is a problem on the 0 FAM tags, except in this file they are not FAM tags but FAMI tags with an “I” on the end.

The other interesting difference is the linkages. Look in the above example and you’ll see two lines containing:  1 PARE 2 RFN @89@. This is a link to the parents of the person, and in version since GEDCOM 5.3, this has become a single line: 1 FAMC @89@. 

All the other linkages were different as well. The list is:
- FAMC was PARE + RFN
- FAMS was FAMF + RFN
- CHIL was CHIL + YOUN
- HUSB was HUSB + RFN
- WIFE was WIFE + RFN
and I’m still working on the extra one they had which now has no equivalent:
- SIBL + OLD
which seems to be a linkage to a sibling which should be redundant information, but I’ll check that.

The dates are also in yyyymmdd format which has been changed in newer GEDCOMs to dd MMM yyyy. In a way, the old version was better, because it is the basic ISO standard for date representation. Within a GEDCOM file, it doesn’t matter how a date is stored. The GEDCOM file is not meant to be viewed by the genealogist. It is your genealogy software that simply must load the information and display it understandably for you. And using English month names for the 3-letter abbreviation does more harm than good. So I’m not sure why later versions made this change.

So I have now changed my development version of Behold so that these situations will be handled (and this will be included in the next release of Behold in case anyone else happens to have some ancient GEDCOMs lying around.) Once I did that, Behold was able to properly present the information in the file.

Do you have any of these ancient GEDCOMs lying around in this format? The sure way to tell is if the file ends with a line containing: 0 EOF. Newer GEDCOM versions end with 0 TRLR.  I wouldn’t mind having a few more for testing, so if you have an oldie, please contact me.

Genealogy Technology – Random Thoughts - Wed, 13 Aug 2014

Lots going on in the technical genealogy world, and so much incorrect thinking in my opinion.

The major online services are quietly going about their business: Ancestry, FamilySearch and MyHeritage (which now includes Geni) are the big three, but there are scores of others such as GeneaNet and WikiTree. They’ve had years to do so, but no one service has shown dominance. It may still be years before this all gets sorted out.

Single World Tree or Individual Trees? Now that is the question, and everyone has an opinion and argues, but both ways have their faults. The two will have to coexist for a while because no consensus is in sight.

It is being said that handheld pads and mobile devices are the future. Therefore everything will be in the cloud and accessed with apps from these devices. And desktop genealogy software will not be needed. Well that’s all bullfeathers. More than anything, people want control of their data. They’ll want their own database in their own possession and not on some alien planet somewhere. And if it is on some alien planet, they want control of it, and don’t want the aliens to have the ability to destroy it.

Family Tree Maker is a good program!? Ouch. Have you seen its reviews lately on GenSoftReviews? I don’t understand how Ancestry has dropped the ball so badly with it. The rewrite in 2008 was necessary because the earlier technology needed upgrading. But how did they take a reasonably good program and destroy it so badly? How, after six years of upgrades, can their software still crash and cause so many problems? Why can’t they get it to sync data properly with their own online database? Why don’t they fix it?

Customer service will win the day. People don’t mind encountering problems or learning a different system if they are dealing with a company that will do everything to help them. In contrast to Family Tree Maker, check out the GenSoftReviews of Family Tree Builder and MyHeritage and note how many of the comments talk about their great support.

The Master Genealogist says farewell. I’ve met Bob Velke and he’s a really smart guy and a fine person. He was one of the early innovators of genealogy software and developed one of the most capable genealogy programs of the day. Everyone else had to catch up to him. Unfortunately, he couldn’t make the leap that was necessary and switch TMG’s deprecated FoxPro database to a modern database that could continue.

Legacy 8 still uses FoxPro the Microsoft Jet Engine which is also deprecated. It doesn’t support Unicode 64-bit. The limitations are starting to mount, despite the new releases. Why have few noticed this? Why are they not demanding Legacy to address this? Will the Legacy folk switch in time before they hit the same brick wall that Bob did?

Genealogy Proof. Citation Templates. Evidence Tracking. Everyone’s so concerned about all these. But I’m not ready to spend 4 hours documenting each event I add to my database. What’s wrong with just recording exactly where we got the data from and our reasoning? That should take 30 seconds. We can then spend the other 3:59:30 more usefully.

Data doesn’t transfer. It’s GEDCOM’s fault. We need a new standard. => Ugh! Give me a break! Developers are the one’s that make GEDCOM fail. They fail to adhere to the standard whenever they feel like it and add their own extensions. They then ignore other program’s extensions. GEDCOM has most of what’s needed. With a few (what I call) tweaks, it can be updated and serve the genealogy community for another 25 years.

The whole push to replace GEDCOM with a new standard, that I was happily contributing to in BetterGEDCOM, which evolved into FHISO that was doing great and … Thud! After Drew Smith was appointed chair of FHISO there was nothing. That was over a year ago. I questioned Drew about this at RootsTech in February, and he told me FHISO was still looking for a coordinator. All the founding members would support FHISO if it could get going, and it’s quite a group: Ancestry, RootsMagic, WikiTree, OurFamily*ology, Calico Pie, Coret Genealogie, the Federation of Genealogical Societies (FGS), the Federation of Family History Societies (FFHS), BrightSolid and Mocavo. But it looks like FHISO is stalled and dead in the water unless someone steps forward with the energy and initiative to reboot it.

Oh where oh where did AncestorSync go? They had the right idea. Sync data directly between many desktop programs and online family trees. That’s exactly what every genealogist really wants and even needs. But doing it did not turn out to be as simple as they thought. Someone should … hmmmm.

Thanks for letting me rant. I feel better now.


August 15 update re Legacy:

I received an email from Geoff Rasmussen from Millennia (Legacy Family Tree) who informed me that Legacy does not use FoxPro but is built on top of a Microsoft Access database. Indeed I was wrong, and inspecting a Legacy .FDB file, one can see it is using the Microsoft Jet Database Engine.

However, this unfortunately does not change Millennia’s situation with Legacy. The Microsoft Jet Database Engine, like FoxPro, has also been deprecated by Microsoft. The Jet driver will not be updated and there is no 64-bit version of the driver available, nor will there ever be. So Millennia will need to switch before they hit the brick wall.

In July 2011, Microsoft acknowledged an issue that “severely affects query performance” with Access and Jet since the introduction of Windows 7 due to the nature of resource management being vastly different in newer operating systems. “Microsoft issued hotfixes for Microsoft Access, but will not fix the issue with Jet 4.0 as it is out of mainstream support.” (from Microsoft Access on Wikipedia) – So already, Legacy is starting to feel the effects of staying with Jet.

This, unfortunately, is the nature of programming. Choosing a technology is sometimes a crapshoot, and you may be lucky, or you may not. But you’ve got to see the writing on the wall when it’s there and change before it’s too late.


August 16 update re FHISO:

Interestingly, as I wrote this blog post, FHISO had completed a year of getting organized and announced that they are now ready to begin technical work. This is good.

See Richard Smith’s comment below.