Parent-Child relationship facts

[nilsbrummond]

From https://github.com/FamilySearch/gedcomx/blob/master/specifications/conceptual-model-specification.md#3141-known-fact-types

URI	description	scope
http://gedcomx.org/Adoption	A fact of a person's adoption. In the context of a parent-child relationship, it describes a fact of the adoption of a child by a parent.	parent-child relationship
http://gedcomx.org/Birth	A fact of a person's birth. In the context of a parent-child relationship, it describes a fact of the biological birth of a child to a parent.	parent-child relationship
http://gedcomx.org/Foster	A fact about a foster relationship between a foster parent and a child.	parent-child relationship
http://gedcomx.org/Guardianship	A fact about a legal guardianship between a parent and a child.	parent-child relationship
http://gedcomx.org/Step	A fact about the step relationship between a parent and a child.	parent-child relationship

There are many records, (e.x. 1930 US federal census records) that list children of the household as any of the above types. The records give the relationship in the social context, but says nothing about the biological context.

I think there needs to be another type added for the semantics of "Filled the social role of parent, but exact biological relationship is not specified."

I propose the addition of:

URI	description	scope
http://gedcomx.org/Parent	A fact of a person's parenting in a social context without providing information on biological relationships.	parent-child relationship

This new http://gedcomx.org/Parent would not conflict with any of the currently existing types above. It is in a sense a parent type of the above. That is given two records, one can give evidence to 'Parent' and another to 'Birth' without a semantic conflict.

[EssyGreen]

I think the problem here is rather that many (if not most) sources omit information and use common terms which imply but do not confirm the exact nature of the relationship ... For example, "Adoption" and "Guardian" are legal terms (with implications on responsibility, ownership and inheritance) but may be used (technically incorrectly) to describe an informal parenting relationship. It is down to the skill of the researcher to interpret how terms were being used within their social context and to find supporting evidence for the assumptions made. I don't think that trying to code up variations will help resolve the problem and will actually lead to confusion for inexperienced researchers.

[nilsbrummond]

@EssyGreen

I think the problem here is rather that many (if not most) sources omit information and use common terms which imply but do not confirm the exact nature of the relationship ... For example, "Adoption" and "Guardian" are legal terms (with implications on responsibility, ownership and inheritance) but may be used (technically incorrectly) to describe an informal parenting relationship.

Agreed. The purpose of the proposed http://gedcomx.org/Parent is to capture evidence of the nature you just described. The person is shown to be in parent role, but the exact nature of the relationship is not defined.

It is down to the skill of the researcher to interpret how terms were being used within their social context and to find supporting evidence for the assumptions made. I don't think that trying to code up variations will help resolve the problem and will actually lead to confusion for inexperienced researchers.

In the context of coming to a conclusion based on all the available evidence I can agree with you, but, in the context of a single source and extract evidence, I see the usefulness of a feature like the proposed.

As for the confusion of inexperienced researchers, that is possible. I think that good documentation, good examples, and good user interface design can resolve that.

[mikkelee]

+1 on proposal as described by @nilsbrummond

For reference, some terms used in the Danish censuses 1787 + 1801:

• "Common child of head of household" (Though these are indeed usually children of head+spouse, in some cases I have evidence that they are actually one of the below; I would probably use the proposed Parent type for these unless a more specific term was explicitly used in the census).
• "Separate child of head of household"
• "Separate child of spouse of head of household"
• "Foster-child of head of household"

See http://ddd.dda.dk/Counting%20Danes.pdf -- pg. 15 (in English)

Also pg. 16: "The most striking differences are that there are a larger proportion of servants in 1787 and more separate children of head in 1787. The last could probably be result of that the 1787 census ask specifically of from which marriage the children comes." [sic]

[EssyGreen]

The purpose of the proposed http://gedcomx.org/Parent is to capture evidence of the nature you just described.

I do understand (and actually I would prefer the "Parent" identifier to be the main attribute and the Adoption/Foster/Guardianship/Step to be sub-attributes of this as was the case in old GEDCOM) BUT I think there is a fundamental problem in trying to code-up exactly what is in a source in this way because of the multitude of variations of (and in) sources and the sociological and contextual implications which are necessarily negated by such coding ... either we have to make things very general (and lose context etc) or we have to make things very specific (and keep an ever-increasing list of variants). The only way to capture the true meaning of what was recorded in a source is to look at the original (or image copy) in the context of its containing source, the person recording it and in the context of the wider society/culture/time etc in which it was recorded. I believe this is impossible to codify to any degree of accuracy. .... and in any event this would be coding up the source rather than the interpreted "fact" and so is irrelevant to this discussion.

The "fact" on the other hand should be in effect a heading for a conclusion which has been arrived at from studying a multitude of evidence from a variety of sources.. It's perfectly acceptable for this to be incomplete since it's only a heading and the full details can be better described in the text.

What I'm trying to say is that the "Fact" types should be a reasonably short, codified list of "headings" which can be further described in text ... they should not attempt to relate directly to the various categorisations described within various sources.

Having said that I'll shoot myself right in the foot here since I've said elsewhere that I prefer these to be verbatim (rather than codified) and so there is no reason why you shouldn't have "Parent" :)

[nilsbrummond]

@EssyGreen

I do understand (and actually I would prefer the "Parent" identifier to be the main attribute and the Adoption/Foster/Guardianship/Step to be sub-attributes of this as was the case in old GEDCOM) BUT I think there is a fundamental problem in trying to code-up exactly what is in a source in this way because of the multitude of variations of (and in) sources and the sociological and contextual implications which are necessarily negated by such coding ... either we have to make things very general (and lose context etc) or we have to make things very specific (and keep an ever-increasing list of variants).

Agree on the sub-attributes.

Something like this might be better:

• Parent (generic level - no details)
  • Birth-Parent
  • any sub-types needed here?
  • Non-Birth-Parent
  • Foster
  • Adopted
  • Step
  • etc...

Something like that can capture the basic information (unknown, birth, non-birth), and allow the flavor to further defined by addition sub-types or text.

[EssyGreen]

Agreed :)

Tho' I would prefer just 2 levels:

• Parent (generic level - no details) -- Foster -- Adopted -- Step -- Other -- Unknown

One other point ... I'm assuming this is for parent (singular) not parents (plural) since in my experience it is fairly rare to have the same degree of confidence for both parents and both mother and father need room for debate/analysis separately.

[thomast73]

+1 for the concerns raised by @EssyGreen

It is my experience that given a source(s), researchers and system implementers make the common assumption -- biological parent(s) -- unless they find evidence to suggest the contrary. It might not be the right assumption -- and likely we have all experienced cases where it has been the wrong assumption -- but I do not think most researchers start out by assuming the most generic and safest assumption (that the lineage relationship type is unknown) and wait for conclusive proof to declare it otherwise. We start off with the assumption that a parent is a biological parent until we discover conflicting evidence, at which time we re-evaluate our evidence and re-form our conclusions.

In the GEDCOM X model, we declare the lineage relationship type by adding a Fact of type http://gedcomx.org/Birth (or another type, typically a value in the list that @nilsbrummond quoted at the beginning of this issue) and adding that fact to the Relationship that associates a child to a parent. If I discovered conflicting evidence and decided that the lineage type can no longer be stated with confidence, I remove the lineage type -- not apply a generic type code -- and the lack of a fact with a lineage type would indicated the lineage type is unknown.

The existence of a Relationship of type http://gedcomx.org/ParentChild essentially represents the generic case; adding a Fact of a given lineage type to that relationship makes it a more specific instance.

[EssyGreen]

In the GEDCOM X model, we declare the lineage relationship type by adding a Fact of type http://gedcomx.org/Birth (or another type, typically a value in the list that @nilsbrummond quoted at the beginning of this issue) and adding that fact to the Relationship that associates a child to a parent

Thanks for the clarification @thomast73 - so "Parent" is implicit (by virtue of the Relationship) and can be refined by adding Adoption/Guardianship/Step/Birth facts etc?

That seems a bit strange since presumably you would typically have a person having a role of child in 2 relationships (mother and father) - all fine and dandy ... but then each of those has say a "Birth" fact meaning that the child appears to have 2 births? Seems a bit weird to me.

[nilsbrummond]

@EssyGreen

That seems a bit strange since presumably you would typically have a person being with a role of child in 2 relationships (mother and father) - all fine and dandy ... but then each of those has say a "Birth" fact meaning that the child appears to have 2 births? Seems a bit weird to me.

I read this as a Fact with the type field set and the rest blank. It is used to sub-type the relationship only. When looking at the Birth facts of the child, the relationship fact should not be included. I can not see how there would ever need to be more than one fact in the relationship fact list. I do not see how any fields of the Conclusion base could differ except maybe confidence in the case that we are more confident of the relationship then the exact sub-type. The Relationship type doesn't document this. This is just my assumptions. Perhaps Relationship type documentation needs some clarification in this area.

I think now I would prefer this:

1. remove Relationship.facts. All info will be in Relationship.type
2. define all types as tree with the dumb down semantics from Dublin Core.
3. define a method to define custom sub-types.
4. allow "abstract class types" to specify some types cannot be used directly?
5. define a basic type tree as something like as follows
   • RelationshipType
   • CoupleRelationship
   • PreCoupleRelationship
     • Engagement
     • etc..
   • StartCoupleRelationship
     • Marriage
     • etc...
   • MidCoupleRelationship
     • Separation
     • etc...
   • EndCoupleRelationship
     • Divorce
     • Death
     • etc...
   • ParentChildRelationship
   • BiologicalParentChildRelationship
   • SocietalParentChildRelationship
     • Foster
     • Adopted
     • etc....

[nilsbrummond]

I read this as a Fact with the type field set and the rest blank. It is used to sub-type the relationship only. When looking at the Birth facts of the child, the relationship fact should not be included. I can not see how there would ever need to be more than one fact in the relationship fact list. I do not see how any fields of the Conclusion base could differ except maybe confidence in the case that we are more confident of the relationship then the exact sub-type. The Relationship type doesn't document this. This is just my assumptions. Perhaps Relationship type documentation needs some clarification in this area.

Never mind on that.. Just read the spec again and my understanding was off.

[EssyGreen]

1. remove Relationship.facts. All info will be in Relationship.type

I agree with removing Relationship.facts but do we actually need a Relationship type at all since these can all be expressed as the EventRole(s) for Person.facts (although the predefined list of EventRoleTypes is too limiting at present)?

Personally I would also consider Relationships to be superfluous since these are more accurately represented in the EventRoles too but I suspect there would be a huge objection to this.

[nilsbrummond]

@thomast73

It is my experience that given a source(s), researchers and system implementers make the common assumption -- biological parent(s) -- unless they find evidence to suggest the contrary. It might not be the right assumption -- and likely we have all experienced cases where it has been the wrong assumption -- but I do not think most researchers start out by assuming the most generic and safest assumption (that the lineage relationship type is unknown) and wait for conclusive proof to declare it otherwise. We start off with the assumption that a parent is a biological parent until we discover conflicting evidence, at which time we re-evaluate our evidence and re-form our conclusions.

I agree that you are correct in what you say here. My thinking is if a researcher changes his/her methods to not make these assumptions, it becomes possible to analyze the tree to show place where more research can be directed to determine the birth parents vs step/adoption/etc...

There may be too much inertia to overcome to change this, but maybe there should at least be the option.

[thomast73]

@EssyGreen: Personally I would also consider Relationships to be superfluous since these are more accurately represented in the EventRoles too but I suspect there would be a huge objection to this.

I am having trouble with this idea. I understand that it might be optimal to model a record with a residence using an Event and associate people with that event using EventRole instances. But Relationship instances are not for modeling records; they are for showing our conclusions about how people are related. Event instances do not seem like a good mechanism for expressing conclusions about how people are related.

@nilsbrummond: There may be too much inertia to overcome to change this, but maybe there should at least be the option.

Inertia is going to be a problem on this...but it sort of seems to me that I need a lineage type of "indeterminate" -- a mechanism to say that I have evaluated this and I am not comfortable with making any assumptions. If a lineage type is never provided, programs ought to feel free to make the typical assumptions. But it sort of feels like I need a way to say that assumptions ought not be applied.

[EssyGreen]

Relationship instances are not for modeling records; they are for showing our conclusions about how people are related. Event instances do not seem like a good mechanism for expressing conclusions about how people are related.

I guess it depends how you think of a relationship in general ... my thinking is that the connection (relationship) between people is something which lasts for a period of time (which may/may not be a lifetime) and the nature of that relationship may change over that time period. It is a dynamic not a static thing. So the "type" of relationship will depend upon the time period. A spouse becomes a widow when their other half dies; a divorcee if they divorce; a spouse again if they re-marry; a woman who thinks she is a wife may find she is not if her husband is a bigamist; a child may be fostered then later adopted by the same parents (who may even be their biological parents).

Also, how we label relationships changes over time/culture ... In the 1800s there was no legal form of adoption in the UK (this only came into being in the 1920s) so labelling a relationship as "Adopted child" in 1850 would have an entirely different meaning to that of 1950.

So, personally I find it more useful to code up the Events that people experience in their lives (along with the roles which other people played in those events) because this allows me to record the time period and context in which my conclusion is based.

[thomast73]

@EssyGreen, I appreciate the excellent explanation of your thinking on this.

... the nature of that relationship may change over [time] ... the "type" of relationship will depend upon the time period.

We are also interested in representing the dynamic nature of relationships.

Actually, this is what the list of "facts" on the Relationship was intended to represent. By adding more than one Fact (which can have, among other things, a Date which can represent a point in time or a time period), we can represent the dynamic nature of the relationship in a manner similar to what you are talking about. For a "couple" Relationship, we could have facts representing an engagement, a marriage, a separation, a divorce, etc. For a "parent-child" Relationship, we could have facts representing a progression like being fostered, then later being adopted.

[EssyGreen]

this is what the list of "facts" on the Relationship was intended to represent

Yes, I realise that ... so I guess my point is that since these Facts already describe the "dynamic" relationship ... then surely the Type of the actual Relationship (to the degree being discussed) is less important (if not superfluous) and all we need is a simple categorisation of Parent/Child, Couple and Other? For example, Adoption, Birth, Guardianship, Foster and Step can all be described as "Facts" of a Relationship of type Parent/Child.

[thomast73]

Facts already describe the "dynamic" relationship ... then surely the Type of the actual Relationship ... is less important...and all we need is a simple categorization of Parent/Child, Couple.... Adoption, Birth, Guardianship, Foster and Step can all be described as "Facts" of a Relationship of type Parent/Child.

+1. This is essentially the intention of the current model.

The proposal @nilsbrummond makes is that we add a lineage "Fact" type to represent something very generic (proposed name: Parent) that does not convey the assumptions that come along with the others "Fact" type currently intend for the purpose of representing lineage type.

My feeling is that the absence of a Fact declaring lineage type is sufficient to express a generic parent-child relationship. I also feel that adding an explicit generic "Fact" type would be confusing and difficult to interpret. Therefore, I am not in favor of adding the proposed "Fact" type value.

[nilsbrummond]

@thomast73

My feeling is that the absence of a Fact declaring lineage type is sufficient to express a generic parent-child relationship. I also feel that adding an explicit generic "Fact" type would be confusing and difficult to interpret. Therefore, I am not in favor of adding the proposed "Fact" type value.

The only oddity I see here is the sourcing of the Relationship vs the Relationship->facts. When ever there is a Fact type that fits then that fact is gonna have it's sources and confidence fields set. The odd part is if there is no Fact object in the relationship due to uncertainty on the relationship type then your now using the sources and confidence of the Relationship object itself. This just feels a little disjoint. Would the the sources and confidence fields of the Relationship ever be directly used outside of the "unknown specifics" case?

Note: With generic relationship type facts it may be possible to make Relationship not be a Conclusion, but just a Conclusion container.

2nd question on Relationship in general... Does the Relationship type serve as a container for shared facts between to people only? or does it represent a specific relationship between 2 people? Example of what I'm asking: 2 people are marriage and divorced to each other multiple times. Should there be one Relationship object? or should there be one Relationship object per marriage?

[EssyGreen]

My feeling is that the absence of a Fact declaring lineage type is sufficient to express a generic parent-child relationship. I also feel that adding an explicit generic "Fact" type would be confusing and difficult to interpret. Therefore, I am not in favor of adding the proposed "Fact" type value.

+1

if there is no Fact object in the relationship due to uncertainty on the relationship type then your now using the sources and confidence of the Relationship object itself.

The sources and confidence etc of the Relationship always relate to the Relationship ... the sources and confidence of the Fact always relate to the Fact ... If I find evidence of a Parent/Child relationship which is insufficient to conclude further facts or the exact nature of the relationship then I just use the evidence against the Parent/Child Relationship; if maybe later I have evidence of a Birth then I can add this in as a Fact (and I might also amend/refine the actual relationship and add the extra evidence to it); ditto adoption etc etc

Does the Relationship type serve as a container for shared facts between to people only? or does it represent a specific relationship between 2 people?

I think this is where GEDCOM-X gets a bit flakey .. I'd like to know the official answer too :) ... As I see it there is nothing to stop anyone having a Relationship Fact which also has roles for people who are not in the Relationship and conversely there is nothing to ensure that either/both the people in the Relationship are represented in the Fact .... hence my problem with Relationship Facts. ... If on the other hand we just had plain old Facts then you could calculate who is involved by virtue of their Roles. e.g. a Marriage with two Spouses implies a Relationship between the two spouses; a Marriage with say 10 spouses (say a man and 9 wives) also implies a Relationship between the man, each of his wives and also the relationships between each of the wives themselves - this would be extremely tedious to represent via Relationship objects.

[stoicflame]

Hi folks.

You've brought up some great discussion here. I've got some time to weigh in, so here goes.

Does the Relationship type serve as a container for shared facts between to people only? or does it represent a specific relationship between 2 people?

This is a great question, and I agree that it's not very clear when reading the spec. The Relationship is more than just a container for the shared facts. It's intended to represent a specific relationship between two persons. I would appreciate your help in getting the spec clarified so as to answer these questions. Where do you suggest we add wording that addresses this?

[EssyGreen]

Where do you suggest we add wording that addresses this?

I don't think it's so much a matter of wording ... there is nothing in the structure to ensure data integrity ... ie it is totally possible to have a Relationship between people A & B but then to list Facts against it which only involve people X & Y ... The only way I can see to solve this is to remove the Facts from within the Relationship so that the Facts "speak for themselves" (excuse the pun!)

[nilsbrummond]

I don't think it's so much a matter of wording ... there is nothing in the structure to ensure data integrity ... ie it is totally possible to have a Relationship between people A & B but then to list Facts against it which only involve people X & Y ... The only way I can see to solve this is to remove the Facts from within the Relationship so that the Facts "speak for themselves" (excuse the pun!)

I assumed a Fact in the Relationship facts list may not be in a Person facts list:

• That a http://gedcomx.org/Couple type Relationship facts list may only contain couple relationship scoped Fact types.
• That a http://gedcomx.org/ParentChild type Relationship facts list may only contain parent child relationship scoped Fact types.
• That a Person may only have person scoped 'Fact' types in the facts list.

This way relationship fact's only possible connection to a person is through the Relationship. Putting a 'Fact' in a relationship facts list between A & B means that the Fact IS about A & B, as there is no way to link the Fact to X and Y. Does making my assumed points explicit solve your concern?

[stoicflame]

This way relationship fact's only possible connection to a person is through the Relationship. Putting a 'Fact' in a relationship facts list between A & B means that the Fact IS about A & B, as there is no way to link the Fact to X and Y.

This is correct. Fact doesn't "point to" any persons, and the only way you can determine the persons a fact applies to is by looking at the containing relationship. In other words, there is no way to add a fact about persons X and Y to a relationship between persons A and B.

[EssyGreen]

Fact doesn't "point to" any persons, and the only way you can determine the persons a fact applies to is by looking at the containing relationship. In other words, there is no way to add a fact about persons X and Y to a relationship between persons A and B.

Ah OK my bad ... I had assumed that Facts and Events were synonymous (and hence both had Roles) but I see from looking now that Events are top level entities and have Roles whereas Facts don't have Roles (and are embedded within Persons or Relationships) ... so a Birth Event, for example, would be a top level node with Roles for the child, parents, witnesses etc whereas a Birth Fact just describes either Person1 or Person2 in the containing Parent-Child Relationship ... is that right? If so, then how do you know whether the child is Person1 or Person2?

[thomast73]

... so a Birth Event, for example, would be a top level node with Roles for the child, parents, witnesses etc ...

Yes, this is right.

... whereas a Birth Fact just describes either Person1 or Person2 in the containing Parent-Child Relationship ... is that right?

Close.

A Birth Fact would be added to a Person.

A Fact indicating lineage type (e.g., a biological lineage relationship) would be added to a parent-child-type Relationship. The parent-child Relationship would refer to the parent Person and the child Person.

If so, then how do you know whether the child is Person1 or Person2?

The Conceptual Model document says this about the Relationship object: "...when a relationship type implies direction, the relationship is said to be from person1 to person2. For example, in a parent-child relationship, the person1 property refers to the parent and the person2 property refers to the child."

[EssyGreen]

"...when a relationship type implies direction, the relationship is said to be from person1 to person2. For example, in a parent-child relationship, the person1 property refers to the parent and the person2 property refers to the child."

Ah OK I missed that subtlety

A Birth Fact would be added to a Person.

The documentation says that a Birth Fact is applicable to a Parent-Child Relationship:

3.14.1 Known Fact Types URI: http://gedcomx.org/Birth Description:A fact of a person's birth. In the context of a parent-child relationship, it describes a fact of the biological birth of a child to a parent. Scope:parent-child relationship

[thomast73]

A Birth Fact would be added to a Person.

The documentation says that a Birth Fact is applicable to a Parent-Child Relationship:

3.14.1 Known Fact Types URI: http://gedcomx.org/Birth Description:A fact of a person's birth. In the context of a parent-child relationship, it describes a fact of the biological birth of a child to a parent. Scope:parent-child relationship

Okay. I see I am missing a subtlety. :-)

Indeed, in the "Known Fact Types" list, Birth appears twice, each intended to mean something separate from the other. We have assigned the same name to two different concepts. This is probably a bad thing -- something we did not consider well when we put it into that state. We will change the name of the second so that the two concepts become distinct. How about naming the second to be something like http://gedcomx.org/BirthParent or http://gedcomx.org/Biological. Our current leaning is toward BirthParent.

[EssyGreen]

in the "Known Fact Types" list, Birth appears twice, each intended to mean something separate from the other. We have assigned the same name to two different concepts. This is probably a bad thing

I agree this is confusing!

How about naming the second to be something like http://gedcomx.org/BirthParent or http://gedcomx.org/Biological. Our current leaning is toward BirthParent.

I would vote strongly for "Biological Parent" ... this keeps it clearly separate from "Birth" to avoid confusion. It also separates the birth from the conception so that there is no confusion between say a biological parent who conceives a child and a person who is takes on a parenting role at birth even tho' they may not have been there at conception.

[thomast73]

http://gedcomx.org/BiologicalParent

We hadn't considered this variation. Seems okay. Other votes for or against the value proposed by @EssyGreen?

[nilsbrummond]

I would vote strongly for "Biological Parent" ... this keeps it clearly separate from "Birth" to avoid confusion. It also separates the birth from the conception so that there is no confusion between say a biological parent who conceives a child and a person who is takes on a parenting role at birth even tho' they may not have been there at conception.

so is this what we are proposing?

http://gedcomx.org/BiologicalParent -> Provided DNA to the child.

http://gedcomx.org/BirthParent -> There at the time of Birth (i.e. on birth certificate).

So it will be possible to model the tabloids of modern reproductive medicine? A couple M1 and W1 want to have a baby, but W1 is not capable. The doctor takes eggs from W1 and sperm from M1. The doctor places a fertilized egg into the surrogate mother W2 who is contracted to birthing the child for M1 and W1. The doctor, M2, secretly used his own sperm to fertilize the eggs...

http://gedcomx.org/BiologicalParent = M2 and W1

Depending on law in the place of birth: http://gedcomx.org/BirthParent = M1 and W2? http://gedcomx.org/Adoption = W1?

[thomast73]

@nilsbrummond: So it will be possible to model the tabloids of modern reproductive medicine? ...

Okay, that made me laugh. :-)

@nilsbrummond: so is this what we are proposing? ...

I was proposing only the addition of http://gedcomx.org/BiologicalParent. This value supersedes the previously proposed value http://gedcomx.org/BirthParent.

I am assuming that this value will usually exist without DNA proof. :-) It is the assumption most make -- until they find evidence to the contrary.

[nilsbrummond]

Ya I'm fine calling it http://gedcomx.org/BiologicalParent and with people, that want to, assuming biological until evidence to the contrary. But it still leaves the question of what do you call the birth father when that DNA evidence does show up...?

[EssyGreen]

A couple M1 and W1 want to have a baby, but W1 is not capable. The doctor takes eggs from W1 and sperm from M1. The doctor places a fertilized egg into the surrogate mother W2 who is contracted to birthing the child for M1 and W1. The doctor, M2, secretly used his own sperm to fertilize the eggs...

[...] what do you call the birth father when that DNA evidence does show up...?

Disappointed ;)

It depends how the researcher wanted to model it and what evidence there is - the father could simply be a http://gedcomx.org/Participant at the child's birth ... if it was discovered in M1's life time maybe he adopted the child so would become an adopted parent ... it is probable that M1 would still be recorded as the "father" for other events such as the later marriage of the child.

[nilsbrummond]

I guess what I'm getting at is there is a type of parent missing still. We thought he was the http://gedcomx.org/BiologicalParent based on the birth certificate, but a later DNA shows that wrong. Lets say the DNA test came 20 years later. So the only father the child has ever know is M1. The child is an adult now so no need for an adoption, etc.. We are missing a designation of the parent role for this case as it is not Adoption, Foster, Guardianship, or Step.

We could say we care about 2 things at the most basic level of genealogy:

1. Biological parents. (source of child's DNA)
2. Sociological parents. (who did the child know as mom and dad)

http://gedcomx.org/BiologicalParent covers all of the first category

The second category is covered by: http://gedcomx.org/Adoption http://gedcomx.org/Foster http://gedcomx.org/Guardianship http://gedcomx.org/Step

But this list has holes in coverage as shown be my example above. I not sure exactly what the best way to complete the coverage is. Perhaps a http://gedcomx.org/SociologicalParent type for any case not covered by the other types.

[EssyGreen]

I think the problem here is that the modelling depends on what the researcher is trying to establish ... if he/she were interested in the legal status (e.g. to ascertain inheritence) then that would be modelled differently to a researcher interested in the biological ancestors ... which might be modelled differently to someone interested in the looser family relationships.

For example, M1's relationship to the child could be:

• Legal = probably nothing, could be adopted if he bothered to go through the process, there may be a sort of "common law" fatherhood of this type
• Biological = nothing
• Loose = Father

[nilsbrummond]

That is a good point. Legal should really be it's own category of research. I would call Loose -> Sociological, as in who filled the role of parent for the child in the social context. In the simple case all 3 categories are filled by the same person. It is possible for the Legal, Biological, Sociological parent to be different people in the extreme case.

[EssyGreen]

Loose -> Sociological

+1 I like that :)

[thomast73]

I talked with another genealogist that I know and asked her opinion on this subject. She liked the idea that @nilsbrummond has suggested, except she immediately started using the term "socioeconomic" (without thinking or being explicit about the changed). She also immediately named a case in her family that includes enough of the unusual to make this label applicable.

[thomast73]

To summarize, here are the changes we would like to make to FactType values as a result of this issue:

Original Value	New Value
http://gedcomx.org/Birth (the second one)	http://gedcomx.org/BiologicalParent
http://gedcomx.org/Adoption	http://gedcomx.org/AdoptiveParent
http://gedcomx.org/Foster	http://gedcomx.org/FosterParent
http://gedcomx.org/Guardianship	http://gedcomx.org/GuardianParent
http://gedcomx.org/Step	http://gedcomx.org/StepParent
no preexisting value	http://gedcomx.org/SociologicalParent

All in favor?

[thomast73]

This change was made and checked in as e84fc2745e58241a72043d5f08ea21e1be00f45b.