Family entity - Is this needed or desired???
Perhaps a "Relationship" or "Group" entity would be better? Perhaps all these concepts are better represented within the Event class of entities? How would these decisions impact mapping into and out of today's genealogy software?
A family entity should NOT be included in BetterGEDCOM. It should instead be handled by the Event Entity as follows:
There is no need to implement the CHIL, HUSB and WIFE links in the FAM record, The above links are sufficient whereas the reverse links are redundant and don't add any information to the GEDCOM but only cause potential inconsistencies and make the GEDCOM larger. Any program can produce the reverse links it needs for its database when the GEDCOM is input.
Should there be information that is associated with the family as a whole, then something is needed for it. See the Group Entity.
- The birth event should link to the person born and that person's father and mother.
- The adoption event should link to the person adopted and that person's adoptive parents.
- The marriage event should link to the people being married.
- The divorce event should link to the people being divorced.
- The commonlaw event should link to the people entering a commonlaw relationship.
A Relationship entity could serve as a catchall mechanism to document relationships even if the relationship is unspecific or non-biological. Some do not favor this because it would introduce more ambiguity. Does that argument hold water?
GEDCOM already represents relationships in a reasonable way, using the RELA tag to indicate a relationship and the TYPE tag to represent the type of relationship. It is limited in GEDCOM in that it can only be used between INDIs.[If we were building upon the existing GEDCOM standard this would be more relevant.] However, very few programs have made use of this. Most have ignored this tag but used a WITN or _WITN tag instead, The WITN tag was deprecated in GEDCOM 5.4.
The tricky part is that one relationship implies the reverse. Example: If Person A attended the birth of Person B, then Person B's birth was attended by Person A. Only one relationship need not be specified, and the other can be implied. Placing both in the BetterGEDCOM file will only cause problems. The receiving program can build the reverse link itself.
Note this link to a GRAMPS enhancement project advocating their adoption of a relationship object. This page includes a discussion of how GEDCOM handles relationships. Please also note that the definitions in all these cases are quite different.
It would be worthwhile to implement groups of people, places, or things. Normally, you might think all you need is a GROUP tag and name the groups that this individual, place or event belongs to. That would work, but there would be no place to specify information about the group as a whole. So it does make sense to have a Group entity.
Groups may be groups of People, Events, Locations, Objects, or any other entity or combination thereof. You may want a group to be "All people invited to a specific event" or "All marriages in a certain city" or even "People in a picture taken at a certain event at a certain location". You may have all sorts of information to attach to this group.
This is where family information would go, if there were specific events or pictures that existed for the family. It would be impracticle to try to hang that information anywhere else. But family groups need not be defined unless there was additional information about it that needed to be recorded. This is not a replacement for the parent and child links of the FAM structure in GEDCOM. In fact, you can have many different types of families defined for overlapping groups of people.
Groups should not, in BetterGEDCOM, contain links to the Entities within them. Instead, the entities should have links to the groups they are in, maybe with a GROUP tag and a ROLE subtag to identify what their part is within the group. The GROUP tag may also have a DATE subfield to indicate when they belonged to the group.
An individual entity may belong to the same group multiple times, since it may leave and rejoin a group, or may be a member with different or multiple roles.