Draft v8.0 TEMPLATE, STICKY, FLEX, ASSET, GROUP, PROOF, alongside V7

[mother10]

This PR models new structures for GEDCOM V8, to try and take that to a higher level. It is based on TEMPLATEs and STICKYs. They describe the evidence in documents, on gravestones, in a census, and any other evidence "entity" that can hold genealogical information. It has 3 huge enumtables so it becomes a bit "Data driven". It is structured alongside GEDCOM 7.x (for now) to help users and developers get used to this new system. But before implementation the group might decide to totally disconnect it from V7.x and start a new direction. In that case changes have to be applied to make this draft work.

While designing, time and effort have been spend to make it extendable, reliable, easily changeable, logical, solid and easy for users and developers.

It needs polishing, refinements, help from the group to find missing ends. It has a huge extra file with examples, they are not there for fun (although some have some fun inside) but they are there as a testbed. I heavily used that to make sure things would fit.

But I now want to show it all, I can hardly wait.😁

[Norwegian-Sardines]

Kindly explain how this PR will codify the various values of family relationships into a common understand crossing language, custom and time using examples. Thx

[mother10]

The ROLE system in PR #679 doesn't codify family relationships - it codifies document roles. This is a fundamental distinction.

What GEDCOM 7 does (conclusions):

• States "John is Mary's father" as a concluded fact
• Requires interpreting multiple documents to establish this

What PR #679 does (evidence):

• Preserves what each document actually says
• A baptism record shows "John Smith, father" - that's his ROLE in that specific event
• A marriage record shows "John Smith, witness" - different ROLE, same person
• A will shows "Mary Smith, heir, daughter" - her ROLE in that specific document

The ROLE values are document-centric, not relationship-centric:

• ROLE MAIN, BRIDE - this person is the bride in this marriage certificate
• ROLE FATHER, BRIDE - this person is identified as the bride's father in this document
• ROLE WITNESS - this person witnessed this event

Each STICKY preserves roles as recorded in one specific document. Multiple STICKYs from different documents, all linked to the same INDI, show how that person appeared across sources. The family relationships emerge from analyzing those documented roles - they're not imposed by the structure itself.

This crosses languages/customs/time because it records what's actually written, not what we interpret it to mean. A Norwegian "fadder" gets its own ROLE. A Dutch "peter" gets its own ROLE. The enumeration tables contain the documented roles found in real genealogical sources.

The GEDCOM 7 approach of concluded relationships (FAMC/FAMS) remains available in the INDI record itself. (But in fact its no longer necessary with this new system)

CRITICAL CLARIFICATION on ENUM values:

My system does NOT allow software to invent their own translations or ROLE values in GEDCOM files.

The GEDCOM file itself contains ONLY official ENUM values from the GEDCOM specification. Every ROLE value like FATHER, BRIDE, WITNESS, HEIR comes from standardized enumeration tables defined in the GEDCOM 8 specification.

Translation happens in the user interface, NOT in the GEDCOM file.

• GEDCOM file stores: ROLE FATHER, BRIDE
• Dutch software displays to user: "vader van de bruid"
• French software displays to user: "père de la mariée"
• But both read/write the exact same GEDCOM: ROLE FATHER, BRIDE

This is exactly how GEDCOM 7 already works with tags like BIRT, DEAT, MARR. German software shows "Geburt" to users, but writes BIRT in the GEDCOM file.

Software that writes custom values into GEDCOM files is breaking the specification - that's not a problem with my design, that's a problem with non-compliant software. My system maintains the same standardization approach GEDCOM has always used.

The standardized ENUM tables ensure interoperability. User interface translations are a separate layer that every genealogy application already handles for current GEDCOM tags.

I didnot add any examples as there are many in that huge examples file that accompanies my pr.
O and before I forget, This is about the ROLEs, for EVENT types and STICKY TYPES the same is true.

[Norwegian-Sardines]

The standardized ENUM tables ensure interoperability. User interface translations are a separate layer that every genealogy application already handles for current GEDCOM tags.

Where in the "Standardized Enum Table" is the definition for "Main", "Bride", "Biological Father/Mother", "Adoptive Father/Mother", "Foster Father/Mother", "Witness", "God Father/Mother", "Step Brother/Sister/Mother/Father", "Half Brother/Sister", etc?

I agree that GEDCOM is generally a "conclusion based" transmission and it would be nice that "Evidence without a conclusion" had a better role in the transmission of data. This is a topic that goes beyond current use. But this evidence layer should not replace the conclusions made by the transmitting party as you indicated in your comment:

It is structured alongside GEDCOM 7.x (for now) to help users and developers get used to this new system.

If I have enough evidence that pertaining to the Father/Mother of a child I would want to conclude the same!

[mother10]

ROLES` tables: Where in the "Standardized Enum Table" is the definition for....................

https://github.com/FamilySearch/GEDCOM/blob/3900bf2c9e7ab15ae396365d2a4faaa167cf8e3d/specification/gedcom-3-structures-4-enumerations-roles.md

[Norwegian-Sardines]

ROLES` tables: Where in the "Standardized Enum Table" is the definition for....................

https://github.com/FamilySearch/GEDCOM/blob/3900bf2c9e7ab15ae396365d2a4faaa167cf8e3d/specification/gedcom-3-structures-4-enumerations-roles.md

Yes I've seen these.