Many articles treat the words sex and gender as two interchangeable words for the same thing. An example is the original 2017 version of the GEDCOM SEX article. The recently updated version recognises that in current discourse, sex and gender have two related but different meanings, and uses those words accordingly, to avoid confusing readers who expect those two different meanings. Here is how the World Health Organisation (WHO) explains that two different words are for two different concepts:
What is the difference between gender and sex?
Gender interacts with but is different from sex. The two terms are distinct and should not be used interchangeably. It can be helpful to think of sex as a biological characteristic and gender as a social construct. Sex refers to a set of biological attributes in humans and animals. Sex is mainly associated with physical and physiological features including chromosomes, gene expression, hormone level and function, and reproductive and sexual anatomy.
Classic Genealogy (without medical or technological intervention) is fairly simple; everyone has one father and one mother.
While that simple statement can be regarded as the core of genealogy, it does not imply that we have just one father and mother.
We have biological, official and legal parents, and thus a biological, official and legal genealogy.
It is worth noting, that while this is not particularly complex, genealogy software developers already struggle with the difference between official and legal genealogy,
as evidenced by age warnings given for children adopted by younger siblings or the children's grandparents.
Unsurprisingly, every genealogy data standard ever proposed has a sex attribute for individuals
with a choice between at least male and female.
Typically, those standards also recognise that in genealogy, not everyone's sex is known;
GEDCOM supports the values M, F and U for Male, Female and Unknown,
but not every version of GEDCOM does.
Any experience with GEDCOM 5.5.1 import and export will make you believe
that GEDCOM 5.5.1 supports U for Unknown, but that is not exactly true.
FamilySearch GEDCOM's support for sex Unknown is an unbelievable mess.
As detailed in GEDCOM SEX, FamilySearch GEDCOM 3.0 supports U for Unknown, but GEDCOM 4.0 does not,
GEDCOM 5.0 & 5.3 do not, GEDCOM 5.4 does, and GEDCOM 5.5 does not.
Then, to really mess things up, FamilySearch GEDCOM 5.5.1 brought back U,
but tried to redefine its already established meaning (!), something you just cannot do.
Today, even genealogy software claiming to export GEDCOM 5.5.1, actually supportsUmeaningUnknown, as defined in GEDCOM 3.0, GEDCOM 5.4 and GEDCOM 5.5.5.
Issues created by this continual flip-flopping between allowing and not allowing
the sex of individual to be unknown were exacerbated by FamilySearch claiming
that GEDCOM 5.5.1 was merely a draft and GEDCOM 5.5 their latest standard (while using GEDCOM 5.5.1 themselves).
Most genealogy software developers solved these issues by deciding that the FamilySearch GEDCOM 5.5 does support
U for Unknown, in defiance of what the FamilySearch specification says, and later by switching to GEDCOM 5.5.1.
Well, actually by switching to using a mentally modified GEDCOM 5.5.1; GEDCOM 5.5.1, but with U meaning Unknown,
rejecting FamilySearch's attempt to redefine an existing code.
Today, even genealogy software claiming to export GEDCOM 5.5.1, actually supports U meaning Unknown,
as defined in GEDCOM 3.0, GEDCOM 5.4 and GEDCOM 5.5.5.
Support for Intersex in GEDCOM starts with the GEDCOM 5.5.1 Annotated Edition (2018),
which includes an annotation noting that applications should support X for Intersex in addition to M, F and U.
The GEDCOM 5.5.5 Standard (2019) added X for Intersex.
The key to specifying relationships is the MARR.TYPE record.
The FamilySearch GEDCOM specifications may seem to support traditional marriage and exclude all other relationships. Those legacy specifications actually do allow recording relationships other than marriage, but are less than crystal clear about it. The GEDCOM 5.5.5 specification clearly documents how to record relationships, but that clarity is all that is new; the simple technique documented in GEDCOM Relationships was already supported in GEDCOM 5.5.1 and some earlier GEDCOM versions.
The key to specifying relationships is the MARR.TYPE record.
The FamilySearch specifications do not mention this essential technique in the section on the MARR record,
but only the definition of the FAMILY_EVENT_DESCRIPTOR (GEDCOM 5.3)
or EVBNT_OR_FACT_CLASSIFICATION (GEDCOM 5.5.1).
An interesting feature of this technique, that has advantages as well as disadvantages,
is that there is no fixed list of relationships types.
The article and the GEDCOM 5.5.5 specification provide a list of relationship types to get you started,
but it is an open-ended list, and it is explicitly allowed to
record relationship types not mentioned in the specification.
The user has to strike a balance between adding new relationship types to better document some couples,
and using already defined, widely known and understood relationships.
It is possible to support same-sex marriage in GEDCOM, because and GEDCOM allows extensions.
Traditional marriage is marriage between a male and a female. Today, multiple countries allow same-sex marriage, and most genealogy software supports that.
Support for same-sex marriage in genealogy software did not come easy, because FamilySearch does not want to support it.
The FamilySearch GEDCOM specifications do not mention same-sex relationships at all.
Those legacy specifications are written in a way that not only ignores the existence of same-sex relationships,
but even try to define GEDCOM in such a way as to make it impossible to record a same-sex marriage.
Genealogy software developers that did not want to support same-sex marriage
claimed they couldn't support it because GEDCOM does not support it.
It is possible to support same-sex marriage in GEDCOM, because and GEDCOM allows extensions.
Some genealogy software developers added support for same-sex marriage by using GEDCOM extensions.
Eventually developers figured out that although FamilySearch GEDCOM specifications to exclude same-sex relationships,
a careful reading of their specifications actually allows recording same-sex relationships without using any extensions.
The article Same-Sex Marriage in GEDCOM details how it is done in GEDCOM 5.5 and 5.5.1,
and GEDCOM 5.5.5 explicably supports recording same-sex relationships that way.
There have always been intersex people, but recognition of intersex as a sex to be recorded on documents is a fairly recent development. This recognition is in fact so recent that, as far as I know, there is no genealogy software yet that supports it.
As already mentioned, the GEDCOM 5.5.1 Annotated Edition alerted developers to the need to support intersex, and the GEDCOM 5.5.5 standard actually supports it.
Despite the current lack of support for intersex in genealogy software, or perhaps because of it,
some people are confusing intersex with gender,
with mistaken statements such as that the X value is for gay or transgender people.
The GEDCOM 5.5.5 specification is clear; the X is for intersex, nothing else.
Intersex is not a catch-all placeholder for gender, and it is disrespectful to treat it as such.
Genealogy software developers that want to support intersex should not only upgrade their GEDCOM support to version 5.5.5,
they also need to review their application logic, and particularly any consistency checks they do.
Two individuals in a same-sex marriage cannot have children together, but can adopt children (it is still called adoption even if one parent is already an official and legal parent).
An intersex individual can not only marry any other sex, but can have children as either the father or the mother.
The software needs to allow this, and not complain about any inconsistency.
Then again, as far as we know, an intersex individual can only be a parent as either a father or a mother, not both.
Genealogy software may err on the side of caution by allowing it, but should warn that it is highly unlikely.
An intersex person that has multiple marriages (or other relationships) can even marry multiple sexes,
but that situation does seem so unlikely that a consistency warning is helpful.
That gender is part of family history does not imply that genealogist can, should or may ignore gender.
Here's a convenient or inconvenient truth; you can do genealogy without any regard for gender.
After all, gender is a social construct, and as such not part of genealogy, but of family history.
That gender is part of family history does not imply that genealogist can, should or may ignore gender.
Not only are there many genealogists who essentially refuse to recognise
that genealogy and family history are two different things,
genealogy and family history are so interwoven, that genealogy data standards are full of family history stuff.
The GEDCOM specifications supports facts like emigration, immigration, occupation, graduation, and even Social Security Number (SSN).
These facts are not genealogical, but do assist genealogical research, and so does gender information.
Gender is relevant to genealogical research and should be supported by genealogy software and standards.
The idea of multiple genders, different from sex may be new to many people in the western world, but has been around for ages.
The people of Istmo de Tehuantepec region in the Mexican state of Oaxaca recognise male, female and muxes.
Thailand has kathoey.
The Bugis in South Sulawesi recognise five different genders in their society;
makkunrai (male), oroani (female), calalai (females in traditionally male roles),
calabai (males in female roles), and bissu (both male and female).
To ignore gender is to deny the important cultural impact of gender in society.
The significance of gender is not unlike that of castes in a caste system,
which is already supported by genealogy data standards (CAST in GEDCOM).
Gender is relevant to genealogical research and should be supported by genealogy software and data standards.
As far as I know, there is no genealogy software that supports gender yet. A developer that want to support gender has to figure out how to do it without any other software as an example.
There are still applications that seem to confuse sex and gender
simply because the developers still use these two words interchangeable.
Those applications should be updated to always refer to sex as sex
, and never call it gender
.
There is no genealogy data standard that supports gender either. Even GEDCOM 5.5.5, the first GEDCOM version to explicitly support intersex, relationships other than marriage, same-sex relationships, and treat all religions equally, does not feature explicit gender support.
The sex field is for sex, gender belongs in a gender field.
That genealogy software does not support gender has not stopped genealogist from trying to shoehorn it in.
One relatively common and well-meant but seriously mistaken advice is to put gender in the sex field.
The entire point of gender is that isn't sex.
Entering misinformation in your database isn't a solution, it is creating problems.
Besides, the sex field lacks most of the values needed to record gender correctly.
The notion that the INDI.SEX value should be expanded with
the value O for Other reflects the same confusion between sex and gender.
The sex field is for sex, gender belongs in a gender field.
If there is no gender field, you should make one.
non-exhaustive
list of genders.
An obvious issue with user-defined extensions is that, even if they are exported to a GEDCOM file,
a third party application is not likely to recognise & import those extensions.
Software developers and users should try to enter information in records that
will be recognised & imported by third party software,
by taking full advantage of already existing record types that do transfer between applications.
Being able to enter gender and facts related to gender, and not losing that data on transfer to another application is only half the issue. The other half is that application logic needs to take advantage of that data, for example for choosing the pronouns used in reports, and making sure that family chart created for a family reunion uses a person's current name.
An issue for genealogy software developers willing to pioneer support for gender is that gender is a fluid concept.
While there is wide consensus on terminology, there is no such consensus on an exhaustive list of possible gender identities.
The very fact that gender is a social construct may even make it impossible to create a definitive list.
The lack of an exhaustive list for genders is similar to that of relationships types;
there is no definitive or exhaustive list of relationship types either.
This similarity suggests that gender should be recorded using a similar approach;
an open list with a number of predefined values to get you started, that users can extend with other values as necessary.
Custom facts, custom events, and note fields should transfer as a GEDCOMFACT,EVENTandNOTErecords respectively.
0 @I1@ INDI 1 NAME Jan /Doe/ 2 SURN Doe 2 GIVN Jan 1 SEX F 1 BIRT 2 DATE 1 Jan 2000 1 FACT gender 2 TYPE non-binary
Gender in GEDCOM
That GEDCOM does not support gender explicitly does not stop you from entering gender information.
It is certainly possible to define some GEDCOM extension,
but the more practical approach is to take advantage of GEDCOM's support for custom facts and events.
Users of genealogy software can create a custom fact gender
and give it any value they value.
The FACT record was added in GEDCOM 5.5.1 (1999).
Custom facts and events are nearly free-form record types already supported by many genealogy applications.
Custom facts, custom events, and note fields should transfer as a GEDCOM FACT, EVENT and NOTE records respectively.
What's more, a FACT record can have, among other things, a date, a place, notes, source citations and even media attached.
That an individual can choose their gender more than once is no problem either, as an INDI record can have multiple INDI.FACT records.
There is more to supporting gender in genealogy software and recording gender in GEDCOM than discussed here. For example, a gender change will often involve a name change. While the last legal name may often be preferred in charts and reports, the birth name must be recorded; we need the birth name to find the birth record, the name change and other records. Users and developers must figure out when to use which names in which reports, with reasonable default settings and user controls.
This article merely suggests a basic approach to recording gender information in today's genealogy software, in such a way that all the information you entered should survive a data transfer to other geneaiogy software.
FACT and EVENT records
Copyright © Tamura Jones. All Rights reserved.