Add some possible additional family events for consideration

[cdhorn]

Adds Civil Union, Domestic Partnership, Family Story and Newspaper Marriage Notice for possible consideration.

[albertemmerich]

I do not see Family Story and Newspaper Marriage Notice as Family Events. Family Story is a report (I see it in NOTE), Newspaper Marriage Notice will be put as source citation under the MARR event.
Civil Union I handle as another type of MARR event, like Civil Marriage and Religious Marriage. For me Domestic Partnership is more a fact than a event, however Domestic Partnership has no unique definition, and there may be cases where it is used for an event. But this must be made clear before creating a tag!
Generally there is the question how to model the many special events users are asking for. They might be modelled as groups of events differenciated by TYPE, or they all get an own tag. I think this should be decided before we create more and more tags which might be deprecated if the general decision is made afterwards.

[cdhorn]

Thanks for the feedback. Keep in mind inclusion here documenting that these are currently provided for or in use in some way in programs out in the real world or a standard like Gedcom X does not mean they need be accepted and added to the standard.

Note I started the process of trying to put together a PR documenting individual events used by various programs and standards and there are a great number. I'm honestly unsure if I should continue work on it or not.

I agree there is the question of how to handle these things. Up until now the Gedcom standard has always handled them as a flat namespace. Most programs do as a result and would require extensive changes to handle them differently.

Stepping back a little... I would like to point out very few programs seem to have adopted version 7 of the standard at all from what I can tell. Exports I ran to examine from Ancestry.com, FindMyPast and MyHeritage yesterday are all still using the legacy 5.5.1 standard. As version 7 has been available for quite some time now the future of the standard if no one of any major size is adopting and using it seems somewhat nebulous to me.

[Norwegian-Sardines]

@cdhorn and @albertemmerich

Thanks for documenting the various facts/events used by the multitude of applications and data providers.

I am proponent of what I call, “Typification” of similar facts/events.

I am however losing faith in a Better GEDCOM, the standardization of the various “dialects” of GEDCOM and the adoption of v7, but more so, some very important (in my view) improvements in future GEDCOM protocols.

It is hard for me to contribute here when I feel that other factors are pulling in a different direction!

[tychonievich]

Thanks for adding all this information!

[dthaler]

Approved during GEDCOM Steering Committee meeting June 13, 2024
More input will be needed before adding to FamilySearch GEDCOM 7.1 (or later) but this is all great information towards that end.
Thanks!

[tychonievich]

@cdhorn, I appreciate the scope of individual events! If you wish to document those that various applications use that would be valuable, whether in whole or in part. I've had something like that on my wish list for a while, and am very happy to see the progress you've made on it!

[clarkegj]

I'd like to comment on the comment "As version 7 has been available for quite some time now the future of the standard if no one of any major size is adopting and using it seems somewhat nebulous to me.". As new standards go it does take some time for industry adoption. For example HTML 4 took way to long. Please review the up to date information on the adoption of Familysearch GEDCOM 7 at https://www.familysearch.org/en/GEDCOM/implementation-progress which can also be navigated to by merely going to GEDCOM.info and then choosing "Implementation Progress".

[cdhorn]

If you wish to document those that various applications use that would be valuable, whether in whole or in part.

@tychonievich I will submit a PR for this when I have time to finish sifting through things. It will likely overlook many things and be incomplete but the hope is that it helps some.

As new standards go it does take some time for industry adoption.

@clarkegj yes I know it can take time but it has been 3 years now. I think for it to really gain traction the big players need to support both importing and exporting with it and I am surprised they have not yet. I wonder if the thinking is that 5.5.1 is 'good enough' and what 7.0 has to offer is not enough to justify spending time and resources on it.

[emyoulation]

The project should choose a couple Open Source projects (in different coding languages) that already use GEDCOM 5.5.1 for display and contribute GEDCOM7 reader (and writer) code.

For instance, a severely cropped (eliminate the GUI modules and most internal plugins) fork of Gramps could be used as a tool to transform to and from different formats. That would be multilingual straight off the starting block. The data model is flexible enough to allow unrecognized Tags to be stored as attributes tuples. And the fork COULD offer the Gramps plug-in framework so other tools could add support for their format.

As the different vendor wrote Import/Export plug-in for their native format, they could use the fork as an external ETL (Extract, Transform, and Load) and ELT (Extract, Load, and Transform) utility. And use it as a bridging technology until the GEDCOM7 format was internally supported.