FAM.<event>.ASSO, are they one way associations?

[Norwegian-Sardines]

An association points to an individual. So when we record an association to an individual event, for example a birth, we can create a the BIRT.ASSO pointing at the individual local doctor who delivered the child. A back pointer on the doctor’s INDI.ASSO can record all of the children that doctor brought into the world, an interesting bit of trivia!

For a marriage, we can record the priest that married a couple using the FAM.MARR.ASSO to the priest record. However to record on the priest’s record who s/he married we can only point at the parties of the marriage (bride and groom) not the family record that carries the MARR tag, still interesting but requires additional record links to located any detail of the marriage. Complicated by the fact that these individuals could have multiple marriages.

I’m not asking to change the use of the ASSO tag in v7.0, just looking for any additional thoughts on what can be recorded and where to record it for better reporting!

[albertemmerich]

I think we do not need the backward association within the GEDCOM file. It is up to the program to expand the data after import. In case of the priest: The application can collect all callings of this INDI record in marriage events and show them with the priest's data. That is what my application is doing with GEDCOM 5.5.1 and GEDCOM 7.0 input files.
If we include the backward ASSOciations, too, we will have the problem of contradicting data!

[Norwegian-Sardines]

I think we do not need the backward association within the GEDCOM file. It is up to the program to expand the data after import. In case of the priest: The application can collect all callings of this INDI record in marriage events and show them with the priest's data. That is what my application is doing with GEDCOM 5.5.1 and GEDCOM 7.0 input files. If we include the backward ASSOciations, too, we will have the problem of contradicting data!

If an ASSO is created to connect a child to its godfather, why can’t you correctly attach the godfather via ASSO to the child at the same time? Why would you have contradicting data? What happens when an individual is legitimately godfather to two children, and you need to know what children they were godfathers for. A merge from a file that had back pointers would either require you to delete the back pointer or not have all of the correct ASSO for the godfather. THAT would be confusing!

My real issue is with Family Event Association, but your rule would effect all Association!

I think that all links to a structure should also have a back link to the originator in the GEDCOM file! A problem for Family Events.

[albertemmerich]

@Norwegian-Sardines : As my software automatically shows the backward associations, too, in case of double information (association and additionally backward association in GEDCOM file) these associations are shown both, on both sides. It needs to be deleted one of them.
Fortunately I do not know any case of backward association in the thousands of files I have been importing so far.
But I do know files with contradicting HUSB / WIFE / CHIL on one side and FAMS / FAMC on the other side. These will through error messages and need manually correction.

If backward association is entered by user, too, there is a chance of mismatch. Example: I1 is godfather for I2. Then the users corrects this information and modifies in record for I2: I3 is godfather for I2. But he forgets to modify the record I1, this still pointing to I2. So in database we only should have one direction (which is the way in my application), and it does not make sense to double this information for export. Godfather is always entered in the record of the child, together with other data of baptism. I do not have the option of "godchild" in godfather's record...

[Norwegian-Sardines]

If you merged my GEDCOM, all ASSO at the individual level would have back pointers. Godparent to godchild is one example. I don’t use ASSO at the fact level yet, but if a family member witnessed a wedding, sponsored an immigration, was a partner in a business. I would certainly want the back pointer! Forgetting to enter the back pointer should not be an option in my opinion!

[albertemmerich]

Ok, we now know that we have different proposals for associations. There is no new information any more, so we wait for other people to tell their view.

[fisharebest]

If we include the backward ASSOciations, too, we will have the problem of contradicting data!

Agreed 💯

On a related subject, I asked about the redundant INDI…FAM links:
https://groups.google.com/u/0/g/gedcomgeneral/c/8OdZ-creiFs/m/wLfjejOfAAAJ

I still feel that only one of theINDI.FAMS/FAMC and FAM.HUSB/WIFE/CHIL sets of links are needed.

[Norwegian-Sardines]

So I’m wrong to include all backward ASSO pointers! How do you propose to prevent this in the GEDCOM specification? How do you know that the pointer in the ASSO is backward and not the only pointer. Let’s say that you have a priest’s notebook/registry that is a family member and he lists all of the marriages, baptisms, wakes where he was the officiant. How should that be recorded? The entries could appear as backpointers to Albert’s system but they are not!

[Norwegian-Sardines]

If we include the backward ASSOciations, too, we will have the problem of contradicting data!

Agreed 💯

On a related subject, I asked about the redundant INDI…FAM links: https://groups.google.com/u/0/g/gedcomgeneral/c/8OdZ-creiFs/m/wLfjejOfAAAJ

I still feel that only one of theINDI.FAMS/FAMC and FAM.HUSB/WIFE/CHIL sets of links are needed.

If we remove one of the dual pointers INDI <-> FAM, I’d rather remove the INDI pointer and use the Family_Record as a Network Style Junction Record, then I would agree that we should look into how to create a new Junction Record for Associations with connection types that indicate the event of the connector and any other important data.

[fisharebest]

Let’s say that you have a priest’s notebook/registry that is a family member and he lists all of the marriages, baptisms, wakes where he was the officiant.

Since you can only link an ASSO record to an individual (not to a fact/event), then a "backwards" link from the priest to the person baptised/buried can't link to the baptism/burial, only the individual.

"Forward" links (from the baptism/burial to the priest) provide this linkage. You can add the source (priests's notebook) to all these facts/events.

[Norwegian-Sardines]

With ASSO pointer now allowing a void, I can still list all entries in the clergy INDI record, with notes about the persons he married and not have a person in the database, but some married couples will be in the database at some point. If I first entered the clergy data, then later add one or more couples as being married. The void pointer would normally be updated to include the new pointer. You would want it deleted!