Modern Software Experience

2017-04-21

This 2017 article was updated in 2023 to reflect that the words sex and gender are no longer used interchangeably. The original text remains available: GEDCOM SEX.

a gender-neutral article

0 HEAD
1 SOUR TJ
2 NAME Tamura Jones
2 VERS 1.0
1 DATE 18 Apr 2017
1 FILE UMF.GED
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
1 LANG English
1 SUBM @SUB1@
0 @SUB1@ SUBM
1 NAME Tamura Jones
0 @I1@ INDI
1 NAME Child /Unknown/
2 SURN Unknown
2 GIVN Child
1 SEX U
1 FAMC @F1@
0 @I2@ INDI
1 NAME Father /Male/
2 SURN Male
2 GIVN Father
1 SEX M
1 FAMS @F1@
0 @I3@ INDI
1 NAME Mother /Female/
2 SURN Female
2 GIVN Mother
1 SEX F
1 FAMS @F1@
0 @F1@ FAM
1 HUSB @I2@
1 WIFE @I3@
1 CHIL @I1@
0 TRLR

UMF.GED

sex

In genealogy, one of the basic attributes of an individual is their sex. Unsurprisingly, GEDCOM has had a sex field since GEDCOM 1.0.

The current de facto GEDCOM standard, GEDCOM 5.5.1 (1999), allows three xex values: male, female, and unknown. The file UMF.GED is a small but complete GEDCOM file that demonstrates use of all three values. The screenshot shows UMF.GED loaded into Personal Ancestral File (PAF) 5.2.18.

UMF.GED in PAF 5.2.18

GEDCOM SEX

In GEDCOM, the sex of an individual is stored in the INDI.SEX record. That record can have only one three values: M for male, F for female, and U for Unknown.
An individual can have only one sex, not two or more. Including a sex is not mandatory but optional; the SEX record is an optional subrecord of the INDI record.
The FamilySearch GEDCOM 5.5.1 specification expresses all that like this:

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female
U =    Undetermined from available records and quite sure that it can ’t be.

{Size=1:7}

There are only three possible line values for an INDI.SEX record, M, F or U. Each one of these three possible values is exactly one character long, yet the specification states the line values may be up to seven characters (code points really) long. Clearly, the FamilySearch GEDCOM specification is wrong, the size of the line value shouldn't be specified as {Size=1:7}, but as {Size=1:1}.

When Louis Kessler mentioned this specification error in his Sex in GEDCOM blog post, more than a year ago, I posted this comment:

You ask, why {size 1:7} if the allowed values are the one-letter values M, F, U? Well, the full words for the possible SEX values are MALE, FEMALE and UNKNOWN, and that last word is 7 letters long. The rest of the explanation is either the usual sloppy FamilySearch editing, or one [of] FamilySearch’s systems actually used the full words…

GEDCOM 4.0

While researching this article I looked at several older GEDCOM specifications, and came across this example GEDCOM file in the GEDCOM 4.0 specification:

0                       HEAD
1                       SOUR        PAF 2.1
1                       DEST        ANSTFILE
0       @1@             INDI
1                       NAME        John Quentin/Doe/
1                       SEX         Male
1                       BIRT
2                       DATE        1836
2                       PLAC        Illinois
1                       DEAT
2                       DATE        24 Oct 1905
2                       PLAC        Idaho Falls, Bonneville, Idaho
1                       FAMS        @4@
0       @2@             INDI
1                       NAME        Mary Ann/Wilson/
1                       SEX         Female
1                       BIRT
2                       DATE        1838
2                       PLAC        Iowa
1                       FAMS        @4@
0       @3@             INDI
1                       NAME        John/Doe/
1                       SEX         Male
1                       BIRT
2                       DATE        11 June 1861
2                       PLAC        Idaho Falls, Bonneville, Idaho
1                       FAMC        @4@
0       @4@             FAM
1                       HUSB        @1@
1                       WIFE        @2@
1                       MARR
2                       DATE        Dec 1881
1                       CHIL        @3@
0                       TRLR
The FamilySearch GEDCOM 5.0 specification contains an example that is illegal according to that same specification.

That same example actually occurs several times within the GEDCOM 4.0 specification. It looks a bit odd. Real GEDCOM files do not contain superfluous spaces. All the extra spaces are there to make the structure of GEDCOM file easier to see.
The truly odd thing about this GEDCOM file is that it has lines saying 1 SEX Male and 1 SEX Female instead of 1 SEX M and 1 SEX F.

GEDCOM 5.0

The FamilySearch GEDCOM 5.0 specification clearly states that these lines should be 1 SEX M and 1 SEX F, yet still contains the same example with the illegal 1 SEX Male and 1 SEX Female lines. The FamilySearch GEDCOM 5.0 specification contains an example that is illegal according to that same specification. That is what genealogy software developers have to deal with; they cannot even trust the examples to be valid GEDCOM.

PAF 2.1?

The GEDCOM header of this example file claims that it is a PAF 2.1 GEDCOM file. I find that hard to believe, as every real PAF 2.1 GEDCOM file I have seen uses 1 SEX M and 1 SEX F, not 1 SEX Male and 1 SEX Female. Moreover, FamilySearch GEDCOM specifications keep using PAF 2.1 as the ostensible source for example GEDCOM files, while there are many other products and newer versions of PAF.

0 HEAD
1 SOUR UNSPECIFIED
1 SUBM @SUBM@
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR ANSEL
0 @SUBMISSION@ SUBN
0 @I1@ INDI
1 NAME Anakin /Skywalker/
2 GIVN Anakin
2 SURN Skywalker
1 SEX Male
1 BIRT
2 DATE 1967
2 PLAC Suffolk, Virginia, USA
1 FAMS @F1@
0 @I3@ INDI
1 NAME Luke /Skywalker/
2 GIVN Luke
2 SURN Skywalker
1 SEX Male
1 BIRT
2 DATE 1995
2 PLAC Chesapeake, Virginia, USA
1 FAMC @F1@
0 @I2@ INDI
1 NAME Padme /Amidala/
2 GIVN Padme
2 SURN Amidala
1 SEX Female
1 BIRT
2 DATE 1967
2 PLAC Chesapeake, Virginia, USA
1 FAMS @F1@
0 @F1@ FAM
1 HUSB @I1@
1 WIFE @I2@
1 CHIL @I3@
0 @SUBM@ SUBM
1 NAME Matt /Harrah/
0 TRLR

gedcom4j example

0 HEAD
1 SOUR Family For Windows
1 DEST GEDCOM File
1 FILE WUTZKE.GED 
1 DATE 05/27/95 
1 CHAR ASCII
0 @00000001@ INDI
1 NAME Christoph/Wutzke/
1 SEX  Male
1 BIRT
2 DATE 01 Jan 0000
1 FAMS @01000004@
1 FAMC @01000005@
0 @00000002@ INDI
1 NAME Dorothea/Ganske/
1 SEX  Female
1 FAMS @01000004@
....
0 @0100000c@ FAM
1 HUSB @0000001e@
1 WIFE @0000001f@
0 TRLR

gedr3495.ged (originally WUTZKE.GED)

0 HEAD
1 SOUR Family For Windows
1 DEST GEDCOM File
1 FILE TRAPP.GED 
1 DATE 09/15/99 
1 CHAR ASCII
0 @00000001@ INDI
1 NAME Luis Gustavo/Trapp/
1 SEX  Male
1 BIRT
2 PLAC Porto Alegre - RS - Brazil 
1 FAMC @01000003@
....
0 TRLR

trapp.ged

Perhaps what's really going on here is that the example code is from another program, and the FamilySearch editors changed the header to make FamilySearch PAF, their own product, the example. Perhaps the example file was actually created by some internal product that uses the full words Male, Female and Unknown instead of the official one-letter values. Perhaps it is for backward compatibility with that product that the specification says to use one-letter values, but allow space for seven characters.

Family for Windows

Anyway, I wondered whether there are any public product that actually use the full words instead of the one-letter abbreviations, and I think I found one! The GenelaogyForum.com has many old user-contributed GEDCOM files, which it presents those as the GEDCOM Library. One of those file is gedr3495.ged (originally WUTZKE.GED), created back in 1995 by Family For Windows. It actually uses 1 SEX Male and 1 SEX Female instead of 1 SEX M and 1 SEX F.
I found another GEDCOM file created by this program, trapp.ged, created back in 1999, on OoCities.org, a GeoCities archive; pages by Luis Gustavo Trapp (lgtrapp).

Neither GEDCOM provides a version number for Family for Windows, nor a GEDCOM version number. In the absence of a GEDCOM version number, mandatory since GEDCOM 4.0, a GEDCOM reader must assume these to be GEDCOM 3.0 or earlier files. The additional lack of a product version number (HEAD.SOUR.VERS record) suggests these are GEDCOM 2.x files.

There is no pressing need for GEDCOM readers to support GEDCOM files like these. Family for Windows is a long-forgotten genealogy application that does not even have an entry in GenSoftReviews, and any user who ever has to import a GEDCOM file like this can easily fix the file with a few search & replace operations.

gedcom4j

There is a current product that needs fixing, the gedcom4j library. The gedcom4j library is ready-made code that Java programmers can use to read and write GEDCOM files. The gedcom4j website has an Example: Creating a GEDCOM from scratch page that creates a GEDCOM file . The example code produces a GEDCOM file that uses 1 SEX Male and 1 SEX Female instead of 1 SEX M and 1 SEX F.
The presence of this error is surprising, but becomes especially stunning when you notice the sentence It also shows how you can use the GedcomValidator to check that your data is ok before writing your file. above the example code that creates the invalid GEDCOM file; apparently, gedcom4j's GEDCOM validator did not catch this error.
By the way, while the poor identification of the GEDCOM source as UNSPECIFIED is conceptually wrong, the inclusion of the submitter record at the end of the file instead of immediately after the GEDCOM header, while unusual, is perfectly legal.

Products that actually write GEDCOM 4.0 files do not follow the GEDCOM 4.0 example.

GEDCOM 4.0

The example in the GEDCOM 4.0 specification uses 1 SEX Male and 1 SEX Female instead of 1 SEX M and 1 SEX F. Products that actually write GEDCOM 4.0 files do not follow the GEDCOM 4.0 example. They do not specify the sex using full words. Products like Ancestral Quest 3.0, Personal Ancestral File 4.0, Reunion 5.0 and Ancestry.com Online Family Tree 1.0 all use the one-letter codes. Every actual GEDCOM 4.0 I've ever seen uses 1 SEX M, 1 SEX F and 1 SEX U.
Apparently, all the vendors who ever added GEDCOM 4.0 support to their product understood the FamilySearch GEDCOM 4.0 specification to be wrong.

Family Historian 6.2

Recall the file UMF.GED shown at the beginning of this article. It is a valid GEDCOM 5.5.1 file that demonstrates all three legal values for the INDI.SEX record.
Personal Ancestral File (PAF) 5.2.18 imports the file without any problems; the PAF import log reports zero errors. Developers often test GEDCOM files with FamilySearch PAF 5.2.18 because it is the closest thing we have to a GEDCOM reference implementation.

GEDCHK, a GEDCOM validator that FamilySearch published on their site, is a rudimentary GEDCOM validator that never made it past version 0.9; it only checks the overall structure of a file, but it does validate line values. There are newer and better GEDCOM validator available. Tim Forsythe's VGED and the Chronoplex's GEDCOM Validator agree that UMF.GED is a valid GEDCOM file. Nigel Button Software's GedPad, GedCom Solutions's Gedcom Explorer, Louis Kessler's Behold, and Tom de Neef's Genealogica Grafica find nothing to complain about either.

However, when I import UMF.GED into Family Historian 6.2.4, it reports an error:

Record Type=Individual. Gedcom Id=I1. Record Number=1.
l.19 - INFO ONLY: Converted invalid GEDCOM tag to valid GEDCOM extension by adding underscore: "1  _SEX U"

Notice that Family Historian complains about line 19, 1 SEX U only, and does not complain about line 25, 1 SEX M or line 31, 1 SEX F.

This is odd. Calico Pie claims that Family Historian features 100% GEDCOM compatibility, yet its GEDCOM import claims to find an error in perfectly valid GEDCOM file, and even suggests using a user-defined GEDCOM extension instead of the standard GEDCOM tag.
Just in case that isn't confusing enough, know that none of the following few brief statements is completely false:

It is wrong for a product to try and import a GEDCOM version it does not support.

Calico Pie is only partially to blame for this confusing state of affairs. The origin of this problem lies with the FamilySearch GEDCOM specification.

0 HEAD
1 SOUR FAMILY_HISTORIAN
2 VERS 6.2.4
2 NAME Family Historian
2 CORP Calico Pie Limited
1 FILE D:\Users\Tamura\Desktop\UMF.GED
1 GEDC
2 VERS 5.5
2 FORM LINEAGE-LINKED
1 CHAR UNICODE
1 SUBM @U1@
1 _UID {E50549A3-79C9-40CB-8043-34A82D808030}
1 _LIST Key Individuals
1 _LIST Work in Progress
1 _LIST Bookmarks
1 _USED I3,F1,N0,S0,R0,U1,B0,O0,P0
0 @I1@ INDI
1 NAME Child /Unknown/
2 GIVN Child
2 SURN Unknown
1 FAMC @F1@
1 _SEX U
0 @I2@ INDI
1 NAME Father /Male/
2 GIVN Father
2 SURN Male
1 SEX M
1 FAMS @F1@
0 @I3@ INDI
1 NAME Mother /Female/
2 GIVN Mother
2 SURN Female
1 SEX F
1 FAMS @F1@
0 @F1@ FAM
1 HUSB @I2@
1 WIFE @I3@
1 CHIL @I1@
0 @U1@ SUBM
1 NAME Tamura Jones
0 TRLR

Family Historian's version of UMF.GED

GEDCOM 5.5

GEDCOM files have a GEDCOM version for reason. It is wrong for a product to try and import a GEDCOM version it does not support.
Family Historian 6.2 does support the UTF-8 encoding, a major GEDCOM 5.5.1 feature, but does not really support GEDCOM 5.5.1 yet.
So, confronted with a GEDCOM 5.5.1 file, Family Historian should inform the user about this major implementation limitation, and refuse to import the file. Family Historian 6.2 actually decides to import the GEDCOM 5.5.1 file as if it were a GEDCOM 5.5 file, and makes that decision silently; the user is not informed about this decision.

Family Historian 6.2 produces that error because it treats the valid GEDCOM 5.5.1 file as a GEDCOM 5.5 file - and if it were a GEDCOM 5.5 file, Family Historian's error message would be technically correct!
You may find this hard to believe, but the GEDCOM 5.5 specification does not allow the INDI.SEX record to have the value U; the specification enumerates the allowed values, and because it only enumerates M and F, the value U is illegal.

Practically every vendor that still supports GEDCOM 5.5 agrees that this is an error in the specification (for reasons discussed below), and allows the value U anyway. Calico Pie prides itself on following the GEDCOM specification to the letter, so Family Historian flags the line 1 SEX U as illegal, and suggests the simplest technically valid workaround to turn the file into a valid GEDCOM 5.5 file; add an underscore to turn the predefined GEDCOM tag into a user-defined GEDCOM tag. That is no random suggestion either, that is what Family Historian 6.2 itself actually does.
Check out Family Historian's version of the UMF.GED file; Family Historian turned a pure GEDCOM 5.5.1 file into a GEDCOM 5.5 file, and replaced one standárd GEDCOM record with a user-defined record.

_SEX

The good thing about using 1 _SEX U (with a leading underscore) instead of 1 SEX U is that it is valid GEDCOM, even under the strictest interpretation of GEDCOM 5.5. The bad thing about it is that most GEDCOM readers simply do not expect that particular user-defined GEDCOM tag at all.
All GEDCOM readers are allowed to ignore unknown user-defined tags, so that is what many of them do; the INDI.SEX line-value will not be used, because there is no INDI.SEX value, and the INDI._SEX that is there instead will not be used either, because the GEDCOM reader does not recognise that particular user-defined tag. The net result is that the record value is lost...

luck

The loss of this record value is a serious issue, or would be, if Calico Pie did not happen to luck out. It just so happens that the value that won't be recognised because Family Historian chooses to use a different tag is the default value for the record. After all, if there is no INDI.SEX record specifying that the individual is male or female, the GEDCOM reader may not assume either one, but must leave it at unknown.
The practical upshot of this is that GEDCOM readers need not add special handling for Family Historian's INDI._SEX record; they just need to make sure that the default sex value is unknown. You still may want your GEDCOM reader to recognise this special case, to issue a brief informatory message once, instead of producing some potentially confusing messages for every occurrence.

5.5.1

Calico Pie is using _SEX (with a leading underscore) instead of SEX to make sure their GEDCOM files are valid, even under the strictest interpretation of GEDCOM 5.5. That's fine, because they are technically correct, and their solution, although different from other vendors, does not create problems. However, the fact remains that Calico Pie should not be using GEDCOM 5.5 anymore, they should be using GEDCOM 5.5.1. and not just because it has been the de facto industry standard for more than decade, but because they care about producing valid GEDCOM files. Family Historian's GEDCOM export dialog box allows the user a choice between several character sets and encodings, and it defaults to UTF-8 now. That is the perfect default, but only for GEDCOM 5.5.1 (or later) files; GEDCOM 5.5 does not allow UTF-8! There is no such thing as a valid UTF-8 GEDCOM 5.5 file; that particular combination is illegal.
GEDCOM 5.5.1 has more benefits over GEDCOM 5.5, including the fact that it explicitly allows the INDI.SEX record to have the value U.

There are two different kinds of unknown sex, but GEDCOM does not distinguish between them.

sex unknown

It is not rare for an individual's sex to be unknown. On the contrary, practically every genealogist has individuals of unknown sex in their genealogy database. An obit may use initials for the names of the children, and records for stillborn children often omit mention of their sex altogether.

These two examples are two different kinds of unknown sex. When we only have initials from an obit, we do not know the sex yet; we will know it once we find the birth record. When we have a record for a stillborn child that does not mention the sex, we will never know it; the information really isn't available. That there may be more information in the obit, that there may be no birth record, and that the child may be mentioned in other records, is all beside the point here. The point is that these are two different kinds of unknown sex. There is not knowing whether there is a sex for the stillborn child in the death record because you have not seen it yet, and knowing that the death record does not mention a sex are two different things. These are two different kinds of unknown, but GEDCOM does not distinguish between them.

Every individual has a sex, but the INDI.SEX record isn't a mandatory record. The INDI.SEX record is an optional record, so there are four possible cases; value M, value F, value U and no value.
So, if FamilySearch had stated, from the very beginning, that value U and the absence of a value correspond to the two different kinds of unknown, GEDCOM would support the two different types of unknown. Because FamilySearch did not do that, and because of things they did do, the value U and the absence of any value mean the same thing: some kind of unknown.

The typical genealogy applications always includes the sex record as part of the individual, and supports just the three values. In fact, genealogy applications may not treat the value U and the lack of a value as different, because FamilySearch did not let them. On the contrary, FamilySearch has forced GEDCOM readers to treat the absence of an INDI.SEX value and the value U as the same thing, by never making the distinction in the first place, and also by not allowing the value U!

New genealogy applications need to be compatible with existing practice, so it is practically impossible to try and impose a distinction between the value U and no value now. A new GEDCOM version could make the INDI.SEX mandatory, leave U the default, and then add the explicit value N for None, together with clear rules about when to use to what.

Update: The GEDCOM 5.5.5 standard, published 2 Oct 2019, not only adds support for intersex(X), but also does distinguish between the two kinds of unkown; U for Unkown, and N for None / No information.

FamilySearch GEDCOM unknown flip-flop

FamilySearch has been flip-flopping on whether the value U is allowed or not.

GEDCOM 1.0

GEDCOM 1.0 is quite different from later GEDCOM files. It seems GEDCOM 1.0 supports the line 1SX M for male, 1SX F for female, and the absence of a value for unknown.

GEDCOM 2.0

Some quick google searches suggest that PAF 2.0, PAF 2.1 and PAF 2.2 do not use 1 SEX U. The PAF 2.1 record description states the sex field may be either M for male, F for female, D for Deleted, blank or null. The Personal Ancestral File GEDCOM Specifications mentions only M and F. The only PAF 2.2 GEDCOM I found that contains the text 1 SEX U at all (gedr7182.ged), contains it in comments that seem to result from importing a GEDCOM file that did contain the 1 SEX U line more than once.

GEDCOM 3.0

GEDCOM 3.0 explicitly supports the value U.


SEX     InId    SEX_CODE         The indicator for male or female. This should be
                                 subordinate information. It contains the codes for
                                 male (M), female (F), or unknown (U) in the value
                                 portion of the record.
                                 
                                 0 INDI
                                   1 NAME Hannibal/Farwell
                                   1 SEX M

GEDCOM 4.0

The GEDCOM 4.0 specification does not provide clear definitions of GEDCOM records. The cited example shows male and female individuals only. The only occurrence of the word unknown is in this sentence: The day and month may be omitted if unknown., so it seems that GEDCOM 4.0 does not allow an individual's sex to be unknown.

The fact that the GEDCOM 4.0 specification contains an example that uses 1 SEX Male and 1 SEX Female instead of 1 SEX M and 1 SEX F, combined with the facts that GEDCOM 3.0 added explicit support for sex unknown and that later specifications state that the line value may be up to seven character long, does suggest that GEDCOM 4.0 meant to support 1 SEX Unknown as well, but the fact remains that it is not in there.

GEDCOM 5.0

GEDCOM 5.0 does not allow 1 SEX U:

INDIVIDUAL_RECORD:=
    n  @XREF:INDI@ INDI                                                         
    ...
      +1  <<INDIVIDUAL>>                                        {1:1}
    ...

INDIVIDUAL:=
    ...
    n  SEX <SEX_VALUE>                                          {0:1} 
    ...

SEX_VALUE:=                                 {Size=1:7, Type=CHARACTERS}
     The following code indicates the sex of the individual:
      M = Male                                                               
      F = Female

GEDCOM 5.3

GEDCOM 5.3 does not allow 1 SEX U:

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female

GEDCOM 5.4

GEDCOM 5.4 explicitly supports sex unknown:

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female
U =    Unknown

GEDCOM 5.5

GEDCOM 5.5 does not allow 1 SEX U:

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female

GEDCOM 5.5.1

GEDCOM 5.5.1 explicitly supports sex unknown:

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female
U =    Undetermined from available records and quite sure that it can ’t be.

GEDCOM 5.6

GEDCOM 5.6 (a draft that surfaced much later) explicitly supports sex unknown too. The relevant sections are identical to those in GEDCOM 5.5.1.

GEDCOM 5.5.5

GEDCOM 5.5.5 explicitly states that an individual's sex is provided by the INDI.SEX record and the INDI.SEX record only, and not implied by the HUSB and WIFE records.
GEDCOM 5.5.5 is also the first GEDCOM version to supports sex unknown and introduced two new INDI.SEX values: X and N.

INDIVIDUAL_RECORD:=
n @@XREF:INDI@@ INDI {1:1}
...
+1 SEX <SEX_VALUE> {0:1}
...

SEX_VALUE:= {Size=1:7}
A code that indicates the sex of the individual:
M =    Male
F =    Female
X =    Intersex
U =    Unknown / Unfound
N =    None / Not recorded

versionSEX U
GEDCOM 1.0N
GEDCOM 2.0N
GEDCOM 3.0Y
GEDCOM 4.0N
GEDCOM 5.0N
GEDCOM 5.3N
GEDCOM 5.4Y
GEDCOM 5.5N
GEDCOM 5.5.1Y
GEDCOM 5.6Y
GEDCOM 5.5.5Y

flip-flop practice

This flip-flopping between allowing sex unknown as a value and not allowing it is less than unprofessional. You cannot keep flip-flopping on the legality of such a basic value, that's plain irresponsible. FamilySearch was wrong to do so, and vendors were right to reject FamilySearch's flip-flopping behaviour.
Vendors were right to decide that a basic value like U cannot be introduced, then made illegal, then legal again, then illegal again, and so on, but that it is legal now, period. Vendors that want to follow the GEDCOM specification strictly, even when it does not deserved to be followed, can adapt their output to the GEDCOM version, by explicitly stating the sex is unknown when it is legal, and omitting the line 1 SEX U when it is not, thus implying sex unknown by the absence of the INDI.SEX record. Many vendors opted for the simplest approach: keep producing that 1 SEX U line, because it makes no sense to for it be illegal.
Family Historian takes a third approach by using the user-defined INDI._SEX record. It's better to simply omit the INDI.SEX record, then to introduce a superfluous user-defined record.

Best Practice

GEDCOM writer

Strict GEDCOM writer

GEDCOM reader

Strict GEDCOM reader

GEDCOM validator

updates

2017-04-21: instant update: UMF.GED available for download

The file UMF.GED is available for download from the Download Family GEDCOMs page.

Z

2023-02-13: sex versus gender

The original article used the words sex and gender interchangeably. The usage of these two words been updated to reflect that nowadays, sex is a biological fact and gender a social construct.

2023-02-13: N supported since GEDCOM 5.5.5

Added remark noting that GEDCOM 5.5.5 (2019) introduced N in addition to U.

2023-02-13: GEDCOM 5.5.5 updates

Added GEDCOM 5.5.5 syntax. Added GEDCOM 5.5.5 to comparison table.

links

 

Copyright © Tamura Jones. All Rights reserved.