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

Source of a child-parents relationship #346

Open
dthaler opened this issue Sep 5, 2023 · 4 comments
Open

Source of a child-parents relationship #346

dthaler opened this issue Sep 5, 2023 · 4 comments

Comments

@dthaler
Copy link
Collaborator

dthaler commented Sep 5, 2023

In the individual record we have:

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

and in the family record we have:

+1 CHIL @<XREF:INDI>@                    {0:M}
   +2 PHRASE <Text>                      {0:1}

In neither place can you have a source citation. The only place one can have a source citation is to create a note under the FAMC, and put the source citation under that.

Having sources on this linkage is particularly important when there are multiple possibilities.

@Norwegian-Sardines
Copy link

I understand that in research mode (collecting data but not making conclusions about the data) we may come across multiple possibilities such as two individuals with similar or exact name being born or adopted at the roughly the same time/place thus generating two different “parent families”. This can generate recording issues, such as multiple BIRT tags or the need to create multiple individuals, until a conclusion is made.

Question - Are the tags such as BIRT, ADOP that also contain FAMC connections to the birth/adoption family and have sources not sufficient for managing the source link for a majority (one possibility) of the child to family relationship?

Question - For cases of multiple possibilities what are the possible reasons the would generate this condition? If it is based on multiple birth or adoption sources, would a second/contradictory source better be implemented as an ALIA (second individual)?

Question - Would changing the cardinality of the BIRT.FAMC for multiple possibilities and adding a source subtag to the FAMC be sufficient to implement this condition?

@tychonievich
Copy link
Collaborator

Discussed in steering committee

We agree with @Norwegian-Sardines that you can use an INDI.BIRT.SOUR and INDI.BIRT.FAMC pair to indicate this in 5.5 through 7.0, but do not believe this is commonly done. It is more common to put the source in a FAM.SOUR, where it lacks specificity.

We like adding CHIL.SOUR to 7.1. We like CHIL.SOUR more than FAMC.SOUR because the CHIL expresses child order as well as parent-child relationship and that is something some sources address. We can also add a CHIL @VOID@ with a SOUR when we have a source about an nth-child but not yet an INDI record for it.

We should also add something to the technical FAQ

@Norwegian-Sardines
Copy link

Thanks Luther,

Adding a FAM.CHIL.SOUR and especially a 'FAM.CHIL' @void@ does solve some issues where we have a source that says a couple had more children than we can find actual named references (not allowing us to create an actual INDI record).

We agree with @Norwegian-Sardines that you can use an INDI.BIRT.SOUR and INDI.BIRT.FAMC pair to indicate this in 5.5 through 7.0, but do not believe this is commonly done. It is more common to put the source in a FAM.SOUR, where it lacks specificity.

This may not be common, I do use it and advocate to others using the same software to use this combination as well. I would hope that in the future GEDCOM does not eliminate this use!

dthaler added a commit to FamilySearch/GEDCOM.io that referenced this issue Sep 21, 2023
@tychonievich
Copy link
Collaborator

tychonievich commented Jul 23, 2024

See also #494 which is a closely-related (duplicate?) issue

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

No branches or pull requests

3 participants