As a trial, I entered a mother, father, and child. The relationship between the parents is set to “unmarried”. When I export to GEDCOM 5.5.1, the parents are listed as HUSB and WIFE. This causes, for example, TreeDraw to assume they are married.
Even Gramps on the Relationship page refers to “Ehepartner” (marriage partners).
It is correct to establish a „family“ with HUSB and WIFE. If there is no marriage event in that family it is a partnership. It is wrong to assume that the two persons were married. So you are right. TreeDraw is wrong.
The problem is with the TAGS HUSB and WIFE which is the presumptive of a
marriage whether civil or religious and regardless of sex because it is
regularly the case in single sex marriages one partner verbally becomes
the husband or wife of the other.
It would need these TAGS to be changed to MPART and FPART because
genealogy is based on reproduction and that is usually dependent on a
biological male and biological female being involved.
Cannot see that ever happening when the Standard falls in the domain of
a religious organisation which actively promotes marriage.
phil
HUSB and WIFE are tags without the meaning of spouses. HUSB and WIFE can have any SEX value (M, F, X, U). If there is no marriage event, you cannot assume one exists. Those tags will not be renamed in the GEDCOM standard because it is not backwards-compatible. Genealogy is not based on biological reproduction only. The FAM is used for adoptive families and foster families as well. This is all in line with the GEDCOM standard promoted by FamilySearch, so your remark about them is wrong.
I first started using Personal Ancestral File (PAF) authured by the LDS. It was impossible to add a same-sex couple as a family. I tried tricking the program by adding the couple through a GEDCOM import. All was good until doing a database check & repair. It made the sex change.
When I learned of a second same-sex couple in the family I went looking for a new program and finally migrated to Gramps.
You cannot say that HUSB is equal to the word husband. That is an incorrect assumption. Please read, what the standard says about that tag:
The FAM record was originally structured to represent families where a male HUSB (husband or father) and female WIFE (wife or mother) produce CHIL (children). The FAM record may also be used for cultural parallels to this, including nuclear families, marriage, cohabitation, fostering, adoption, and so on, regardless of the gender of the partners. Sex, gender, titles, and roles of partners should not be inferred based on the partner that the HUSB or WIFEstructure points to.
The individuals pointed to by the HUSB and WIFE are collectively referred to as “partners”, “parents” or “spouses”.
The Standard is a mass of contradictions
“structured to represent families where a male [`HUSB]”
“and female [`WIFE`]”
Then goes politically correct with
“Sex, gender, titles, and roles of partners should not be inferred based
on the partner that the [`HUSB`] or [`WIFE`]structure points to.”
This is pure theology with a nod to the 20th century.
phil
To claim ‘there is no theology’ is historically incorrect.
I think people here should look into the actual history of GEDCOM and its original purpose.
It was never intended to be a ‘gold standard’ for genealogical data modeling; it was designed specifically as a transport format for the LDS Church’s (Latter-day Saints) temple work and their Ancestral File system.
The Ancestral File was the central theological project of the LDS, and GEDCOM was the pipe built to feed it. Its architecture reflects those specific religious requirements, which is why it struggles to map more complex or modern social structures.
Most software developers didn’t adopt it because it was ‘good,’ but because it became a de facto necessity for data portability.
We are essentially still using a 1980s shipping container to move 21st-century data, which is why you see these awkward patches being bolted onto an aging framework.
The GEDCOM standard is rooted in LDS theology by design.
FamilySearch has only recently attempted to modernize it because it became the standard—largely due to industry inertia back when FamilySearch was the only viable gateway to global records for those who couldn’t travel to physical archives.
Calling it ‘open’ now doesn’t change the fact that its DNA was built to serve the Ancestral File and religious ordinances, not universal genealogical science.
It’s not for nothing that I advocate for supporting other Free Open-Source, Open-Data formats alongside it. While Gramps XML in itself is a good standard with wide data support, we need to fully embrace other open standards to ensure interchangeable formats with other humanities research projects and software in related historical research fields, rather than just waiting for GEDCOM to eventually play catch-up.
You are right. My claim was only related to the question how “family” is defined in GEDCOM 7. Your post is completely OK, but a bit off topic.
Is it really a good standard for exchange of genealogical information? Where can I find the formal definition of that standard? Is that standard used outside the Gramps world? Are there examples of digital humanities research projects based on that standard?
Have you even read what I have been writing at all?
Regarding Gramps XML: You are conflating ‘widely adopted’ with ‘technically sound.’ Gramps XML is an open-source schema that is far more capable of representing complex historical reality than GEDCOM ever was. It supports hierarchical places, event sharing, and complex citations without the ‘lossy’ workarounds GEDCOM requires. Both the DTD and RELAX NG Schema for Gramps XML and the database structure are openly available online. In fact, a link to the schema used in an export is always written at the very top of the XML file itself.
Furthermore, Gramps XML has the potential to support even more advanced features for those who need them, without compromising for those who prefer a relatively simple structure for a basic family tree.
And as I have written in my other post:
I advocate for supporting much more commonly used exchange and transport formats alongside it.
And I have been doing this approx. since Gramps 5.0 was in “Public Beta”.
One of the reasons for this is that when the wider research communities—historians, sociologists, and data scientists—see that they can actually export and import high-fidelity data to and from Gramps, the project will attract more people with specialized knowledge.
This includes experts in Python, R, and Julia who currently find GEDCOM too primitive and ‘lossy’ for serious analysis.
By clinging to a 40-year-old theological transport format as the ‘only’ standard, we are effectively locking ourselves out of the modern Digital Humanities ecosystem.
Instead of asking ‘who else uses Gramps XML,’ we should be asking: ‘Why are we still letting a religious extraction format from the 80s dictate the limits of our scientific research?’
And NO, this is NOT off-topic in a discussion about GEDCOM tags as long as it seems people don’t really understand where they come from.
Note: This text was originally drafted in Norwegian, then translated and refined for flow and technical clarity using AI assistance (Google AI).
I can see you guys love a good bundle; I don’t plan to get involved in that. My takeaway from the answers is that GEDCOM has no way to represent that Gramps has specified a relationship between parents as Unmarried. That is a shame, since many millenials and Gen Z at least in my tree consider marriage to be outdated and unnecessary. So GEDCOM is unsuitable for porting my data.
I was also planning to use GEDCOM as the format for archiving data. My tree is meant for posterity and I’m working on passing it on to future gatekeepers of the family history when I’m no longer here. So I could live with the terms HUSB and WIFE as being a quirk of a bygone age if only new software would interpret those labels correctly. Standards are not standards if you change them later.
It’s also a shame that Gramps plays along with LDS by also using the term Spouse (German: Ehepartner) in their interface. That definitely implies that the partners are married. But I realize that’s a separate point.
When it comes to long-term archiving from Gramps, Gramps XML is the superior format. Since it is a well-structured open standard, it will always be relatively simple to write a Python script to transcode it into any future format if needed.
My personal archiving strategy is to store the Gramps XML file alongside the installer for the specific version of Gramps used (e.g., 4.8.x, 5.2.x, 6.x.x, etc.).
Additionally, I maintain a fully synced copy of all my media and source files separately. I intentionally avoid using the ‘Gramps Backup’ (.gpkg) format for long-term storage, as a compressed ZIP archive of that size is much more susceptible to corruption than individual files and raw XML.
Since I manage terabytes of media files, I need them to be accessible for other software as well, such as Zotero, Obsidian, Foam for VSC, Gephi, and Cytoscape. Keeping the media library independent of a proprietary backup container is the only way to ensure interoperability across these different research and analysis platforms.
To bridge the gap between genealogy and professional historical research, I am considering developing a Gramplet-enabled module for both FITS (Flexible Image Transport System) and CIDOC CRM (Conceptual Reference Model).
The goal is to support full export and import, alongside an advanced mapper to and from other structured data formats.
Since this will be a modern, AI-assisted development, it likely won’t fit into the traditional Gramps ecosystem or official repository due to current infrastructure and policy limitations.
No. GEDCOM defines it precisely. The problem is that some genealogical programs do not implement the standard precisely. GEDCOM says: if there is no marriage event in a family, you should name HUSB and WIFE as partners or parents. If Gramps names them spouses, then this is a bug in Gramps. You should open an issue in Gramps and not complain about the standard.
Is father/mother really better than HUSB/WIFE? What do you do when a couple of two female persons adopt a child? Do you make one of the two to “father” or do you add two “mothers”? Where is the list of events that are allowed in a family? I didn’t find it. Where is it defined in the Gramps XML “standard” that unmarried father/mother have to be called partners and not spouses?
It is easy to complain about GEDCOM, but it seems that it is hard to make it better.
Unfortunately you will have to use GEDCOM if you intend to port your
tree to any of the major sites Ancestry, FindMyPast, MyHeritage and just
ignore the garbage that all of them produce.
And using GEDCOM as you long term storage is a whole different debate
phil
CIDOC CRM sounds promising. If you develop a Gramplet to export a family modeled in CIDOC CRM, I will follow you and develop a webtrees custom module to import such a family. Lets see if we can make it better than GEDCOM by defining a network of relationships. Let us use
E67 Birth
E21 Person — for children and biological parents
P96 by mother — relation between birth and mother
P97 from father
E7 Activity oder E8 Acquisition — for adoption or a foster contract
…
We should consider biological, social and legal families. And same sex parents, patchwork families, families with more than two spouses, temporary foster relationships, surrogate mother, rada mother (breastfeeding), and anonymous sperm donor. One difficulty will be the necessary user interface: how to enter and how to present such a flexible relationship network.
That should allow us to model the following scenario as an example. In GEDCOM it is very hard to model this scenario correctly by using FAM, INDI:ASSO, INDI:RESI and NOTE.
James is the result of an assisted reproduction procedure. The sperm donor is Anonymous, the egg donor is Maria, and the surrogate mother who carried the pregnancy is Karen. After James is born, Maria and Josefine adopt him and thereby become his legal parents.
Before this adoption, Josefine had been married to Georg. From that marriage comes Jason, the biological son of Josefine and Georg. Jason lives in the household of Maria and Josefine until his sixteenth birthday. After turning sixteen, he moves to live with his father Georg and Georg’s partner Julia.
Even GraphML would handle that situation without a flinch.
This is exactly the kind of forward-thinking conversation we need! I am glad to see that we agree on the limitations of the INDI/FAM model when faced with the complexity of modern and historical social structures.
The example you provide—James’s birth and adoption—is a perfect use case for CIDOC CRM’s event-centric approach. By using E67 Birth linked to E21 Person through specific properties like P96 by mother and P97 from father, we move from ‘labels’ to ‘evidence-based relationships’. We can finally distinguish between biological, legal, and social roles without hacking the system with notes and custom tags—just as we can with role-based relationships in Gramps today.
Regarding the User Interface (UI) challenge: This is indeed the ‘holy grail’. How do we present a multi-dimensional network to a user used to a 2D tree? I believe the answer lies in layered visualization and contextual role-mapping.
I am very excited about the prospect of a webtrees custom module for this. If we can create a high-fidelity bridge between Gramps and webtrees using a CIDOC-based interchange, we will have done more for genealogical data integrity than GEDCOM has achieved in 40 years.
I must clarify one thing: I am not a professional developer. While I am leveraging AI-assisted coding to build these modules, the process will take time. I will eventually need the community to help review the code—both for technical quality and to ensure everything is original and compliant; otherwise, this remains a personal research project. However, I see it as my mission to prove the concept and convince the community once I have a working prototype.
As soon as I have something drafted, more than a simple idea, I wil make a seperate post about it…
Let’s move genealogy from old theology to newer ontology.”
Note: This text was originally drafted in Norwegian, then translated and refined for flow and technical clarity using AI assistance (Google AI).
Another reason this will take some time is that I am currently upgrading my Research Workstation—replacing my Ryzen 9 3900X with a Ryzen 9 5950X.
This hardware upgrade represents an investment of both time and money, necessitated by an extensive OCR and data extraction project I am currently developing in Python. I am working with a volume of 2,000 to 5,000 historical sources, spanning over 80 years of records.
I planned the CIDOC CRM transcoder as a core part of that project, including a long-term backup archive format built with FITS (Flexible Image Transport System). Handling this level of high-resolution source material and ensuring data integrity across decades of research requires significant local computational power, and I need my ‘data factory’ fully optimized before I finalize these modules.
But, yes, I will of course rearrange the workflow a little and look at the CIDOC mapping as soon as I have managed to get an OpenCV/Tesseract or Kraken solution running. At the moment, I am working on installing Ollama as a server service and getting it to work with Codium and Continue.
