GEDCOM v8: Things I had hoped would be in v7

[Norwegian-Sardines]

When I first saw that a new GEDCOM v7.0 was about to be published, with help from people that were part of the "BETTERGEDCOM" movement (FHISO) I had hoped that many of the structural changed that we discussed would be present in the new update. Version 7 was for the most part a much needed cleanup of the internal workings of GEDCOM v5.5.1 with limited structural changes. For example, v7 embraced international standards for language tags, media types and data character encoding. GEDCOM file standards remove line length limits ( that simulate flat file constructs), modernizing the data transmission. Tags that allowed both phrases and numeric values have now been Normalized! These are just a few of the changes needed to move GEDCOM forward to a more modern standard.

This being said, GEDCOM v7.x still has many issues that need to be resolved. This is my attempt (open for discussion) to outline some issues that should be looked at for the next major release. I'm not putting these items in an particular order of importance, more of a list as I think of them!

Normalization.

As a database designer I look heavily at the Normalization of data, by this I mean looking at places where data regularly gets duplicated that could be stored in a singular place. The problem of multiple instances of the same data has a profound affect on making changes to a GEDCOM that has been received from another creator where the receiver needs to make a change to all duplicate information but has no way to identify that data. Two such data points come quickly to mind:

1. The Source_Citation structure. Every assertion should cite a Source Artifact as evidence for the assertion. The current GEDCOM model associates the citation data directly with the asserted information ("FACT"). In cases where a single Source Artifact asserts multiple FACTs, each FACT would receive the same citation data. This works well when creating a transmission for the first time, however if the transmission is read into a new application and the citation data needs changes, recreating the list of citations that need the change may be impossible. The Source_Citation structure should have one place that contains a citation data.

2. The Place_Structure (PLAC tag). Each asserted "FACT" could occur at a place in the world. These "places" can be located on a map using Latitude and Longitude coordinates and could be part of the Place_Structure. Since many FACTs can occur at the same place, for data integrity purposes, each occurrence of that place should have the same data. Similar to the Source_Citation above, the initial creation of a GEDCOM can easily generate an identical Place_Structure. However, a imported shared GEDCOM would have issues updating all instances of the same Place_Structure.

Extending the GEDCOM

The current GEDCOM design does not take into account new technology and understandings of some genealogical constructs.

1. Evidence/Citations/Sourcing data in GEDCOM. The current design of GEDCOM has a very basic set of data points that can be used to cite an assertion. The Source_Record and Source_Citation structure are:

• geared toward non-digital Source Artifacts
• incomplete regarding modern citation ("first note") and source list ("biblography") creation. Should we do a hard review of "EE" standard notes/citations?

2. NAME and identity structures taking into account non-western and other customs for international compliance. As we can see by the many queries that ask "How do I enter this name", GEDCOM has an incomplete understanding of the nuances of name use and identities by various cultures both modern and historical.

3. "FACT" (Attributes and Events) additions used in both Genealogy and Family History datasets. This board has been inundated with requests for adding additional tags to represent "FACTs" that various application have used. GEDCOM needs a way to both include more attributes and event tags to the current design but to have a way for applications to add less common or unique to their implementation "FACT" tags.

• The current method of adding a new tag by an application is to introduce an extension (a new tag value preceded by a "_") and asking the application to create an EXID entry with a URL to a site that defines the extension. In some cases these extensions would be minimal and transmission receiving application can easily ignore many of these extensions. However, as it pertains to new "FACT" tags is this still an appropriate use case for an EXID? The problem here arises that the EXID is great information for the application developer but has very little value to the user of the software! The software may drop the new "FACT" tag or flag it as unknown but the user may not have any way to include the tag in their software without an update from the developer which may or may not happen in a timely manor.

• For Example: The data loss for an event such as _MILT ("Military") could make a transmission useless for the receiver! It might be better to create a data-dictionary as part of the GEDCOM transmission for "FACT" extensions that outlines new attributes/events with detail that the reading/importing application can use directly such as display label and a provided description in the data-dictionary could allow the user to understand how to use the data in custom reports.

4. Address_Structure: As pointed out in Tineke's PR some addressing information should have the ability to be associate with a specific individual at a repository. This could be an easy update to the structure, but should be discussed!

5. Deprecation of the Family_Record. This is a radical change that could upset the status quo. But the term "family" may not be valid in the modern world. Should we start modeling person to person relationships rather than connect people to a Family Relationship? This would require some way for relationship ENUM values to be recorded in the GEDCOM as part of a Data Dictionary so that the GEDCOM model does not have to support a never ending list of interpersonal types. This change would also make the FAM.HUSB and FAM.WIFE less of an issue. This change would eliminate pointers in two places, and change the way Associations, Adoptions, Fostering and other concepts are constructed.

6. Create an Accessioning structure. Some people want to tract a photo or other objects that they received from other people or organizations. It would be wrong to call/use the "Source_Record" for this type of information, rather we should provide for an "Attribution" tag or record.

[tychonievich]

Discussed in steering committee 26 AUG 2025

• This discussion prompt covers a variety of topics which would likely result in independent discussions. We've added a few tags to bring it to the attention of existing working groups, but recommend that discussion of specific items above take place in their own github discussion and/or issue.
• We also noted that there is not yet a tag for places, despite several discussions and issues related to them; we plan to add such a tag.
• We did not have time in this steering committee meeting to discuss the specific suggestions above. We plan to do so in future meetings.

[Norwegian-Sardines]

Thank you for your comment.

I created this "discussion" entry because I think several of the proposals have taken us down a path that requires discussion before a proposal is submitted. Some proposals a too big to be one proposal! I also did not want us to forget about these topics, when some new proposals are made that touch on other discussions but do not incorporate those ideas.

I realize planning by committee can be a frustrating process, but I see a need for slow, thoughtful discussion on these topics since many of these changes will be hard to undo in the future if we get them wrong!

[dthaler]

Discussion entries are good. A separate discussion entry per orthogonal topic is even better :)

[Norwegian-Sardines]

I agree and we can certainly create the 8 or so points in my entry. The main thing was, I got tired of the discussions we were having and forgetting about the ones we started 2 or 3 years ago! That is all! 😉

[mother10]

I must say I was very surprised to read this post and the subjects that are in it.

Why? Because many of these points were already addressed in my PR #679, so I don’t quite see why they are being raised again separately. Let me highlight where the overlap is:

• 1: Normalization
  In my PR the whole database design was restructured to be more flexible, extendable, and efficient. The intention was exactly to reduce duplication and scattering, and to make later updates easier to handle.

• 2: Citations
  Redesigned a lot of the citations structure and use, we can now work with a single, consistent version. In fact, citation data is now machine-processable inside the TEMPLATE and its STICKYs. Because of that, I believe we could even reduce the need for a separate CITA in many cases.

• 3: FACTs
  FLEX gives users the ability to define their own facts without having to wait for software vendors to add custom code for every new situation. That’s a big shift — software only has to implement the general mechanism once, and users can fill in the rest.

• 4: Extensions
  Same story here: with FLEX, users have more control, while software doesn’t have to change each time. Instead of _EXT tags with unclear meaning or disappearing external definitions, everything is self-contained. Adding research notes, TODO lists, or other personal structures becomes as simple as adding a line in the table.

• 5: More events (e.g. MILT)
  My PR makes events fully data-driven. Adding a new event is no longer a matter of programming, just adding an extra entry in the events table. Each event also has an action list guided by an action table, software only needs to program the actions once. After that, it’s the data definitions that do the heavy lifting.

  "Good declarations do half of the job."

• 6: The FAM record
  Maybe it wasn’t clear enough in my proposal, but the FAM record disappears. Its role is taken over by the TEMPLATE and the STICKYs inside it. That avoids the double pointers (parents/children both ways) and makes the design simpler and more consistent.

• 7: Assets (photos, objects, heirlooms, etc.)
  That is what the new ASSET record was designed for. It’s flexible, supports many kinds of assets, and is not obligatory — so those who don’t care about assets can skip it. But for those who want to track family objects, property, titles, or any kind of possession, the structure is now available.

Further points

My PR also introduces:

• GROUPs (clans, tribes, farms, religious orders, etc.), with membership history.
• Support for non-traditional relations (same-sex, polyamorous, step-relations) without having to force-fit them into the old FAM model.
• Keyword searchability for the role/event tables.
• Consistency across templates, so the same roles and events behave coherently everywhere. TEMPLATES act as a mini-tree.
• Clearer separation of evidence vs. conclusion, with TEMPLATE/STICKY capturing what the source says, and INDI storing the researched interpretation, linked back to evidence.

A higher-level question

Many of the issues that keep being listed (citations, extensions, missing roles, missing events…) may come from the fact that the current GEDCOM design itself is not optimal anymore. Each time, the response is to patch a missing structure or add an extension, but maybe it’s time to ask whether the foundation itself is the real problem.

My PR is one attempt to take that step back: to show that if the foundation is more flexible and consistent, many of these recurring problems solve themselves.
I don’t claim my approach is the only solution, but I do believe it’s the first real move in that direction.

Do you need more help to explain how things work? And if so, what kind of help would you prefer? I realize the PR may have been a lot to digest, but many of these points are already inside it.

[Norwegian-Sardines]

Why?

if you don’t understand why then I can’t tell you without writing a long dissertation on design and teamwork!

You clearly don’t understand that a user can currently define their own “facts” even before v7 GEDCOM, but that’s not the point. We are a “standards committee and should set some FACT value standards.

I’m not sure if you understand “normalization”!

A user can already add all kinds of assets! I can go on about things but I’ve already said a lot about them and you have dismissed them.

I’m not sure your design fixes the citation issue, or even understands the issue!

If you think that adding a “Premiss” Based section to the GEDCOM transmission “. I would be in favor of starting a design group toward that outcome.

So I’m looking to go back to a thoughtful design approach, but if your design continue to have legs then so be it!

I’m out!

[albertemmerich]

@Norwegian-Sardines

The current method of adding a new tag by an application is to introduce an extension (a new tag value preceded by a "_") and asking the application to create an EXID entry with a URL to a site that defines the extension. In some cases these extensions would be minimal and transmission receiving application can easily ignore many of these extensions.

I do not understand this statement. I do not see a link in between definition of an extension tag and the EXID tag. EXID is pointing to an external system, the paylod of EXID being the ID in the external system. Like a place database. An extension tag is defined in the HEAD section, and the link to the explanation / definition of an extension tag is provided by SCHMA.TAG. It is up to the exporting application to give the information how to use the extension tag in the page which is linked by the TAG payload.

I do see another problem: Excessive use of extension tags where standard structures are available. So you are wondering that the data transmitted by _MILT will not show up in all receiving application. But why use _MILT for an military event having the standard way

1 EVEN
2 TYPE military

Most application will show this. I admit, it would be better, to have a TYPE payload not depending on a language. So improvement to the standard can be done and is necessary to improve data exchange - but a lot of todays transfer problems result from use of standard which is not the recommended way.

[Norwegian-Sardines]

@albertemmerich

@Norwegian-Sardines

The current method of adding a new tag by an application is to introduce an extension (a new tag value preceded by a "_") and asking the application to create an EXID entry with a URL to a site that defines the extension. In some cases these extensions would be minimal and transmission receiving application can easily ignore many of these extensions.

I do not understand this statement. I do not see a link in between definition of an extension tag and the EXID tag. EXID is pointing to an external system, the paylod of EXID being the ID in the external system. Like a place database. An extension tag is defined in the HEAD section, and the link to the explanation / definition of an extension tag is provided by SCHMA.TAG. It is up to the exporting application to give the information how to use the extension tag in the page which is linked by the TAG payload.

I do see another problem: Excessive use of extension tags where standard structures are available. So you are wondering that the data transmitted by _MILT will not show up in all receiving application. But why use _MILT for an military event having the standard way

1 EVEN
2 TYPE military

Most application will show this. I admit, it would be better, to have a TYPE payload not depending on a language. So improvement to the standard can be done and is necessary to improve data exchange - but a lot of todays transfer problems result from use of standard which is not the recommended way.

As I said "I'm out", but as a courtesy I'll will reply!

I agree that

1 EVEN 
2 TYPE Military

as the most appropriate way of creating a new "fact", I've used this method since at least v5.4 GEDCOM. Maybe my use of the term EXID is incorrect, but my point is that an External Identifier can also be used to define a new TAG as outlined in v7.0.14 page 21. where a new tag is introduced _SKYPEID

0 HEAD
1 SCHMA
2 TAG _SKYPEID http://xmlns.com/foaf/0.1/skypeID
0 @I0@ INDI
1 _SKYPEID example.person 

The new tag is defined within the schema:

0 HEAD
1 SCHMA
2 TAG _SKYPEID http://xmlns.com/foaf/0.1/skypeID
2 TAG _MEMBER http://xmlns.com/foaf/0.1/member

As far as understanding this how the External Identifier may be used, yes it is an external link, but that link is not any better or worse than including the same information in the "FLEX" GEDCOM. The receiving user will most likely not see it and probably can't use it and the application probably will not know how to use the "FLEX" in it application other than just displaying the data. If the data controls the behavior of the application the receiving application can't adjust its control path to accommodate the tag!

As far as _MILT, GEDCOM should include additional new tags within The Standard.

I hope this help you to understand the statement I made and why several of the concepts written by myself at the beginning of this "Discussion" are important as separate entities rather than one mammoth PR which as I said before "I'm OUT"!