New Relationship Status/Event type: Separated

Ideas
1

Feature Request Number: 14211

As outlined on the feature request, it would be useful if, as well as having divorced, annulled and married for relationship events/Civil Union, Married, Never Married, Unknown for Family Status, to have a status or event (perhaps both?) of Separated for couples that are still wed, but no longer live together (Event use case), or couples that were together, but are no longer (Family status use case)

It is present in other family tree software, such as Family Historian 7 and My Family Tree (Chronoplex) as examples.

2

The Relationship Type field in the Family Editor is a custom type field that has a Selector Combo Box. You can simply type “Separated” in that box to add the new type.

Likewise, you can add custom Event types if there are legal filings to record.

3

I appreciate that as an option, and if not accepted I will be choosing that path, as I have done for other matter, but aren’t custom types just empty tags so to speak. By that I mean that it wouldn’t be exportable/readable outside of another Gramps file?

I was proposing something that could bring Gramps into alignment with other family tree softwares

4

Gramps typically exports tags that are compliant with the GEDCOM standard. And Separated is not one of the supported Relationship or Family Event types for GEDCOM 5.5.1 nor even for GEDCOM7 (see section 3.3.1.2 of The FamilySearch GEDCOM Specification)

The GEDCOM import tends to handle importing custom types by writing it into a Note.

What you are requesting is supporting custom tags in nonstandard dialects of GEDCOM. (Which is certainly possible but an bottomless quagmire.) Adapting to the right dialect is a pretty big challenge. (Although there are some interesting proposed ‘sniffer’ code changes for 6.2, the release for this coming Fall. With that code, dialect handling might be more viable as addon pluggins. So the feature request becomes more viable too.)

5

Thank you for providing the GEDCOM Spec. As had seen it applied in multiple softwares (did a wider check, and seems Heredis 2026 also has separated), I had made the assumption that it was an overlooked/not yet implemented GEDCOM 7 type.

makes me wonder how they do theirs. I can only say that My Family Tree they have it as both a RELATIONSHIP_STATUS element, and then separation which gets picked up as a custom event by Gramps when cross importing.

Please how that looks below after importing in (My Family Tree having added the UID, RELATINSHIP_STATUS, separation and CREA elements, the other 3 made in Gramps before I imported into My Family Tree to test)

image
image1629×742 89.6 KB

6

Yes. All GEDCOM tags beginning with an underscore are non-standard (custom) types.

7

The problem is that GEDCOM is an aged, lossy, and limited format not meant for transferring genealogy data in a public or scientific manner. It was created as a clerical transfer format for the legacy LDS Ancestral File system, not as a common-use format for modern research.

This discussion about a “Separated” status is a perfect illustration of why Gramps should not be shackled by this 40-year-old religious submission format. It doesn’t matter if FamilySearch releases a minor “patch” every 10 or 20 years; their updates often make the format even less historically accurate and socially relevant. GEDCOM was never intended for the way we use it today; it only became a “standard” because commercial developers in the 80s failed to collaborate on proper social science or humanities standards.

While GEDCOM might have been “fine” in the era of punch cards, it is woefully inadequate for the depth of data available today. Furthermore, limiting exports to the restrictive “lineage-linked” methodology creates unnecessary bottlenecks for evidence-based research.

In my view, the Gramps XML structure is already one of the best formats for digital humanities research—short of moving to pure Linked Data or Graph databases.

A software as inherently agnostic as Gramps should never limit its internal functions or data model to the constraints of GEDCOM. Support for GEDCOM in Gramps should be treated strictly as a “data subset export”—a feature included only because it remains a “necessary evil”—accompanied by a clear warning that data integrity will be lost when using this export format.

Nothing in Gramps’ internal logic or relationship handling should ever be defined or limited by GEDCOM’s lack of support for real-world historical data. We should prioritize the integrity of our internal model over the limitations of a legacy relic.

—
Note: Denne teksten er skrevet på norsk, basert på tidligere innlegg jeg har skrevet om GEDCOM i dette og andre fora, den er oversatt til engelsk og strukturert av Goggle AI for lesbarhet på engelsk

17

I have no objection to adding “Separation” as a new pre-defined event type. We already use it in the Gedcom and GeneWeb import/export.

We could also add “Separated” to the list of family relationship types. I note the “Engaged”, “Divorced” and “Annulled” are also missing from this list.

We are not bound by the Gedcom standard and can always use custom tags.

18

Pull Request #2338 filed

19

I agreed @ 200 % !!! :+1:
As GRAMPS is an acronyme for Genealogical Research and Analysis Management Programming System and not a GEDCOM editor as many other software like Ancestris, Webtree…

It’s so nice feeling that I’m not alone to think that GEDCOM should be considered as an (old) export protocol and not a “data model”.

20

Coming rather late in this discussion.

I use Family as a “container” for a relationship between two persons, relationship which can end up in new offsprings. This relationship has a legal (?) status, such as Married.

This relationship has a start and an end. They are described by events. Most of the time, the end event is implicit with the death of a participant.

I would not mix the “status” of the relationship with its history (how it started: engagement, marriage, other; how it ended: death, divorce, annulment, other; what happened in between: separation, …). I prefer to neatly separate the events from the “container”.

For me, a Family is a node merging two lines (ancestors), fanning out into new lines (descendants). I see it as rather “static”. The “dynamic” point of view is brought by the Event records.

So, I vote for a new event type of Separation and against a new family type of Separated.

21

I would argue that there is only the need for one Type for Family say the “Joining” everything else is Events whether starting the relationship with Religious ceremonies, Legal Contracts or cohabiting, or indeed the ending of the relationship Divorce, Separation, Mutual Consent, whatever all are Events not Types of Relationship.

Though I suspect that good old GEDCOM would not be happy here.

Visually it is quite handy having the Joining changing colour to reflect the latest or last status or the relationship but that should come from the Events that are currently pertinent to the Joining not an arbitrary selection by whosoever is creating the tree.

phil

22

The Pull request looks really good, and didn’t expect to see the level of expansion from my original idea to include further engaged, annulled to be added, though I welcome them, so thank you Nick for suggesting them. Would suggest only that, much as annulled and divorced represent the end of a union, that there is a broken engagement event, to represent that ending.

Not sure if Betrothal/Broken Betrothal also warrants inclusion, or if such arrangements are to be folded into Engagement.

I am happy though however it is approached, just would be good to see an expansion to the statuses of unions, given the limited options currently present of Civil, Religious, Alternate, Unmarried, and Unknown (by the way, is there a way to force Unmarried before Unknown, or must those options be A-Z?

23

You could use the limits of a date range to indicate a broken engagement.

e.g., Engaged event from 14 Feb 2023 to 11 Dec 2023 (Valentine’s Day to International Breakup Day)

Although having Places at each end of the engagement would be informative.

24

and on the matter of betrothals? are they to be folded into Engagements or will do you feel they warrant being distinct? (just thinking of more historical circumstances were the arrangement of marriage, rather than simply the couple deciding for themselves e.g.)

37

Back to the open question on Betrothal: historically it’s not just an earlier stage of Engagement. A betrothal was often arranged by parents/guardians, sometimes with binding legal or financial consequences, independent of the couple’s own consent - unlike a modern Engagement. An important information.

Suggestion: add Betrothal / Broken Betrothal as predefined types alongside Separation/Separated from PR #2338, as a concrete addition - independent of the broader vocabulary-import discussion.

38

Perhaps Custom Types for Events could have a Grouping capability for types that have a menuing hierarchy?

Or (like the Sync Associations tool) there could be a user-maintained crosswalk file of Custom Types (e.g. My Family Tree:_RELATIONSHIP_STATUS:_SEPARATED in the .ged to Gramps:Family:FamilyRelType:Custom:Separated )

Event types available in Gramps

  1. Life Events
    • 2.1 Adopted
    • 2.2 Baptism
    • 2.3 Birth
    • 2.4 Burial
    • 2.5 Cremation
    • 2.6 Death
    • 2.7 Stillborn
  2. Family
    • 3.1 Alternate Marriage
    • 3.2 Divorce
    • 3.3 Divorce Filing
    • 3.4 Engagement
    • 3.5 Marriage
    • 3.6 Marriage Settlement
    • 3.7 Marriage License
    • 3.8 Marriage Contract
    • 3.9 Marriage Banns
    • 3.10 Annulment
  3. Academic
    • 4.1 Degree
    • 4.2 Education
    • 4.3 Graduation
  4. Legal
    • 5.1 Probate
    • 5.2 Will
  5. Religious
    • 6.1 Adult Christening
    • 6.2 Bas Mitzvah
    • 6.3 Bar Mitzvah
    • 6.4 Blessing
    • 6.5 Christening
    • 6.6 Confirmation
    • 6.7 First Communion
    • 6.8 Religion
  6. Residence
    • 7.1 Census
    • 7.2 Property
    • 7.3 Residence
  7. Travel
    • 8.1 Naturalization
    • 8.2 Emigration
    • 8.3 Immigration
  8. Other
    • 9.1 Nobility Title
    • 9.2 Number of Marriages
    • 9.3 Cause Of Death
    • 9.4 Medical Information
  9. Vocational
    • 10.1 Elected
    • 10.2 Military Service
    • 10.3 Occupation
    • 10.4 Ordination
    • 10.5 Retirement
  10. Custom
  11. Fallback Events
39

Alternatively because I hate multiple embedded drop down lists
From eventtype.py (my version)

    _MENU = [
          [
             _T_("Regularly"), {First displayed on right arrow click)
             [BIRTH, BIRTH_REG, BAPTISM, MARRIAGE, MARR_REG, DEATH, 
DEATH_REG, BURIAL, CREMATION,PROBATE,],
         ],

         [
             _T_("Occasionally"), {Drop down List 1}
             [DIVORCE, MARR_BANNS, MILITARY_SERV, MILT_ATT, EDUCATION, 
DEGREE, GRADUATION,
             EMIGRATION, IMMIGRATION, NATURALIZATION, WILL, RESIDENCE, 
CENSUS, PROPERTY,
             CRIM_CONV, NAME_CHANGE, PASSPORT, HOL_VAC, ANNIV, MEMBER_ORG,],
         ],
         [
             _T_("Rarely"), (Drop down list 2}{Custom being Drop down 
list 3}
             [
             CHRISTEN,
             ADULT_CHRISTEN,
             CONFIRMATION,
             FIRST_COMMUN,
             BLESS,
             BAR_MITZVAH,
             BAS_MITZVAH,
             RELIGION,
             MARR_CONTR,
             DIV_FILING,
             MARR_ALT,
             ENGAGEMENT,
             ANNULMENT,
             MARR_SETTL,
             MARR_LIC,
             OCCUPATION,
             RETIREMENT,
             ELECTED,
             ORDINATION,
             CAUSE_DEATH,
             MED_INFO,
             NOB_TITLE,
             NUM_MARRIAGES,
             ],
         ],
     ]

phil

40

Sounds good. Was just wanting to be sure the intended approach; I personally agree with this idea to split them out, rather than folding the two together for, as we both say, the mechanisms and in practice approach is quite different between it and an engagement.