Draft NOTE.TYPE and HEAD.NOTE cardinality

[tychonievich]

Based on #219 and #687, using a single NOTE type for all contexts. The table of enumerated values is probably not the right one, but there were far more proposed in #219 than I have any confidence in describing.

[dthaler]

OTHER.PHRASE is fine, but means that the other items above should only be added if they need to be machine-detectable. Some definitely do, but I am not sure that all the other values have sufficient justification. it might help to put the justification in the Meaning column.

I also observe that https://gedcom.io/specifications/FamilySearchGEDCOMv7.html#enumset-ord-STAT has an "Applies to" column when not all values fit in all contexts. If we do use the same enumset for HEAD.NOTE, then I think we may need an "Applies to" here as well. For example, a "life sketch"/"bio" applies to an individual note type, and I believe has a sufficient case for being machine detectable, but not a HEAD.NOTE.TYPE.

[tychonievich]

Discussed in steering committee

• Applies To might make since for something like "Life Sketch", though past issues suggested we might want to make that an INDIVIDUAL_ATTRIBUTE instead. That said, "Life Sketch" seems likely to have ended up in NOTE in the past.
• OTHER.PHRASE lets applications use the PHRASE as headers or other navigation information to help users navigate the set of notes.
• Naming this NAME.TYPE if it's an enum matches the rare case of NAME.TYPE rather than the common text-payload TYPE naming. It might be better to call this NOTE.KIND instead.
• One nice future solution (8.0) would be to have all cases use KIND and OTHER PHRASE instead of a mix of enum and free-text TYPE. But for 7.1 we can't do that everywhere (it's not backwards compatible), though we can use KIND to move in that direction.
• One criterion for what enums to include would be an application decision point that depends on the value. If we can find those, we could/should add them to the table.
  • An example might be LIFE_SKETCH which is often displayed in a different place/way than general notes.
  • Another example is import notes are generated during GEDCOM import to provide information about the import process itself. Similar technical notes might be part of merging files. These notes are unlike human-generated notes and UIs might wish to separate the two kinds of notes (possibly even preventing users from overwriting/editing the technical log notes). We might name this IMPORT_LOG or TECH_NOTES or CHANGE_LOG or the like.
  • Another example is TODO which some applications have a way of displaying in a report of things that need doing.
  • Some users wish to have AI_GENERATED flagged as separate from human-generated. That might suggests a KIND <List:Enum> {0:1} or KIND <List:Enum> {0:M} instead of KIND <Enum> {0:1}.
    • Because we can envision substructures of KIND (such as human text clarifying what variety of TODO it is), {0:M} might be preferable.
  • There is work to do to decide which other proposed KINDs are programmatically important.

To do:

• Change from TYPE to KIND.
• Fix the g7.1: prefix for (transitive) superstructures.
• Think more carefully about the programmatic value of each value in the table, and explain that value in the table.