Add BIRT.KIND BORN_DEAD in v7.1

[tychonievich]

This is part of the actions recommended in #106

[Norwegian-Sardines]

The relation between TYPE and KIND is that TYPE will most likely be eliminated in the future and be replaced with KIND.PHRASE for human readable information! This is what I envision advocation when I introduce various <fact>.KIND for tags like MARR, BURI, and maybe others I can’t recall right now. Ken On Tuesday, November 11, 2025 at 11:49:35 AM MST, Dave Thaler ***@***.***> wrote: @dthaler commented on this pull request. In specification/gedcom-3-structures-3-meaning.md:

@@ -298,6 +298,17 @@ See also `INDIVIDUAL_EVENT_STRUCTURE`.

An [Individual Event](#individual-events). See also `INDIVIDUAL_EVENT_STRUCTURE`. +#### `KIND` (Birth Kind) `g7:BIRT-KIND` + +An enumerated value from set `g7:enumset-BIRT-KIND` indicating the type of birth. + +There is some conceptual overlap between `BIRT`.`TYPE` and `BIRT`.`KIND`: + +- `BIRT`.`TYPE` is preferred for general-purpose human-readable information elaborating on the birth type. +- `BIRT`.`KIND` is preferred for information that informs some programatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`). ⬇️ Suggested change-- `BIRT`.`KIND` is preferred for information that informs some programatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`). +- `BIRT`.`KIND` is preferred for information that informs some programmatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`). typo In specification/gedcom-3-structures-3-meaning.md:

@@ -298,6 +298,17 @@ See also `INDIVIDUAL_EVENT_STRUCTURE`.

An [Individual Event](#individual-events). See also `INDIVIDUAL_EVENT_STRUCTURE`. +#### `KIND` (Birth Kind) `g7:BIRT-KIND` + +An enumerated value from set `g7:enumset-BIRT-KIND` indicating the type of birth. + +There is some conceptual overlap between `BIRT`.`TYPE` and `BIRT`.`KIND`: + +- `BIRT`.`TYPE` is preferred for general-purpose human-readable information elaborating on the birth type. +- `BIRT`.`KIND` is preferred for information that informs some programatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`). + Should we say something about the relationship between TYPE vs KIND.PHRASE? Are they semantically the same or different, when KIND BORN_DEAD is used? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Norwegian-Sardines]

Originally I had hoped to change <fact>.TYPE to be an enumerated list with “other” and phrase as an option! Since I’ve been told we can’t do that until v8.0, I’ve come to the conclusion this needs to be done using <fact>.KIND and eventually removing TYPE. I currently use “stillborn” in BIRT.TYPE and “civil”, “religious”, “common law” in MARR.TYPE, “cremated”, “grave”, “columbarium”, “at sea” in BURR.TYPE and “murdered”, “accident”, “combat” in DEAT.TYPE. So it is natural for me to consider these as possible enum values in either a TYPE or KIND, but having both is illogical to me!

[webtrees-pesz]

It is also not entirely clear to me why TYPE has to be replaced by KIND.
Why is it not possible to allow enumerated "and" user-defined values in a mixed form for TYPE in version 7.x, as it was practiced in 5.5.1 for NAME_TYPE, ROMANIZED_TYPE and PHONETIC_TYPE?
A minor version allows additional data valid if there is no change in the semantic meaning.
With the next major release, the step to a pure enumerated list with OTHER and PHRASE can then be taken.

[Norwegian-Sardines]

It is also not entirely clear to me why TYPE has to be replaced by KIND. Why is it not possible to allow enumerated "and" user-defined values in a mixed form for TYPE in version 7.x, as it was practiced in 5.5.1 for NAME_TYPE, ROMANIZED_TYPE and PHONETIC_TYPE? A minor version allows additional data valid if there is no change in the semantic meaning. With the next major release, the step to a pure enumerated list with OTHER and PHRASE can then be taken.

From my perspective I don’t quite understand why TYPE can not be augmented either, but if TYPE is used as an enum it must also allow for “other” and .PHRSE for those small instances where the enum does not cover a value the data entry person would like to enter!

[albertemmerich]

@webtrees-pesz "Why is it not possible to allow enumerated "and" user-defined values in a mixed form for TYPE in version 7.x, as it was practiced in 5.5.1 for NAME_TYPE, ROMANIZED_TYPE and PHONETIC_TYPE?"
GEDCOM 7.0 is more clear in its structure - mixture of different types of payloads is replaced by well defined structures. If there is need to have enumerated values and free text, too, we have the PHRASE tag in 7.0 for the text values. We should not fall back to the way GEDCOM 5.5.1 handled this!

[webtrees-pesz]

As I wrote, only as a temporary form until the next major release.
In my opinion, this makes more sense than using TYPE and KIND in parallel, because that only confuses the users!
If you are against the mix as a temporary form, then you should wait with a change to 8.0 and continue to use TYPE in the next major release.

[albertemmerich]

I agree that using both TYPE and KIND in parallel will give a lot of problems for users to put data in the correct data field.
Therefore I would prefer to have KIND including a payload OTHER allowing user defined payloads, too.

@Norwegian-Sardines (3 days ago):

I don’t know of any software other than the one I use that supports .TYPE!

My application does - and it is heavily used by its users. Especially when putting in occupations. Moreover my users are asking for a language-independant solution for born dead, so I recommended to start with

1 BIRT
2 TYPE totgeboren

and will transform that automatically to

1 BIRT
2 _KIND BORN_DEAD

in next version (coming in some days). Whatever the standard will decide: I will stay with an enumerated payload for born dead, being able to translate to other languages by application. I hope 7.1 will have a solution. If not, I stay with the extended version waiting for a solution in 8.0.

[albertemmerich]

Only as additional information:
The actual version of my application already offers to classify NOTE payloads by NOTE._KIND. Used to separate additional genealogical data put in NOTE from comments saying something about steps done in research, or steps still to be done, or about the status, if the research not yet showed a solution confirmed by primary sources.

[Norwegian-Sardines]

My application does - and it is heavily used by its users. Especially when putting in occupations.

Ok, that is two. I know that the major applications in the UK and US don’t and I’m sure there are more users in those than the one we use!

How does OCCU need to have an OCCU.TYPE and how does that work with the major ones from the US and UK?

Example:

1 OCCU Farmer
2 TYPE ?

1 OCCU Salesman
2 TYPE ?

1 OCCU Programmer
2TYPE ?

Just asking so I understand how it works!

[tychonievich]

Discussed in steering committee

• Many of the concerns are around KIND.PHRASE and its duplication with TYPE. We do not know how to unambiguously remove that duplication, so we think KIND.PHRASE should not be included here.
• Another concern was about adding a KIND at all instead of augmenting TYPE to allow a mix of enumerated and free-text entries.
  • We did consider how to add a "Enum if it matches that syntax, Text if it doesn't" type, and it is technically possible to add
  • However, adding that as the data type of TYPE would be backwards incompatible: if an existing file has e.g. BIRT.TYPE TWIN that is human text in 7.0 but if we changed the data type it would become and undefined (and thus not compliant) Enum instead.
  • 5.5.1 did have some mixed "enum or text" fields (e.g. NAME.TYPE) but this created incompatibilities in applications when users chose user-defined text over appropriate enums, and was removed intentionally from 7.0 to remove that source of incompatibility and bad data. We do not want to undo that fix.
• Hence, we are leaning toward removing KIND.PHRASE and committing the rest of this PR (adding BIRT.KIND)

There were many comments above, not all of which were easily summarized. If we have missed some point, please let us know.

[Norwegian-Sardines]

Copied from #106

My understand of the above statements (which could be wrong!) is that "the committee" wants to move forward in v7.1 with only an update to the BIRT tag by adding an enumerated BIRT.KIND tag to support the birth state of "born dead". My understanding leads me to think that the following structure would be the solution, (again, I could be misunderstanding the directive). NOTE: that the cardinality allows for multiple BIRT.KIND entries so that at any time we can add new enum values that could be inclusive, i.e. BORN_DEAD + CESAREAN. ALSO NOTE: The BIRT.TYPE tag in GEDCOM v7.1 will continue to be used for free-form subsets of the BIRT tag, but this could be deprecated later in GEDCOM v8.0 if desired.

n BIRT [Y|<NULL>]                          {1:1}  g7:BIRT
  +1 TYPE <Text>                           {0:1}  g7:TYPE
  +1 KIND <Enum>                           {0:M}  g7:BIRT-KIND
  +1 <<INDIVIDUAL_EVENT_DETAIL>>           {0:1}
  +1 FAMC @<XREF:FAM>@                     {0:1}  g7:FAMC

KIND (Kind) g7:NAME-TYPE
An enumerated value from set g7:enumset-BIRT-KIND indicating the kind of the birth.

g7:enumset-BIRT-KIND

Value	Meaning
BORN_DEAD	A fetus that has died during pregnancy, at or after the 20th week of gestation, antepartum or intrapartum.
BORN_LIVE	A live birth

NOTE: An update to the definition of "BORN_DEAD".

These concepts then can be used in future versions of GEDCOM (v7.2, 7.3, etc) for other tags (MARR, DEAT, BURI, etc) that warrant a refinement/extension using the <fact>.KIND construct.

[tychonievich]

We've made the changes suggested above (removing PHRASE and add BORN_LIVE). We still have some incorrect URIs (for example BIRT should now be v7.1:BIRT not v7:BIRT) which need fixing before we merge this PR. Approved by steering committee pending those updates and a final check to ensure they were made correctly.

[tychonievich]

Because this PR creates a new v7.1 enumset and enum values, it runs into the specification and tooling issues in #727

[dthaler]

Also change line 180 of gedcom-1-hierarchical-container-format.md.

[dthaler]

Suggested change

	- `BIRT`.`KIND` is preferred for information that informs some programmatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`).
	- `BIRT`.`KIND` is preferred for information that informs some programmatic behaviors, such as creating a list of persons who were ever live (`BORN_LIVE`).

Either that or change "ever live" to "never live" if you keep BORN_DEAD

[Norwegian-Sardines]

Or for reports and displays that require translation to languages different from the entered language!