Common wisdom is that FamilySearch GEDCOM does not support same-sex marriage, but common wisdom is not always right.
The FamilySearch GEDCOM 5.5.1 specification provides brief text definitions of GEDCOM tags in Appendix A Lineage-Linked GEDCOM Tag Definition.
In this appendix, FamilySearch defines the MARR tag this:
MARR {MARRIAGE}:=
A legal, common law, or customary event of creating a family unit of a man and a woman as husband and wife.
The ill-named MARR record isn't a marriage record, but a couple contract record, with marriage as the default relationship type.
The FamilySearch editors provide a narrow definition of marriage,
and to make sure you cannot possibly mistake their intention,
they add their restriction not just once, but twice in the same sentence:
they not only define marriage as between a man and a woman
, but also as between husband and wife
.
This FamilySearch definition is not merely a narrow definition of marriage, the social and legal concept,
but provided as a definition of MARR, the GEDCOM record.
This is incorrect, as the relationship defined by MARR need not be marriage at all!
The MARR.TYPE record (and in practice, the MARR._STAT record too) defines the actual type of the relationship,
with marriage merely being the default.
One of the values used for MARR.TYPE (and MARR._STAT) is NOT MARRIED...
The ill-named MARR record isn't a marriage record, but a couple contract record, with marriage as the default relationship type.
That same appendix contains an equally narrow definition of family:
FAM {FAMILY}:=
Identifies a legal, common law, or other customary relationship of man and woman and their children, if any, or a family created by virtue of the birth of a child to its biological father and mother.
The FamilySearch definition of family is consistent with the FamilySearch definition of marriage. Just like the FamilySearch definition of marriage, the FamilySearch definition of family excludes gay and lesbian couples.
That FamilySearch's definitions of marriage and family exclude gay and lesbian couples is not some accidental oversight.
It's a deliberate restriction, one that FamilySearch has asserted multiple times.
FamilySearch stopped updating GEDCOM many years ago, but they have proposed several proprietary standards as a replacement for GEDCOM since then,
to wit GEDXML (2000), GEDCOM XML (2002) and GEDCOM X (2011).
None of their proposed replacements supports same-sex marriage.
All those FamilySearch standards deliberately define marriage in a way that aims to exclude same-sex marriage.
That FamilySearch's definitions of family excludes gay and lesbian couples is just one problem with those definitions. It is not hard to come up with other objections against FamilySearch's definition of family, and that's because it is hard to define family. Family isn't an elementary concept, but a complex one with multiple meanings.
Luckily, Genealogy does not need a definition of family unit.
That is a quote from the 2010 article Family in Scientific Genealogy,
which introduced the guiding principle that explains why genealogists do not need a definition,
and that it may even be wrong to try and define it anyway:
A genealogist should record what a family was.
A genealogist cannot dictate what a family is.
.
The FamilySearch GEDCOM 5.5.1 specification contains just one definition for each lineage-linked GEDCOM record, and that's the definition in Chapter 2 Lineage-Linked Grammar.
The quoted definitions occur in Appendix A of the GEDCOM 5.5.1 specification, not in the body of that specification, so it is fair to wonder how relevant they are, if at all.
Typically, appendices are for things that aren't truly part of the standard proper.
Appendices are a good place to add some handy quick reference material, that is actually defined by another standard.
The FamilySearch GEDCOM 5.5.1 specification does exactly that; it includes an ANSEL table as Appendix C.
The ANSEL Character Set is defined in another standard (ANSI/NISO Z39.47-1985) by another organisation.
definitionin this appendix, but the phrase
brief descriptioninstead. The FamilySearch GEDCOM 5.5.1 specification contains just one definition for each lineage-linked GEDCOM record, and that's the definition in Chapter 2 Lineage-Linked Grammar.
This is how Chapter 2 Lineage-Linked Grammar of the FamilySearch GEDCOM 5.5.1 specification defines the FAM record:
FAM_RECORD:=
n @<XREF:FAM>@ FAM {1:1}
+1 RESN <RESTRICTION_NOTICE> {0:1)
+1 <<FAMILY_EVENT_STRUCTURE>> {0:M}
+1 HUSB @<XREF:INDI>@ {0:1}
+1 WIFE @<XREF:INDI>@ {0:1}
+1 CHIL @<XREF:INDI>@ {0:M}
+1 NCHI <COUNT_OF_CHILDREN> {0:1}
+1 SUBM @<XREF:SUBM>@ {0:M}
+1 <<LDS_SPOUSE_SEALING>> {0:M}
+1 REFN <USER_REFERENCE_NUMBER> {0:M}
+2 TYPE <USER_REFERENCE_TYPE> {0:1}
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<CHANGE_DATE>> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<MULTIMEDIA_LINK>> {0:M}The FAMily record is used to record marriages, common law marriages, and family unions caused by two people becoming the parents of a child. There can be no more than one HUSB/father and one WIFE/mother listed in each FAM_RECORD. If, for example, a man participated in more than one family union, then he would appear in more than one FAM_RECORD. The family record structure assumes that the HUSB/father is male and WIFE/mother is female.
The preferred order of the CHILdren pointers within a FAMily structure is chronological by birth.
Marriages (and other couple relationships) are asserted by the MARR record.
This MARR record isn't some kind of status indicator, but an event record for the marriage event.
The MARR record does not link to the individuals involved in the marriage, but is subordinate to a FAM (family) record.
The FAM (family) records specifies the make-up of a family, and the MARR record applies to the parents of the family.
The MARR record is one of several FAMILY_EVENT_TYPE_STRUCTURE records,
and that is what shows in the FAM_RECORD definition.
The FAM record uses the FAM.HUSB (husband), FAM.WIFE (wife) and FAM.CHIL records
to link to the INDI (individual) records making up the family.
The referenced INDI records link back to the FAM record
using either the INDI.FAMS (family spouse) or INDI.FAMC (family child) record, as the case may be.
The article Marriage in GEDCOM; No MARR without FAM discusses this awkward design in some detail.
The most obvious way of defining a same-sex couple in GEDCOM is through a FAM record
with either two HUSB links or two WIFE links, but the FamilySearch GEDCOM 5.5.1 specification does not allow that.
The definition of the FAM record contains a restriction on the number of HUSB and WIFE it may contain;
each FAM record may contain no more than one HUSB record, and no more than one WIFE record.
That the specification does not allow multiple HUSB or WIFE record within a single FAM record
may sound like some theoretical objection to using two HUSB records or two WIFE records,
but it is actually a very practical one.
Because it's in the GEDCOM specification, FamilySearch's FAM record with at most one HUSB, and at most one WIFE
has become part in a lot of genealogy software.
Lots of genealogy software will report an error when asked to import a GEDCOM file
that contains a FAM record with either two HUSB links or two WIFE links,
and the software that doesn't report an error is likely to import only the first or the second spouse,
while silently ignoring (failing to import, throwing away) the other one.
The issue isn't that FamilySearch GEDCOM doesn't allow same-sex marriage, the issue is that it does not allow same-sex couples.
It is sometimes said, most notably by vendors of genealogy software that still doesn't support same-sex marriage, that GEDCOM does not allow same-sex marriage. That is true enough, but its neither the exact truth, nor the complete truth.
Marriages are recorded through the MARR record.
The MARR record may have subrecords that identify the age at marriage of the HUSB and WIFE, but these are optional.
The MARR record can actually be used in a gender-neutral way.
The MARR record does not prohibit same-sex marriages.
However, that MARR record is subordinate to a FAM record,
and the FAM record was explicitly designed to exclude same-sex couples.
The issue isn't that FamilySearch GEDCOM doesn't allow same-sex marriage,
the issue is that it does not allow same-sex couples.
The problem isn't a MARR record restriction, but a FAM record restriction.
That is not just a slightly different issue, but a bigger issue as well;
a FAM record restriction is not only inherited by the FAM.MARR record,
but by all the family events defined within the FAM record.
It's a fact that the FamilySearch GEDCOM specification was deliberately designed to exclude same-sex couples. It's another fact that multiple genealogy applications support same-sex couples anyway. Naturally, these applications allow you to import and export such couples via GEDCOM. You might expect that it is done done through some GEDCOM extension, but that's not the case. Interestingly, these applications support same-sex couples in GEDCOM without using any GEDCOM extensions and without violating the FamilySearch GEDCOM standard
This is the Same-Sex GEDCOM Paradox; FamilySearch designed GEDCOM to support opposite-sex couples exclusively, yet genealogy applications are reading and writing Same-Sex GEDCOM files anyway.
I have highlighted more than one GEDCOM inconsistency of the years.
Before highlighting another inconsistency, relevant to the solution of this paradox,
I call attention to a consistency between FamilySearch's definition of marriage,
and their definition of the FAM record (and thus the FAM.MARR record);
both define the gender of the two individuals getting married twice.
The FamilySearch definition of marriage refers to both a man and a woman
and husband and wife
.
The FamilySearch FAM record definition uses both FAM.HUSB and FAM.WIFE records,
that link to INDI records that each define the gender of that individual in their INDI.SEX record.
The relevant inconsistency is that while the FAM.HUSB and FAM.WIFE links are gendered links (links for gendered roles),
the return links from the INDI record to the FAM record are not gendered, but identical for both husband and wife.
There are no distinct FAMH (family husband) and FAMW (family wife) links.
Both husband and wife link back to FAM record through an ungendered INDI.FAMS (family spouse) record.
You specify a same-sex marriage in GEDCOM the same way you specify an opposite-sex marriage.
You specify a same-sex marriage in GEDCOM the same way you specify an opposite-sex marriage;
you define the couple through the FAM record, and then add the marriage to the FAM record.
You specify a same-sex couple in GEDCOM the same way you specify an opposite-sex couple;
you define the couple through the FAM record,
linking one spouse through FAM.HUSB and the other through FAM.WIFE.
That's it.
You might think that when you link FAM.HUSB and FAM.WIFE to two individuals of the same sex,
then surely one of the two links is wrong?
After all, a same-sex marriage consists of two husbands or two wifes, not a husband and a wife, as the FAM structure expects.
LinkingFAM.HUSBandFAM.WIFEto two individuals of the same sex is perfectly valid GEDCOM.
Linking FAM.HUSB and FAM.WIFE to two individuals of the same sex
does violate FamilySearch's intention, but it does not violate the FamilySearch GEDCOM specification!
Linking FAM.HUSB and FAM.WIFE to two individuals of the same sex is perfectly valid GEDCOM.
The FamilySearch GEDCOM definition of the FAM record demands that, if present,
the subrecords FAM.HUSB and FAM.WIFE link to an INDI record - and that is all it demands.
Nowhere in either the syntax or the description do they demand
that FAM.HUSB link to a male individual or that FAM.WIFE link to a female individual.
There is no reason to doubt that FamilySearch meant to demand a gender-restriction.
They tried to put the gender-restriction in there through the HUSB and WIFE roles, and the at-most-one restriction for those.
However, the way the FamilySearch GEDCOM specification is written,
HUSB and WIFE are gendered roles,
and there is no gender-demand for those roles in their specification.
... 0 @I456@ INDI 1 NAME Partner /One/ 2 GIVN Partner 2 SURN One 1 SEX F 1 FAMS @F123@ ... 0 @I789@ INDI 1 NAME Partner /Two/ 2 GIVN Partner 2 SURN Two 1 SEX F 1 FAMS @F123@ ... 0 @F123@ FAM 1 HUSB @I456@ 1 WIFE @I789@ ...
same-sex couple in GEDCOM
assumes
The FAM record definition includes the sentence
The family record structure assumes that the HUSB/father is male and WIFE/mother is female.
.
The usage of the word assumes
instead of demands
would be an odd way of of phrasing a restriction,
but FamilySearch is not phrasing same-sex restriction there.
The entire specification, including that sentence, is aimed at developers, not end-users.
A programmer understands what FamilySearch is saying there;
FamilySearch is saying that there is no need to verify the gender of the linked INDI records.
Report-generating code need not check, but may simply assume
that the HUSB-linked INDI is male or that the WIFE-linked INDI is female,
and use words corresponding to these roles, like father
and mother
.
As the text does not make an exception for GEDCOM readers, GEDCOM readers do need not check gender either.
Whether FamilySearch regrets that they did not demand that
the HUSB-linked INDI is male or that the WIFE-linked INDI is female, is beside the point.
The fact is that they did not, that the specification actually allows
the HUSB-linked INDI to be female and the WIFE-linked INDI to be male.
It makes perfect sense for a GEDCOM reader to perform gender-checks on the INDI records the HUSB and WIFE records link to,
and issue some message when these do not match the suggested role.
However, it is legal to use either gender with either link, so a GEDCOM including a same-sex couple may not be rejected as invalid.
A vendor that wants their genealogy application to reject same-sex couples anyway, has to identify that restriction as an application limitation.
Within GEDCOM, a same-sex marriage in specified in exactly the same way as an opposite-sex marriage.
In GEDCOM, a same-sex marriage in specified in exactly the same way as an opposite-sex marriage.
The use of the predefined HUSB and WIFE roles for couples does not prohibit specifying a same-sex marriage.
Within many genealogy applications, those roles are used for report sentences,
and because of that, quite a few programs are likely to output awkwardly wrong sentences for same-sex couples.
That's unfortunate, but it's more important to correctly document a same-sex marriage as a same-sex marriage, then to get those sentences right.
Smart programs can base the sentences on the actual or legal gender of the partners.
The FamilySearch GEDCOM specification actually allows an individual to be married to themselves!
... 0 @I1@ INDI 1 NAME In /di Vidual/ 2 SURN di Vidual 2 GIVN In 1 SEX U 1 FAMS @F1@ 0 @F1@ FAM 1 HUSB @I1@ 1 WIFE @I1@ 1 MARR Y ...
married to yourself
The FamilySearch GEDCOM specification does not demand that
the HUSB-linked INDI is male or that the WIFE-linked INDI is female,
nor that they point to different INDI records.
The FamilySearch GEDCOM specification actually allows an individual to be married to themselves!
Whether you can marry yourself depends on the law,
and a law that wasn't written to exclude the possibility may well allow it...
Whether marrying yourself makes any sense is something you'd have to ask a lawyer.
Fact is that the GEDCOM specification can already handle that case.
Whether your application can handle it is another question;
the download page linked below provides a tiny test you can use to find out.
Within GEDCOM, a same-sex marriage in specified in exactly the same way as an opposite-sex marriage.
That's how genealogy applications that support same-sex marriage do it.
That it's legal GEDCOM, and does not any GEDCOM extension, makes it highly interoperable.
This straightforward method of specifying same-sex couples in GEDCOM is even compatible with applications that do not support same-sex couples!
This method is so compatible, that you can use it to get applications that do not support same-sex marriage to support same-sex marriage anyway.
The article How to enter a Same-Sex Marriage in PAF discusses the Lie, Export, Correct & Import (LECI) method.
This method is so compatible, that you can use it to get applications that do not support same-sex marriage to support same-sex marriage anyway.
Plenty of genealogy applications import families without checking the gender of the partners.
Applications that do bother to check gender gain the ability to issue an informational message when the individual gender does not match their traditional role.
There is nothing unreasonable about issuing an informational message; most couples are opposite-sex couples, and it is good to be alerted to possible mistakes.
In fact, such messages are even somewhat reassuring regarding the capabilities of the application,
and remind you to double-check that the same-sex couple was imported correctly.
Some applications, such as PAF, will misclassify that the message as an error,
which makes it sound like there is some import problem when there isn't one,
but will otherwise handle import of a same-sex marriage just fine.
This article is, as far as I know, the first article to explain how to specify a same-sex couple in GEDCOM.
However, what it documents and explains is not new, but an already existing practice.
Genealogy applications that support same-sex couples include Ahnenblatt, Brother's Keeper, Family Historian,
MyHeritage Family Tree Builder, Reunion and RootsMagic - and they all do it this way.
The example file MARRMM.GED has a male-male marriage,
the example file MARRFF.GED has a female-female marriage,
and the example file MARRUU.GED has an unknown-unknown marriage.
All these are valid GEDCOM files.
The example file MARRSELF.GED has an individual married to themselves.
This is valid GEDCOM too.
A genealogy application must allow the user to record the facts. A genealogy application should not exclude relevant facts, nor force users to create misinformation by artificially restrict the facts they can enter. Genealogy application must support same-sex couples.
Genealogy applications should follow the existing practice for supporting same-sex couples in GEDCOM. It is used by leading genealogy software, is valid GEDCOM, does not require any GEDCOM extensions, and is more than compatible with most applications that do not support same-sex couples; it even adds that capability to those applications.
Genealogy applications may perform gender-checks on the HUSB and WIFE links,
but should not categorise the existence of a same-sex couple as an error or warning,
but issue an informational message instead.
HUSB and WIFE roles for any user interface text or report sentences,
but either use gender-neutral terms, or rely on the actual gender of the individual -
that's what the application would do anyway, if GEDCOM did not force awkward linkage through a FAM record.
A final note; the Best Practices below recommend always checking whether the HUSB and WIFE links are to the same individual.
Checking whether these two links are the same is a cheap and simple operation, that does not require accessing the linked INDI records at all,
merely comparing the FAM.HUSB and FAM.WIFE line-values.
FAM records in which the HUSB and WIFE link are to the same individual;
export it if its exists, but include checks within the application to prevent accidental creationHUSB- and WIFE-linked INDI records
HUSB and WIFE roles seem reversedHUSB and WIFE links are to different individuals;
if they are to the same individual, issue a strong warningHUSB- and WIFE-linked INDI records
HUSB and WIFE roles seem reversedHUSB and WIFE links are to different individuals;The GEDCOM SEX article discusses the GEDCOM SEX record in detail.
MARR without FAM
Copyright © Tamura Jones. All Rights reserved.