Gender Change -- best practices?

[MissouriTraveller]

Hello, everyone. Yes I’m new here – though I’ve been doing this stuff (just for my family) for at least thirty years now (started with Roots III!).

Yesterday, I realized that I needed to account for the recent gender change of a family member. I tried to search for “best practices” for documenting such an event – both here and in other genealogy forums. Found only one discussion on the matter (in the Ancestry message boards); everyone was pretty-much spitballing ideas about it. I’m not sure there is a “best practice” on this matter, so far.

Well, I came up with something. I’d like to share it, so that (a) other bewildered people might be able to use it and (b) others might be able to improve on it. Here goes …

From my POV, the “ideal” database would make “gender” a non-permanent aspect of a person’s record. “M/F from xxxx to yyyy; F/M from yyyy to [zzzz or present-day].” While that may happen someday, it ain’t happenin’ now. So – what to do?

For everyone’s info, the hack I pulled together yesterday, after my search, goes like this:

1. Assign the person the post-change gender (if already in the database, change gender from birth-gender to new gender)
2. In the person’s profile, add a new “fact” that I have created: “Gender Change - Legal Date” (see image, below)

In this case, the “date” I entered was the date on which the court approved the person’s petition. “Place” was the town in which the court is located. “Place details” was the name of the court (the type of court), e.g., “Circuit Court, [name of county]”

In the description, I described the person’s previous status:

“Born male, as [birth name]. Gender changed under law on this date.”

I don’t yet have a Sentence Template for it. Maybe I’ll do that, some day.

This case is simplified by the fact that the person had not already had children. If they had, reports etc could get messy. (“Did this child really have two birth-mothers?”)

I’m open to suggestions for improvement.

[TomH]

@MissouriTraveller

the “ideal” database would make “gender” a non-permanent aspect of a person’s record

I’ve not had to deal with this but I get the difficulty it presents. One’s DNA presumably is constant regardless of gender change so it seems to me that one needs both a time-variable gender identity and a permanent genealogy gender (DNA gender?). I will freely admit that I’ve not explored whether that concept is valid or practical… Meanwhile, your solution sounds sensible for that particular case of no children.

[MissouriTraveller]

Thanks.

One thing I’ve been watching is the feelings of self-worth that surround the concept of “gender identity.”

You talked about “a permanent genealogy gender (DNA gender?).” This seems to be a concept that’s shared among others in the “genealogy world.” In that thread over on the Ancestry forum, one person said, “Genealogy is about genetic relationships.” Therefore, that person said, keep the birth name & gender, and put the change into notes.

However, another person in that thread said, “As a transgender person, to be respectful a note as to the persons real and chosen identity will not cut it.” IOW, to manage “gender” solely as A Matter Of Genetics And DNA shows a lack of respect for the person.

Hmm. Is genealogy truly only about “genetic relationships?” Is DNA truly the only thing that matters, when documenting the history of a family? If so, wouldn’t an adoptive parent be ignored by genealogists – since there is no connection through DNA? Even when the adopted child never encountered the birth parents, and felt that the adoptive parents were his/her “true parents?” (This feels like a reductio ad absurdum argument, doesn’t it?)

Right now, there is no general consensus about the best way to show respect for the feelings of everyone involved. Some are offended that this happens (at all). Others are offended that some people deny that it happens.

ISTM that a decent long-term solution would be – for the database to offer the “time-variable gender identity” that you mentioned. If the gender identity never changes, then that entry can just stay on the single gender. If it does change, then the genealogist can use the feature to document the change.

In the meantime, we muddle on, with hacks and kludges.

(When it comes to giving priorities to those who get offended, I must admit that my own personal preference is to give priority to the offense felt by the person, the subject, themself. Perhaps one might show some respect for the feelings of family members who are/were offended by the change itself, by documenting the fact that those feelings exist/existed. ISTM that the decision not to document a fact (at all) comes out of a decision that the fact merits no respect.)

[MissouriTraveller]

A follow-on remark:

Would “a time-variable gender identity” be an unusual element, in a genealogy database? I’m trying to think of existing “identity” elements that might be “time-variable.”

Some people do have name changes, during their lifetimes. There are some “name” related “facts” that come with dates, including name changes. But those entries don’t show a “time-variable identity,” do they? They don’t change the (single and permanent) name that will show up in the genealogy charts.

[scoobiejon]

I had used the “Name” to show when the change of name of the person in my tree, I then made this new name the Primary name.
My thought on this is that it would probably be easiest if that same fact also included a Gender option that could be used then as the primary gender also. Sorry just trying to think of the easiest way around this.

[MissouriTraveller]

“The ‘Name’” … sorry, which one?

Here are the types of “name” “facts” I see in RM8:

All of these are different from “Primary Name,” which appears everywhere that the subject appears. (I have just noticed BTW that “Primary Name” includes a “date” field. Which can be different from the subject’s date of birth…)

These are the types of “facts” I have for my family member (including the “Gender Change” “fact” I have created):

(Today, I used “Name-Var” as a field in which to record the person’s birth-name (and, in the Description, the birth-gender).)

“A Gender option” … yes, sounds good. However I have noticed that “facts” have only three fields in which to record data: Date, Place, and Description. (See below)

As you can see, “Date” is a one-time thing, not a “started when, and ended when” thing. “Description” is for text, whose content will not be transferred to any entries in any other “facts” about the subject. “Sentence template” can put the text into a structured sentence.

ISTM that adding a “gender” option … might mean adding a completely different field to the nature of the basic “fact” entry. Might be a Big Mucking Deal, in terms of database design.

Hence, my decision to define a separate “Gender Change” “fact.” At least, for now.

[kfunk]

@MissouriTraveller

Is genealogy truly only about “genetic relationships?” Is DNA truly the only thing that matters, when documenting the history of a family? If so, wouldn’t an adoptive parent be ignored by genealogists

Yes, it is about the genetic relationship. Since you brought it up, I do ignore adoptive parents other than noting they adopted someone that has a relationship to me. If someone related to me adopts a child, I note the birth parent’s names, if known, but I don’t go looking for it. I also do not follow the descent of an adopted child that a genetic relative adopts.

As for gender identity, this is something that apparently develops over the life of the person. It is not know at birth. You have two known genders, male or female with a small percentage of the births being hermaphrodites. I am going to enter m, f, or unknown when adding the record. A paper I once read on the NIH.gov website stated there were about 15 observable gender forms, and if someone settles on one of those forms as they grow, then I will note it in notes. However in most cases, I am not going to know that they have settled on some other gender identity, and it really is not relevant to me if they do.

[scoobiejon]

One of the first things that I did when I discovered that RM8 had a date on the names was I changed this person’s info.
I had used the Alternate name and then made that name the Primary name, my person is fairly removed from me so I hadn’t researched it further than saying that the event was done in the early 80s and used an “about” date for the change. If I had needed to research the process, I would have probably gone for an end date.
The part that I don’t have is just the change of gender and that’s the part that I don’t like.
I had thought that when you open the edit person screen and select the Primary name fact, that an option for gender could be added there. Making it the “Primary Gender” at the same time.
I think that you want to include a lot more info than I need to do and so that’s why I was thinking of a more simplistic way.

[kfunk]

@scoobiejon

option for gender could be added there

Easier said than done when there is really no well defined and generally accepted names for the various possibilities and overlap between those genders. For example the term non-binary overlaps pretty much every gender definition other than male and female.

[scoobiejon]

So your positive suggestion to solve this problem is what??

[TomH]

@MissouriTraveller

Here are the types of “name” “facts” I see in RM8

All of the “Name-xxx” fact types are custom ones in your database, not the built-in Name fact type that corresponds to the GEDCOM NAME tag. They cannot use the data entry form of the Name fact, only that of an event so the name must be entered in the Description field. Nor can they be elevated to become the Primary Name because they are not a Name type fact; only the built-in Alternate Name can be.

You’re right about the database design being significantly affected by a time-variable sex property for a person. Currently, a person record is basically one row in a table having columns for UniqueID, Sex, Note and a bunch to register volatile things for display purposes such as ParentID, SpouseID, Color, Relationship… Only one value of Sex can be associated with a person. That field then controls the silhouette shape/colour, and the pronouns used in fact sentences (he/she, him/her, his/hers).

To make Sex time-variable, it would have to be a column in a related but separate table that also carries Date and can have more than one record for a person. The Sentence Template language would have to compare the date of an event to the Sex records in order to pick the appropriate pronouns.

Interchange with other systems is then another issue. GEDCOM does not support date dependent or multiple Sex attributes for a person (maybe there’s some opening in GEDCOM 7 but not before).

I don’t see developers of lineage-linked databases clambering to fill the need because it is so complex. So I think you are doing about the best that can be done within the limitations of current structures.

[TomH]

@MissouriTraveller

Is DNA truly the only thing that matters, when documenting the history of a family?

No, of course not. While genealogy by definition is about blood lines, Family History is about more than genealogy. Adopted children inherit wealth, language, names, associations, experiences, viewpoints - the colour of their lives is greatly affected by their adoptive families. It is said that more than six degrees of genetic separation makes those blood relatives about as closely related to you as a random person on the street. So the culture in which one is raised is a more powerful determinant of affinity with another person than the shared DNA when the DNA linkage is weak.

Lineage-linked databases struggle with the duality of genealogy and family history. I don’t know if there is any one that handles it well, especially while supporting GEDCOM. There is a project called History Research Environment that is attempting to build a software that may do better in this regard but I’m sure it will run into difficulty over the same barriers and is far from beta testing.

[MissouriTraveller]

@TomH

All of the “Name-xxx” fact types are custom ones in your database, not the built-in Name fact type that corresponds to the GEDCOM NAME tag. They cannot use the data entry form of the Name fact, only that of an event so the name must be entered in the Description field. Nor can they be elevated to become the Primary Name because they are not a Name type fact; only the built-in Alternate Name can be.

Ah, now this is a new topic. The “Name-xxx” fact types are “custom ones in your database?” Only the “built-in Name fact” and the “built-in Alternate Name” are built into the database?

That … is a surprise. You see, I did not create those fact-types, or customize my database to add them to it. (Unlike the “Gender Change” fact-type, which I did indeed create a few days ago.) I stumbled across them yesterday, while composing one of my replies and looking at the types of “facts” in my brand-spanking-new RM8 database (converted from my RM7 database, which goes back to my Roots III database). Had never seen them before.

Some of them look downright promising. For example, for some of my Jewish relatives (who have Hebrew names (which I will call “religious names”) as well as “public” or “English” or “American” names).

Now, I’m sure you didn’t use the term “custom [fact-types]” casually. I simply don’t understand how you’re using it. Could you help me understand?

For example, are there perhaps three categories of name-related data elements? Such as,

1. “Built-in fact types” that correspond to GEDCOM tags – and thus are more likely to be seen in other databases too (e.g., Ancestry or Family Search)?
2. “Custom fact types” that do not correspond to GEDCOM tags, that were created by RM programmers, and that are provided along with the “built-in” fact types, with the RM8 software? And, finally –
3. “Custom fact types” that each user might create, ad hoc?

I do see that all of the “name” fact types provided with RM8 have a “yes” check-mark for “include when exporting GEDCOM files.” That said though, I also do recognize that “exporting a GEDCOM file” that has non-standard data elements (“fact types”) could produce a file that other database software might stumble over when they think they are importing “a GEDCOM file.”

[thejerrybryan]

RM has built-in fact type which include the obvious ones such as Birth and Death. You can add additional fact types, sometimes called custom fact types or user defined fact types. It’s not always easy to tell just looking at the facts which are which. I think the only surefire way of knowing the difference is to create a new and empty RM database and look at its fact types. Those will be the built-in ones. Anything else will be custom/user defined.

I believe that there is a one-to-one correspondence between RM’s built-in fact types and standard GEDCOM tags. But as soon as I say that, someone is going to point out an exception. But even if it’s not perfectly one-to-one, it’s pretty close. For example, the RM developers included the Census (family) fact type in RM primarily because of GEDCOM compatibility, not because RM itself needed the fact type.

If you didn’t enter those name type fact types yourself, then you imported them at some point via GEDCOM from some other database. It might have been a GEDCOM you received from a friend or colleague. Or it might have been a GEDCOM you created with some other genealogy software. So even if you weren’t the actual creator, you introduced the name fact types into RM via some sort of import operation at some point.

[MissouriTraveller]

@TomH

While genealogy by definition is about blood lines, Family History is about more than genealogy.

Also interesting! I had not realized that there might be a distinction between these two terms! No doubt this is because I have so little real experience with the field, outside my own little world of my database and my family.

(I suppose the crux of the distinction might be the meaning of “gene” in “genealogy.” Does “genealogy” mean the study of “genes,” as in DNA or “blood lines;” or does it mean the study of “genes,” as in γένος, often used as “clan, house, family?”)

(But, I’ll admit, I’m guessing)

To be sure, bloodlines (genetic connections) are as important to the aristocracy (“is this person the genuine heir to the title of Duke of XX?”) as they are to people who breed horses or dogs. That focus might well lie at the origins of the practice of the craft of genealogy. But I’m just thinking aloud. I’ll shut up now…

[thejerrybryan]

An obvious example of distinction between blood lines and family history is adoptions. Adoptions may or may not even be documented, especially if they took place a long time ago. But children can also be raised by family members other than their biological parents such as aunts and uncles or grandparents. In the event of the death of a biological parent, a child can be raised by one biological parent and one step-parent, often without there being a formal adoption. And there’s always the so-called non-parental event where the purported biological father was not actually the biological father. In modern times, there are all kinds of surrogate situations where even the birth mother is not the DNA mother, etc.

My father’s mother died shortly after he was born. He was fostered for three years by an aunt and uncle. His biological father remarried and he was then raised by his biological father and his stepmother. There was no non-parental event or divorce or anything like that, yet my father had three sets of parents - #1 biological, #2 foster, #3 part biological and part step. That’s family history and I think it needs to be recorded, even though the DNA is also clear.

I have several cousins who were adopted in a variety of different ways. The most obvious is the old adoption agency model where the birth parents are anonymous. The family history needs to be recorded, even though the DNA is very much unknown. And I’m sure I have only scratched the surface of the examples.

[MissouriTraveller]

@thejerrybryan

If you didn’t enter those name type fact types yourself, then you imported them at some point via GEDCOM from some other database.

Wow. I learned something today … about my own database.

I just created several new, empty RM8 files.

• One had no support for LDS or Family Search Family Tree features
• One added support only for LDS features
• One added support only for FS/FT features

All three had only two “fact types” with the word “name” in them:

• Alternate name, and
• Namesake

Wow. Cool!

Thinking back – way back – I think I did do a GEDCOM import, I think from some public “family tree” (generic term, here) site that seemed to have info about my family. (This was decades ago BTW and I’m still struggling to clean up gaffs and glitches from my uncritical inclusion of other people’s data into my database!) So, yeah, perhaps all those additional name-related “fact types” might come from that distant event.

Hey, it’s Christmas Eve, but I’ll accept this as a Christmas present! Thank you!

[MissouriTraveller]

@thejerrybryan

An obvious example of distinction between blood lines and family history is adoptions.

Yes indeed.

In fact, adoptions have been A Big Deal among the aristocracy – at least, among some aristocrats, during some time periods. Such as the Roman aristocracy, in the last years of the Republic and the first years of the Empire. If the pater familias had no male heir “of his body,” he could still control where the family’s property and leadership went by adopting the man of his choice as his son. Once that was done, he could name that adopted son as his heir.

This was how the “Julio-Claudian dynasty” handled the succession of the first five Roman emperors, from the death of Julius Caesar in 44 BCE to the death of Nero in 68 CE. (Anyone who wants details can check the Wikipedia article about that dynasty, under that name.)

But – obviously – different people will be interested in different things. Some will be all about the “bloodline.” Others will be all about the family relationships.

And TBH that’s going to be true also about the newly-emerging topic of “gender identity.” Some will care, some will not.

[TomH]

@MissouriTraveller

Only the “built-in Name fact” and the “built-in Alternate Name” are built into the database?

Rather, hard-coded in the program and available to every database. The ones you will have available immediately on creating an ‘empty’ database. Cannot be deleted from the database through the UI.

@MissouriTraveller

are there perhaps three categories of name-related data elements?

1. All the default and custom fact types export to valid GEDCOM tags although RM might violate certain rules. For example, I don’t think it has any support for recognising and exporting Attribute type tags; they all go to custom Event tags. And there may be some misuse of certain tags.

2. I do not think there are any “name-related” custom fact types in the program code but there are many custom tags in a RM export to support features that standard GEDCOM tags cannot. These tag names are prefaced with an underscore “_” which GEDCOM allows for custom tags. Only the Primary Name and Alternate Name fact types are Name-type and they export to the GEDCOM NAME tag, Primary being the first NAME tag for a person in their block.

3. Users cannot create custom Name-type fact types. By Name-type, I mean having separate fields for Prefix, Given, Surname, Suffix. All user-defined custom fact types are Event-type: Date, Place, Description.

Here’s your filtered search on an empty database:

Note that Namesake is an Event-type, despite its label. While Alternate Name uses the [Desc] variable in its sentence template, notice that it is disabled in the Use: area. That’s because programming substitutes the Alternate Name values from Given, Surname et al.

[PJ_Evans]

What I’d probably do is like what I do for an adoption with name change: add an AKA with the new name to the person under the birth parents, and create a new person with the new name under the adopted parents (or birth parents, in the case of gender change) with the new gender and an AKA with the original name.