Family Historian User Group

Mike

I have had a discussion with support at Calico Pie today about their failure to use the 2 TYPE tag under 1 MARR which is in the 5.5.1 standard (not checked 5.5). This allows the storage of such things as 'Never Married', 'Civil Partnership' or similar against the marriage.

Family Historian currently stores such qualifiers under the custom tag 1 _STAT even though they are entered in the Main window for a Marriage.

They have suggested a convoluted way to also create the 2 TYPE tag.

Next time you do some work on the Export Gedcom plugin could you consider duplicating the 1 _STAT under the marriage to a 2 TYPE. This is not something that will be used by Family Historian but will be used by other programmes, it is the next enhancement I am adding to my Wordpress plugin.

I think that this would be a more appropriate solution rather than Calico's suggestion of a Wish List request. It is another example of how FH fails to meet the gedcom standard that will become more important given current social norms.

The 2 TYPE fact tag is a standard GEDCOM tag with the same specification in both 5.5 and 5.5.1 but it is not very well supported in many products.
c.f. In https://www.gedcomassessment.com/ see Assessments of GEDCOM for 05-IDNO (ID Number) with TYPE.

See existing Wish List Ref 559 Fact Descriptor for Civil Union, two Place Travel, Preferred Occupation, etc. for TYPE tag support, that has many links to related details, and in particular its focus on the Marriage Event which is the example given in the GEDCOM specification! It explains that the TYPE tag is on the All tab, but FH offers few ways of using it.

It is very easy to customise the FAM.MARR.TYPE field into the Spouse section of the Main tab.
Then you can populate it with whatever status you like, and Export Gedcom File needs no changes.
The snag with copying FAM._STAT to FAM.MARR.TYPE on export is that some of the Status values are not rational as a Marriage TYPE Descriptor, i.e. Divorced, Separated, Unknown.
Also, some useful Marriage TYPE Descriptor values such as Civil Partnership or Common Law are not available.
All the above options are well documented in how_to:recording_a_marriage_civil_partnership|> Recording a Marriage/Civil Partnership and probably satisfy your requirements.

Mike

Thanks for your comprehensive reply as always.

I have upvoted the wish list item.

Mike and Colin,

In my opinion, it's wrong to create a MARR record with a subordinate TYPE record of "Never Married" and similar "no marriage occurred" values. The second assertion contradicts the first. So, I agree with Mike's comment that some family status values are not rational as MARR.TYPE values. Some programs do it anyway and it creates various headaches.

A marriage record is not needed to create a family (using the GEDCOM term) and simply omitting a MARR record makes sense in some situations. For example, if the parents had a one-time fling, were never married, and never were true parental partners, there shouldn't be any MARR record. However, capturing such circumstances may present a challenge. Where does one record the information that the parents were never partners?

Civil Partnerships are a different matter in that a marriage-like event may have occurred and the participants either did not want to label the event or their partnership a marriage or were legally unable to do so. I don't think it's perfect to use MARR.TYPE for that circumstance, but it usually works reasonably well and is often the only choice.

FYI:
In FH it is necessary to set the Status to Never married or Unmarried couple so that Reports say the couple had a relationship instead of being married. Otherwise, they insist on saying married even when there is no Marriage Event.

I created a Liaison custom family event in which to capture any known details of such relationships!

JohnnyCee wrote: ↑

05 Feb 2020 16:00

Mike and Colin,

In my opinion, it's wrong to create a MARR record with a subordinate TYPE record of "Never Married" and similar "no marriage occurred" values. The second assertion contradicts the first. So, I agree with Mike's comment that some family status values are not rational as MARR.TYPE values. Some programs do it anyway and it creates various headaches.

A marriage record is not needed to create a family (using the GEDCOM term) and simply omitting a MARR record makes sense in some situations. For example, if the parents had a one-time fling, were never married, and never were true parental partners, there shouldn't be any MARR record. However, capturing such circumstances may present a challenge. Where does one record the information that the parents were never partners?

Civil Partnerships are a different matter in that a marriage-like event may have occurred and the participants either did not want to label the event or their partnership a marriage or were legally unable to do so. I don't think it's perfect to use MARR.TYPE for that circumstance, but it usually works reasonably well and is often the only choice.

John

In that case what is the point of the TYPE tag as a subordinate of MARR? The Gedcom v5.5.1 spec states:

For example, a MARR tag could be subordinated with a
TYPE tag with an EVENT_DESCRIPTOR value of `Common Law.'
1 MARR
2 TYPE Common Law

So even that authors of the standard have a different point of view to you as do I.

Valkrider wrote: ↑

05 Feb 2020 18:59

John

In that case what is the point of the TYPE tag as a subordinate of MARR? The Gedcom v5.5.1 spec states:

For example, a MARR tag could be subordinated with a
TYPE tag with an EVENT_DESCRIPTOR value of `Common Law.'
1 MARR
2 TYPE Common Law

So even that authors of the standard have a different point of view to you as do I.

Colin,

I think you misunderstand my position.

The TYPE value is intended to further classify the parent tag type. The example from the spec creates an instance of a custom event with the TYPE "Common Law". I don't think that's a great use of the MARR tag but given the overall context of how marriages and families work in GEDCOM, it's reasonable.

My issue with "Common Law" is that GEDCOM specifies events as occurring at a particular point in time: "As a general rule, events are things that happen on a specific date."[GEDCOM 5.5.1] That's not true for many partnerships that are called "common law marriages". If we agree that a common law marriage is "where a couple is legally considered married, without that couple having formally registered their relationship in a civil or religious marriage."[Wikipedia] So, unlike a partnership that formally begins with a religious or civil marriage ceremony, a common law marriage usually does not begin with a specific event.

I am more than willing to set aside that relatively minor objection for practical reasons: there is often no other way to record a common law marriage without using the MARR.TYPE combination that doesn't involve sacrificing something important.

A couple that objects to religious or governmental participation in their relationship might call it a "committed partnership" or something like that. If the relationship formally begins with an event (an explicit oral agreement, a party, a handshake, or whatever), then a MARR.TYPE of "Committed Relationship" or similar is fine with me. As with "Common Law", if there is no defined event to mark the formal beginning of the relationship, we probably have to use MARR.TYPE set to "Committed Relationship" but that triggers my same minor objection as above.

"Civil Partnership" is a good value for MARR.TYPE when a couple begins their formal partnership with a civil ceremony. While there may be disagreements from some people on labeling a civil partnership as a type of marriage, that's a religious/political issue that I don't care to debate. For practical reasons, genealogists usually want to treat a Civil Partnership exactly or almost exactly as a relationship that begins with a civil or religious marriage.

The combination that I discommend is using a MARR record with a TYPE that contradicts the purpose of the MARR tag such as "TYPE Not Married". The spec says, "Using the subordinate TYPE tag classification method with any of the other defined event tags provides a further classification of the parent tag but does not change the basic meaning of the parent tag."[GEDCOM 5.5.1, my emphasis] It seems to me that "Not Married" is an attempt to negate the basic meaning of the parent MARR tag. Furthermore, as a practical matter it will probably lead to unexpected outcomes such as charts or reports that imply a couple was married when the person who recorded the data meant to explicitly indicate the opposite. Not good!

The MARR record in GEDCOM is used for an event, not for a status value.

I tend to agree with John.
It's a shame FH chose to create a non-standard Status rather than a custom Family Attribute such as Couple Status that could have Not Married as its value/description and a Date Period such as After 1900.
However, neither GEDCOM 5.5 nor 5.5.1 support custom Family Attributes (FACT) so that would still be non-standard.
They do support custom Family Events (EVEN) but then the TYPE and Date would fail John's criteria.
So what would be the ideal solution for partnerships that are Not Married or are a Common Law Marriage?