* Exporting sources to FTM

[Mark1834]

I’m looking at the ability of FH to exchange source data with other popular apps (the native ability of the program, not via a community plug-in).

I have a very simple test database containing one individual with a birth fact supported by both a separate split source and a citation to a lumped source. Both sources are text only.

Exporting a GEDCOM and importing into RootsMagic 7 appears fine, I can see all the detail I entered in FH. However, FTM 2014 appears to lose the split source text altogether, and shows the source with no text. The lumped source is fine, as I would expect (FTM treats all sources as lumped by default). This is confirmed by reversing the process and exporting from FTM and importing into FH. The split source text has disappeared.

I couldn’t find any combination of options that fixed this and FTM seems incapable of handling split source text. Is that the case, or have I done something daft? If there is a significant incompatibility between FH’s preferred way of working and a major app like FTM, I’m surprised I can’t find any reference to that in either the FH documentation or FHUG Knowledge Base.

[Valkrider]

Mark

The majority of limitations that you mention are the constraint of Gedcom 5.5.

You say you don't want to use a plugin but don't explain why. Plugins enhance the capability of Family Historian. The Export Gedcom File plugin has settings for FTM and many other programs and this overcomes the majority if not all of your issues. Check it out it is worth it.

[tatewise]

As Colin says, the only viable solution for many products is my Export Gedcom File plugin.

Although GEDCOM 5.5 & 5.5.1 are the recognised formats for migrating data between products, many products do not support all the specified features, and even substitute their own custom variants that differ from the specification.

FH V6 only supports GEDCOM 5.5 and not 5.5.1 and also has its own custom extensions such as Place records, Fact Witnesses, and Media face frames that are not recognised by other products.

So for some products including FTM/Ancestry even some simple data structures do not migrate.

If you investigate other products you will see they offer GEDCOM Import & Export options for various GEDCOM versions and popular products. But they don't offer Plugins as a workaround.

The GEDCOM Assessment website lists assessments of many products against the GEDCOM 5.5.1 specification. FH despite only supporting GEDCOM 5.5 does quite well, whereas FTM is fairly poor.

[Mark1834]

Certainly the choice of GEDCOM as the primary data storage format steers FH towards its preference for split sources, but that is not the reason for the incompatibility between apps. GEDCOM permits text at both the source and citation level, and FH does a pretty decent job of implementing that. The problem is more that FTM doesn't!

If the export is done directly from FH, split source text is discarded without warning, even if FTM is specified as the format for the GEDCOM file. Using the plugin at least prevents data loss, but the source text is buried down in source definition comments, rather than up on the citation tab where it belongs.

Don't get me wrong - I'm not taking a pop at FH for following the standards correctly, or the plug-in for doing a slightly less than elegant job of transferring the data across. The approaches of the two apps to source data are fundamentally different, and it is virtually impossible to transfer in either direction in a way that looks neat and elegant on both sides.

It's just that I'm a little surprised that such a fundamental issue as potentially corrupting sources hasn't had more (any?) air time in either the program documentation or FHUG Knowledge Base.

[tatewise]

GEDCOM does not steer towards either split or lumped Source Citations.
Prior to FH V6.2 it is true that FH was biassed towards split Source Citations but that is no longer the case.

The fundamental problem is that FTM internally does NOT follow the GEDCOM data model.
It is the way it maps between its internal data model and the GEDCOM model using lumped Citations that is the problem.
However, several other products follow a similar strategy.

I have to admit that I'd forgotten about the Export > GEDCOM File command Destination option for Family Tree Maker but as you say that does not resolve the split Source problem.

With the Export Gedcom File plugin and its (FTM) Family Tee Maker mode try selecting (-) Brief Data mode top left (instead of (+) Full Data) and Source Citations may be somewhat better. One of my difficulties is that I do not have FTM installed, so rely on others to provide feedback, together with the free Ancestry online trees that I presume are similar.

It might be possible, to improve the way the plugin maps Source Citations to better fit with the FTM data model.

I cannot explain why FTM is given such little attention in the FH documentation or Knowledge Base.

[Valkrider]

I cannot explain why FTM is given such little attention in the FH documentation or Knowledge Base.

Perhaps it is because FTM is such a poor choice of genealogy software and people prefer FH

[Mark1834]

GEDCOM does not steer towards either split or lumped Source Citations.
The fundamental problem is that FTM internally does follow the GEDCOM data model.

Presumably you meant to say "does NOT follow..."? I can see why it doesn't, as GEDCOM does not cope properly with a lumped source cited for more than one event (e.g. multiple people in a census).

Taking a split census source as an example, the source is "1841 census, with detailed reference", and the detailed transcript is recorded at the SOURCE level. Each citation (which could be dozens in a large household if birth, occupation and residence are cited as well) refers back to that one source, and nothing is duplicated.

If census are lumped, the source is "1841 census", the citation is "detailed reference", and the transcript is recorded at the CITATION level. GEDCOM does not deal with that very well, and every use of the citation results in the detailed transcript being duplicated in the file. FH follows GEDCOM, so there are also potentially dozens of copies of the same citation text stored independently in FH. There is nothing in either the GEDCOM standard or FH's internal logic to keep those multiple instances in sync. If one is changed to add more detail or correct a typo, every other one has to be changed separately. If one is missed, neither GEDCOM or FH picks up the data inconsistency, and the error goes unreported.

FTM does a good job of managing this inefficiency by appearing to adopt a more traditional database approach internally, with separate tables for sources and citations. On that model, there is only ever one copy, so they stay in sync by definition. As you say, it is the mapping of that back to GEDCOM that is the problem, as they omitted to include a field in the sources table for Text From Source, as their lumped way of working puts all the detail at the citation level.

[tatewise]

Yes sorry, I've corrected the missing NOT.

Your analysis is pretty good, and FH could do better at keeping the duplicate Citations in sync.
Out of sync Citations usually become evident when producing Reports with Sources as each Citation variant gets listed.
It is quite easy to regain sync by using the Citation copy & paste feature, or perhaps a Plugin.
It is possible to use a shared Note record linked to the duplicate Citations so that the "detailed reference" only exits once.