# Unmarried parents in GEDCOM **URL:** \ **Category:** Help\ **Tags:** gedcom\ **Created:** [March 2, 2026, 1:07pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183 "2026-03-02T13:07:44Z")\ **Posts on this page:** 11\ **Page:** 2
**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\ **Post date:** [March 4, 2026, 5:56pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/21 "2026-03-04T17:56:58Z")
> [@hartenthaler](#): > > We should consider biological, social and legal families. I like this discussion. I would encourage you to think beyond “families”. Yes, they are needed in order to support import/export with GEDCOM. But if you are trying to create a better standard, why not think differently? One of the fundamental limitations of GEDCOM (and therefore most genealogy software is its bipartite nature of the "nodes – there are individuals, and there are families, and that’s all. Even though the definition of family attempts to allow for modern realities, it is still limited by its structure (separate slots for parents and children). Instead of having a concept of “family” with variations to accommodate different circumstances of biology, society, and legality etc., why not just have a more generic “group” structure? This could also replace one-way “associations” between people. Then you could have a group for biological relations (not simply parent/child, but everyone involved in the conception and gestation), a group for each household that a person lived in (for census records), a group of people who inherited a person’s estate (for probate records), etc. Each type of group could support whatever inter-personal relationships are appropriate for that type of group. Anyway, glad to see some friendly discussion about this. ---
**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\ **Post date:** [March 4, 2026, 8:32pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/22 "2026-03-04T20:32:53Z")
In agnostic formats like **CIDOC CRM** or **GraphML** , the term ‘Family’ is no longer a restrictive container—it’s just another **node**. Because these formats are type- and role-based, a node can represent a nuclear family, a clan, a household, or even a larger civilization-specific grouping. You can have nodes representing groups within groups, or groups connected to multiple families, without ever breaking the underlying data structure. The label ‘Family’ doesn’t limit the logic anymore; the graph handles the complexity of the relationships regardless of how you choose to categorize the collective unit. It’s the **ontology** that provides the flexibility, whereas GEDCOM’s bipartite structure forces you into a specific, rigid mold. ---
**Author:** ![hartenthaler](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/hartenthaler/32/3404_2.png) [@hartenthaler](https://gramps.discourse.group/u/hartenthaler)\ **Post date:** [March 4, 2026, 9:50pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/23 "2026-03-04T21:50:51Z")
Such structures will allow us to build a group of individuals living and working together at a farm. Or working together as colleagues in a company. The superset of individuals of all the farms and houses in a village build the inhabitants of that village. I‘m interested in dynasties of organ builders. There are some trees of students and doctor fathers in mathematics. They are connecting Arab scientists one thousand years ago with recent students. Many new possibilities. ---
**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\ **Post date:** [March 4, 2026, 10:44pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/24 "2026-03-04T22:44:34Z")
Yes, and that is why I write that GEDCOM is a limited and lossy format. In addition, these agnostic formats (like **CIDOC CRM** and **GraphML** ) are able to hold **Main-/Sub-Events** and **Events on Places** , alongside full-fledged **RSC (Repositories, Sources, and Citations)** data. And even though it certainly requires some effort, the **Gramps data structure** can actually support these types of relations and hierarchies today, because its underlying structure is not based on the restrictive **lineage-linked** methodology. If Gramps and other genealogy software would support these types of objects and relations/hierarchies, we could start doing historically correct research… without the need for huge research software packages like **Arches** , **nodegoat** , **ResearchSpace** (from the British Museum), **OpenAtlas** , or **Blue Brain Nexus**. We would have a full offline desktop tool capable of interoperating via an interchangeable format with these massive platforms—tools that often require an engineer to install and set up—even if we only research a subset of what those larger systems can do. ---
**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\ **Post date:** [March 4, 2026, 11:20pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/25 "2026-03-04T23:20:08Z")
> [@hartenthaler](#): > > superset of individuals Groups of groups would be nice. Also heterogeneous groups (containing more than one type of object). See [this earlier discussion](https://gramps.discourse.group/t/sets-in-gramps/924) (in which I called them “sets” rather than “groups”). ---
**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\ **Post date:** [March 9, 2026, 5:48pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/26 "2026-03-09T17:48:35Z")
> [@StoltHD](#): > > ResearchSpace _“ResearchSpace can represent assertions and arguments using CRMInf – the argumentation extension of the CIDOC CRM – and support continual critical analysis to provide quality conclusions that can better inform the present and the future.“_ Sounds like something that might be productive for collaborative genealogy, more so than FamilySearch or WikiTree. > **[Argument & Uncertainty - ResearchSpace](https://researchspace.org/argument/)** > > Record arguments or uncertainty. Transform digital information systems into valuable dynamic environments rather than fragmented tools ---
**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\ **Post date:** [March 10, 2026, 12:03am UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/27 "2026-03-10T00:03:44Z")
> [@GeorgeWilmes](#): > > Sounds like something that might be productive for collaborative genealogy, more so than FamilySearch or WikiTree. **Yes, thanks, George** … \*\*That’s exactly why I have been advocating for open-source open-data interchangeable formats for so long, and why I mentioned it earlier as an example: not because CRMInf or CIDOC CRM is the whole and holly answer for genealogy, but because it shows what becomes possible when data is stored in open, non‑lossy, research‑oriented formats. The fact that it actually is one of the better ontologies for this type of research is just something that has become a really great bonus in my search for this type of “formats”.\*\* What I’m really advocating is simply this: **genealogy tools should support at least one or two export/import formats that preserve _all_ structure and evidence, and that can interoperate with tools outside the genealogy bubble.** Whether that’s JSON‑LD, GraphML, OWL, Markdown, or CIDOC crm and CRMInf doesn’t matter as much as the fact that the data remains complete, mappable, and reusable. And I agree with you, even though I haven’t even got as far as to CRMInf in my readings yet… 🤣 something in that direction could be far more productive for collaborative genealogy than the current lossy or siloed approaches likeGEDCOM, FamilySearch or WikiTree or the vendor locked-in platforms like MyH or Anc., Geni etc. It would finally let genealogical data participate in the wider ecosystem of research tools instead of being locked into a single domain. ---
**Author:** ![hartenthaler](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/hartenthaler/32/3404_2.png) [@hartenthaler](https://gramps.discourse.group/u/hartenthaler)\ **Post date:** [March 15, 2026, 8:44pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/28 "2026-03-15T20:44:45Z")
By the way, there is a proposal under discussion for GEDCOM 8 that might eliminate the “family” (FAM) construct and replace it with more complex concepts (membership in groups). The approach—which is more evidence-based and strongly focused on events—is particularly interesting: > > > \--- > > title: A Gentle Proposal: New Record Types for GEDCOM 8 > author: Tineke Ko…smis > date: Aug 15, 2025 > tags: \[gedcom8, suggestion, structure, sticky, template, asset, group, proof, flex\] > > \--- > > > \## A Structured Event-Based Source System > > \--- > > 🦜 \*A clean structure is a happy structure.\* > 🪶 A gentle proposal — designed to nest in the minds of developers, not ruffle their feathers. > > \--- > > \# A Personal Note Before We Begin > > Back in 1971, when I first started programming, we had no schools or structured learning materials for what we were doing. We simply figured it out — experimenting, failing, trying again. There were no “best practices” — just logic, curiosity, and perseverance. I’ve carried that approach ever since, and it led me, decades later, to take a fresh look at GEDCOM. > > I’ve always found it odd that in GEDCOM, source metadata is so carefully structured — what book, page, archive, etc. — but the actual data from documents gets dumped as one large transcription into a single blob of text. That transcription then gets chopped into pieces and glued to individual persons and facts, often detached from the document context it came from. That never sat right with me. > > One day, I thought: what if we approached this the way forensic teams do — like in CSI movies? They use evidence boards: post-its, strings, scribbled notes, all anchored to specific events and people. I began to imagine little post-its sliding across an invisible whiteboard — grouped, rearranged, then pinned down again. Once I visualized those post-its, the solution came. > > That vision gave birth to STICKY records: a way to preserve and structure document-derived data as it really appears, before it’s scattered across a family tree. Not just metadata, not just conclusions — but the raw material, \*\*kept in context\*\*. > > This whole system didn’t come from a spec sheet. It came from a feeling — a hunch, a sense that something in the process was broken, and that if I could see it clearly, I maybe ould fix it. That’s how I work. Always have. > > This isn’t just about data. It’s about respecting context, improving clarity, and letting software assist human understanding — not just mimic it. I’ve been the odd one out before: a woman in a field of men, a logic-driven person who follows intuition. But I believe GEDCOM can evolve. And I hope this helps a bit to point the way. > > \--- > > \# How this was done: > > Now before diving into the details, I want to explain how this proposal was created — both technically and personally. > It started with the \`STICKY\` idea, nothing more, and I had absolutely no idea at that time, where it would lead me, that it would lead me to all this. But I saw it grow, and it looked beautifull, and it seemed worthwhile, so I kept going. > Countless hours were spent experimenting, building examples, and asking: > \- “Is this the easiest and best way to do this?” > \- "Is this the only and the correct solution?" > \- "Doesnt this make things too complex?" > \- "Could this be programmed in an easy way?" > > Ánd when the answer was "NO", a new search began for a solution that was better. > This is not just a list of technical tweaks; it’s the outcome of deep, hands-on testing, long searches and stubbornly continuing to make the format easier for real genealogists to use — while keeping it rigorous for software developers. > > The tone of this proposal reflects me — sometimes meticulous, sometimes playful, always focused on clarity. If you see humor and beauty here, it’s intentional: real family history is rarely dry, and neither should the examples we use to model it. > > \--- > > \## 🧭 Executive Summary > > This proposal introduces a set of new GEDCOM record types to provide a more structured and flexible approach to source citations, event roles, and document representation. The new records and structures — \`TEMPLATE\`, \`STICKY\`, \`GROUP\`, \`ASSET\`, \`PROOF\`, and \`FLEX\` — are designed to operate \*\*alongside existing GEDCOM 7 records\*\* without breaking compatibility. Together, they form an optional but powerful system for capturing source information in an event-centric, role-aware format. > > \--- > > \## Why GEDCOM 8 Might Need New Structures > > This goes beyond "convenience features" — the new structures solve real modeling problems that GEDCOM 7 simply cannot express cleanly, consistently, or at all. > > \### The Problem > > GEDCOM's biggest strength — and its biggest limitation — is that it's built around \*\*conclusions\*\*. You declare people (\`INDI\`), link families (\`FAM\`), cite sources (\`SOUR\`), and build up a network of logical relationships. That works great for clean trees. But not for messy documents. > > In real-life research, documents don't hand you neat conclusions. They give you messy input: odd names, unclear relationships, strange places. You need space to \*describe\* what's in front of you — before drawing conclusions. > > ✅ \*\*Problem: Unstructured event blobs\*\* > Traditional GEDCOM often reduces a real-life document to a single \`EVEN\` or \`FACT\` tag with scattered \`NOTE\` and \`SOUR\` references. There's no way to model complex roles, shared documents, or assets cleanly. The data ends up flat, unlinked, and ambiguous. > > \*Example:\* A land grant may mention a grantor, grantee, several plots, and legal witnesses — but GEDCOM 7 users must cram that into one \`EVEN\` tag, with disconnected notes or loosely associated sources. > > ✅ \*\*Problem: Repeating participants in multiple roles\*\* > A person appearing in several documents must be described repeatedly, without clear links or context. > > No way to say: > \> "This baptism record, and this marriage record, both refer to this person, but use different names." > > No way to show: > \> "This inheritance record mentions the same asset described in that land record." > > ✅ \*\*Problem: No way to model non-human participants\*\* > GEDCOM lacks a real structure for non-person entities. Assets (land, medals, books, etc.) can't be linked properly across multiple records. > > That’s where these new structures help. They let you \*\*describe the evidence\*\* — document by document, person by person, object by object — and keep the connections alive, even if you don’t yet know who someone “really” is. > > \--- > > \## 🧩 What This Proposal Includes > > This project introduces \*\*five new GEDCOM8 record types\*\* — and one flexible extension — all designed to work alongside the existing \`INDI\`, \`FAM\`, \`SOUR\`, and \`OBJE\` structures. > > \--- > > \## 🍃 TEMPLATE — One Document, One Container > > > TEMPLATE records act as \*\*containers for one event\*\*: a birth, a census, a will, a gravestone. They hold a date, a place, and a set of STICKYs — each one representing a person, object, or group involved. > > Think of a TEMPLATE as a virtual version of the event, often a piece of paper in your hand. > > A single TEMPLATE can link to several STICKYs. Each STICKY has a role — “father,” “child,” “registrar,” “property,” “clan.” And the TEMPLATE brings them all together with a shared context. > > \--- > > \## 🧍 STICKY — One Person (or Thing), One Moment > > > A STICKY record is \*\*a role in a specific context\*\*. Not a person’s full life — just their appearance in one event or document. > > You might have 20 STICKYs all linked to the same person (\`INDI\`) — one from a birth record, one from a marriage, one from a court file. Each one shows \*\*how that person was recorded at the time\*\* — their name, role, place, occupation, sex, and more. > > This preserves the raw data \*\*before\*\* it’s merged into conclusions. And it makes it easier for software to analyze discrepancies or patterns across sources. > > STICKYs can also represent \*\*non-human things\*\* (via ASSET), or memberships in GROUPs. Everything that plays a role in a document gets a STICKY. > > \--- > > \## 🏠 ASSET — One “Thing,” Over Time > > ASSETs are like \`INDI\`, but for \*\*non-human entities\*\*. Think of: > > \- A parcel of land passed through a family > \- A medal awarded to multiple individuals > \- A horse or ship documented in property transfers > > Each ASSET is a stable container, with \*\*STICKY records linked into it\*\*. Over time, these STICKYs show how the ASSET changed: who owned it, where it was, what its status was. > > \--- > > \## 🧑‍🤝‍🧑 GROUP — Named Communities with Join/Leave > > GROUPs represent \*\*named social structures\*\* that people can join, leave, or interact with: > > \- A village council > \- A religious order > \- A rebel faction > \- A sports team > > GROUPs give a name, date, place, and optional attributes. STICKYs link people (or things) into them — showing \*\*how\*\* they were involved, and when. > > \--- > > \## 🔍 PROOF — Describe reasoning and outcome > > The \`PROOF\` record is an \*\*experimental and optional structure\*\* designed to support \*\*reasoning, weighing, and justification\*\* when evaluating competing \`STICKY\` records for use in an \`INDI\` , \`GROUP\` or \`ASSET\` role. > > It has a list of candidate STICKYs, each with ARGUMENTs and OUTCOME. > And a TOPSTICKY designating the chosen STICKY from all ARGUMENTs. > > \--- > > \## 🎛️ FLEX — Clean Representation of Unknown or Nonstandard Fields > > FLEX is a new container that holds \*\*structured values\*\* that don’t map directly to GEDCOM tags — things like: > > \- "Height: 1.73m" > \- "Name uncertain: 'Antonia?'" > \- "Currency: 12 gulden" > \- "Land size: 4 morgens" > \- "Alias: 'Jan de Wit'" > > These are \*\*not extensions\*\* in the traditional sense. FLEX is \*not\* a tag like \`\_MYSILLYTAG\` — it’s a self-contained structure with a type, required \`CONTENTS\`, and human-readable \`PHRASE\`. > > \--- > Continued in next post..... ---
**Author:** ![StoltHD](https://avatars.discourse-cdn.com/v4/letter/s/db5fbb/32.png) [@StoltHD](https://gramps.discourse.group/u/StoltHD)\ **Post date:** [March 16, 2026, 2:58am UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/29 "2026-03-16T02:58:49Z")
GEDCOM is still essentially a remnant of a theological transfer format, designed specifically for LDS temple work. No matter how many ‘groups’ or ‘events’ they try to patch into version 8, the core architecture is still anchored in a 1980s database mindset that was never meant for modern, evidence-based genealogy. Instead of trying to fix a format that was broken from the start, we should be looking at entirely different interchangeable formats. This niche of research needs open-source and open-data formats built for data integrity and complex relationships from the ground up, not another layer of paint on a theological relic. ---
**Author:** ![GeorgeWilmes](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@GeorgeWilmes](https://gramps.discourse.group/u/GeorgeWilmes)\ **Post date:** [March 16, 2026, 7:02pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/30 "2026-03-16T19:02:27Z")
> [@hartenthaler](#): > > might eliminate the “family” (FAM) construct and replace it It sounds like the author’s intent is for the new version 8 features to live alongside of the existing version 7 features, with only a few small changes to existing structures. (And unfortunately, the proposed concept of “groups” does not seem to include events.) But I do like the way she approached the problems. I can’t say whether her solutions are the best, because I don’t know enough about it, but at least it’s a new direction. ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/gramps/original/1X/2ac1e712b7adf612e31ca08a55419f4cf37c0158.png) [@system](https://gramps.discourse.group/u/system)\ **Post date:** [April 15, 2026, 7:02pm UTC](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183/31 "2026-04-15T19:02:54Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed. [Previous page](https://gramps.discourse.group/t/unmarried-parents-in-gedcom/9183.md?page=1)