GEDCOM: INDI.FAMC vs FAM.CHIL

Question

This question pertains to processing GEDCOM files. Specifically, establishing the relationships between individuals: Fred is a child of Mary, Mary is married to John, John is a child of George, etc.

Which spouse/child reference in GEDCOM "wins"? INDI.FAMC/INDI.FAMS or FAM.HUSB/FAM.WIFE/FAM.CHIL? Ideally, I think, each INDI.FAMC is correctly paired with a matching FAM.CHIL, and likewise for INDI.FAMS and FAM.HUSB/FAM.WIFE. Could anyone offer guidance on how inconsistent references "should" be handled?

I have encountered GEDCOM files "in the wild" where the INDI.FAMC tags are not consistent with the FAM.CHIL tags. In other words, FAM records have CHIL references to INDI records without a matching FAMC reference. A pseudo-GEDCOM example:

0 @I1@ INDI
1 FAMC @F1@
0 @I2@ INDI
0 @F1@ FAM
1 CHIL @I2@
1 CHIL @I1@

Here, family F1 lists person I2 as a child in the family, yet person I2 doesn't have the corresponding FAMC reference. I believe the "correct" interpretation is person I2 is not a child of family F1. Am I wrong?

The reason for my concern is also illustrated with the above example: person I2 has become an "island", with no relationship within the forest. Using the FAM.CHIL link, person I2 is no longer an "island".

Does anyone have any data about specific genealogy programs with a history of writing GEDCOMs with these kinds of problems? E.g. I have a GEDCOM created by "Ftree for Linux" with a bunch of these issues.

Answer 1

The GEDCOM 5.5 specification provides most explanation about the link inside the individual record, pointing to the family record. It says:

The normal lineage links are shown through the use of pointers from the individual to a family through either the FAMC tag or the FAMS tag. The FAMC tag provides a pointer to a family where this person is a child. The FAMS tag provides a pointer to a family where this person is a spouse or parent. The << CHILD_TO_FAMILY_LINK >> (see page 29) structure contains a FAMC pointer which is required to show any child to parent linkage for pedigree navigation. The << CHILD_TO_FAMILY_LINK >> structure also indicates whether the pedigree link represents a birth lineage, an adoption lineage, or a sealing lineage.

Bold emphasis is in the original. Italicised emphasis is mine.

By contrast, the text against the family record is much thinner in meaning.

There can be no more than one HUSB/father and one WIFE/mother listed in each FAM_RECORD. If, for example, a man participated in more than one family union, then he would appear in more than one FAM_RECORD. The family record structure assumes that the HUSB/father is male and WIFE/mother is female. The preferred order of the CHILdren pointers within a FAMily structure is chronological by birth.

There is, note, no particular explanation about the purposes of these cross references.

Note that it is possible to have multiple child-to-family-links from an individual to families to cater for (say) birth and adoption. Note further that it is also possible to navigate from events for an individual to their family - e.g. from an adoption event to their adoptive family via a child-to-family-link.

It would be logical to deduce that priority should therefore be given to data inside the family record. However, it would be a mistake to do this automatically given the number of programs that have made errors in their GEDCOM construction.

Ideally, when loading the GEDCOM data, the user should be asked to confirm what the situation is. Is the child genuinely part of the family? In which case, proceed on that basis. Or is the child not part of the family, in which case sloppy programming has left data around.

If the user is not able to answer that question, then I would recommend proceeding on the basis that the child is part of the family (rather than losing information) but sticking a note in somewhere to say that this may be questionable.

NB - the << text >> construction above is not identical to that in the GEDCOM specification as the space immediately after the << and then immediately before the >> is not present in the GEDCOM specification. However, omitting the space results in the disappearance of the text between the arrows in this editor - no doubt there is some sort of escape character to use but I'm cheating / being lazy.

Answer 2

I think you'll find just about every genealogy program makes many mistakes when exporting their GEDCOM. Some of them even add their own illegal GEDCOM on purpose because they want to export some data they don't believe GEDCOM handles.

You'll find a number of people who have analyzed mistakes made in GEDCOM by certain programs and posted about them, including:

• Tamura Jones on his Modern Software Experience
• Bob Coret about Internet and genealogy
• Keith Riggle on GenealogyTools.com
• Louis Kessler at Gaenovium and in his Behold Blog

The mistakes made in following the standard are mostly because programmers have not taken the time to ensure they have interpreted and implemented the standard correctly. As a result, we are left with a lot of data that one program exports but others cannot import.

With regards to your specific example of the FAM.CHIL link and the opposite INDI.FAMC link, GEDCOM does not specifically state that both must exist. However, most programmers realize that the link both ways should be included and most do.

You may find some GEDCOM files that do not have all their links paired, maybe due to a programming error, or maybe the file was truncated and you want to extract what you can. Many programs do not include checks for one-way links and will refuse to load the data. Others may create islands as you noted.

But a flexible program that checks for errors as it reads the data should give you a warning when only one of the links exists. It should then internally create the reverse link for you. There are a few that will do this. For these programs, your data won't become islands.

If your program will not do this fix for you, you might have to resort to manually editing the GEDCOM and adding the reverse links yourself.