Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Citing parent-child relationships #586

Open
jl5000 opened this issue Jan 15, 2025 · 6 comments
Open

Citing parent-child relationships #586

jl5000 opened this issue Jan 15, 2025 · 6 comments

Comments

@jl5000
Copy link

jl5000 commented Jan 15, 2025

I have been trying to work out the best way of citing the relationship between an individual and their mother and father from a birth certificate. I'm keen to understand if there is a recommended way.

1. Citing from a Family record

0 @F1@ FAM
1 HUSB @FATHER@
1 WIFE @MOTHER@
1 CHIL @I1@
1 SOUR @S1@

Being a record-level citation, it's not really clear what this citation is supporting.

2. Citing from an Individual Association

0 @I1@ INDI
1 ASSO @FATHER@
2 ROLE FATH
2 SOUR @S1@
1 ASSO @MOTHER@
2 ROLE MOTH
2 SOUR @S1@

This one seems the most logical to me.

3. Citing from an Individual Birth event association

0 @I1@ INDI
1 BIRT
2 ASSO @FATHER@
3 ROLE FATH
3 SOUR @S1@
2 ASSO @MOTHER@
3 ROLE MOTH
3 SOUR @S1@

Semantically, this seems to be saying that they are the mother and father of the birth event, rather than the individual.

4. Citing from an Individual Birth event which links to the Family record

0 @I1@ INDI
1 BIRT
2 FAMC @F1@
2 SOUR @S1@

I believe BIRT.FAMC structures are not widely used.

@Norwegian-Sardines
Copy link

Norwegian-Sardines commented Jan 16, 2025

I can only talk from my own experience and usage. Beyond what is written in the GEDCOM Standard I'm not sure this organization (Family Search) can "recommend" a way. If it is in the Standard it could be used, but it may not be support by all applications!

  1. I can't recall the last time I "sourced" anything at the "FAM_RECORD" level. Logically it does not make much sense as it only acknowledges that a source indicated that a family existed, and normally a Source Artifact is usually something that represents an event that occurred to a person(s), but what is a "Family" and how can an event happen to a family?

  2. I never use the INDI.ASSO construct in v5.5.1 GEDCOM for birth parent identification and sourcing. I reserve this for other individual to individual relationships that are not normally supported by GEDCOM. As a genealogist rather than a family historian the INDI.ASSO has limited value, but for a family historian in v5.5.1 GEDCOM (before a fact.ASSO was developed) this was used to indicate all kinds of relationships (such as: named after, birth physician, priest, godparent, slave/master, etc)

  3. I commonly use a Birth Certificate (Source Artifact) to "source" a BIRT event at the event level, but yet to use the ASSO tag to connect that individual to their father and mother in v7 GEDCOM (v5.5.1 GEDCOM does not support an ASSO here!). Using the Source Artifact as part of the event (not the ASSO) is the best way to indicate a "sourced" event. In a v7 GEDCOM application that supports the entire BIRT.ASSO and BIRT.ASSO.SOUR construct you could use your solution, but it is unknown how many applications support this construct when transmitting data.

  4. I think this construct is not within the v5.5.1 or v7.x GEDCOM Standard! The BIRT.FAMC is documented, but the BIRT.FAMC.SOUR is not document.

In v5.5.1 GEDCOM I do the following which is supported in the application I use!

1 BIRT
2 FAMC @F1@
2 SOUR @S1@ 

This indicates the Family (a misuse of the term if the parents never formed a true unit) and the source of the birth information. And I have carried this over to v7.x GEDCOM.

In v7.x GEDCOM Option3 (IMHO) is probably the best solution but support of this construct in current applications is questionable in my mind. For myself, I could reorganized all of my data to support your Option3 (this would avoid the misuse noted above) in a v7.x supported GEDCOM but that would be a lot of work and gain very little.

Your question points out one of the shortcomings of the current GEDCOM design that an individual to individual relationships can take several paths (via ASSO, FAMC or FAMS) and any ASSO relationship requires a ROLE indicator that is enumerated for common international usage but could include unlisted relationships. The ADOP tag has similar questions for best practices.

@dthaler
Copy link
Collaborator

dthaler commented Jan 21, 2025

I'll observe that Option 4 is what is currently in the Technical FAQ for this specific question.
See https://gedcom.io/techfaqs/#how-do-i-provide-a-source-citation-for-a-parent-child-relationship

@dthaler
Copy link
Collaborator

dthaler commented Jan 21, 2025

Discussion in GECOM Steering Committee 21 JAN 2025:

  • The technical FAQ discusses option 1 and 4, along with the issue with option 1. It does not currently discuss options 2 or 3.
  • There is nothing technically wrong with options 2 or 3, but recording an individual's parents using ASSO for FATH or MOTH seems to be rare in the wild. Instead using option 4 is much more common.
  • The spec contains an example where ROLE.MOTH is used under NAME.SOUR.EVEN (not using ASSO), and is used commonly in GEDCOM files we see:
0 @I1@ INDI
1 NAME Mary //
2 SOUR @S1@
3 EVEN BIRT
4 ROLE MOTH
  • The spec currently says "Family structures with more than 2 partners may either use several FAM records or use ASSOCIATION_STRUCTUREs to indicate additional partners." We could augment that with something like "For family structures with 2 or fewer partners, using HUSB, WIFE and CHIL in FAM records are recommended rather than using ASSOCIATION_STRUCTUREs."
  • The spec currently says "individual records are linked to Family records by use of bi-directional pointers. Details about those links are stored as substructures of the pointers in the individual record.
    Other associations or relationships are represented by the ASSO (association) tag." We could augment that with a similar statement.

tychonievich added a commit that referenced this issue Jan 21, 2025
Addresses #586 by saying ASSO "should" not be used where HUSB/WIFE/CHIL/FAMS/FAMC could work
tychonievich added a commit that referenced this issue Jan 21, 2025
* Draft recommendation on ASSO

Addresses #586 by saying ASSO "should" not be used where HUSB/WIFE/CHIL/FAMS/FAMC could work

* Update specification/gedcom-3-structures-1-organization.md

* Update specification/gedcom-3-structures-1-organization.md
@tychonievich
Copy link
Collaborator

#587 adds the recommendations against using ASSO when other structures suffice mentioned in the previous comment

@jl5000
Copy link
Author

jl5000 commented Jan 21, 2025

We should probably distinguish between representing a family relationship and citing a source record for a relationship, and these may not use the same substructure (although it would be ideal if it did).

I think it is well understood that using FAM.HUSB/WIFE/CHIL together with matching INDI.FAMC/FAMS is the primary method for recording these relationships. However I am still not clear on the recommended way to support this with source citations.

In many respects flexibility is good, but when it results in several possible (arguably sub-optimal) ways to cite a fundamental family relationship, I see it as a flaw.

@Norwegian-Sardines
Copy link

1 BIRT
2 FAMC @F1@
2 SOUR @S1@ 

Why is the above code (if the family record contains pointers to the birth parents) not sufficient to indicated the source for a parental relationship?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants