GEDCOM/NOTE-Tag

From GenWiki

Jump to: navigation, search

Contents


This page is an English extract of the German page GEDCOM/NOTE-Tag [1], for full details see the German page.

Name and Meaning

Tag

NOTE

Meaning

NOTE

Usage

Additional information that will help in understanding the data, provided by the submitter

Formal Description of Permissible Values

Base: GEDCOM Standard Draft 5.5.1

Notes can be represented in a GEDCOM file by the following structure:

NOTE_STRUCTURE:=

[

n NOTE @<XREF:NOTE>@ {1:1}

|

n NOTE [<SUBMITTER_TEXT> | <NULL>] {1:1}

+1 [CONC|CONT] <SUBMITTER_TEXT> {0:M}

]

The first variant shown is referred to as "cross-reference to a note record", the second variant as "embedded" note.

Split of Lines by CONC

There are special considerations required when using the CONC tag. The usage is to provide a note string that can be concatenated together so that the display program can do its own word wrapping according to its display window size. The requirement for usage are defined on page GEDCOM/CONC-Tag.

Note Record

NOTE_RECORD:= 
n @<XREF:NOTE>@ NOTE <SUBMITTER_TEXT> {1:1} 
+1 [CONC|CONT] <SUBMITTER_TEXT> {0:M} 
+1 REFN <USER_REFERENCE_NUMBER> {0:M} 
+2 TYPE <USER_REFERENCE_TYPE> {0:1}
+1 RIN <AUTOMATED_RECORD_ID> {0:1} 
+1 <<SOURCE_CITATION>> {0:M} 
+1 <<CHANGE_DATE>> {0:1}

Use of Pointers and Note Records

As Grammar Rules stated

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.

Remark: In todays environment the risk of losing parts of records due to small read buffer can be neglected.

Content of Notes

The standard defines ( regardless of the subject of the notes ):

As Grammar Syntax for Line_Value

Values are generally not encoded in binary or other abbreviation schemes for reducing space requirements, and they are generally constrained to be understandable by a typical user without decoding. This is intended to reduce the decoding burden on the receiving software. A GEDCOM-optimized data compression standard will be defined in the future to reduce space requirements. Meanwhile, users may agree to compress and decompress GEDCOM files using any compression system available to both sender and receiver.

Agreements for NOTE

The agreements for NOTE are derived from the discussion on the Gedcom-L. They were decided by a vote of the program authors of the list.

Preface to the Agreements

When using note records more information can be stored by substructures than when using embedded notes. The discussion of whether and, if necessary, which agreements are to be derived is not yet completed. This topic is therefore excluded in subsequent agreements.

Export of NOTE

E1 Dealing with the Content of Notes

The content of notes ( "<SUBMITTER_TEXT>" ) must be exported unchanged. This also applies to leading and trailing spaces and blank lines as well as for any type of content. The required procedure and agreements for a division into sub-lines by using the tags CONC and CONT - see pages GEDCOM/CONC-Tag and GEDCOM/CONT-Tag.

E2 Embedded Notes and Note Records

It is optional to export either embedded notes or note records with corresponding cross-reference pointer or a mixture of both.

E3 Optionale Export Settings

It is allowed to offer export options to the user to remove leading and/or trailing spaces or blank lines when exporting.

E4 Several Notes to an Event, Consolidation of Notes

During standard export several notes or cross-references to note records may be assigned to an event. It is allowed to offer export options to the user to consolidate several notes to one content ( "<SUBMITTER_TEXT>" ) in a note. The contents of the various source notes have to be separated in this case by a line feed, it is recommended to make this separation by a second line feed more clearly. Different notes are therefor consolidated by the tag CONT.

E5 Cross-references from several Records to a Note Record

It is allowed to reference from different record types (e.g. individual or family records) by cross-reference pointers to a shared note field.

Import of NOTE

I1 Dealing with the Content of Notes

The content of notes ( "<SUBMITTER_TEXT>" ) must be imported unchanged. This also applies to leading and trailing spaces and blank lines as well as for any type of content. The required procedure and agreements for a division into sub-lines by using the tags CONC and CONT - see pages GEDCOM/CONC-Tag and GEDCOM/CONT-Tag.

A possible interpretation of the contents of notes ( e.g. classify texts after a tilde ~ as confidential text, interpretation as HTML structures ) is considered as an internal function of the importing program here and therefore not further discussed.

I2 Embedded Notes and Note Records

Embedded notes as well as note records with corresponding cross-reference pointer or a mixture of both need to be supported during the import. The content ( "<SUBMITTER_TEXT>" ) must be imported unchanged in all cases.

I3 Optionale Import Settings

It is allowed to offer import options to the user to remove leading and/or trailing spaces or blank lines when importing.

I4 Several Notes to an Event, Consolidation of Notes

Multiple notes or cross-references to note records must either be imported as such multiple links to an event, or ( especially for programs not supporting multiple links ) the contents of multiple notes to an event ( "<SUBMITTER_TEXT>" ) must be consolidated into one note. This has to be done identical to the procedures described in E4.

I6 Handling of Note Records by Programs with only Embedded Notes

Supports the importing program no note records, adequate copies of the content of the note record have to be inserted at the appropriate field instead of the pointer to a record during import.

Personal tools
GenWiki-internal
In other languages