GEDCOM/NOTE-Tag
Name und Bedeutung
Tag
NOTE
Formelle Bezeichnung
NOTE
Deutsche Bezeichnung
Notiz
Verwendung
Vom Verfasser bereitgestellte zusätzliche Informationen, die bei dem Verständnis der Daten helfen
Formale Beschreibung zulässiger Werte
Aussagen des GEDCOM Standards 5.5.1 zu NOTE
zitiert aus der Übersetzung von Jörn Daub
Notiz-Struktur
NOTE_STRUCTURE:=
[
n NOTE @<XREF:NOTE>@ {1:1}
|
n NOTE [<SUBMITTER_TEXT> | <NULL>] {1:1}
+1 [CONC|CONT] <SUBMITTER_TEXT> {0:M}
]
Teilung der Zeilen bei Einsatz von CONC
Bemerkung zur Notiz-Struktur: Es gibt besondere Dinge zu beachten, wenn das CONC-Kennzeichen eingesetzt wird. Es wird dazu benutzt, einen Notiztext anzugeben, der so zusammengefügt wird, dass das anzeigende Programm selbst abhängig von der Fenstergröße den Zeilenumbruch durchführen kann. Dafür ist es erforderlich, dass entweder die Zeilen mitten in einem Wort geteilt werden, oder am Ende eines Wortes, sodass das Leerzeichen in der nächsten CONC-Zeile vorangestellt wird. Ansonsten würden die meisten Betriebssysteme die Leerzeichen am Zeilenende entfernen, und das Leerzeichen geht beim Zusammensetzen der Notiz verloren.
Diese Aussage aus dem GEDCOM-Standard 5.5.1 wird an anderer Stelle anders dargestellt, nämlich bei der Definition des Kennwortes CONC.
Zur weiteren Diskussion siehe eigenständigen Artikel GEDCOM/CONC-Tag.
Notiz-Datensatz
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}
Nutzung von Zeigern und Notiz-Datensätzen
unter GRAMMATIKREGELN:
Logische Datensätze in GEDCOM sollten beschränkt werden, sodass sie in einen Speicherpuffer von weniger als 32K passen. GEDCOM-Dateien mit Datensätzen, die größer als 32K sind, laufen Gefahr, von einigen Programmen nicht verarbeitet werden zu können.4 Die Nutzung von Zeigern, insbesondere zu NOTE-Datensätzen sollte gewährleisten, dass diese Limitierung ausreichend ist.
4 (Anmerkung des Übersetzers Jörn Daub) Die Gefahr, Teile von Datensätzen aufgrund zu kleiner Lesepuffer zu verlieren ist historisch zu betrachten, und spielte auch 1999 keine praktische Rolle mehr.
Inhalte der Notizen
Hierzu führt der Standard ( unabhängig vom Thema der Notizen ) aus:
unter Zeilen_Wert
Werte sind im Allgemeinen nicht binär zu kodieren, oder durch Abkürzungen zu ersetzen, um Platz zu sparen. Sie sind allgemein so zu halten, dass ein typischer Anwender ihre Bedeutung ohne Dekodierung verstehen kann. Dies soll den Dekodieraufwand der empfangenden Software klein halten. Ein GEDCOM-optimierter Datenkompressionsstandard wird in Zukunft definiert werden, um Platz zu sparen. In der Zwischenzeit können Anwender sich darauf einigen, eine bestimmte Kompression zu nutzen, die Verfasser und Empfänger beide verstehen.
Behandlung/Darstellung schwieriger Situationen
Abweichungen vom Standard bei der Verwendung
Trennung der Inhalte bei Einsatz von CONC
Dieses Thema ist als eigenständiges Thema in GEDCOM/CONC-Tag ausgelagert.
Verwendung von NOTE-Datensätzen
Die ursprüngliche Begründung der Verwendung von NOTE-Datensätzen, nämlich beschränkte Lesepuffer von nur 32kB Größe, ist heute bedeutungslos.
NOTE-Datensätze könnten jetzt noch helfen, bei mehrfachem Auftreten von identischen NOTE-Inhalten diesen Inhalt nur einmal in einem NOTE_RECORD einzuspeichern und dann mit Zeigern mehrfach auf diesen NOTE_RECORD zu verweisen.
Weiterhin erlaubt der Standard eine Unterstruktur zur weiteren Beschreibung des NOTE-Datensatzes, u.a. mit REFN, SOUR, CHAN. Dies ist unter NOTE ohne NOTE_RECORD nicht möglich.
Zu entscheiden ist, ob bei einer Export-Vereinbarung zu NOTE eine der beiden Möglichkeiten präferiert oder sogar zur einzigen zu verwendenden Variante gemacht werden soll.
Status:
in Diskussion
Besondere Inhalte bei NOTE
In der Gedcom-L wird diskutiert, wie mit folgenden Inhalten eines Zeilen_Wertes zu NOTE umgegangen werden soll:
- Tilde ~ als Kennzeichnung von vertraulichen Notizen
- Klammern < und > als Teile einer HTML bzw. HML Struktur
Dabei wird argumentiert, dass solche Inhalte entweder Anwendereingaben oder Programm-interne Funktionalitäten darstellen, die beim Import oder Export keine Sonderbehandlung erfahren sollten.
Das führt in die Richtung, dass Texte in Zeilen_Werten weder beim Export noch beim Import geändert bzw. interpretiert werden sollen. In eine ähnliche Richtung geht die bereits verabschiedete Vereinbarung DATE I3.
Status:
in Diskussion