This question raises the need to rethink the nature of primary parents. I resolve this into 3 cases (and argue for the use of 3 separate primary markers for type of parenting): (1) Setting a person as the primary *Biological **Father *of a child - implies to me that he provided the sperm and the primary *Biological* *Mother *that implies to me that she supplied the egg. This designation is based on genetics. (2) Setting a person as the primary *Legal **Father *of a child or *Legal **Mother *of a child**where these is some legal action (guardianship or adoption) involved (3) Setting a person as the primary *Social **Father *of a child or *Social****Mother *of a child where these is no some legal action is involved NOTE: In same sex marriages/partnerships there can be 2 Social and/or 2 Legal parents of the same gender. If there were 3 primary markers (Biological, Legal and Social) then for a normal biological situation the 3 primaries could be set to the same father or mother. HOWEVER, it is a bit like how a person's name can change, Legal and Social parentages can change over time, Legal and Social parentage may involve a number of parent persons for the one child. So who is the primary Social or Legal parent at the date of the Event? This implies that the Legal and Social primary setting are bound by the Event Dates that case the swap of person involved. So the question arises how does the user want to show these difference in an output, table, report or a chart? So in the report format that could only name one pair of parent would need an option to show which parents. In narrative reports, where there has been more than There will be good reasons for wanting to show the primary Legal or Social and not the primary Biological parents in some reports. There should be defined marker characters used to identify (when considered necessary) Legal and Social use of primary parents. There come privacy and a potential health/trauma problems if some relationship facts are exposed. Just my thoughts. I would be interested if others have alternative views of how to control the recording and display of these parenting relationships. RobinL On 08-Dec-17 01:07 PM, Lee Hoffman/KY wrote: > At 12/7/2017 20:50, Karla Huebner wrote >> Just curious--how do people handle this? I've been aware that TMG >> considers >> any primary parent-child relationship as if it wee biological, and have >> just put up with it knowing that adopted family members and their >> descendants end up looking biologically related to me. I wouldn't >> want to >> leave them out of family trees, but... >> >> I know we've gone over this in years past, but that may have been before >> DNA testing was common. > > TMG has not changed in this regard since before TMG v0.93.  TMG > considers the Primary Father and Primary Mother to be treated as > biological parents regardless of the actual relationship. > Unfortunately, non-Primary parents are just ignored.  I have long > thought that there should be some way for TMG to "automatically" > report that a non-Primary parent was an adoptive, step, foster or > whatever parent whether that parent was Primary or Non-Primary. When I > add an Adoption Tag, I always add the adopting parent(s) as witnesses > with the appropriate Tag and Witness Sentences.  For Step-, Foster-, > God-, and other parents, there is no equivalent Tag, so I just add a > Note Tag with Sentences similar to the Adoption Tag. > > As to whether parents are Primary or Non-Primary, I select Primary for > the adoptive  (whatever) parent(s) if the child should show there and > the biological parent(s) as Primary if the child should show there. In > either case, the Adoption/Note Tag pretty much explains the > situation.  It is really a case by case situation.  I had one adoption > whose Primary parents for years were always the adoptive parents until > the child was told that he was adopted. After that, I switched parents > based on the focus of the report. > > Interestingly, my grandfather's 1st cousin was adopted.  His son was > also adopted.  I have been in contact with his son, my 3rd cousin and > found that he was also adopted.  We have been working trying to find > the circumstances of the three adoptions.  My 2rde cousin has found > his birth parents, and will be meeting with them soon.  His adoptive > father is still living, but we have not found his birth parents and > odds are that we may not. > > Lee > > The TMG archive is found here: > http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: > http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to > [email protected] with the word 'unsubscribe' without the > quotes in the subject and the body of the message > -- Robin Lamacraft, Adelaide, Australia

robin lamacraft wrote: > This question raises the need to rethink the nature of primary parents. Robin, I "think" we discussed this somewhat in the past. But if not, my opinion is that the entire concept of a "primary" parent is a really *bad* idea. (This assumes I understand your meaning of the term "primary". If not, see the last paragraph below.) Primary has been a problem in TMG and most other genealogy programs. But I strongly hope it will not be a problem in HRE. I believe there is no need for a "primary" designation when entering a relationship tag. That tag should simply indicate the nature of the relationship (in each direction) between two database entities, e.g. parent-bio, child-bio, parent-ado, child-ado, etc. And the user should be able to create and define any type of custom relationships. (Note that "location areas" as entities should be able to have relationships as well. Think of county formations where new counties are created (as "children"?) from parts of old counties.) I believe what is needed instead of "primary" is the ability to calculate and output "directed" graphs or trees or reports etc. of *any* kinds of directional relationships which exist in the database. The definition of such an output should include which relationship(s) are to be used for each direction in the calculation of that output. And yes, the plural of relationships for the output definition is intentional. As an analogy think of the TMG way to define multiple people Accent conditions to come up with a single color accent for a person. Something similar should be able to be defined for selecting amongst one or more relationships which may be exist in a given direction between entities. For example, a strictly genetic relationship output could be defined as requiring only parent-bio "up" the tree, and only child-bio "down" the tree. But an output which "also" included "Family" relationships while focused on biology could be defined where "up" is parent-bio if there is one, else parent-ado if there is one, else parent-social. Alternatively an output including "Family" relationships but focused on social relationships could be defined where "up" is parent-social if there is one, else parent-ado if there is one, else parent bio. Also the output definition should have options to specify other criteria to use to choose a relationship among several in the same direction or among several of the same relationship type, e.g. using parent-social then use "last" based on the dates of these relationships, or "then" based on the date range including a provided date, or ... (use your imagination). I believe the relationship *output* should define what type of relationship is "Primary" (or secondary, or ...) for the purposes of that specific output. "Primary" should not be an attribute of the individual relationship itself. The user needs to be able to choose different relationships as "primary" for different output purposes. However, I do believe there would be a need for an attribute of "default" for _each_ relationship type. (Maybe that is what you were thinking of when you used the term "primary"? If so I think the terminolgy of "default" more clearly reflects its purpose.) Only one among multiple relationships for a person of the _same_ type would have this attribute. Thus each type would have its own default. The output would then only use that relationship among multiple relationship tags of the _same_ type in the case where any defined output criteria (e.g. date) does not make the choice among these multiples clear. Note that I don't believe there is a need for a default type among multiple "types" of relationships. I believe that always should be part of the definition for that output. Just my (strongly held) opinion <grin>, Michael

One purpose of the 'Primary' marker is to take information where the may be multiple theories of what is true, and to mark which one is considered most likely so that a more limited report can be generated. It can also be used allow reporting multiple supporting events for one principle event (like an infant baptism being a possible substitute for a birth event). This method works well for key events in a persons life, they are born just once, die just once, normally buried just once (and the exceptions in reburials are really a different type of events), and have just a single biological mother and father (at least until science starts meddling in the process). It mostly works for a marriage, but you do have an occasional remarrage. This filtering work best on the more limited presentation forms, like charts, where you just don't have room for all the details (those would be in the related text reports (and such charts tend to not show the sort of event like census where having multiple instances are expected). On 12/8/17 12:54 PM, Michael J Hannah wrote: > robin lamacraft wrote: >> This question raises the need to rethink the nature of primary parents. > > Robin, > > I "think" we discussed this somewhat in the past.  But if not, my > opinion is that the entire concept of a "primary" parent is a really > *bad* idea.  (This assumes I understand your meaning of the term > "primary".  If not, see the last paragraph below.)  Primary has been a > problem in TMG and most other genealogy programs.  But I strongly hope > it will not be a problem in HRE. > > I believe there is no need for a "primary" designation when entering a > relationship tag.  That tag should simply indicate the nature of the > relationship (in each direction) between two database entities, e.g. > parent-bio, child-bio, parent-ado, child-ado, etc.  And the user > should be able to create and define any type of custom relationships.  > (Note that "location areas" as entities should be able to have > relationships as well.  Think of county formations where new counties > are created (as "children"?) from parts of old counties.) > > I believe what is needed instead of "primary" is the ability to > calculate and output "directed" graphs or trees or reports etc. of > *any* kinds of directional relationships which exist in the database.  > The definition of such an output should include which relationship(s) > are to be used for each direction in the calculation of that output. > > And yes, the plural of relationships for the output definition is > intentional.  As an analogy think of the TMG way to define multiple > people Accent conditions to come up with a single color accent for a > person.  Something similar should be able to be defined for selecting > amongst one or more relationships which may be exist in a given > direction between entities. > > For example, a strictly genetic relationship output could be defined > as requiring only parent-bio "up" the tree, and only child-bio "down" > the tree.  But an output which "also" included "Family" relationships > while focused on biology could be defined where "up" is parent-bio if > there is one, else parent-ado if there is one, else parent-social.  > Alternatively an output including "Family" relationships but focused > on social relationships could be defined where "up" is parent-social > if there is one, else parent-ado if there is one, else parent bio.  > Also the output definition should have options to specify other > criteria to use to choose a relationship among several in the same > direction or among several of the same relationship type, e.g. using > parent-social then use "last" based on the dates of these > relationships, or "then" based on the date range including a provided > date, or ... (use your imagination). > > I believe the relationship *output* should define what type of > relationship is "Primary" (or secondary, or ...) for the purposes of > that specific output.  "Primary" should not be an attribute of the > individual relationship itself.  The user needs to be able to choose > different relationships as "primary" for different output purposes. > > However, I do believe there would be a need for an attribute of > "default" for _each_ relationship type.  (Maybe that is what you were > thinking of when you used the term "primary"?  If so I think the > terminolgy of "default" more clearly reflects its purpose.) Only one > among multiple relationships for a person of the _same_ type would > have this attribute.  Thus each type would have its own default.  The > output would then only use that relationship among multiple > relationship tags of the _same_ type in the case where any defined > output criteria (e.g. date) does not make the choice among these > multiples clear.  Note that I don't believe there is a need for a > default type among multiple "types" of relationships. I believe that > always should be part of the definition for that output. > > Just my (strongly held) opinion <grin>, > > Michael > The TMG archive is found here: > http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: > http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to > [email protected] with the word 'unsubscribe' without the > quotes in the subject and the body of the message > -- Richard Damon