Login to participate
  
Register   Lost ID/password?
The Behold User Forum » Topic           prev Prev   Next next

What might be a temprary alternative to Behold - Categorized in: General DiscussionGeneral Discussion

14 posts. Started 24 Nov 2014 by arnold. Latest reply 14 Aug 2015 by cp. RSS 2.0 feed for this topic RSS
1. arnold (arnold)
Canada flag
Joined: Mon, 24 Nov 2014
10 blog comments, 13 forum posts
Posted: Mon, 24 Nov 2014 Permalink

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?

2. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Sat, 29 Nov 2014 Permalink

Arnold,

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.

Louis

3. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Sat, 29 Nov 2014 Permalink

I've now added a question on genealogy.stackexchange.com: How Complete is GEDCOM Export from Various Programs?

4. arnold (arnold)
Canada flag
Joined: Mon, 24 Nov 2014
10 blog comments, 13 forum posts
Posted: Sat, 29 Nov 2014 Permalink

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.
<rant> :-)
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)
</rant>

5. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Sat, 29 Nov 2014 Permalink

Arnold,

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.

Louis

6. cp (cp)
United Kingdom flag
Joined: Mon, 19 Mar 2012
7 blog comments, 9 forum posts
Posted: Sun, 19 Jul 2015 Permalink

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.

Cheers, Colin

* 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.

7. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Mon, 20 Jul 2015 Permalink

Colin,

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.

Louis

8. cp (cp)
United Kingdom flag
Joined: Mon, 19 Mar 2012
7 blog comments, 9 forum posts
Posted: Tue, 21 Jul 2015 Permalink

Hi Louis

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.

Colin

9. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Tue, 21 Jul 2015 Permalink

Colin,

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.

Louis

10. cp (cp)
United Kingdom flag
Joined: Mon, 19 Mar 2012
7 blog comments, 9 forum posts
Posted: Tue, 21 Jul 2015 Permalink

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.

11. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Tue, 21 Jul 2015 Permalink

Colin,

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.

Louis

12. Louis Kessler (lkessler)
Canada flag
Joined: Sun, 9 Mar 2003
287 blog comments, 245 forum posts
Posted: Wed, 22 Jul 2015 Permalink

... and then if you would, please send me the GEDCOM Famiy Historian produces from this file.

13. mjashby (mjashby)
United Kingdom flag
Joined: Fri, 23 May 2014
3 blog comments, 2 forum posts
Posted: Thu, 13 Aug 2015 Permalink

Louis/Colin,

Was reading through the message threads and came across the mention of Family Historian, my main Family History 'database' program since 2003. As you are aware, Family Historian saves its data to a GEDCOM file rather than a true database (As does GEDitCOM on Mac OS X). However, the 'dialect' of Gedcom does vary according to which version of Family Historian is in use, i.e. the most recent release, Version 6, introduced various new innovations which have increased the complexity of moving Gedcom Files to other programs. Changes in the Gedcom structure used by FH have arisen from a move to the use of Unicode internally (UTF-16), which means that it can store any character from any language and any accent; new support for Witness Citations, and greater support for Places and Mapping all of which get in the way of simply using a native FH Gedcom file for transferring data to other software (See http://www.family-historian.co.uk/features/whats-new-in-version-6 for more detail). To improve data transfer the program does provide a Gedcom Export function which can be tailored in numerous ways to produce a Gedcom file that is 'more acceptable' for importing to other programs/utilities or to earlier versions of Family Historian. The downside of this is that, having exported a Gedcom structure that is suitable for transfer to another program/utility there is obviously a loss of direct compatibility with the internal file structure, so making a 'return journey' of the data to Family Historian is not a straightforward process.

It's also worth mentioning that for Version 5 or 6 of Family Historian, there is a user developed "Export Gedcom File" plugin available which has the capability of creating a wide range of Gedcom dialects tailored to other programs/online services see - http://www.family-historian.co.uk/pluginstore/plugin-entry?id=522 for more information.

So, the point I would really want to put across is that there is really no such thing as a 'standard' Gedcom output file from Family Historian because of the wide variety of options possible, unless the intention is to be able to work with the internal gedcom file structure, which will still vary dependent on how the relatively new Witness and Places functionality have been used; what use is made of Unicode accented characters in individual names, place names etc, etc..

Mervyn

14. cp (cp)
United Kingdom flag
Joined: Mon, 19 Mar 2012
7 blog comments, 9 forum posts
Posted: Fri, 14 Aug 2015 Permalink

Hi Louis,

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.

Cheers, Colin

Leave your Reply

You must login to post your reply.

Login to participate
  
Register   Lost ID/password?