Proposal: Add FLEX (coming from #680 and is an unseparable part of it.)

[mother10]

FLEX

FLEX_STRUCTURE :=

n FLEX <Text>                         {1:1}  g8:FLEX
  +1 TYPE <Text>                      {1:M}  g8:FLEX-TYPE
  +1 PHRASE <Text>                  {1:1}  g8:PHRASE
    +2 LANG <Language>              {0:1}  g7:LANG
  +1 CONTENTS <Text>                  {1:1}  g8:CONTENTS
  +1 RESN <List:Enum>                 {0:1}  g8:RESN
  +1 <<NOTE_STRUCTURE>>               {0:1}

A FLEX structure allows flexible encoding of additional typed values within records, that are specific to a document, template, or local practice. It supports structured value recording even when the type is not part of standard GEDCOM fields.
It processes lots of possibilities as DATA, NOT as a new structure or a new TAG.
When you look at the accompanying enumtable you see the DATA-types under the TYPE column. It has all DATA types GEDCOM understands. And some more because of my TEMPLATE and STICKY proposal.

And I added a couple that can be seen as a DATATYPE although in current GEDCOM they are not mentioned like that. Like NOTE and ADDRPLUS. Those are structures, but they contain DATA.

Software can handle a FLEX in 1 and the same way, no matter what DATA it processses.
Only thing needed is that once in the software code is written to process that DATA type.
As soon as thats done, we can add as many lines of this DATAtype we want.

@albertemmerich
Remember you mentioned a RESEARCH type as you wanted to be able to have special researcher notes?

Now look at how easy this can be implemented with a FLEX. All we need to do is add 1 extra line in the FLEX enumtable, and because the processing of a FLEX NOTE is programmed once already, we could keep adding lines for all things we want to be treated as a `NOTE but we wanted to call different.

We want a TODO, ok great we add 1 line saying this is a TODO type,
fill in the fields the correct way, and we have a TODO

without having to program anything extra !!!

So nothing changes in the software and I guess that will please developers.

Now how easy do you want it to be!

And if we would make things very easy for developers, we hand them the enumtables as a MYSQL downloadable files, each time we add or change some lines.
Discussion about a new event could be easy, and it would not have to take until a new release to add just those (changed) lines of an enum.

I tried to make GEDCOM datadriven, as much as possible. Following the saying we once used way back in 1971 when I started programming:

Good declarations do half of the job !

If you define your data smart, it takes less code and less trouble to introduce something new.
Adding a line does not have to change the code of software. And if the table is a bit more difficult, as with the events, we add an extra column that "defines" the actions software should take for a certain event. And we add an extra table with these actions.
Now all software has to do is go over the event it finds in the TEMPLATE, run over the event-table till it finds the correct line, and look in that extra column for the actions it has to take.
You define and program the actions once, and you never have to touch them again anymore.

That is the way my proposal was constructed. Thats why it took so much time, as those tables are realy important and should be carefully crafted to make sure things work.

FLEX can be the answer to #692 and probably more.

Some of you asked what the data driven meant, well THIS is what I call datadriven.
My proposal #680 s full of those enumtables. Realy huge ones.

Do people want a new EVENT, ok we add a line or we add an extra keyword for a line that already has that kind of event, so we do not unnessarily keep adding lines.

Do we want an extra ROLE, ok same thing. Do we want an extra ENTITY type, same thing too.

Rules

• FLEX can only be used inside TEMPLATE, STICKY, ASSET, PROOF or GROUP.
• Unless it is decided it can be implemented in GEDCOM 7.1 there it could be used on more places.
  That is up to the committee.

Ok now back to FLEX

What is FLEX and how does it look?
It consists of a FLEX tag followed by one or more subordinate lines that define its meaning.

By using FLEX, a lot of the maybe dozens and more widespread _SILLYTAG's, can be changed into user readable information, while the software processing it, can deal with it, without having to know the real meaning, or its definition or otherwise. If a FLEX later will have to be replaced by an offcial GEDCOM tag, because that FLEX is so widespread and often used, it deserves its own tag, its likely that software can do that, without much user assistance. (By comparing the PHRASE of the FLEX, with the _SILLYTAG's tagname.)

• The TYPE line declares one or more types describing the structure of the CONTENTS. If multiple types are given, they must be separated by a comma and a space. The TYPE's appear on the same line as FLEX, separated from FLEX by 1 space.

• The CONTENTS line contains the value, matching the declared TYPE. In certain case this line can be followed by 2 CONT some text, in case the FLEX type is a NOTE-type enum.

• The PHRASE line must be present and must exactly match the label of the field on the original document or template. This ensures that software can display or print human-readable information even if it does not interpret the TYPE or CONTENTS. The PHRASE line appears directly after the FLEXline.

• LANG, defines the language of the PHRASE.

• NOTE can be used for special remarks about this specific FLEX.

• RESN, with this the user can decide if the information of this FLEX should be presented in the outputs.

Rules:

• TYPE values must be valid entries from the FLEX-TYPE enumeration. For readability they must be put directly behind the FLEXtag, separated from it by 1 space, like this: FLEX DECIMAL, CURR, USD. So the TYPEtag itself does not show. And, for instance with CURR, the chosen currency value itself, also goes on that same line. Same for UNIT.
• The only allowed combination of TYPEs as for now is with CURR or UNIT behind AMOUNT, DECIMAL, or INTEGER.
• Parsers must treat the contents as an ordered list.
• Use of TEXT as a TYPE is allowed only if no more precise type is applicable. For instance, do not use TEXT to represent "1944-06-06" or "12500.00"; use DATE and DECIMAL, respectively.
• The PHRASE must reflect the exact label used on the source document to help users recognize the field's meaning.
  • This allows software to:
    • display fields using user-recognizable labels,
    • disambiguate similar fields (e.g., two different monetary amounts),
    • and support output of human-readable versions even without interpreting the underlying TYPE/CONTENTS.

$\color{Coral}\large{\textbf{Important! GEDCOM 8 changes:}}$

In this PR FLEX has been given a restriction:

• It can only be used inside TEMPLATE, STICKY, ASSET, or GROUP.
  This way it does not interfere with current GEDCOM7.

If this PR would be accepted, it is always possible to extend the use of FLEX to other places in GEDCOM. So we maybe could already add this to GEDCOM 7.1

Example 1: Single typed value

1 FLEX DATE
2 PHRASE "Date of Transfer"
2 CONTENTS 1944-06-06

In this case "Date of Transfer" does NOT have its own GEDCOM tag, so a FLEX is used instead.

Example 2: Combined typed value (decimal amount with currency)

1 FLEX DECIMAL, CURR, USD
2 PHRASE "Property Value."
2 CONTENTS 12500.00
2 NOTE "Transferred to widow"

Value of the property on a will.

Example 3: Typed field in a STICKY from an inheritance template

0 @ST0043@ STICKY
1 TYPE FINANCE, ACCOUNTS "Inheritance Share: Savings Account at Miami Credit Union"
2 PHRASE "Savings Account at Miami Credit Union"
1 ROLE ASSET
1 FLEX DECIMAL, CURR, USD
2 PHRASE "Savings"            /* Text as on the original certificat */
2 CONTENTS 12500.00
1 NOTE "Savings inherited by Anna Harrison from George Harrison."

g8:enumset-FLEXTYPE

This enumset defines the type of the CONTENTS that follows the tag FLEX.
Each FLEX block includes a PHRASE and a CONTENTS line, optionally followed by one or more CONT lines. This table describes how CONTENTS is interpreted based on its TYPE.

TYPE	Description	Multiline	NOTE-type	CONTENTS Value
ACCOUNTNR	An account number, such as for a bank account. Interpreted as a string.	➖	➖	value
ADDRESS	Structured address data. ADDRESS_STRUCTURE follows under CONTENTS.	✅	➖	ADDR
ADDRPLUS	Extended address structure. ADDRPLUS_STRUCTURE follows under CONTENTS.	✅	➖	ADDR
AMOUNT	Raw numeric quantity or size.	➖	➖	value
ANNOTATION	Annotated remark, such as in a census or bible. Treated like an inline NOTE.	✅	✅	NOTE
ARRAY	A tuple array. Only simple 2-column tuples allowed. Multiline required.	✅	➖	ARRAY
BOOLEAN	A truth value: TRUE or FALSE.	➖	➖	value
CURR	Currency code (ISO 4217), e.g., USD, EUR.	➖	➖	value
DATETIME	A DateValue, combined date and time using 1 DATE and 2 TIME.	✅	➖	DATE + TIME
DATExx	GEDCOM-compliant date where xx clarifies intent: DATEV, DATEE, DATEP, etc.	➖	➖	DATE
DECIMAL	Decimal number, e.g., 12500.00	➖	➖	value
DESCRIPT	Short description. One-liner. For longer text, use NOTE.	➖	➖	value
HEX	Hexadecimal string.	➖	➖	value
INTEGER	Whole number without decimals.	➖	➖	value
LANDSIZE	Area or size of land or estate. May include units (e.g., "5 acres").	➖	➖	value
MATERIAL	Material of an object (e.g., "wood", "linen").	➖	➖	value
NAME	Full name without structure parsing.	➖	➖	value
NOTE	Free-text remark. Treated like an inline NOTE.	✅	✅	NOTE
OBJECT	Label or ID of a tangible item. Not a pointer.	➖	➖	value
PERCENT	Percent (0–100), can include decimals.	➖	➖	value
PERCENTR	Percent ratio, may exceed 100%.	➖	➖	value
REGNUMBER	Identifying registration or case number. May include alphanumerics.	➖	➖	value
ROLE	Functional role or designation (e.g., heir, witness).	➖	➖	value
RESEARCH	Special research type note.	✅	✅	NOTE
TEXT	Fallback free-text. Not for structured data.	✅	✅	NOTE
TITLE	Honorific or title (e.g., "Dr.", "Queen").	➖	➖	value
UNIT	Unit of measurement (e.g., acre, meter, foot, pennyweight).	➖	➖	value
URL	Valid file path or web URL.	➖	➖	value

🧾 Notes

• The Multiline column indicates whether the type supports/encourages CONT lines after CONTENTS.
• The NOTE-type column marks types that behave like inline NOTEs — they render and wrap identically and allow CONT.
• The CONTENTS Value column shows what the CONTENTS line itself should contain:
  • value means raw content (e.g., number, string).
  • NOTE, ADDR, or ARRAY means that tag name appears literally in the CONTENTS line.
• ⚠️ Parsers must distinguish between value and tagname in CONTENTS.
• 🧠 DATExx supports disambiguation when the DATE's meaning (exact/approx/range/etc.) isn't clear from context, unlike regular GEDCOM event structures.

💬 Suffixes for DATExx

Suffix	Meaning	TAGS
DATE	date	[calendar D] [[day D] month D] year [D epoch]
DATEV	General DateValue	[ date / DatePeriod / dateRange / dateApprox ]
DATEE	Exact date	day D month D year
DATEA	Approximate date	(%s"ABT" / %s"CAL" / %s"EST") D date
DATEP	Period (e.g., "BET 1890 AND 1900")	[ %s"TO" D date ] / %s"FROM" D date [ D %s"TO" D date ]
DATER	Date range	%s"BET" D date D %s"AND" D date / %s"AFT" D date / %s"BEF" D date
DATERS	Date restriction (e.g., "BEF 1860")	%s"FROM" / %s"TO" / %s"BET" / %s"AND" / %s"BEF" / %s"AFT" / %s"ABT" / %s"CAL" / %s"EST"

• This enumeration defines the list of valid types that can appear in a FLEX structure's TYPE line.
• New types may be added over time. Unrecognized types must be ignored or flagged.
• Each type adds meaning to the associated CONTENTS value(s). Parsers and tools must validate types against this list for interoperability.
• 🧾 TEXT must not be used to encode structured values (like numbers, currency, or dates) in string form. Always use the appropriate type. TEXT is a fallback only.
• (NOTE-like enum value), this means this FLEX-type is to be handled like an inline NOTE including the tag NOTE.
• Multiline, this FLEX type is a multiline type, like NOTE or ARRAY, see the examples.

💬 Comments on FLEX Type Handling

• ⚠️ Parsers must validate that the number of TYPE entries matches the structure of CONTENTS values.
• ⚖️ LANDSIZE may include implicit or explicit units (e.g., 10.5 ACRE), but software should gracefully handle unitless values when the historical context is uncertain.
  • The units are only present because they appeared on the original document, and do not have to be interpreted by software.
• ♾️ UNIT, for old measurements see: https://en.wikipedia.org/wiki/Medieval_weights_and_measures or https://en.wikipedia.org/wiki/List_of_obsolete_units_of_measurement.
  • Here too: units do not have to be interpreted by software.

:::example
These are examples for a NOTE, an ARRAY, and an ANNOTATION:

1 FLEX NOTE                   /* FLEX re4placement of a normal inline NOTE */
2 PHRASE description on form
2 CONTENTS NOTE
3 CONT First line of text
3 CONT another textline

1 FLEX ARRAY                  /* DNA values */
2 PHRASE DNA values
2 CONTENTS ARRAY
3 CONT (rs123456, A)
3 CONT (rs234567, T)
3 CONT (rs345678, G)

1 FLEX ANNOTATION             /* An annotation, which is always of type NOTE */
2 PHRASE Annotation in a Census
2 CONTENTS NOTE
3 CONT First line of annotation
3 CONT another annotated line

These are examples for DATEP, DATETIME and an ADDRESS:

1 FLEX DATEP                  /* A Dateperiod */
2 PHRASE Dateperiod of event
2 CONTENTS FROM 1850 TO 1880

1 FLEX DATETIME
2 PHRASE Birth Date and time
2 CONTENTS DATETIME
3 DATE 18 SEP 1832
3 TIME 12:45

1 FLEX ADDRESS
2 PHRASE Address of laboratory
2 CONTENTS ADDR 43 Mainstreet /* ADDR1, ADDR2, ADDR3 are deprecated so street and nr follow ADDR!! */
3 CITY Cristal Lake
~ ~ ~                         /* Other lines of the address structure */

:::

:::note
During draft there was also an ENUM:

• ENUM: A value from a predefined list of allowed values. (Use cautiously.)
• If used, CONTENTS must reference a known enum value, and we’d likely need a way to specify which enum set is being used (like PEDI, SEX, or a user-defined list).
• 🚫 ENUM has been excluded for now due to the need for explicit reference to an enumeration list, which is not yet defined in the spec. It could be used/defined as 1 FLEX ENUM, PEDI, ADOPTED

$\color{Coral}{\textsf{ENUM might be too ambiguous. Might want to drop for now unless a specific use-case exists.}}$

:::

Some other FLEX-TYPE Specifications

• Each FLEX-TYPE value defines the structure and interpretation of the associated CONTENTS. This section describes the expected format and usage rules for common FLEX-TYPE values.
• Each value in a multi-part CONTENTS line must exactly match its corresponding type in the FLEX declaration, by position.

FLEX-TYPE	Description	Example
BOOLEAN	Must be one of: TRUE, FALSE (uppercase).	Example: 1 CONTENTS TRUE
CODE	A short, predefined value from a controlled vocabulary or government list.	Example: 1 CONTENTS "C-01" (case and format depend on the code system used)
CURR	Currency code following ISO 4217. Always combined with DECIMAL or INTEGER	Example: 1 CONTENTS INTEGER, USD or 1 CONTENTS DECIMAL, EUR
LANDSIZE	Land size measurement. First value must be numeric (DECIMAL); second value is a unit label (TEXT).	Example: 1 CONTENTS 3.75, ACRE Non-SI or historical units (e.g., "BUNDER", "MORGEN", "MUD") are permitted as quoted text.
PERCENT	A numeric value representing a percentage.	Example: 1 CONTENTS 25.0 (meaning 25%)

Look in the examples file for many more FLEXes !

[albertemmerich]

Again: Wow!
I try to understand, but there are more questions than answers...

Let's start:

n FLEX {1:1} g8:FLEX
+1 TYPE {1:M} g8:FLEX-TYPE
+1 PHRASE {1:1} g8:PHRASE
+2 LANG {0:1} g7:LANG
+1 CONTENTS {1:1} g8:CONTENTS
+1 RESN List:Enum {0:1} g8:RESN
+1 <<NOTE_STRUCTURE>> {0:1}

? Why PHRASE {1:1} => does not allow to add translations. If I have a Chinese document, I am only allowed to put in the Chinese label, no translation.
? Why CONTENTS {1:1} => how does that work with todays NOTE.TRAN with translations to different languages? If we put the translation to the NOTE structure, how do we know it is the translation of the content?
? Does the application really has an easier job to do if we transfer

1 NOTE text1
2 CONT text2

to

1 FLEX NOTE                   /* FLEX replacement of a normal inline NOTE */
2 PHRASE description on form
2 CONTENTS NOTE
3 CONT text1
3 CONT text2

In the user interface we have to offer an input datafield of type NOTE, anyway...
? how it will be organized with all these FLEXs that we gather all information related to one event (which may be one out more events cited in one record of the source)?

Perhaps I could better understand, if we get an example of representation of one record using FLEX. I would like to see a GEDCOM code for the following record:

Source: Church Book Wienhausen
Page: Volume: "Trauungen und Beerdigungen 1845-1852", chapter: Gestorbene und Begrabene; page: 41, number: 35, number for females: 18.
URL: https://www.archion.de/p/373e7ccbcf/
Content: Geschlecht: weiblich; Name und Status: Catharine Marie Hesse, geb. Meyer, des Kötners in Oppershausen, Johann Heinrich Hesse, Ehefrau; Alter: 23 Jahre 3 Tage; Krankheit: Brustkrankheit; Sterbeort: Oppershausen; Sterbetag: 1852 October 17.; Beerdigung: öffentlich, Octob. 22; Bemerkungen: Geboren in Gokenholz 14. Oct 1825

Translation of content: Sex: female; name and status: Catharine Marie Hesse, born Meyer, wife of Kötner [farmer] in Oppershausen, Johann Heinrich Hesse; age: 23 years 3 days; cause: disease of the chest; place of death: Oppershausen; day of death: 1852 October 17; burial: public, October 22; notes: Born in Gokenholz 14 Oct 1825

This is a rather simple example as it only shows the main individual and one other, the husband. And it shows the main event (death) and another event (birth including the place of birth).

At this time, my application has this stored as (deleted some part as CREA and CHAN):

0 @I1@ INDI
1 NAME Catharine Marie /Meyer/
2 GIVN Catharine Marie
2 SURN Meyer
2 SOUR @S1@
3 _CIT @C1@
1 NAME Catharine Marie /Hesse/
2 TYPE MARRIED
2 GIVN Catharine Marie
2 SURN Hesse
2 SOUR @S1@
3 _CIT @C1@
1 SEX F
1 BIRT
2 DATE 14 OCT 1825
2 _LOC @P1@
3 PHRASE Gockenholz, Celle DE-NI
2 SOUR @S1@
3 _CIT @C1@
1 DEAT
2 DATE 17 OCT 1852
2 _LOC @P5@
3 PHRASE Oppershausen, Celle DE-NI
2 AGE 27y 3d
2 CAUS Brustkrankheit
2 _ZVST MARRIED
2 SOUR @S1@
3 _CIT @C1@
1 BURI
2 DATE 22 OCT 1852
2 _LOC @P7@
3 PHRASE Wienhausen, Celle DE-NI
2 TYPE öffentlich
2 SOUR @S1@
3 _CIT @C1@
1 FAMS @F1@
1 UID 0198e5f6-a8b2-7000-b347-a242188ac1ba
0 @I2@ INDI
1 NAME Johann Heinrich /Hesse/
2 GIVN Johann Heinrich
2 SURN Hesse
2 SOUR @S1@
3 _CIT @C1@
3 _ROLE HUSB
1 SEX M
1 BIRT
2 DATE ABT 1820
1 DEAT
2 DATE AFT OCT 1852
2 SOUR @S1@
3 _CIT @C1@
3 _ROLE HUSB
1 OCCU Köthner
2 _LOC @P5@
3 PHRASE Oppershausen, Celle DE-NI
2 DATE 1852
2 SOUR @S1@
3 _CIT @C1@
3 _ROLE HUSB
1 RESI
2 _LOC @P5@
3 PHRASE Oppershausen, Celle DE-NI
2 DATE 1852
2 SOUR @S1@
3 _CIT @C1@
3 _ROLE HUSB
1 FAMS @F1@
1 UID 0198e5f8-0a46-7001-8235-956b17ec1f2d
0 @F1@ FAM
1 HUSB @I2@
1 WIFE @I1@
1 MARR Y
1 UID 0198e5f7-174c-7001-ad06-eeca267ef64b
0 @C1@ _CIT
1 SOUR @S1@
1 EVEN DEAT
1 PAGE_BD TrB 1845-1852
1 PAGE_KP Sterbefälle
1 PAGE_JG 1852
1 PAGE_PG 41
1 PAGE_NR 35 w:18
1 PAGE_WW https://www.archion.de/p/373e7ccbcf/
1 QUAY 3
1 DATA
2 DATE 17 OCT 1852
2 TEXT Geschlecht: weiblich; Name und Status: Catharine Marie Hesse, geb. Meyer, des Kötners in Oppershausen, Johann Heinrich Hesse, Ehefrau; Alter: 23 Jahre 3 Tage; Krankheit: Brustkrankheit; Sterbeort: Oppershausen; Sterbetag: 1852 October 17.; Beerdigung: öffentlich, Octob. 22; Bemerkungen: Geboren in Gokenholz 14. Oct 1825
1 NOTE Archion Bild Nr. 42
1 UID 0198e5f6-a7f7-7001-978c-ea0a211c99b1

Extended standard tag _ROLE is used instead of standard EVEN.ROLE, as the citation including EVEN is extracted and put to an own record _CIT. Uses _LOC records of GEDCOM-L, too, but not copied to the example. The very long data of the source citation are not repeated again and again, but put into extension record _CIT. For better searching in the database the PAGE tag is split into detailed tags like PAGE_NR.

Now I would like to see how this is put to proposed TEMPLATE, STICKY using FLEX.

And to compare the TEMPLATE with my citation record. Looking for all INDI and FAM citing this record I have all the "stickies" belonging to this citation.

[mother10]

@albertemmerich

If you could look down here you would see a very happy user! 😀
I will answer everything you asked for, but the last part takes some more time as we dont have real software yet.

But first this:

? Why PHRASE {1:1} => does not allow to add translations. If I have a Chinese document, I am only allowed to put in the Chinese label, no translation.

This is really great, I was very much hoping things like this would popup. As you found a shortcoming in the proposel, the first one!
After so many weeks I was sure I would be getting blind for things, staring at the same lines. And each time thinking I had covered everything I could think of. But I was sure I did not.

First thing, FLEX is not a replacement for already existing TAGs. It is meant for information that does not have a TAG in current GEDCOM.
Or for information that does have a TAG but that in fact we want to categorize. Like you were asking for a RESEARCHER Note. Now in current GEDCOM, that would indeed mean we somehow have to add a type or anything else so we, and software, understand it is a special kind of Note.
Problem with that, this user wants this type of Note, another user wants that type of Note, so yes, we can add all that but it means we introduce something that forces developers to do extra programming to be able to process it.

So in case it is a Note that is used in current GEDCOM and a user has no special needs, it just wants info stored,
we do not need FLEX.

So I certainly dont mean to say, we should replace all NOTEs!

But in your case in fact you wanted a NOTE that stood out, that had special meaning, and that is something current GEDCOM cannot do, unless we add another TAG or a TYPE, or any other solution, but that forces developers to do extra programming. Or it ends up by using a TAG in a way it originally was not designed for.

What I want is to find solutions that, when programmed once, can be just used without any need of extra programming, and still give flexibility.

The whole proposel is build on that principle

I Tryed to make it as easy for developers as possible, make them program things once, and test them, and forget about them as much as possible for next changes in GEDCOM.
I dont say I succeeded, maybe I failed, I will accept that, that is for you all to judge, but that was one of the main things I wanted to achieve with all this.

Now the questions:

PHRASE {1:1},

I made that {1:1} as this is needed. It is meant for a user to read and understand what this value (in the CONTENTS) is about (when the value is shown or printed).

And, as Luther said, users might add rubbish, like "Dont know", but then they should not complain when the results that are printed are also rubbish.
This PHRASE is meant to tell a user the "label" that was in front of the information on a certain form. But information that does not have its own proper GEDCOM TAG.
If a form/certificate, or anything else, does NOT have those extra things, or it does have them but we are not interested in them, we just use the normal GEDCOM TAGs.

Suppose we have a marriage form or something, that also has info like a description of the room the marriage was held, the number of people who were present, and that kind of thing. If a user should want to add all that too, to "decorate" his tree, current GEDCOM does not have room for that except a NOTE. Now if a user is happy with that, great, he uses a NOTE, but in case he is not, he can uses FLEXes to put that data in, and with the PHRASE explain what the data is about.
I can imagine that for instance on an adoption form, there can be many fields without a 1 on 1 own TAG in GEDCOM.
Those are the cases a user can use a FLEX.
He does not have to, its voluntarily, but if a user wants more than GEDCOM can provide, he now has a means to put that info in, without having to define an extension for it.

And very important:
No need for a _SILLYTAG that MUST have a definition somewhere online and/or a line in the header which might clutter the header, but is needed to somehow "tell" GEDCOM what this extension is about.

FLEX has all software needs inside, with the TYPE.

(One of the programs I use, in the latest release of last week, added 22 new extension tags in its GEDCOM output, in that release)🙈 (help)

FLEX also adds the possibility to process forms, certifates or whatever it might be, that have a lot of info that does not yet exist in GEDCOM, like DNA forms. Even those can be processed and inserted, see example :

🧬 Example 11: DNA Test Results – Match Comparison & Genotype Report

Why I am happy with your remark:

And now why I am happy about your remark. Indeed there should be something added to make sure translations are possible, thats a very good point. But only for the PHRASE itself. So it should be:

n FLEX <Text>                         {1:1}  g8:FLEX
  +1 TYPE <Text>                      {1:M}  g8:FLEX-TYPE
  +1 PHRASE <Text>                    {1:1}  g8:PHRASE
    +2 LANG <Language>                {0:1}  g7:LANG
    +2 TRAN <Text>                    {0:M}  g7:NOTE-TRAN
      +3 MIME <MediaType>             {0:1}  g7:MIME
      +3 LANG <Language>              {0:1}  g7:LANG
  +1 CONTENTS <Text>                  {1:1}  g8:CONTENTS
  +1 RESN <List:Enum>                 {0:1}  g8:RESN
  +1 <<NOTE_STRUCTURE>>               {0:1}

Is this what you meant Albert?
With this the PHRASE can also be given in other languages, am I correct?

other question

? => how does that work with todays NOTE.TRAN with translations to different languages? If we put the translation to the NOTE structure, how do we know it is the translation of the content?

Like this:

1 FLEX RESEARCH
2 PHRASE Inconsistencies found
2 CONTENTS NOTE First line of text
3 CONT Second line of text.
2 LANG nl
2 TRAN Eerste regel tekst
3 CONT Tweede regel tekst

As you can see the first line of text of the NOTE itself, goes directly after the NOTE tag. As that is how a normal NOTE is working.
And its CONT lines have a number 1 higher than the NOTEline (even if that Note now is behind CONTENTS)
Only I am not sure if the normal working of TRAN is the same, as I have never used TRAN sofar. But I expected it to be the same so the tranlated first line also goes directly after TRAN.

So to me, I would say, the whole NOTE_STRUCTURE works as a normal one, only the first NOTE does not directly follow after the line number, but after the CONTENTS-tag that is after the line number. But the linenumbering itself, and the whole structure, is the same as a normal Note.

(same for using the Addres_structure or the Addrplus_structure in a FLEX)

Sofar I only said it would accept an inline Note, but we could extend that to also have it accept an SNOTE link!

Your example code:

Next part will be a reverse engineering of the example you give.

Very happy with that too

As it has full written citations among other things.
Result will follow in another post.

Remarks: from your description I understand you want the Template, all Stickys, Flex where needed, and all Indis? (you mentioned FAM too but thats not necessary anymore.)

Am I correct?

[albertemmerich]

First: Yes, you are correct. I would like very much to see the example for the record I proposed to build this example. As that is in German, the example can show translations, too.

You added FLEX.PHRASE.TRAN: ok for me. It solves the problem I told.

However in FLEX.CONTENTS it should be modified: To be sure we know for which original text the TRAN is giving the translation, it is substructure, and not on same level in current GEDCOM 7.0. And LANG is substructure of TRAN. This would give:

1 FLEX RESEARCH
2 PHRASE Inconsistencies found
2 CONTENTS NOTE First line of text
3 CONT Second line of text.
3 TRAN Eerste regel tekst
4 CONT Tweede regel tekst
4 LANG nl

Moreover I wonder whether we could have a solution a bit closer to GEDCOM 7.0. If an application does not understand the new structure, it always is recommended to skip that.

1 FLEX RESEARCH
2 PHRASE Inconsistencies found
2 CONTENTS NOTE First line of text

would be totally skipped.
Something like:

1 NOTE First line of text
2 KIND RESEARCH
3 TYPE Inconsistencies found

or

1 NOTE First line of text
2 TYPE RESEARCH: Inconsistencies found

would only skip the TYPE and KIND (or whatever we introduce to classify different types of NOTE).

However to see how TEMPLATE and STICKY work using this very general FLEX I need the example :-)

[Norwegian-Sardines]

1. we currently have a way to define application specific entities not found in the GEDCOM standard called an EXID.

2. GEDCOM has an unwritten rule that all tags and enumerated values should be written in English unless no English word adequately identifies that condition. Translations of tags and enumerations should be handled by the application, not carried in the standard! However all tags and enumerations in the GEDCOM standard must be defined in the standard document.

3. GEDCOM already has a way to refine attribute and event (“facts”) in the standard using for example: BIRT.TYPE where the TYPE value could be defined as STILL, NATURAL, WATER, HOME, BREECH, CAESAREAN. I’m not saying these TYPE enumerator anre exactly what I want (just an example), but we should consider using what we have, maybe a BIRT.TYPE.PHRASE would work better!

However, I agree that a data-definition layer might be a great idea for GEDCOM as a different approach than using EXID links. Carrying the definition of an extension in the GEDCOM rather than relying on an internet link that could evaporate at some time in the future has benefits, the DBMS engine I worked on in my distant past had such an animal!

I see a lot of words in the above document and I am inclined to want to see a set of issues that don’t have a solution in the current standard and how the proposal solves those issues! This way I can comment on the issue at hand and the proposed solution.

[mother10]

1. we currently have a way to define application specific entities not found in the GEDCOM standard called an EXID.

EXIDs need an exid type, which (as far as I can see in the spec) is an Uri, so a link outside GEDCOM. Thats not what I wanted, as URIs might change or disappear. A FLEX has no external dependancy.

2. GEDCOM has an unwritten rule that all tags and enumerated values should be written in English unless no English word adequately identifies that condition.

One possible approach could be to add a rule that PHRASE is always required in English, with an optional second instance in the language of the original document. That way everyone has a consistent English label, but people still see the local wording.
Of course, people could ignore that (as sometimes happens with other rules), but at least the framework would be there.

3. GEDCOM already has a way to refine attribute and event (“facts”) in the standard using for example: BIRT.TYPE

I may have overlooked it — but is there an enum table that hardcodes values like STLL, NATURAL etc. Without such a table, I could equally well use DOOD, NATUURLIJK, KEIZERSNEDE, or maybe even Natuurlijk, Dood, and more. That makes consistency difficult.

I see a lot of words in the above document and I am inclined to want to see a set of issues that don’t have a solution in the current standard

Some examples of where people invented their own tags: _TODO, _PRIVATE, _DABOVILLE, _SOSA, _VALID, _DNA, _DEST and many more.
These arose because developers and users needed the information but GEDCOM didn’t offer it. And formally requesting new tags often takes a very long time.

A FLEX could cover those cases directly, for example:

1 FLEX BOOLEAN
2 PHRASE Private
2 CONTENTS TRUE

1 FLEX DESCRIPT
2 PHRASE D'Aboville number
2 CONTENTS 1.2.1s

1 FLEX BOOLEAN
2 PHRASE Value is valid
2 CONTENTS TRUE

Hopefully that clarifies how FLEX addresses the issues you raised.

[albertemmerich]

@Norwegian-Sardines

we currently have a way to define application specific entities not found in the GEDCOM standard called an EXID.

I do not understand this. EXID has a payload which is an ID in an external system: it shows which entry in the external system describes the object of the superstructure of EXID. Like Tinneke I do not see how this can support the use of a "flex"ible GEDCOM structure.

@mother10

One possible approach could be to add a rule that PHRASE is always required in English

In GEDCOM 7.0 the tag PHRASE was implemented as free text for sending data, which are not in the ENUM values of its superstructure, see definition for g7:PHRASE :

Textual information that cannot be expressed in the superstructure due to the limitations of its data type.

By this PHRASE is not under the rule to be in English, or taken out of a list of enumerated values. An English translation would not fit to your idea to put the label taken from the form to PHRASE - I understand you want to put it as taken from the form without modification.

[mother10]

Thanks for the addition, so we need another tag instead of PHRASE.
Which tag should be appropriate? or do we need to define a new tag for that?

[Norwegian-Sardines]

I do not understand this. EXID has a payload which is an ID in an external system: it shows which entry in the external system describes the object of the superstructure of EXID. Like Tinneke I do not see how this can support the use of a "flex"ible GEDCOM structure.

Flexability for whom? I don’t see any difference between the two!

I’m all in favor of application flexability, but FLEX is trying to provide transportable flexibility to another unknown application.

In an application the developer already knows what structures they need to use and support, their Flexability is that they are writing the code. Therefore they should use an EXID to define those new structures!

If you’re talking about Flexability for a user, as in adding a new “fact” or “enum”, how does this help the receiving application?

This the fallacy of EXID and user defined structures being useful outside of the immediate user or the application! No amount of Flexability will help the receiving application understand how to use the new extension without also allowing the user to code for the new data or conditions.

I’ve already questioned the use of EXID when I receive a GEDCOM with a link. In general the user can’t control reports in their desktop application to support a new structure or enum. We see this all the time with GEDCOM files that contain extensions that control functionality in the creator application, but have no value in the receiver application.

[Norwegian-Sardines]

Tineke said:

Some examples of where people invented their own tags: _TODO, _PRIVATE, _DABOVILLE, _SOSA, _VALID, _DNA, _DEST and many more.
These arose because developers and users needed the information but GEDCOM didn’t offer it. And formally requesting new tags often takes a very long time.

I understand, I have come across 100s of made up extensions, this (and I could be wrong) is exactly what the EXID was designed for to provide a resource with information about the structure.

But even if I’m wrong about EXID, it is one thing to define a new tag or structure but it is a completely different thing to be able to support the structure, tag or enum in the receiving program! Normally code needs to be added to support an extension like _TODO to make it viable. Users are not going to be able to do that, and software companies may not care, or have the time to put out an update to support another companies extension!

[mother10]

This will be a longer post again, sorry, but to help you understand better I also added how I reason. As unfortunately there is no user guide for this new system yet. 😁
So I did it this way. Hope it helps you.
Hope there are not too many errors as this had to be done by hand.

Problems I encountered, also showing the workflow:

• 1: I cannot follow the link to see what that says, as it is behind a login. So I dont know what the document shows, and use your transcript for that.
• 2: From the given text (Content: ) that mentions Death, but also Burial, so to me it does not look like a Death certificate nor a Burial certificat. But as your CITA only talks about DEAT itself, I will take this as a kind of Death certificate.
  That means the TEMPLATE event type will be DEATH, DEATH.
• I used: 1 TORIGIN ORIGDOC, COPIEDFRAG Why? As I use just the description, without being able to look at the original document, I started with ORIGDOC (it came from an original document, described in your "Content:"), but also COPIEDFRAG as I reconstructed a lot from your GEDCOM code pieces.
  • Now what you put in TORIGIN is totally up to you. TORIGIN clarifies the origin and trust context of each entry — whether manually entered, system-generated, or reverse-engineered — supporting gradual adoption of the new model and better transparency in data lineage.
  • Together with the QUAY following it, it defines the quality of this whole TEMPLATE.
  • Values of TORIGIN and QUAY are totally free, a user can put there what he thinks is correct, but they must come from the enum table.
• DATE and SPLAC, these are the date and place of the template, as sometimes the template date (and or place) might differ from the eventdate (with a birth for instance)
• As this is a Death event, I can use the official tag DEAT for the event. If the TEMPLATE would be about another Death event, like
  1 TYPE DEATH, FUNERAL
  I would have used
  1 EVEN DEATH, FUNERAL
  So with the same event behint the EVEN-tag as is after the TYPE tag of the TEMPLATE itself.
• AGNC I added this tag and got the info from the link in your example. But just to show its possible, if you dont want it you leave this one out.
• Now the ROLES section:
  For now we just add the STICKY for the death of Catherine. Her internal role (inside the sticky) will be
  1 ROLE MAIN, WIFE, DECEASED
  as the example also mentions she has a husband when she died. MAIN because she is the subject in the TEMPLATE, WIFE as also her husband is mentioned, so she was a wife of someone, and DECEASED as she is the one who died.
  Because she is mentioned as MAIN we can give the husband, Johann the role:
  1 ROLE HUSBAND
  which means he is the husband of the MAIN, so of Catherine, we will put that in his STICKY later, we only add the link of his STICKY for now.
  We will fill the ROLES section, after we have done the CITA.
• CITA. Maybe you think CITA is a separate thing, as it is in current GEDCOM. But here it is not.
  CITA is an indivisible part of a TEMPLATE. It only exists once.
  It was taken out as a separate structure because:
  • Currently the source citation committee is still working on it, so its easier to have it separate, where it can be changed independently.
  • Also: CITA is a very long structure with many lines, if we left it inside the template it would clutter too much.
  • But when we create the TEMPLATE, CITA goes inside it.

For now we have this: (more STICKYs later)

0 TEMPLATE @T001@
1 TYPE DEATH, DEATH           /* Main category Death, subcategory Death */
1 TITL Death of Catharine Marie Meyer
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG
1 QUAY 2
1 DATE 17 OCT 1852            /* Template date */
1 SPLAC @SP019@               /* Oppershausen */
1 DEAT
2 DATE 17 OCT 1852
2 SPLAC @SP019@               /* Oppershausen */
1 AGNC Archion, Stuttgart     /* Found online from the link */
1 ROLES
2 STICKY @ST01@               /* ROLE MAIN, WIFE, DECEASED Catharine Marie Meyer */
2 STICKY @ST02@               /* ROLE HUSBAND Johann Heinrich Hesse */
1 CITA                                   /* INSIDE the template but not filled yet */

Now first the CITA part:

Remember that this goes inside the previous TEMPLATE, where we now see just the line with CITA.

What is inside the CITA part:

• In principle the whole SOURCE_CITATION of GEDCOM 7, so all lines defined in there,
  Except:
  The EVEN tag and everything belonging to that. Now why?
  Because the EVEN is now handled by the TEMPLATE TYPE itself, and by the event tag in its structure.
• Further the Cita part has got some new tags, but they are kind of "under construction". As the committee decides otherwise they might change, but for now we will use those.
• There were a number of PAGE_xx Tags, some go in TITL, VOLUME, CHAPTER, SUBCHAPTER, as I already had tags for these things in the CITA. Others went in FLEX. But even some of those FLEX are in fact already in
  2 PAGE page: 41, number: 35, number for females: 18.
  so I dont know if those FLEX are realy necessary here, that is for you to decide. The url went into WWWLINK
• The transcription went into 3 TEXT, although there is a new tag TRANSCRIPT for it. But as CITA will probably change I did not use that.
• Added AUTHOR but dont know if you want that in.
• There now is VOLUME I guessed it was your: 1 PAGE_BD TrB 1845-1852, so I put that info in VOLUME.

Here is the CITA:

1 CITA
2 SOUR @S1@                   /* Church Book Wienhausen */
2 PAGE page: 41, number: 35, number for females: 18.
2 DATA
3 DATE 17 OCT 1852
3 TEXT Geschlecht: weiblich; Name und Status: Catharine Marie Hesse, geb. Meyer, des Kötners in Oppershausen, Johann Heinrich Hesse, Ehefrau; Alter: 23 Jahre 3 Tage; Krankheit: Brustkrankheit; Sterbeort: Oppershausen; Sterbetag: 1852 October 17.; Beerdigung: öffentlich, Octob. 22; Bemerkungen: Geboren in Gokenholz 14. Oct 1825
4 MIME text/plain
4 LANG du
2 AUTHOR Wienhausen Church
2 TITL Trauungen und Beerdigungen 1845-1852, Wienhausen
2 VOLUME Trauungen und Beerdigungen 1845-1852, or just: TrB 1845-1852
2 CHAPTER Gestorbene und Begrabene
2 SUBCHAPTER Sterbefälle
2 ITEMTYPE Church Register
2 FLEX INTEGER
3 PHRASE Year
3 CONTENTS 1852
2 FLEX INTEGER
3 PHRASE Pagenumber
3 CONTENTS 41
2 FLEX DESCRIPT
3 PHRASE Number
3 CONTENTS 35 w:18
2 WWWLINK
3 VALUE https://www.archion.de/p/373e7ccbcf/
1 NOTE Archion Bild Nr. 42
1 UID 0198e5f6-a7f7-7001-978c-ea0a211c99b1

The above CITA_STRUCTURE is inside the TEMPLATE

But I dont do that here again, because of the post length !

The ROLES section:

We now have the TEMPLATE and its including CITA part.

Now we look at the ROLES section of the template again. It already has the deceased wife and her husband, so 2 STICKYs.

• From the transcription we see info about the Birth, and the Burial. Those are in fact 2 other events. But what this TEMPLATE describes is the death event and each template only describes 1 (main) event.
  
  
  Unfortunately I cannot see the picture belonging to this, so I presumed it is the death event, not an obituary. That means the Birth and the Burial are mentioned here, but this TEMPLATE is not the official TEMPLATE of the birth, nor of the funeral itself. So those 2 (birth and funeral) are, what I called annotated or secondary events. We still need to find their official document later. But as they contain very important information from this transcript, we also give them a STICKY, but we kind of "label" that STICKY as annotated.
  That way their info is not lost, and also can be "hooked" in the proper INDI, but shows (for user and software), that these are not the official STICKYs. As those should have come from another TEMPLATE describing that official Birth or Burial event.
  
  Doing it this way we make sure no info is lost from the transcript.

This is what we have sofar:

1 ROLES
2 STICKY @ST01@               /* ROLE MAIN, WIFE, DECEASED Catharine Marie Meyer */
2 STICKY @ST02@               /* ROLE HUSBAND Johann Heinrich Hesse */

Now we add the "annotated" STICKYs.

1 ROLES                       /* Ann: stands for Annotated event */
2 STICKY @ST01@               /* ROLE MAIN, WIFE, DECEASED Catharine Marie Meyer */
2 STICKY @ST02@               /* ROLE HUSBAND Johann Heinrich Hesse, at death of Catharine */
2 STICKY @ST03@               /* Ann, Birth, Catharine Marie Meyer */
2 STICKY @ST04@               /* Ann, Funeral, Catharine Marie Meyer */
2 STICKY @ST05@               /* Ann, Marriage, Catharine Marie Meyer */
2 STICKY @ST06@               /* Ann, Marriage, Johann Heinrich Hesse */

When you have watched what I write in the code sections sofar, you will have seen how I use that /* */ comments. It would be alsmost impossible to figure out which STICKY belongs to whom, and what is inside it. I kind of summarize what should go in a STICKY before actually creating it. And later, when all is written, and I go over the GEDCOM, I use that comment in the STICKYs in the ROLES section, to get a faster view of all roles belonging to this template.

Without that comment I fear we are lost looking in that GEDCOM.

The STICKYs:

• Had problems with the UIDs. I understood it as the UIDs belonged to the INDIs, so I put them there. And the UID that belonged to the marriage (FAMS) is put in both annotated marriage STICKYs (Catherine and Johann). But I dont think thats correct, I suppose a UID can only be on 1 place. So we will need another solution for that as that UID too should be saved.

• The fact they are married is also represented in 2 extra STICKYs, but as that is an annotated event, coming from the original Template, those STICKYs are not the normal type PERSON, but are of type PERSON, AN_MARRIAGE, so it is clear there must have been a marriage, but sofar there is no official TEMPLATE for that. This way the fact they must have been married does not get lost. And software can see from the AN_MARRIAGE Sticky-type, that this is an annotation, NOT the official marriage itself. Same for the BIRT and the Funeral. These too get a STICKY but with type PERSON, AN_BIRTH and PERSON, AN_FUNERAL.

• When creating the STICKYs it's important to only put info inside a STICKY that belongs to the event of this STICKY.

  • Example: the STICKY of the deceased only gets the info that belongs to her death. So the name she had when she died, her age and more.
  • But not her birthday as that came from a birth TEMPLATE we do not have yet. That birthday goes in the annotated birth STICKY. Same for OCCU of the husband, that goes in the STICKY where he was mentioned in his wifes death event, but that OCCU does not go in the annotated STICKY of his marriage, as we dont know if he had that OCCU at that time.

• The husband: In his INDI, we also see RESI and DEAT. But the transcription does not mention them so I expect they come from another "TEMPLATE" and are inside the INDI from a merge ?? So I left them out.
  Other option is to put them in another new STICKY for Johann so they are still there, but I left that out for now. It could be added.
  So the "merging" makes it difficult to trace back where the info came from. If all was done with Templates this problem would not exist.

Now I know this sounds difficult.

But that is caused by the fact we are reverse engineering INDIs and not processing 1 TEMPLATE at a time, and just use the info we find on those TEMPLATEs.
Things are way easier if we process 1 TEMPLATE at a time.

The STICKYs :

0 @ST01@ STICKY               /* ROLE MAIN, WIFE, DECEASED Catharine Marie Meyer */
1 TYPE PERSON
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE MAIN, WIFE, DECEASED
1 NAME
2 FORM Catharine Marie Meyer
2 PART Catharine Marie
3 TYPE GIVN
2 PART Meyer                  /* Might also need another line to show /Meyer/ */
3 TYPE SURN
1 SEX F
1 DEAT                        /* Event from this Template ! */
2 DATE 17 OCT 1852
2 SPLAC @SP019@               /* Oppershausen, Celle DE-NI */
2 CAUS Brustkrankheit
1 AGE 27y 3d


0 @ST03@ STICKY               /* Ann: ROLE MAIN, CHILD Catharine Marie Hesse */
1 TYPE PERSON, AN_BIRTH       /* From the annotated birth event */
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE MAIN, CHILD
1 NAME
2 FORM Catharine Marie Hesse
2 PART Catharine Marie
3 TYPE GIVN
2 PART Hesse
3 TYPE SURN
1 SEX F
1 BIRTH
2 DATE 14 Oct 1825
2 SPLAC @SP033@               /* Gockenholz, Celle DE-NI */


0 @ST05@ STICKY               /* Ann: ROLE MAIN, WIFE Catharine Marie Meyer, Marriage */
1 TYPE PERSON, AN_MARRIAGE
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE MAIN, WIFE
1 NAME
2 FORM Catharine Marie Meyer
2 PART Catharine Marie
3 TYPE GIVN
2 PART Meyer
3 TYPE SURN
1 SEX F
1 AGE 27y 3d
1 MARR Y                      /* Annotated Event from this Template ! */
1 UID 0198e5f7-174c-7001-ad06-eeca267ef64b


0 @ST04@ STICKY               /* Ann: ROLE MAIN, WIFE Catharine Marie Meyer, Funeral */
1 TYPE PERSON, AN_FUNERAL
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE MAIN, WIFE,
1 NAME
2 FORM Catharine Marie Meyer
2 PART Catharine Marie
3 TYPE GIVN
2 PART Meyer
3 TYPE SURN
1 SEX F
1 AGE 27y 3d
1 BURI                        /* Annotated Event from this Template ! */
2 TYPE öffentlich
2 DATE 22 OCT 1852
2 SPLAC @SP019@               /* Oppershausen, Celle DE-NI */ 


0 @ST02@ STICKY               /* ROLE HUSBAND Johann Heinrich Hesse */
1 TYPE PERSON
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE HUSBAND                /* HUSBAND of MAIN, so of Catharine */
1 NAME
2 FORM Johann Heinrich Hesse
2 PART Johann Heinrich
3 TYPE GIVN
2 PART Hesse
3 TYPE SURN
1 SEX M
1 OCCU Köthner
2 SPLAC @SP019@               /* Oppershausen, Celle DE-NI */ 


0 @ST06@ STICKY               /* ROLE MAIN, HUSBAND Johann Heinrich Hesse, Marriage*/
1 TYPE PERSON, AN_MARRIAGE    /* Annotated event */
1 TEMPLATE @T001@
1 SUBM @B001@
1 TORIGIN ORIGDOC, COPIEDFRAG /* Derived from original document and code fragments */
1 QUAY 3                      /* Direct and primary evidence */
1 ROLE MAIN HUSBAND           /* HUSBAND of MAIN, so of Catharine */
1 NAME
2 FORM Johann Heinrich Hesse
2 PART Johann Heinrich
3 TYPE GIVN
2 PART Hesse
3 TYPE SURN
1 SEX M
1 MARR Y                      /* Annotated Event from this Template ! */
1 UID 0198e5f7-174c-7001-ad06-eeca267ef64b

The INDIs :

• As you can see for the INDIs it's just "hooking in" the correct STICKYs, in date sequence.
• The INDIs will contain more info but I left that out.

0 @I@ INDI
1 NAME
2 FORM Catharine Marie Meyer
~ ~ ~                         /* Rest of the name */
1 SEX F
1 ROLES                       /* Ann: stands for Annotated event */
2 STICKY @ST03@               /* Ann, ROLE MAIN, CHILD Catharine Marie Hesse, birth */
2 STICKY @ST05@               /* Ann, ROLE MAIN, WIFE Catharine Marie Meyer, marriage/
2 STICKY @ST01@               /* ROLE MAIN, WIFE, DECEASED Catharine Marie Meyer */
2 STICKY @ST04@               /* Ann, Funeral, Catharine Marie Meyer */
1 UID 0198e5f6-a8b2-7000-b347-a242188ac1ba


0 @I@ INDI
1 NAME
2 FORM Johann Heinrich Hesse
~ ~ ~                         /* Rest of the name */
1 SEX M
1 ROLES                       /* Ann: stands for Annotated event */
2 STICKY @ST06@               /* Annotated, Marriage, Johann Heinrich Hesse */
2 STICKY @ST02@               /* ROLE HUSBAND Johann Heinrich Hesse, death Catharine */
1 UID 0198e5f8-0a46-7001-8235-956b17ec1f2d

Hope this makes things a bit clearer.

[albertemmerich]

@mother10
Thank you very much for this long post. And doing it manually, not suppoerted by an application, is really hard to do! So I am happy to have an application for my data ... :-)

Before I start to go through all your records, first some remarks to your interpretations (sorry for choosing an example with a www-link after a paywall):

• there are no burial records other than this record. It is the only official record, and it is documenting both the death and the burial.
• husbands' death and resi.plac are taken from this record: the resi.plac is directly shown in the record , together with the occupation ("Kötner in Oppershausen"), for the death (AFT OCT 1852) you have to know, that spouses who already died before, are called "weiland" (deceased) in the record. If that is missing, the spouse is alive. By that this record gives his death after the event "death of Catharine Marie"). This kind of information is very helpful, if you have more than 1 person with that name at that place at that time! Therefore I extract it from the record.
• it is correct that UID is identifying one and only one record in my system.

More statements will come shortly.

[mother10]

Happy with your comments Albert. I get the feeling you seem determined to understand what it is all about.

Very much appreciate that! 😊 👍

[albertemmerich]

But that is caused by the fact we are reverse engineering INDIs and not processing 1 TEMPLATE at a time, and just use the info we find on those TEMPLATEs.
Things are way easier if we process 1 TEMPLATE at a time.

I started with one record of an official source (church book of Wienhausen), there should be no reverse engineering. That's only because you cannot see the entry, but that is the reason I gave the full text of this record. You have it in full length in your CITA.TEXT.

So let us go to the "easy" case of 1 TEMPLATE. But I understand we only have one TEMPLATE here. You have only 1 CITA for the complete record, and that is put as part of the 1 TEMPLATE.

But to make it clear how this TEMPLATE system is to work, I chose an example with more than 1 event in it - it has death and burial of Catherine Marie, and it has her birth, too. And it mentions her husband and by that states that there was a marriage without telling details about that.

So, please confirm (or correct me): This record will get exactly one TEMPLATE, in it the CITA giving the full text of the record and much more data.

Next: I am very surprised to see 3 annotated stickys for Catharine Marie, beside her "main" sticky @ST01@. Our record taken from primary source states, that all events (birth, marriage, death, burial) are events in one person's life (Catharine Marie). So separating these in 4 stickys we are left with the task to later combine these stickys again (and many more from other records) to one real person with all her events in life.
Why first put it in so small pieces, and by that increase the work to do putting them together again later? So seeing this your stickys are not the persons which I create from a record: I do not have 6 'stickys' by our example record, I only have 2 'temporary persons': Catharine Marie as the main person in the record, and Johann Heinrich Hesse as her husband. All information which describes Catharine Marie I put in her 'temporary INDI record'. Proceeding further in research I look for other 'temporary persons' who fit, and all together build the real person Catharine Marie, including her parents (in most cases from a birth or baptism record, sometimes only by marriage record), her children (by childrens' birth/baptism/marriage/death records), and so on. But this task seems to be much more complicated, if several stickys are created to carry only one event each...

So what is the reason for this splitting in so many stickys. What do you do using them, what cannot be done by 'temporary persons'?

Next question: Why do you put "1 AGE 27y 3d" to @ST05@? This is the sticky for the marriage - but the age is reported for her death. The record does not say anything about her age at marriage.

Next: The TEMPLATE. I have not yet understood why we need this new type of record. So trying to understand, I look at all details I see there. Some parts I do not use in my model. ROLES.STICKY is doubled information, as the stickys cite the TEMPLATE - my temporary persons (and real persons) cite the SOURCE_CITATION record. 1 AGCY is a property of the source (church book Wienhausen). What is "1 SUBM @B001@"? May be the person who interpreted the record and build the TEMPLATE / CITA? This is included in my model in the SOURCE_CITATION record itself, as is the date of the event...

So the main questions are: Can we simplify your model by skipping the TEMPLATEs (only use CITA records), and by reducing the number of STICKY by only creating one sticky per person in the record, this persons participating in one or more events documented in the record - without loosing information we need for next steps of research?

A independant question is, whether we double any information in the GEDCOM code only to make it easier for humans to read the code directly. As I let the application do the work for me to get the connections in between the data in the GEDCOM code I definitively prefer to put in any information once and only once. So I do not like todays CHIL - FAMC doubling neither HUSB / WIFE - FAMS. I get files in which these pairs of information mismatch - the only thing I know in that moment: The code is false...

[mother10]

The answer to the above has already been given privately, but as it might be important for others too, here is a new scheme, explaining much of the above.

📝 Description of the schematic: Death Record (with secondary events)

This diagram shows how SOURCE, TEMPLATE, and STICKY fit together in the case of a death record, structured in the new model:

1. Source block (SOUR3, pink box)

   • Represents the overall source, in this case a book of death records.
   • Holds its own metadata, like type of record, archive, or repository info.
   • Contains its own event list (e.g., DEAT entries recorded in the book).
   • From here, one specific entry (death event) connects to the TEMPLATE.

2. Template block (TEMPLATE5, blue box)

   • Anchors the single death record entry in that source.
   • Contains the main event type (yellow: EVENT – DEAT, with DATE and SPLAC).
   • Holds one unified citation (pink: CITATION7), which can include:
     • Full transcription text of the entry. (citation text CITATION7)
     • Reference details such as page, line, or record number.
     • Connects back to the SOURce.
   • Collects all participants in its ROLES section (Green STICKYs 01–03).
   • Bottom space for FLEX/meta info: seals, authenticity, registrar’s initials, condition of document, or any other metadata that doesn’t belong in a sticky.

3. Sticky block (STICKY 01, green box)

   • Tied directly back to the TEMPLATE’s event.
   • Defines the person’s role in the record, here: MAIN, DECEASED.
   • Holds all facts tied to this person in this document: NAME, AGE, OCCU, RELI, etc.
   • Can also include secondary events mentioned in the same document:
     • Example: date/place of birth, implying a BIRT event.
     • Example: mention of a wife, implying a MARR event (even if no details given).
   • Has its own FLEX area for extra detail tied to this participant.

4. Connections

   • Blue arrows: SOURCE → TEMPLATE → STICKY (flow of event context and place/date).
   • Red arrows: CITATION → each STICKY (all participants share the same source text).
   • Green arrows: TEMPLATE ↔ STICKY (role-based connection: each participant tied back to the same main event).

👉 Flow of information

• Current GEDCOM: scattered citations, each manually linked to tags like DEAT, BIRT, etc. → “spiderweb.”
• New model:
  • SOURCE (book) → TEMPLATE (death record entry + citation + ROLES + metadata) → STICKY (participant with role, facts, secondary events).
  • A clear, straight pipeline of "evidence" → event → roles → facts.

---

🔄 Comparison with the old GEDCOM model

In the old GEDCOM design, a DEAT fact would sit under the INDI record, and a citation would be attached to it. If the death record also mentioned the person’s birth date or spouse, those would be entered as separate BIRT or MARR tags under the INDI, each with their own dangling citation links. The result is a scattered “spiderweb” of links — the user has to manage them by hand, and the connection to the original document is fragmented.

In the new model, the TEMPLATE anchors everything:

• The citation text is stored once at the TEMPLATE level.
• Each STICKY then ties the citation to a participant role, keeping facts and secondary events together in one place.

Instead of a web of many-to-many links, we now have a straight pipeline:

SOURCE → TEMPLATE → STICKY → facts

This preserves the document as the starting point, avoids duplication, and makes secondary events naturally connected with the right role context.

In fact, a STICKY now becomes a "Lego-block", that can be tied to whatever we want (INDI, GROUP, and many more), without loosing any fact or any connection to where it came from.