GEDCOM NOTE_RECORD vs. embedded note

Question

I'll start off with a little GEDCOM background information before firing off my questions.

The GEDCOM 5.5.1 specification distinguishes record structures (which have xref-ids) from substructures which are contained in records.

For notes, there is a NOTE_RECORD and a NOTE_STRUCTURE. The NOTE_STRUCTURE substructure is embedded by many other records and substructures. The NOTE_STRUCTURE is essentially a wrapper to either an embedded note or a reference to a NOTE_RECORD via its xref-id.

---

My questions are from the perspective of a GEDCOM writer:

When should a note be embedded and when should it be a stand-alone record? Are there any applications that have an explicit interface to generate NOTE_RECORDs?

I am trying to simplify my GEDCOM writer while not limiting its future expansion. I can visualize an application that offers the user an opportunity to enter free-form notes (as NOTE_RECORDs) that could later be referenced in other contexts. A NOTE_RECORD also offers the opportunity to enter a source citation, user reference, and change date.

It seems to be more common that notes are entered in the context of some other record type, and in that case it is easier to implement them as embedded.

Answer 1

"When should a note be embedded and when should it be a stand-alone record?" Unhelpfully, perhaps - whenever the user requests it... (but see later)

"Are there any applications that have an explicit interface to generate NOTE_RECORDs?" I thought PAF did, I know my application (Family Historian) does.

"It seems to be more common that notes are entered in the context of some other record type, and in that case it is easier to implement them as embedded." Easier, yes. But if I want to create a common note, accessed from several points, I'd be disenchanted if I couldn't.

Let me ask a couple of questions in return:

• Simplifying your application is admirable - but what would you do if your user received a GEDCOM with NOTE_RECORDs and you couldn't deal with it? The essence of GEDCOM is transport, i.e. dealing with any conformant GEDCOM;
• How would you advertise a program that was not 100% GEDCOM compliant in that it would not read NOTE_RECORDs?

Now - a very good answer would be, "It's only going to be me using this software and I'm not going to use someone's else GEDCOM". But only you know that.

Let me go back to the first question I answered and explain a bit more. When would I create a NOTE_RECORD? When the note that I want to create is shared across a number of individuals or families. Or when it's simply a note that doesn't link to any individual or family. Examples of the latter include a NOTE_RECORD with a list of census dates, or with details of when the calendars changed from Julian to Gregorian. Examples of the former include details of organisations that are, or might be (because I might not yet know the answer) applicable to several people. For instance, mini-histories of towns or regiments or railway companies. If you think of the ideal web-based version of that file, the mini-history would be accessed via a hyperlink and never have its text duplicated if I find several people in the same regiment / employed by the same company, etc.

In essence, NOTE_RECORDs to me are about sharing and prevention of duplicated text. I detest duplication because a week later - the duplicates are no longer quite duplicate.

Answer 2

The official answer can be found in the GEDCOM standard, version 5.5, and 5.5.1:

Logical GEDCOM record sizes should be constrained so that they will fit in a memory buffer of less than 32K. GEDCOM files with records sizes greater than 32K run the risk of not being able to be loaded in some programs. Use of pointers to records, particularly NOTE records, should ensure that this limit will be sufficient.