Add BIRT.KIND BORN_DEAD in v7.1

[tychonievich]

This is part of the actions recommended in #106

[dthaler]

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? That is, what is the difference between

1 BIRT
2 TYPE totgeboren
2 KIND BORN_DEAD

vs

1 BIRT
2 KIND BORN_DEAD
3 PHRASE totgeboren

?

(or pick any other word, like "stillborn" or whatever else)

[tychonievich]

I'm happy to add something about that, but don't know what to say. Use TYPE because it's older and better supported? Use PHRASE when it applies because it's more precise? Use both because why not? Or do we remove KIND.PHRASE entirely because TYPE is the preferred place to put human-language type information?

[Norwegian-Sardines]

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

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!

[Norwegian-Sardines]

As a programmer I would normally like to have data coming from one place.

[dthaler]

https://github.com/familySearch/GEDCOM?tab=readme-ov-file#branches says:

• v7.1 contains a working draft of the next minor release. Changes from main have been discussed and approved by the working group supervising the next minor release, meaning they are (a) minor, not major, changes, as described in A Guide to Version Numbers and (b) have been judged as meeting all three of the following criteria for inclusion:
  [...]
  • Absent: they are meaningfully distinct from, and not merely a more detailed subtype of, existing structure types

One could argue that KIND.PHRASE in 7.1 would fail the "Absent" test, given the existing presence of TYPE. Passing that criteria I think would require explaining a semantic difference between the two, and when to use each one.

[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!