The “Check Associations Data” tool states that Jumel Guillaume is Ysel Michel’s uncle[oncle] (which is the case), whereas Deep Connexion Gramplet claims he is his nephew[neveu]!
I have asked this question before in a different way with no answer.
Is the Association a “To” or “From” relationship?
i.e., if the Association for John Smith “Godparent” is added to Mark Jones, then which person is the godchild and which person is the godchild?
When the relationship is symetrical (e.g., “cousins”) then they are the same and it doesn’t matter. Nor does it matter as far as running the Sync Associations addon tool. (It merely adds the reciprocal Association between the current person and the associated person to the Associated Person iff it does not already exist.)
The dialog needs some feedback.
Perhaps (like the Name Display editor in preferences) the dialog could preview a formatted description of the Association as it might appear in a biography?
So, adding an Association to Fred Thompson starts with:
Fred Thompson has an undefined Association with an unknown person.
Then, as a Person and Association type are added, the Preview updates.
I guess it is inherited from the ASSO tag (and definition) from the gedcom file format. As there is not a clear direction on the documentation, gramps model only provides a pseudo-free form.
The check associations tool only reads our data as deep connections makes calculation. Both are right!!! To fill uncle (oncle) or nephew (neveu) is just a starting point issue… a bi-directional associations or design issue, which could be missing on gedcom definition?
[NOTE: The ASSOCIATION_STRUCTURE can only link to an INDIVIDUAL_RECORD.]
Directionality is clarified in the RELATION_IS_DESCRIPTOR linked section:
RELATION_IS_DESCRIPTOR: = {Size=1:25}
A word or phrase that states object 1’s relation is object 2. For example you would read the following as “Joe Jacob’s great grandson is the submitter pointed to by the @<XREF:SUBM>@”: person pointed to by the @<XREF:INDI>@":
0 INDI 1 NAME Joe /Jacob/ 1 ASSO @<XREF:SUBM>@ 1 ASSO @<XREF:INDI>@ 2 RELA great grandson
[NOTE: The ASSOCIATION_STRUCTURE can only link to an INDIVIDUAL_RECORD.]
There is a relationship chunk in the vCard 4 .vcf specification. The Import plug-in could be enhanced to support that Association. (And have special parsing to build Families other of the Immediate Family pre-defined association terms. (And maybe any pre-defined Associations in Gramps.)
The cited gedcom.io section for GEDCOM7 has more exposition. (The use of the @VOID@ASSO pointer to a Person who does not exist in the tree is intriguing.)
Once again putting my stupid head on, for me a true Association by definition should never come with up with a Familial relationship unless they are on purely for the purposes of creating a DNA Segment map. For me they are mutually exclusive and the familial link should be used unless there is no other alternative.
That subsection with familial associations is from .vcf vCard, rather than .ged GEDCOM. vCard isn’t concerned about re-assembling Families. So familial associations makes sense there.
My bad, by “no direction”, I thought something like should be read “A is the {value} of B” or “A is the {mirror_value} of B”. The association teacher/student or godparent/godchild does not modify the relation itself, just need to know where should we set the information or to know the ‘direction/orientation’ of the association.
About setting uncle or aunt as an association, this is maybe one alternate way to register one relation if we do not know yet who are the parents. e.g., one nephew, witness into his uncle’s event, or an uncle on any nephew’s event. We have an association but no families clearly set, like two individuals associations.
As pointed out by @PLegoux there is maybe an issue on the deep connexion code? It seems to try to guess a “reverse” association via the relationship built-in module, but maybe set the wrong starting person or return the wrong value on this type of relationship (uncle/nephew).
Yes, the relationship descriptor is still confusing for me. Why should we only set a great grandchild and not a second association record for the great grandparent? The choice is not clear. One specific rule or orientation during seizure? We cannot be consistent by filling the same logic (way or direction) during many years with a free form value as relation set. So, if we get the information that A is the great grandson of B and on an other one, we learn that B is the great grandfather of A, this might be that we are living into a perfect world. I am still waiting of such case into my genealogical tree!
The “Check Associations Data” tool states that Jumel Guillaume is Ysel Michel’s uncle[oncle] (which is the case),
I generated this tool for having a list of values for our associations records. It only displays a quick comparison tab. We get the association record via serialization! So, the textual value should be correct for the person set.
@PLegoux I did an experiment and the problems appears to be a confusing layout in the Check Associations table.
I set both Associations to have the corresponding Association to the other person.
So, the Jumel Guillaume Association would be “Uncle” in the Ysel Michel profile, and the Ysel Michel Association would be “Nephew” in the Jumel Guillaume profile.
The columns are simply out of order for reading in the calculation. The exact same data swapping columns 2 and 4 (with the same header and same value in those columns) reads less ambiguously.
Not certain that it is a layout bug as it is the expected data! I also wondering why @PLegoux cuts the relationship calculation column on this display (screenshot)…
The relationship calculation as a secondary control (column) is not the most important data on the user side for this addon tool. The primary goal was to retrieve pure associations records from user data, as displayed on editors. The feeling of a layout bug might be this secondary test control (column) via the built-in localized relationships handler?
Sure, could be confusing as mixing two different data set or methods. One has been filled by the user and the second one is a simple calculation (or the machine one).
Maybe I also did a mistake on the primary or starting person for the relation. So, there is maybe at least two issues!
Note, there is now a quicker way to check these associations…
for person in people():
for ref in person.references:
row(person, ref.rel, ref.reference)
That works if the relationship can be traced. But I also enter associations to show relationships that are documented but not specific enough to allow me to connect the people through families. For example, an obituary lists children and grandchildren separately, and I can’t tell which grandchildren belong to which children. I add the grandchildren (not connected to any parents) and use associations to connect them to their deceased grandparent.
I patched my version of the tool by changing the column heading “Of” to “Linked Person”.