Are duplicate FamilyTable records ever legitimite?
Are duplicate FamilyTable records ever legitimate?
It has never been entirely clear to me how RootsMagic interprets a FamilyTable entry.
In regards to a trad marriage situation in which a couple marries, divorces and then re-marries, are there supposed to be one or two family table records?
Do the Marriage events all get lumped onto the same FamilyTable record, or are they distributed. Seems like children could be offspring from either.
This gets into the real meaning of a FamilyTable record. In the software I wrote 40 years ago, I didn't have a family table, I had a MatingTable (I was a biologist, not at genealogist). In that case, the mating table entry was directly related to progeny records. Genealogy software now treat family records not just in terms of offspring, but also social relationships.
Any thoughts?
Richard Otter
I don't think there should be any more than one record in the FamilyTable for each unique pair of FatherID, MotherID. When there are duplicates, it distorts the count of Spouses, Parents, duplicates lineages and, if widespread, probably adversely affects processing speed. Transfer of affected lines propagate via GEDCOM and drag'n'drop to other databases.
Just because a couple Marries, Divorces and re-Marry each other has no requirement for a second record. All of those events are attached to the same couple. If they had a child during their first marriage, another while they were divorced, and a third after re-marrying, and, I forgot, another before they first married, all four of those children are genetically tied to the same couple. Do we want them to be separated into 4 different lines of descent?
There is one possible exception and that is an unknown spouse. A woman with MotherID=321 had one set of children by one father and a second set by another father. Should there be two couples:
0,321
0,321
in FamilyTable to separate the children? Better, I think, to create a new person for each of the unknown fathers:
X,321
Y,321
which assures that the children are grouped separately under the two distinct couples and invites more needed research to identify them.
I totally agree with Tom, both with respect to the trad marriages and with respect to the multiple unknown spouses. I have one couple with three marriages to each other and two divorces from each other.
Another way to think about it is what if a couple has a child before they were married, then they were married, and then they had a second child. This is actually a very common situation. If you wanted to tie the family record and associated children to the Marriage event (or events) and/or the lack thereof, then such a couple would need two family records, one before they were married for the first child and one after they were married for the second child.
This whole lineage linked family system with the children linked to the "family" instead of to the parents is so deeply rooted in all of genealogy, including that's the way the FAM, FAMS, and FAMC tags work in GEDCOM, that it probably never can be changed. RM is just following the crowd, and in my opinion RM really doesn't have much of a choice. But I would love to see it changed.
The thing I complain about so much is that it seems to me that the current system does not provide a good data point where a citation for evidence of parentage can be linked. The way RM does it, and really the way it has to be done for GEDCOM, is that such citations are linked to the family. But that means, for example, that each child's birth certificates or similar records all become citations for all the other children as well. I think we need something that links Wiliam Doe and only William Doe as the son of John Doe and Jane Smith, and similarly something that links Elizabeth Doe and only Elizabeth Doe as the daughter of John Doe and Jane Smith. Making separate family records for each child would sort of do it, but then you lose the fact that the children are siblings. It's not an easy problem to fix and it will never be fixed, but it drives me crazy sometimes.