Your suggestion for documenting these relationships (non-parental) is a good "kludge" for a bigger issue. FTM does not support relationships that are tentitive or outside the direct family connection.
I propose that you do as "KMA" always suggests and ask for an enhancement which is "relationship" support. AND since I'm a proponant of the GEDCOM standard use the already defined DDL (data definition language) for "ASSOciations" provided in the 5.5.1 GEDCOM standard, the ASSOCIATION_STRUCTURE for individuals.
This structure provides:
1) a direct database link to another individual, unlike your "kludge" which only notes the individual by name.
2) a user defined value that indicates what the links is (father, grandfather, mother, godparent, slave, attorney, etc)
3) full sourcing information like any other fact/event.
4) a place to include notes
I use this for for non-family relationships (slave, attorney, girl/boy friend, priest, godparent, etc) but this should be the way you enter your relationship rather than a custom fact.
ALSO....
I would ask that you also understand that the BIRTh event can be used to support a direct database link to the biological parents. For example, (AS YOU HAVE INDICATED) just because a person is born we may not know that the individual (via the birth event) know that they are connect to a family (in this case one or two biological parents).
IF the BIRTh event does support the connection to the "birth family" FTM should provide (please ask for it) and use the direct database connection provided in the GEDCOM to that family unit (aka one or two biological parents) and the standard sourcing information available to the birth event.
ALSO...
You should make sure that ou also ask that FTM support child_to_family support of biological vs. social connections as prescribed in the GEDCOM.
Thanks for getting to this point in my rant. I've used the constructs for years and they get totally lost in FTM.
I propose that you do as "KMA" always suggests and ask for an enhancement which is "relationship" support. AND since I'm a proponant of the GEDCOM standard use the already defined DDL (data definition language) for "ASSOciations" provided in the 5.5.1 GEDCOM standard, the ASSOCIATION_STRUCTURE for individuals.
This structure provides:
1) a direct database link to another individual, unlike your "kludge" which only notes the individual by name.
2) a user defined value that indicates what the links is (father, grandfather, mother, godparent, slave, attorney, etc)
3) full sourcing information like any other fact/event.
4) a place to include notes
I use this for for non-family relationships (slave, attorney, girl/boy friend, priest, godparent, etc) but this should be the way you enter your relationship rather than a custom fact.
ALSO....
I would ask that you also understand that the BIRTh event can be used to support a direct database link to the biological parents. For example, (AS YOU HAVE INDICATED) just because a person is born we may not know that the individual (via the birth event) know that they are connect to a family (in this case one or two biological parents).
IF the BIRTh event does support the connection to the "birth family" FTM should provide (please ask for it) and use the direct database connection provided in the GEDCOM to that family unit (aka one or two biological parents) and the standard sourcing information available to the birth event.
ALSO...
You should make sure that ou also ask that FTM support child_to_family support of biological vs. social connections as prescribed in the GEDCOM.
Thanks for getting to this point in my rant. I've used the constructs for years and they get totally lost in FTM.