Most genealogy software I’ve seen seems to just mislabel sex as gender, since those I’ve seen only provide male, female and intersex. Would be nice to have a separate gender attribute, and would be even better to have historical versions of attributes so that it can be clearly indicated when a field (like name and gender) change. However, I don’t think the standard GED format is capable of that, considering that it’s a non-hierarchical key-value format, like INI.
Well, adding a new fact type and/or values for GENDER or this new type would be relatively easy but the GEDCOM standard hasn’t been updated since 2003. 2003! GEDCOM’s “GENDER” fact only allows “male”, “female”, and “unknown”.
The GEDOMX format, using XML to define nodes (facts) and values, would be flexible enough to make the updates but I believe it’s still a proposal. Your question sent me on a reading quest. GEDCOMX has a fact type called “GenderChange” to document a change of gender. I saw a proposal for “intersex” but I’m not sure where that stands in implementation either.
I agree SEX and GENDER should be treated separately but I think we’re a few years from an actual implementation.
Does GRAMPS support XML GEDCOM - GEDCOMX - in any (significant) capacity?
As the undermentioned requests:
Please include your Gramps version and Operating System.
I’ve not GRAMPS installed on this OS installation yet.
The 2012 GEDCOMX proposal was never finalized before being announced as superseded by GEDCOM7. (The GEDCOM7 specification on GEDCOM.io site has since back-pedaled on that GEDCOM-X announcement.) Since no standard emerged after the proposal, GEDCOMX support in Gramps never progressed past a submission (GEPS 37) in the Gramps Enhancement Proposal System.
Note that since the GEDCOM7 standard was published in June 2021, adoption has been… negligible. The plugins for import and export of GEDCOM7 or the ZIPped version with Media. (See 0012226: [GEDCOM 7] Support Import & Export of New GEDCOM standard)
Does not fit the typical definition of only Male or only Female
U
Cannot be determined from available sources
This can describe an individual’s reproductive or sexual anatomy at birth. Related concepts of gender identity or sexual preference are not currently given their own tag. Cultural or personal gender preference may be indicated using the FACT tag.
@emyoulation, thanks for such a comprehensive answer. Does GEDCOM7 utilize XML or a comparable format? I dare say that I don’t trust my ability to interpret such a whitepaper as that which is referenced - apologies. It would be a shame otherwise, surely?
Unfortunately, I imagine that that doesn’t encompass the ability to record previous genders? I find that in general, I end-up having to use git to store previous values for this and similar fields, which isn’t ideal.
However, GEDCOM uses a level-based structure with numeric levels and tags to represent hierarchy. Each line starts with a level number, followed by a tag and optional data.
XML doesn’t number the levels. Instead, it uses nested elements with opening and closing tags to represent hierarchy. Elements can contain other elements, attributes, and text content.
Gramps allows usrs to simply key in a new Type to add a Custom Type to Events when none of the pre-defined Types fit the need. Once a Custom Type is added, it is added to the bottom of the pull-down menu of pre-defined types.
Just like GEDCOM-X has facts, you could use GenderChange as an added Custom Type of Event.
@emyoulation, a little off-topic, but (since you’re incredibly knowledgable) if value changes are feasible to implement, why is it that most values do not store their historical values? For instance, address, gender, and name(s) - things frequently changed - appear to solely store their latest version in every GEDCOM client I’ve used (to my knowledge, GRAMPS too).
I see. Apologies for my assumptions - I’m used to working with SGML derivatives. Does that mean that it’s as versatile as the alternatives, merely in a manner that’s perhaps less immediately readable?
Gramps supports recording changing addresses and names over date ranges. (That support has been there for years.) Until Gramps 5.2, Gramps did not consider anything but Male, Female and Unknown genders. It considered those immutable. Although same-sex relationships have been supported for years, the Other gender was only implemented a few months ago in Feb 2024. Our software architect has not made a ruling on how to expand it to recognize a change in gender.
The Gramps XML format is simple to evolve… once a decision is made about how the data structure should be changed. (As you can see in the Gramps XML schema history page.) XML is only a data exchanges format used for import/export/archival. The working structure is a database schema. The Gramps data model has evolved through 20 major revisions since 2001.
GEDCOM is technically is just as simple to change. Except that the policy-making bureaucracy is absurdly resistant to reaching consensus. It required 20 years (1999 to 2019) to move the version 5.5.1 from ‘draft’ status to ‘final release’. And that only happend because their copyright was expiring.
The Gramps gender field combines aspects of both sex and gender. It is used to specify how the researcher wants to display the sex or gender of an individual.
The newly added option of “Other” gives a way describe an individual as neither male nor female. This could be useful where the person is non-binary, intersex or perhaps belongs culturally specific gender group.
To record specific details of sex or gender, I suggest creating “Sex” or “Gender” attributes. The plan is to enhance attributes so that they are time-dependent and similar to Gedcom-X facts.
It is also possible to create a custom event type for Gender Change. A custom type of “Transition” has been suggested in the past.
@Nick-Hall, in my trees, the gender is nominally recorded so that there can’t be doubt about a person, but it’s of very secondary importance to their sex.
That’s because since until recently, there were no technologies that allowed a person of either sex to have a child without the participation of a counterpart (discounting human parthenogenesis) meaning that it allows me to better guess what to research next in a branch.
In this regard, it’s a bit disappointing that they’re not separated, considering that they’re such different aspects. Why is it that the two are conflated by default?
That’s a good idea. Thanks.
It would be really nice if there were simply a “$attribute change” so that every attribute had an attached date. I can’t think of any attribute except the UID and birthday that really is immutable.