Is there a tag that gives the reliability of a FAM- CHILD connection

[mother10]

When you are far back in your tree, you are not always certain about the parents of a child for instance. While from the child till today you have found a lot of which you are certain.
So mostly the "topmost" Indi's in your tree. To build upward, so to speak, is difficult sometimes.
But you do want to enter those parents, to not lose the information.

I found this:
g7:enumset-FAMC-STAT
with values:
CHALLENGED Linking this child to this family is suspect, but the linkage has been neither proven nor disproven.
DISPROVEN There has been a claim by some that this child belongs to this family, but the linkage has been disproven.
PROVEN Linking this child to this family has been proven.

Now I worked with a program where you can give each child/parent connection a value like:

• Certain
• Probable
• Doubtful
• Unreliable

So a kind of scale that denoted how certain it was that this child belonged to this parent(s)
Later, if you find the right source, you can set it to Certain.
So in the situation I started with, I would enter Doubtful or Unreliable, but still enter the info about the parents that I find.

But doing it as described above, can give programs processing the gedcom, the ability to show the "reliability" of a connection.
So for instanxce in a treeview those parents can be given a special color

Thats a bit different from that g7:enumset-FAMC-STAT

Is this gonna change in the future and if so how?

[Norwegian-Sardines]

The CHILD_LINKAGE_STATUS has been around since v5.5.1, the software you are using probably did not update their program to support The Standard. I would first check to see what they put in the GEDCOM after you select the various different option in their UI and see what they put in the GEDCOM. My guess is that it does not comply with v5.5.1 of GEDCOM.

[tychonievich]

There was some conversation about this topic in the Hypothesis Working Group (which I was a part of) which was active during the design phase of 7.0.0 but was suspended thereafter. No significant consensus was reached on this topic by that group besides that current applications were all over in what they supported and that the genealogical research community had multiple competing views, many claimed by some researchers as the only right way but disagreed with by others. The only consensus to come out of that group was the NO tag, as the ability to provide negative assertions was clearly missing in 5.5.1 and wanted by many researchers.

Are there specific changes to FAMC.STAT you are proposing? Do you remember what tool it was that had the certain/probable/doubtful/unreliable scale?

[mother10]

The tool I used, and where this scaling is possible, is Aldfaer, the most wellknown and most widely used tool in our country. They are working on implementing GEDCOM7 for about 3 years now, but still not released. Their way of dealing with GEDCOM is not what I want, to say it very carefully.

After I found Ancestris 2 years ago, (GEDCOM 7 present since june 8 this year) I realised they do a far better job with respecting GEDCOM. (Dont know if you ever heard of this program) My old tool had to use a lot of _TAG things to be able to make some kind of GEDCOM out of what you could enter. But they had some good things too, (used their prog since 2003) and one of them was this reliability scaling. To be able to have some kind of reliability added to child/parent connections.

Most important argument I have for this, is that it will help to keep your findings in your GEDCOM, in a way, that enables you to later continue with that, if more information is present or found about that connection. Otherwise you will have to add this connection in a note or something, and programs will not have the possibility of showing these uncertain connections in a Treeview, together with those that you can be sure of, because you found their sources.

So before posting here, as always, I turned to the GEDCOM spec to see if there already was something.
And I found that FAM.STAT. But the values at this moment cannot be used for what I mean.

So if that FAM.STAT could have some extra "scale" values like:

• CERTAIN
• PROBABLE
• DOUBTFUL
• UNRELIABLE

(or better words because english is not my native language) that would be great I think.
And maybe there should be 3 values or 5, thats possible, but at least 3 I think.

[Norwegian-Sardines]

Genetically speaking, unless we are talking about DNA "proof" no child to parent connection is "Certain" and since the use of DNA for proving this connection can only exist for the last 100 years at best very little in pure genealogy can be certain!

So when we discuss "proof" we usually say, "Based on the preponderance of the evidence, this is most likely true". Preponderance is based on the more convincing evidence and its probable truth or accuracy, and not on the amount of evidence. Can we truly be "Certain" about the evidence as time passes? Documentation gets thinner (we may only have one document from a third party), stories change to suit the times!

At best (other than DNA proof) a connection would be "Probable", on the other hand using an alternate way of defining "proof" we can also say "beyond a reasonable doubt," which does provide us with some level of understanding. Genealogists ask these questions:

Genealogical Proof Standard (GPS)

To reach a sound conclusion, we need to meet all five components of the GPS.

1. Reasonably exhaustive research.
2. Complete and accurate source citations.
3. Thorough analysis and correlation.
4. Resolution of conflicting evidence.
5. Soundly written conclusion based on the strongest evidence.

Therefore if the sources meet these 5 criteria (in particular the analysis, and resolution of conflicts questions) we can say we have "proof" and can use the enumeration PROVEN!

If the evidence we have actually disproves a commonly thought connection, (I have a couple of these in my wife's genealogy) where someone indicates a parental connection, for example who a child's father is, but either DNA or other documents indicate otherwise, in genealogy we may still connect the child to a family, but indicate the connecting has been DISPROVEN (in GEDCOM the FAMC has no citation element so we don't know what evidence proves/disproves this), but we still maintain the connection because we need to indicate we know about this connection to our readers.

The third enumeration is CHALLENGED stating that:

Linking this child to this family is suspect, but the linkage has been neither proven nor disproven.

While the 4 enumerations you provided have very useful words, I'm not sure that I can use CERTAIN at all, I would rather use HAS PROOF with the evidence associated directly with the status. PROBABLE is equal to HAS PROOF (I'm not totally enamored with PROVEN) DOUBTFUL has elements of DISPROVEN but is not totally the same. UNRELIABLE relates to the evidence and since we have no evidence associated with the enumeration what are we indicating is unreliable?

I will admit that these enumerations are subject to interpretation.

The bottom line is:

1. Do we have proof of the connection (Yes/No)
2. How reliable is the proof (scale of 1-?)
3. How exhaustive was the research, are you confident you turned over all rocks?
4. What type of connection is this (genetic connection, adoption, fostering, other dynamic/what is a family?)

[tychonievich]

Would it be sufficient to add a SOUR under FAMC? The SOUR.QUAY roughly approximates the certainty/evidence-type scale discussed above, and including the SOUR there would let others check the evidence themselves.

[mother10]

Yes I dont see a SOUR under FAMC now, but that would give the same results, there is indeed a scale there. But it should be possible to have more sources so {0:M} And that would also give software the possibility to do something with it.

[mother10]

Now I wonder, should there also be a SOUR under a FAMS then too?

[Norwegian-Sardines]

So are we thinking something like this, just adding the source_citation and all that it brings along:

+1 FAMC @<XREF:FAM>@                
  +2 PEDI <Enum>                             
    +3 PHRASE <Text>                        
  +2 STAT <Enum>                             
    +3 PHRASE <Text>                        
  +2 <<SOURCE_CITATION<>    {0:M}       
  +2 <<NOTE_STRUCTURE<>           

This would bring the FAMC in line with any other Event/Attribute!

[mother10]

@Norwegian-Sardines I guess so.
Are there many other Event/Attributes that might need their own Source-citation?

[Norwegian-Sardines]

@Norwegian-Sardines I guess so. Are there many other Event/Attributes that might need their own Source-citation?

Your question about FAMS is a good one!

I would think about the SEX and ALIA tags as well!

[Norwegian-Sardines]

@Norwegian-Sardines I guess so. Are there many other Event/Attributes that might need their own Source-citation?

Your question about FAMS is a good one!

I would think about the SEX and ALIA tags as well!

Any assertion that is made must have the ability to write a citation!

This would be true in the Family_Record as well!

[mother10]

Geez,
Wow, it seems, as we say in Dutch "the old ones are still doing well"
You must get tired of my questions by now......

[mother10]

Tried to go over the GEDCOM spec to see if there might be more that maybe could have a SOUR added. I am not the expert you are but here goes:

• SUBM
• ALIA (already mentioned, but the definition says future versions of GEDCOM might adjust the definition. So maybe do that at the same time then)
• SEX (already mentioned)
• ANCI and DECI (sources could point to where to search/investigate further. I do a lot of this, but I put it in a NOTE, this might be better.)
• RELI ??

Extra while I was checking: I got an idea: Suppose in the FAM records HUSB and WIFE would be same as CHIL, so {0:M}, and not {0:1} wouldn't that give a Multi person family?

[Norwegian-Sardines]

Extra while I was checking: I got an idea: Suppose in the FAM records HUSB and WIFE would be same as CHIL, so {0:M}, and not {0:1} wouldn't that give a Multi person family?

Personally, I would disagree. Having more than two parents in a family would represent a Polygynandry relationship, and while these do exist in society, this concept takes us far away from the world of Genealogy (genetics) as well as a into a very uncommon (in modern society) family-history setup. These tags could use a source_citation as could the CHIL tag!

I would wait on changing from a HUSB/WIFE, two parent family, to point where we also remove the tag distinction of HUSB/WIFE to a multiple "parent" structure (PRNT tag ??) where the tag itself does not indicate the gender of the parent and move that distinction to where it belongs on the Individual_Record where we can also have a GENDER tag that includes a DATE structure.

I'm not sure that ANCI and DECI tags are asserting a fact and therefore require a source/citation. I'm not even sure how I would use these tags that points at a "Submitter" of information to the database (not an individual_record in the database) they could be anyone in the world. I would hope they already had received recognition as a submitter for information they submitted. I suspect that these are indicating that some individual sent me a name of a person not in my database and said "research them and see if they connect to the information in my database".

Both RELI and CAUS could have "source_citation" substructures but I would hope that the source of that information was also the source for the fact that we are asserting, for example BIRT.RELI if you are asserting they were born and they were born into a religion I would hope that both of these assertions came from one of the "source_citation" attached to the BIRT tag. The same would be true of DEAT.CAUS, if they died and you new the cause then it had to come from something related to a source about their death and that source was already associated with the DEAT tag.

I don't think a "Submitter" needs a citation. The "Submitter_Record" contains the information about where the submitter can be found!

[mother10]

@Norwegian-Sardines I can agree with your explanation of the HUSB and WIFE.

About ANCI - DESI, after more reading I think it can also mean a nephew for instance, or any other person, being interested in that part of your tree, or, as you said, gave you information for your tree. And you keep his/her details in the SUBM record.

So thats different from what I first thought. But that would mean I dont have any other way of keeping my temporary findings, including all links, in a NOTE, until I can go over them to expand and complete that part of my tree. GEDCOM only has 1 kind of NOTE, while I use it for 2 things, 1 for real info about a person, so info that should be printed in reports. And 2 as a scratch for things I have to further investigate. But I have no real way of suppressing that second kind of note, only by adding some starttext to search for, or add some mark to say its a "private" note.
When I first read about ANCI and DESI I thought it was meant for keeping track of all info needed to further investigate.

For RELI yes there is already a source for that, I tried to see if I could get a GEDCOM part with RELI from the definitions. This is what I find, correct me if I am wrong:

INDI
  Individual_attribute_structure {0:M}

Individual_attribute_structure
RELI text
  TYPE text
  individual_event_detail

individual_event_detail
event_detail
AGE
  PHRASE

event_detail
RELI tekst
SOURCE_CITATION

This leads to:
INDI
  RELI tekst
  TYPE tekst
  RELI tekst
  SOURCE_CITATION
  AGE
    PHRASE

I think I must misread the specs now, do I?
Otherwise RELI has its own Source_citation al,ready.

[tychonievich]

I agree with @Norwegian-Sardines about HUSB, WIFE, ANCI, DESI, SUBM, (event).RELI, and CAUS.

@mother10 there are two RELIs. The g7:INDI-RELI is an attribute of a person, like my grandfather being Lutheran. It may have SOURs.

The g7:RELI is the religion associated with an event or attribute, like my grandfather being christened in a Roman Catholic church (a CHR.RELI). It may not have its own SOUR because we assume that the fact that the event was associated with a particular religion will be found in a source describing the event, and thus the event's SOUR attests the event's g7:RELI.

The spec allows RELI under any event or attribute, both those where it seems clearly applicable (religious events like BAPM and CONF) and those where it seems likely to apply (like DSCR and RELI). This flexibility allows for the wide range of religious influence over time and place. For example, the RELI.RELI in your example may seem redundant, but it could make sense if the leader of one faith commanded their followers to switch to a specific new faith or if one faith allowed its members to join other religions.

[mother10]

Thanks for the clarification!

[mother10]

After some extra thinking and seeing issue #494 added, I have some remarks.

An INDI can have a FAMC tag, pointing to a child of that INDI. Now we have said (as stated in issue #494) that adding a SOUR to a FAMC, might solve problems for connections that are not sure yet, but who's information you dont want to loose for further investigation.

But in that same issue FAMS is not mentioned.
I think that a FAMS.SOUR can also be very usefull in cases where you are not sure about a connection between an INDI and his/her spouse.
So I dont understand why FAMS is not mentioned in that issue too.

The issue states that there were no examples mentioned in the discussion for other tags that might have a SOUR added.
I dont understand why there should be examples from real use added, before adding it to the specs.

As it is not possible yet to add a source to these tags, there might not be programs offering that possibility yet, BECAUSE it is not possible.
But that does NOT mean, in my opinion, that those combinations cannot be very useful when added.

Furthermore, if a SOUR can be added usefully to more tags now, in one go in the same GEDCOM update, it is more likely that programs that have to deal with this change, can develop general actions for it.
If SOUR would be added here and there in more minor updates, one after the other, only one at a time, it might be more trouble implementing them for software developers.

So, as we say in Dutch: "een slimme meid is op de toekomst voor bereid" (a smart girl is prepared for the future) I would say: think carefully about this principle of adding SOUR on places it might be usefull, and whether or not there are already examples of programs using these situations, add those that are very likely to be usefull, all together in the next minor.
And if a SOUR is added and no NOTE exists yet at that place, add the NOTE too.

[tychonievich]

Every feature we add is an implementation burden to developers, and thus a delay in some software adding the feature, and thus a reduction in the adoption of the standard and thus the interoperability of family history software. There are always some applications that were engineered in a way that makes each addition straightforward, but others that were designed differently. Hence we try to ensure there is a compelling need and use in practice before adding a feature to the spec.

The FAMS.SOUR I can think of are generally either really FAMC.SOUR (a record mentions the parents of someone) or MARR.SOUR (a record mentions a couple relationship). Note that FAMS is a bit special in that the two partners of a FAM needn't have any actual relationship: a FAM might have partners of a surrogate or sperm or egg donor representing elements of biological parentage that occurred without the partners knowing one another. To represent a couple relationship we either need a FAM.MARR (or a similar family event or family attribute) or potentially an ASSO with a couple-type ROLE.

[Norwegian-Sardines]

I agree with @tychonievich about the FAMS.SOUR in that it is just a pointer providing a two way connection between record types. If the FAMC tag was just a pointer and nothing more I would not necessarily think it needed a SOUR subtag either, but because it asserts a “pedigree” and introduces the status tag we must source those data points.

The concept of INDI.FAMC and INDI.FAMS as back pointers as facts is not warranted, rather, they are structural indicators of the relationship to other individuals. The relationship exists because they are indicated by actual facts within the fact structures of the Individual_Record and Family_Record. For example:

Child to parent by birth (the BIRT tag) already indicates who the birth parents of the child are. The same is told within the adoption, a LDS sealing tags. The FAMC.PEDI is redundant information and I probably would not have design the GEDCOM to include it, but because it is in the specification it must be sourced!

The same is true for the FAMS, the true indicator of the relationship should be indicated with a sourced fact like FAM.MARR. I would however like to have another tag in the Family_Record to assert other types of relationships.

[mother10]

@tychonievich We each have our own ideas about when we would take the trouble of updating a software, when a new version of, in this case, the GEDCOM is out. To me, if the difference from the version already implemented and the new version, were too little, I would not very much like to take the overhead time to implement the laterst feature each time again.
I would rather wait till there is another update, so the amount of overhead is more acceptable for the amount of changes for the 2 versions together.

But each one has its own ideas about that. Certainly if you have to maintain spaghetti software you will not be happy to have much overhead time, for just a few changes. I can agree with that.
But the compelling need can also be, the total amount of changes together. Not just 2 or 3 great new features.
To me, if there is a "principal" change, like adding SOUR to more places, I would rather have more of those in one go, maybe not all, but more, so it takes me 1 one time overhead to implement this principal change.

The program I use now, implemented 7.0.13 as a follow up on 5.5.1. They are not gonna implement 7.0.14 right away, because the versions differ not enough. If the next minor does not differ enough again, I guess they wait till another version.
Which is a pity I think.

Turning the whole GEDCOM structure upside down, yes, that has to wait till a big version change like 8.

But if your group agrees about some principal additions or changes, don't do just one, but define which ones are the most important and put those in. That way giving developers the change to implement it in a flexible way that allows further additions of that principle, to be added without much trouble.

I wonder if I would go over all versions 7.0 how many differences there are in between each step from 7.0.0 till 7.0.14.
We can use 7.0.13 now which is a huge step coming from 5.5.1. And I dont think small minor GEDCOM versions will be implemented soon after this step. That will not be interesting enough to be willing to spend the overhead.

Its volunteers doing this in their spare time, as an unpayed job.
For the old program I used, that I mentioned in another post, its volunteers there too.
But I really appreciate the posts here, and it is great to see the amount of work everyone here does.

[tychonievich]

I understand this conflicting levels of desire for change; it occupies a significant portion of my thoughts when trying to decide on what to propose for the spec. If only everyone was using a program that was actively and recently developed, life would be so much simpler!

FYI, any implementation of 7.0.13 (or even 7.0.0) is identical to an implementation of 7.0.14 (or even 7.0.999 if we get there). We use semantic versioning, so the third number in the version string (the "patch") only describe changes in how the specification document is presented, not in the data files that are being specified.