Change NOTE and SNOTE to include a NAME (Note Title)

[Norwegian-Sardines]

All instances of a record type should have some way beyond the XREF key to visually identify (in a list or display) the content of the record instance. Submitters (SUBM) records have a NAME, Individuals have a NAME, Sources (SOUR) have a title, Media Objects (OBJE) have a FILE name and a TITL, Repositories (REPO) have a NAME, but a Note Record (SNOTE) and inline notes NOTE does not have a tile or name tag.

In cases where I create a inline NOTE or SNOTE record the content of the tag needs a title/NAME so that when the note is placed in a selection list or as part of a report the content can be ascertained without opening or reading the entire note.

Example 1, A collaborator makes comments about an asserted attribute they added to an individual., family or source. Such as, "The reported age at death does not calculate based on the birth date. Either the birth date and the source that provided it are wrong or the given age at death provided by the source is wrong." A title like "Age Dispute" might be valuable. This way when listing all notes for an individual we can see that what they contain.

This change would require NOTE and SNOTE to be reorganized as follows:

n NOTE
+1 NAME <Text>
+1 TEXT <Text> 
+1 MIME <MediaType> 	
+1 LANG <Language> 	
+1 TRAN <Text> 		
+2 MIME <MediaType> 	
+2 LANG <Language> 	
+1 <<SOURCE_CITATION>>

n @XREF:SNOTE@ SNOTE
+1 NAME <Text>
+1 TEXT <Text> 
+1 MIME <MediaType>
+1 LANG <Language> 
+1 TRAN <Text> 
+2 MIME <MediaType> 
+2 LANG <Language> 
+1 <<SOURCE_CITATION>> 
+1 <<IDENTIFIER_STRUCTURE>> 
+1 <<CHANGE_DATE>> 
+1 <<CREATION_DATE>>

Examples:

n NOTE
+1 NAME Age Dispute
+1 TEXT The reported age at death does not calculate based on the birth date. Either the birth date and the source that provided it are wrong or the given age at death provided by the source is wrong.

n @X231@ SNOTE
+1 NAME Family Name Explained
+1 TEXT This family has several forms of the name depending on where they currently lived.  For example ... 

[tychonievich]

The adding of a title would not require moving the payload to TEXT; we could simply add g7:NAME (or g7:TITL) to the existing structure's set of substructures.

[Norwegian-Sardines]

The adding of a title would not require moving the payload to TEXT; we could simply add g7:NAME (or [g7:TITL)[https://gedcom.io/specifications/FamilySearchGEDCOMv7.html#TITL)) to the existing structure's set of substructures.

Then this addition could be added to v7.1 of GEDCOM!

[albertemmerich]

It is the same problem we are just discussing as a part of #694 .
There I proposed to differentiate NOTE by a substructure TYPE, or by a finer resolving substructure KIND with KIND.TYPE.

I think it is obvious that a solution like this would solve many problems we have today to enter research notes (not intended to be published in normal reports, but to be used to continue the research), research results intended to share within reports, and genealogical notes found as additional data which are to be shown to the reader of the report, making clear, that this is cited data and not added researcher's remarks.

As NAME has a very different function in other records, I would prefer a tagname like KIND, TYPE, TITL or something else not yet used in a different way in the standard.

But I vote to implement a solution like this!

[chronoplexsoftware]

There I proposed to differentiate NOTE by a substructure TYPE, or by a finer resolving substructure KIND with KIND.TYPE.

A mechanism for categorising or tagging notes would be useful. We are currently using an extension tag to mark notes which have specific use(s) within an application context, with a payload which behaves as a g7:type-List#Enum. For instance, we see several applications use a note to record a detailed story or history of an individual (either human generated or automated), often with the intention of being included in reports. This has a distinct and separate meaning from any other notes that may have been made, for instance research comments.

As to whether notes need a dedicated title field is less clear. In a formatted note (using HTML or Markdown) there exists the option to give a note a title (albeit, indicated using formating codes, and in a plain text note, maybe the first line) which could have the potential for data duplication. Some applications do use note titles (we don't, but when direct importing databases, this information prepended to note text, if it doesn't already match the first line of the note).

Either way, the concept of a "title" describing the note and that of a "tag" describing its use are subtly different concepts which we'd like to see further dicussion on inclusion in a future version.

[Norwegian-Sardines]

This proposal was made specifically to provide for a name or title for the SNOTE or NOTE not to create a categorization of the note by using a TYPE or KIND.

I see these as two different (although useful) use cases! Maybe they go together, but at this time they are should be separate proposals.

[jl5000]

I would also support this. Currently I am just printing the first n characters of the note as an identifier, so not ideal. A TITL tag would be more intuitive though.