Conversation
This is part of the actions recommended in #106
tychonievich
requested review from
albertemmerich,
clarkegj,
dthaler and
lynchrs3
as code owners
|
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: ***@***.***>
|
Co-authored-by: Dave Thaler <dthaler1968@gmail.com>
|
Originally I had hoped to change |
|
It is also not entirely clear to me why TYPE has to be replaced by KIND. |
From my perspective I don’t quite understand why |
|
@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?" |
|
As I wrote, only as a temporary form until the next major release. |
|
I agree that using both @Norwegian-Sardines (3 days ago):
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 totgeborenand will transform that automatically to 1 BIRT
2 _KIND BORN_DEADin 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. |
|
Only as additional information: |
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 Example: Just asking so I understand how it works! |
|
Discussed in steering committee
There were many comments above, not all of which were easily summarized. If we have missed some point, please let us know. |
|
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 KIND (Kind) g7:NAME-TYPE
|
| 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.
|
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. |
|
Because this PR creates a new v7.1 enumset and enum values, it runs into the specification and tooling issues in #727 |
| 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 programmatic behaviors, such as creating a list of persons who were ever live (`BORN_DEAD`). |
There was a problem hiding this comment.
| - `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
There was a problem hiding this comment.
Or for reports and displays that require translation to languages different from the entered language!
Closes #727 Unblocks #722 and #723 There's a lot going on here, and I spent several weeks trying to minimize this PR, split it into pieces, etc, but couldn't find a way that worked. So here's an outline of what's changed. 1. In the spec, many tables (notably enumsets) now have an explicit URI entry. I made the URIs their own column, not the two-line cells used for URIs of events and attributes earlier, mostly because I thought we have space. We can refactor that into using <br> if we prefer. 2. I re-wrote `build/uri-def.py` from the ground up as `build/extract-yaml-tsv.py`. `uri-def.py` was a 50-line script I wrote that I slowly changed into a 500-line monstristy that I find almost impossible to read or maintain. And it had many assumptions about the spec's format not only in its code (that's inevitable when parsing human text into machine-readable files) ubt also in its design. Trying to add the more versatile URIs was such a headache I decided to use it as an excuse for a long-verdue re-write. `extract-yaml-tsv.py` uses classes to have the code mirror the files it is designed to produce. It uses type annotations (which pass `mypy`) to avoid various typing bugs. It tries to do one thing in one place instead of doing all things possible everywhere. It's 100 lines longer than `uri-def.py` but faster to run and easier to maintain. I spent some effort to match ideosynracies of `uri-def.py`, like when to use `strings`, `'strings'`, or `"strings"` in the emitted YAML; but sometimes dong that was not possible without replicating `uri-def.py`'s worse parts, so there are some trivial changes (notably in the order of lists) in the files it creates. 3. I (accidentally) fixed various bugs of omission. `uri-def.py` was sloppy in how it handled the textual explantions in sections that had either gedstruct rules with alternatives or tables. Fixing that with a more principled approach means adding extra `specification:` entries for around half of all YAML files. 4. I tried but failed to match the sorting of the various .tsv files from `uri-def.py`, which was based on some kind of sorting of structures before they were used to generate multiple lines each. I was tempted to scrap that and simply sort the final lines, which is easy and well-defined, but this commit does not do that, instead doing a half-hearted effort at mimickiing the old sorting. I did all this on 7.1 because that was the original motivation, but if we like it I can port it back to the 7.0 branch (either by adding explicit URIs to the 7.0 spec or by adding special-case handling of tag-to-URI) with relative ease.
5 participants
This is part of the actions recommended in #106