Given that Behold won't write a (corrected) GEDCOM file for some time, what might be the best alternative to use in the meantime to avoid having to go over the issues which will arise as more data is entered.
IOW, which application available now will cause the fewest headache if and when I switch to Behold
so I can carry on with editing and adding to my data til Behold is ready? ;-)
Or are they all more or less equally problematic?
That's a very good question.
Whatever program you use, I would suggest you pick one that will export to its GEDCOM every single item it allows you to enter on any of its forms. The test would be to put some dummy data into every possible input field (maybe use the name of the input field so you can identify it again in the GEDCOM) and then see what does not make it. Check on every single input form, tab and window in the program where data can be entered.
Then you can continue to use your current program, but simply avoid adding data to those inputs that don't get exported.
Which program is best? I don't really know that, since I don't recall that anyone has compared various programs using that test before.
I've now added a question on genealogy.stackexchange.com: How Complete is GEDCOM Export from Various Programs?
What you propose is a very thorough research project of comparing the major apps in this respect.
The time and expertise needed for this I suspect is well above my level of experience and background.
Even if only done with my current app, it will only get me so far because I suspect I would not necessarily detect output which ends up in the wrong place or may have been missed - due to the sheer volume.
Export is only one part of this problem.
Surely a developer would only add input fields to his program if he had a way or the intention of outputing the data - even if only for on-going use in the logic; excepting of course data which is output only if certain options are set - and then one needs a global way to override the exception, as you pointed out in your stack-exchange comment.
Inputting the data in a way that encourages quoting and recording sources and makes it as easy and intuitive as possible is the other part and a very important part of this process is making it easy for the user to validate his data as part of the input process.
The same goes for almost any other data.
I find it incredible that some apps do not verify things as simple as date conformity with the standard they claim to adhere to, let alone other inconsistencies. Mind you, I have really worked with very few apps, so I may have a biased and mal-formed impression.
Though, if an app accepts user input, rather than just gedcom, then, IMO, it is incumbent on the app to make reasonably sure the input is 'reasonable' and if at all possible, it should verify as much as possible at the very time of input.
It is nice to have a separate, one time validation option/phase, but it would save a lot of time and frustration (especially for newbs) if the app complained if someone's third grandfather supposedly died at the age of 345 years, because somebody entered a bad date along the way :-)
The sooner, the better and also because so many validation logs end up too long and not specific enough a week or even years after the data causing the problem have been entered (wrongly)
You said: "Surely a developer would only add input fields to his program if he had a way or the intention of outputing the data"
No. The problem is that developers are first interested in storing their data in their own database. Exporting to GEDCOM is always a secondary thing, and they can easily miss exporting some of their data, or not bother exporting it if GEDCOM doesn't have a convenient container for it. Or they might add some new features to their program, and simply neglect to export them to GEDCOM.
You said: "it would save a lot of time and frustration (especially for newbs) if the app complained if someone's third grandfather supposedly died at the age of 345 years"
That check and many others will be in Behold when I add consistency checks. That'll be sometime (but not too long) after Version 1.1 is released.
Hi Louis and Arnold
I've been using Family Historian heavily (pending Behold!) and with one small caveat* it's gedcoms are accepted by Behold without any errors or cautions. FH uses Gedcom as its file system so there is no conversion to think of.
* FH allows you to create custom events and attributes. So if you create one called Regiment it writes a tag called 'REGI' which Behold reads but warns about. I've been search/replacing all REGI tags to _REGI tags (in Notepad or similar) that FH seems to back accept no problem. So far! But it is a small task to do so for a Behold ready gedcom anyway.
Behold will give a message for unknown tags, but it will still accept them. So you don't have to change the tags for Behold.
In the version I'm working on, when Behold reads invalid tags, it will change them internally to start with the _ and then will export them to GEDCOM that way.
Yep, Behold will do it right. I was more concerned with having a 'correct' gedcom now, and adding the underscore myself was a simple step to 'regularise' it. If it created problems in FH then I wouldn't bother.
Will Behold will offer the choice of gedcom 5.5 or 5.5.1? I don't know if FH will accept 5.5.1 gedcoms and I would like to be able to port back to FH for the charts etc after doing some edits.
Grrrrr. I was hoping not to have to.
What does Family Historian do when it encounters a 5.5.1 file now? All PAF exports are 5.5.1 and RootsMagic and etc. So I couldn't see Simon not having it programmed in.
I'll test - would be good to know. Do you have a test 5.5.1 file to hand? The two that come with Behold are olde stylee and customised for PAF and Legacy.
The best file 5.5.1 test file I know of are the 3 files at http://wiki-de.genealogy.net/GEDCOM_Musterdatei/Musterdatei that are in 3 different character encodings. All genealogy software should support all 3.
The files also contain lines that test the organization's GEDCOM-EL extensions. All the extensions are custom tags starting with an underscore "_". It will be useful to see what Family Historian does with those. Will it load them, give an error for them, add them as comments, or ignore them? It has level 0 custom tags: _LOC. that represent places.
Behold only detects one problem. "LANG" is not a valid tag. But that's good in a test file and you can see what Family Historian does with it. Running that test, I see that I missed programming in support for the 1 _LOC tag that represents a parent location, so Behold puts those in the "undefined tags" section rather than merging them into the places as it should. Another thing to fix when I can get around to it.
... and then if you would, please send me the GEDCOM Famiy Historian produces from this file.
Sorry for the delay - this was one of those threads that disappeared and I couldn't get back for few weeks.
So I've just downloaded the three files and tested them on FH5.0.9. Ascii and UTF-8 loaded fine (with a slew of 5.5.1 derived exceptions). The unicode file wouldn't load at all, but FH6 is now UTF-16 natively so obviously will handle this format OK as well.
Anyway I'll email you the roundtrip gedcoms together with hopefully identical backups and screenshots to show how FH displays the 'unrecognised' tags in the program.
You must login to post your reply.
Also check out other programs: GEDCOM File Finder and Double Match Triangulator
Copyright © Louis Kessler
All Rights Reserved