Add FAMC.SOUR

[tychonievich]

As noted in #491, FAMC.SOUR would solve several problems, including some uses in current applications.

That discussion also suggests other places SOUR might be usefully added, such as SEX and ALIA, but did not include examples of applications using them at the time this issue was opened.

[Norwegian-Sardines]

The SEX tag would be enhanced with a SOUR when all we had was a mention of an individual in a bible or other announcement indicating “a baby girl was born” for a couple and nothing else.

[mother10]

People changing gender, can have official documents that prove it. After all, after the change, the new gender has to be officially documented.

[tychonievich]

Thanks for these examples. All are complicated by the SEX structure's definition as "reproductive or sexual anatomy at birth," not about gender identity or sexual preference, leaving me unsure of the right path forward.

• Could we say that the source of a SEX field is the BIRT.SOUR?
• What about people for whom our only source is a census or immigration or military record included a sex entry or because a journal or letter mentioned a brother, sister, uncle, or aunt. Should that be used to set the SEX field, or is that really about gender?
• Is a record of a gender change a source of the previous gender being a SEX?
• Perhaps the "source" of a SEX is the BIRT.SOUR if available, otherwise SEX is assumed to be inferred from gender?

Structures for mutable parallels of SEX, such as gender identity, transition, fluidity and sexual preference, were discussed at length in the 7.0.0 drafting process but given the multiple recent changes in terminology, addition of new concepts, and culturally-specific variants in definition we were not able to define a structure that we had any confidence wouldn't look outdated a few years later. I suspect we'd have the same conclusion if we looked again today, but I also wonder if defining a partial set might be helpful.

I also wonder if SEX should be made a substructure of BIRT, given it's birth-oriented definition?

Sorry that this comment doesn't have a conclusion. Maybe SEX.SOUR is a good addition, or maybe SEX should state that it's source is a BIRT.SOUR; or maybe GENDER should be added to the set of individual_attributes and SEX should state that it's source is BIRT.SOUR if provided, otherwise inferred from GENDER; or maybe INDI.SEX should be moved to INDI.BIRT.SEX, and thus trivially inherit BIRT's SOURs; or maybe something else?

Part of my hesitation to add SEX.SOUR is that every time it has been discussed, examples are raised that are about gender identity, not birth sex. But I suppose that that misunderstanding is intrinsic in the structure itself, whether it has a SOUR or not.

[mother10]

Now you mention it I think INDI.BIRT.SEX and INDI.BIRT.SOUR seem like a good idea. Because at birth there are only 2 "tastes" male or female, as there are only 2 tastes genetically. (hmmm not really there are XYY and XXY, but those are not normal)
So SEX belongs to BIRT only.

And then add another tag GENDER, by default at birth that is the same as SEX. But during live that might change. When it changes there might be a source to prove it. (and a NOTE there too)
In gender we could put all things that are now recognized as gender types. So if GENDER had a TYPE, we could put in there what we know now exists, and if other things come up, the TYPE can be extended.
So INDI.GENDER.TYPE xxxx

I asked that bot for a gender list of today, never realized there were so many:

• Male
• Female
• Non-binary
• Genderqueer
• Genderfluid
• Agender
• Bigender
• Two-Spirit
• Demiboy
• Demigirl
• Gender Non-conforming
• Pangender
• Neutrois
• Androgynous
• Intersex

Hmmm, that would be a long list of TYPE's.
But I think its future proof, would there be more GENDER's we simply add to the TYPE list.
Don't know if the cultural genders you mention fit in this list.

Now what if a record mentions a sister or brother or something. In fact we then talk about GENDER, because it is not at birth anymore most of the time. In earlier days that would be the same as SEX, So we can use that as the SEX too.
So we could fill in SEX and GENDER

But in more recent days, the only thing we are sure of is they talk about GENDER. As we have no idea about the real SEX "Underneath". :)

Would that help?

[Norwegian-Sardines]

First, I'd like to leave "gender identity" out of this discussion for the moment. It is an important subject that needs to be looked at with a different lens!

The concept of "sex at birth" is interesting, but not totally inclusive to all source types. As I indicated previously, we could learn of the birth of a male/female child via a bible, interview, or other means that does not provide a date or place. In GEDCOM v5.5.1 an Event/Attribute could not be asserted without either of the subordinate DATE or PLAC tag as indicated in the following statement:

All GEDCOM lines have either a value or a pointer unless the line contains subordinate GEDCOM lines. In other words the presence of a level number and a tag alone should not be used to assert data (i.e. 1 DEAT Y should be used to imply a death known to have happened but date and place are unknown, not 1 DEAT ).

Therefore, if the bible, interview or other source can't assert a date or place then the BIRT code would look like this:

1 BIRT Y
2 SOUR ...

If we add a SEX subtag would the "Y" still be warranted"? Should be defined!

The concept and use of the term of "Sex assigned at birth" is however still very controversial within the transgender community and among clinicians. Clinicians assign sex according to the external genitalia of a baby. This determination may not fully characterize a person’s chromosomes, hormonal development, or external and internal anatomy. Up to 2% of participants in population based studies have bodies that do not fit the two sex classification, and other people have chromosomal abnormalities that may make external appearance an incomplete characterization of later hormonal development.

What the above means that their is Male/Female and "too hard to determine". Could this be an example of "X" later in life?

I just point this out that the term "Sex assigned at birth" could be in itself too controversial!

[mother10]

@Norwegian-Sardines Now you mention that, I remeber, I forgot where, but there is a group of people where "boys" cannot be determined boys because they dont have penisses, until the age of 12 or 14. Then they develop the outer signs of being a boy.

So yes then it should be: Male/Female/Undertemined/Unknown

[Norwegian-Sardines]

@mother10
Today it is:
{Male | Female | Does not fit the typical definition of only Male or only Female | Cannot be determined from available sources}
{ M | F | X | U }

[tychonievich]

Discussed in steering committee 2 JUL 2024

• We generally like the idea of FAMC.SOUR, but will want to consider its role in 7.1 overall before making a final decision there.
• Conversation about SEX is interesting, but sufficiently separate from the topic from FAMC.SOUR that we recommend it be moved to another issue.

[mother10]

I just thought of something and I will add it here:
Could the PLACE_Structure also have a SOUR?

It might be interesting to have the possibilty to add a picture of an old map, or pictures of an area or a city, to a Place_structure.

If there would be a SOUR added, and when its filled in a GEDCOM for a certain Place, the corresponding program would have the posibility to add a Place description and/or pictures of that place somewhere in a report.

[Norwegian-Sardines]

@mother10

The Source of the <fact>.PLAC would already be established based on the fact, therefore an additional source would not make sense!

However, if GEDCOM implemented some form of the GEDCOM-L “_LOC” extension (as I have noted in other threads) images, including a map, could be associated with the new record type. I’ve implemented the use of this extension in the software I use to also include text associated with the place which could be used to describe the place in a similar way Wikipedia describes places today!

[tychonievich]

Discussed in steering committee 16 JUL 2024

We generally agree with @Norwegian-Sardines: given the current PLAC as a substructure of an attribute or event, the attribute/event's SOUR seems adequate. We also agree that a _LOC-like record should be added to a future version of GEDCOM.

In some cases there are multiple places with the same name, and it is not trivial to distinguish which one is meant by a given source. In these cases incomplete PLAC hierarchies may be used to indicate uncertainty about which location with that name is meant. Reasoning between multiple possibilities like this is a topic that was discussed by the Hypothesis working group, without creating a concrete proposal. If anyone reading this would like to join that working group and discuss how to handle that issue, please either respond here or email [email protected]. Tools like EXID and SOUR inside a location record may be part of that approach.

[tychonievich]

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