Seems like a bit of odd functionality to me, but when I select any family-based Fact Type, why am I limited to only match to the spouse? It doesn’t seem to be a GEDCOM limitation when I look up GEDCOM fact type definitions. As it is, the functionality is very restrictive.
Instead of only selecting a spouse with an option to add a new spouse, there is a better option. Any family-based types should allow a list drawn from existing family member (grandparents, parents, children) data with selection checkboxes for each individual. This provides easier ability to enter or copy a single event/fact to any & all members of this person’s immediate family, as might be found in census or other record sources.
Today, if I add a Residence (family) fact to Bob and his wife Sarah from a census record. I must add a separate Residence fact to John and Mary (Bob’s parents living in Bob’s household) as well as Anna, Bob Jr, Billy, Samuel and Frederick each, all Bob and Sarah’s kids on the same census in the same house. Of course, I can ‘copy’ the Residence fact to each, but why have two different processes for the same event?
Can we get a feature request to simplify this very common occurrence?
Yea, Residence (family) should really be titled Residence (COUPLE) instead.
Looking at the Fact Type format, The Fact Type is Family with the sentence structure as “[couple] lived < [Desc]>< [PlaceDetails]>< [Place]>< [Date]>”
Residence on the other hand has the Fact Format as being Personal. Sentence is - [person] lived< [Desc]>< [PlaceDetails]>< [Place]>< [Date]>.
The Help should be changed to be “Couple” rather then “Family” as it is misleading.
You can blame the entire issue on the creators of the GEDCOM standard. In the published standards for version 5.5.1 they state “The FAMily record is used to record marriages, common law marriages, and family unions caused by two people becoming the parents of a child. 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.”
While the membership is expanded somewhat in version 7, the concept of Family records remains connected to two people, Husb and Wife, but they can be any sex.
that is important to note-- I believe the main reason why RM adopted that in the past was related to both GEDCOM and other software so it could “handle” it.
I’m sort of repeating what has already been said, but it actually is very much a GEDCOM limitation.
GEDCOM has a tag called INDI for individuals. Individual facts such as Birth and Death are linked to the INDI tag.
GEDCOM has tags called FAM, FAMS, and FAMC for families. Family facts such as Marriage and Divorce are linked to the FAM tag. Those facts are pretty obvious. Perhaps facts such as Residence (family) and Census (family) are not so obvious because they could well be perceived as applying to the children as well. But they don’t. They apply only to the couple, just like Marriage and Divorce apply only to the couple. As others have said, these so-called “family” facts might better be called couple facts. But the “family” terminology is deeply embedded in most genealogy software and data models, including GEDCOM itself.
I actually think the problem is even deeper than the GEDCOM standard. I think the problem is in the whole data model of how people are linked together in relationships and how the evidence is linked to those relationships. My favorite example is something like the following. Suppose you have the statement that “Sarah Doe was the daughter of John Doe and Jane Smith” and suppose you want to link a citation to that statement. Well, in my view you really can’t. And the reason is that there is no such statement in the data model. There is obviously such as a statement in the real world. I just made such a statement. But contrary to popular belief and unless I don’t understand the data model, there is no such statement even possible in the data model.
Here is how the data model really works. A FAM is created, say for FAM #439. A FAMS (family spouses) is created which is linked to FAM #439 with John Doe and Jane Smith being linked to the FAMS. But things like Marriage events and citations are not linked to the FAMS. Rather, they are linked to the FAM. Then a FAMC (family child) is created where Sarah Doe is linked to the FAMC and the FAMC is linked to FAM #439. But all the citations are linked to FAM #439. They are not linked to the FAMS (for the couple) nor to the FAMC (for the children).
You can sort of prove this in RM. Create these people in RM. In Sarah Doe’s Edit Person screen, create a citation for evidence that she was the daughter of John Doe and Jane Smith and attach it to the Parents line in Sarah’s Edit Person screen. So far, so good. It looks like it worked. But then add a second child name Thomas Doe and do the same thing. When you get to the Parents line in Thomas’s Edit Person screen, the citation for Sarah will already be there. That’s because in this data model the citation for Sarah’s parentage is not really linked to Sarah. Instead, it’s linked to the family. But the evidence for Sarah as the child of John and Jane is not evidence for Thomas as the child of John and Jane.
In my view, this data model is a poor data model in multiple ways. It doesn’t support a place for evidence of parentage that is specific to a particular child and a particular parent. It doesn’t support facts that are for multiple people like a true family census. It doesn’t really support any non-family relationships such as those that are supported by RM’s Association feature or by RM’s shared facts feature. Therefore, I think that genealogy software data models as a whole need a complete makeover or do-over or whatever kind of “over” that you prefer. RM cannot solve this on its own because then it would be incompatible with all the other genealogy software in the world.
GEDCOM (if my timeline serves memory) was developed in the 80s then further refined througout the 90s to what we see today. If we leave out the need to transfer via GEDCOM and only based on database & its own model that changes drastically. GEDCOM 7.1 has even taken very little attention. We might be “stuck” with the current limitations of GEDCOM 5.51 for awhile it seems
I think the RM database structure is ready to support parentage as a fact to which citations et al can be tagged. The user interface has not been developed to support it. Like shared events, however, there is the problem of data exchange with other systems.
As I have written about many time, I introduced a Parents fact into my database in part to address the problem of no place to attach evidence of parentage. I got the idea from the ChildParent fact which serves the same function in the now defunct TMG software. I discovered the ChildParent fact in TMG while I was helping TMG users convert to RM after the TMG went out of business.
Version 1 of my Parents fact just listed the parents in the Description field, which didn’t really link the Parents fact to the parents. But Version 1 of the Parents fact did achieve my primary goal of providing a place to attach evidence of parentage.
I later realized that I could share my Parents fact with the actual parents. This was Version 2 of my Parents fact. It provided the kind of linkage which I think Tom is talking about which is supported in the RM database, but which may not transfer to other software - especially not to FamilySearch and Ancestry.
I don’t use RM’s shared facts in general because they so often fail to transfer. But in this case, if my data is transferred to software that doesn’t support RM’s shared facts, at least the Parents fact, its description field, and most importantly its citation with evidence of parentage do transfer anyway.
A side benefit of using my Parents fact along with RM’s shared fact feature is that the role for the shared fact becomes a Birth of Child event for the parents. In particular, the Birth of Child event can be included in printed reports. I think Birth of Child is a significant life event for most people, right along with Birth, Marriage, and Death. I love the way it looks in my printed reports that I take to family reunions.
That’s not what I meant, Jerry, but I’m glad it stimulated a response that may be new to and instructive for some! What I meant was that the ChildTable is the core of a potential Parentage Fact Type as it ties together a Person as a Child of a Couple as the Parents:
PersonID or RIN of the child to the FamilyID of the parental Couple along with a link type to designate Assumed Birth, Birth, Adopted, Fostered, Guardian, all in 1 record. The CitationLinkTable, MediaLinkTable, … are already set up to allow a citation to point to a record number in the ChildTable. But the user interface does not support it.
I think it is feasible to implement in RM and could obviate the convolutions you go through to get such information into your reports but it might be even more trapped within RM than your workaround which I think can be imported by GedSite and Family Historian 7. I don’t know whether GEDCOM 5.5 or 7 have an equivalent structure., e.g., sources for the FAMC.
Absolutely. That would be the key. It would make the Parentage fact and evidence specific to one child, whereas the existing structure applies the Parentage evidence to the family as a whole. My apologies for misunderstanding your suggestion.
I can confirm that Family Historian 7 imports all of RM’s shared facts just fine, not just my Parents fact. It works via direct import. I don’t think RM’s shared facts be imported correctly into FH7 via GEDCOM. I can also confirm that RM meets my needs much, much better than does FH7.
GedSite works via GEDCOM and does not have a direct import for anything except TMG (for TMG users who never converted to current software such as RM). I can confirm that GedSite does a wonderful job of importing RM’s GEDCOM, including RM’s sentence templates, RM’s source templates, and RM’s shared facts. My Parents fact in RM “just works” in GedSite, using the shared roles in the GEDCOM rather than using the text from the Description field from the GEDCOM.
And your final sentence is the way to say it: what is needed is sources and citations in GEDCOM for FAMC. Then, all genealogy software needs compatible support. As you already said, for RM that would mean sources and citations for ChildTable.
@kevync1985, now THERE’s a new Fact Type… “Clueless”
For everyone, thank you for the directions you have taken for workarounds to my problem. The idea of shared facts might be the closest to what I am looking for, but I’ll keep poking at it.
