Proposal: Allow the header to have general Notes.

[mother10]

Since two of the programs I currently use allow users to not only have NOTEs inside GEDCOM, at places the current specification allows them.

But also because more users can have the need to somehow add Notes to a tree, that do not belong to a record. For instance general remarks about the tree, or the way they created their tree, or other things, this proposal adds the following to the HEAD:

Instead of:

  +1 <<NOTE_STRUCTURE>>                    {0:1}
  +1 <<CHANGE_DATE>>                       {1:1}
  +1 <<CREATION_DATE>>                     {1:1}

at the end of the HEAD it proposes:

  +1 <<NOTE_STRUCTURE>>                    {1:M}
  +1 <<CHANGE_DATE>>                       {1:1}
  +1 <<CREATION_DATE>>                     {1:1}

If this should clutter the head too much other solutions are welcome, but allow users somehow to add these kind of notes.

If another solution is chosen, I suggest to still have NOTE in the header as {1:1}, to allow software to describe for instance a conversion from 1 GEDCOM version to another.
Many years have passed before the release of GEDCOM 7, and many files will now be converted since that release.

But until now there is no way to somehow describe that conversion process. We have Notes and CREA and CHAN now to somehow track changes, but a conversion, which to me is an important process, cannot leave any trails it happened, when it happened, what file was involved and possibly more things, anywhere in GEDCOM.

Users feel the need to be able to carefully describe their choice for one INDI above another, but the whole conversion process happens a bit "in the dark".

[Norwegian-Sardines]

Your justification for requiring a HEAD.NOTE is based on conversion to GEDCOM v7. Why would I be required to have a HEAD.NOTE if I'm creating the tree or GEDCOM for the first time? Software is allowed to create this payload, forcing them to enter something that is unknown in a fresh start does not make sense to me!

I agree that software should allow a user to add general HEAD.NOTE entries (many do not at this time) but to require them to have a one is not what I would want.

[mother10]

Why would I be required to have a HEAD.NOTE if I'm creating the tree or GEDCOM for the first time?

Because it is easier to make it {1:1} then to make extra rules saying, the first creation of a file is an exception.

It is not the user that enters the info, it is software, and its very easy to let that fill the note with something like "first creation with software xx on yy etc".

So i dont see the problem.

[Norwegian-Sardines]

Because it is easier to make it {1:1} then to make extra rules saying, the first creation of a file is an exception.

And the application could just put “hello dolly” in the NOTE and your requirement is satisfied. I love the idea (I really do) of having the application pass along the information about the process they used to convert from v7 to v8, but I don’t expect them to really put much effort into putting much thought into it or change the message they put there when the import a v7 GEDCOM when they are on the 4th or 5th update of their software.

And, who will enforce the cardinality that requires the information? They could just ignore the requirement all together!

[fisharebest]

I would be happy to have this {0:1}, but not {1,1}. Although I can't see myself using it.

NOTE fields are allowed to be empty in GEDCOM 7 (though not in GEDCOM 5.5.1).

So having a mandatory field that can be empty seems pretty pointless.

Similarly, in GEDCOM 5.5.1 HEAD:SUBM was {1,1}, so my software (and others) just creates a dummy SUBM record to satisfy GEDCOM validators.

[fisharebest]

Since these notes would come from each of the contributors to the tree, might they be better stored as SUBM:NOTE. This would associate them with their author.

[mother10]

@fisharebest

Yes they could be SUBM.NOTEs. But neither software I use does that. Maybe a remark with that SUBM.NOTE would help?

But that is still different from heaving a way to describe information from a conversion. That should not be mixed with general Notes from a submitter.
But thats what I think.

For 1 of the programs I use, these developer Notes are stored, completely separate from the GEDCOM, so as a different file. And if a GEDCOM file is renamed outside that program, the notes are "gone".

NOTE fields are allowed to be empty in GEDCOM 7 (though not in GEDCOM 5.5.1).

Hmmm, what is the use of an empty NOTE field, any idea why that was changed?

[tychonievich]

Discussed in steering committee 23 SEP 2025

• Changing this to {0:M} could be done in next minor
  • Allowing multiple notes may be particularly impactful if Add TYPE to note structures #219 adds NOTE.TYPE
• Changing this to {1:1} or {1:M} would be a major change, and we are not seeing the need for it
• The change in 7.0 to allow zero-length notes (where 5.5.1 required at least one character) was because of 7.0's removal of payload length bounds. We don't see 1-character notes as being useful, and so don't see allowing 0-character notes as being a significant change from 5.5.1: both allow users to create notes that contain no information if they want.
  • A note with no payload can be used to get a SOUR (via NOTE.SOUR) where a SOUR is not permitted in the specification. We know of users and applications who do this to approximate SOUR.SOUR; the steering committee are split on if this is a good or bad thing.
• We plan to use this issue to track the proposal to change HEAD.NOTE to have cardinality {0:M}. If people wish to continue discussing {1:1}, {1:M}, or other topics we encourage creating a separate issue for that.

[albertemmerich]

Additional remark to @mother10 Aug 22: In my application the user is writing the content of HEAD.NOTE. We have a description of the content, and main steps done to find the content, The application adds information for actions like importing gedcom files. It is important: It adds this information, no information is deleted by the application.
This use case could be better handled if we

• have {0:M} cardinality for HEAD.NOTE
• have a substructure to show whether it is description, reporting of an action, or something else the user wants to put in.

So HEAD.NOTE should be {0:M} and have a HEAD.NOTE.KIND substructure.

[tychonievich]

Discussed in steering committee

• We agree that there is enough need for and use of {0:M} header notes, we should add that to v7.1. Because many GEDCOM files do not have HEAD.NOTE values, we will not use {1:M}.
• We agree that there is enough demand for HEAD.NOTE.KIND (as witnessed by the kinds of notes mentioned in this thread) that we should add that to v7.1. We anticipate KIND being an enumeration value, and likely distinct from a more general NOTE.KIND because there appear to be different use cases for HEAD.NOTE.KIND compared to (e.g.) INDI.NOTE.KIND.
  • A set of enumeration values are still needed. Maybe {progress of research, description of content, provenance/creator of the dataset, inputs/what has been considered to create the dataset}. We would need to distinguish these from HEAD.SOUR.DATA (and possibly other HEAD substructures).

[mother10]

@albertemmerich Yes I agree to that!

@tychonievich Great that is a big improvement! And ok if there are many files withoud HEAD.NOTE, we do {0:M}.
And the KIND as an enumeration that will be very helpfull too.
🥳 😇

[tychonievich]

I have some follow-up design questions as I tried to draft this for 7.1. In 7.0, HEAD has a <<NOTE_STRUCTURE>>, the same as other structures. I see two paths forward.

Option 1: we make separate HEAD-NOTE and HEAD-SNOTE uris with their own TYPE/KIND substructures. That lets us have distinct enums for distinct contexts; INDI-NOTE's TYPE/KIND could have LIFE_SKETCH while HEAD-NOTE and REPO-NOTE would not.

Option 2: we make a single NOTE.TYPE (or NOTE.KIND, I'm not picky about the name) that has values suitable for many contexts, including some (like "inputs/what has been considered to create the dataset" and "life sketch") that make sense in only a few places and others (like "todo" and "research notes") that make sense in many places.

I'm leaning toward option 2, but am open to other opinions.