GEDCOM/NOTE-Tag

aus GenWiki, dem genealogischen Lexikon zum Mitmachen.
Zur Navigation springen Zur Suche springen

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}

]

Ergänzende Bemerkung: Die zuerst dargestellte Variante wird als "Querverweis auf einen Notiz-Datensatz" bezeichnet, die zweite Variante als "eingebettete" Notiz.

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.


Vereinbarungen zu NOTE

Diese Vereinbarungen sind aus der Diskussion in der Gedcom-L Liste abgeleitet und durch Abstimmung verabschiedet worden.

Vorbemerkung zu den Vereinbarungen

Bei Verwendung von Notiz-Datensätzen kann über eine Unterstruktur mehr Information strukturiert abgelegt werden als es bei Verwendung von eingebetteten Notizen möglich ist. Die Diskussion, ob und ggfs. welche Vereinbarungen hieraus abgeleitet werden sollen, ist in der Liste bislang nicht abgeschlossen. Dieses Thema ist bei den nachfolgenden Vereinbarungen daher ausgeklammert.


Vereinbarungen für den Export zu NOTE

Durch Abstimmung unter den Programmautoren sind die folgenden Vereinbarungen getroffen worden.

Zum Umgang mit mehrfachen Notizen / Packen von Notizen im Export ( E4 ) wird es in einem Gesamtreview am Projektende noch einmal einen Aufruf zur Diskussion geben, da hier das Abstimmungsergebnis zwar eine deutliche Mehrheit brachte, aber doch in nennenswertem Umfang auch Stimmen "könnte damit leben" und "dagegen" abgegeben wurden.


E1 Umgang mit dem Inhalt von Notizen

Der Inhalt von Notizen ("<SUBMITTER_TEXT>") muss unverändert exportiert werden. Dies gilt auch für führende und abschließende Leerzeichen und Leerzeilen sowie für jede Art des Inhaltes. Die dafür erforderliche Vorgehensweise bei einer Aufteilung auf Folgezeilen regeln die Vereinbarungen zu den Kennzeichen CONC und CONT.


E2 Eingebettete Notizen und Notiz-Datensätze

Es ist freigestellt, entweder eingebettete Notizen oder Notiz-Datensätze mit entsprechenden Querverweis_Zeigern oder eine Mischung aus beiden zu exportieren.


E3 Optionale Exporteinstellungen

Dem Anwender dürfen Exportoptionen angeboten werden, führende und/oder abschließende Leerzeichen oder Leerzeilen beim Export zu entfernen.


E4 Mehrfache Notizen zu einem Ereignis, Packen von Notizen

Beim Standard-Export dürfen einem Ereignis mehrere Notizen bzw. Querverweise auf Notiz-Datensätze zugeordnet werden. Dem Anwender darf in diesem Fall eine Option angeboten werden, bei solchen Mehrfachverknüpfungen von Notizen zu einem Ereignis die Inhalte ("<SUBMITTER_TEXT>") in eine Notiz zu packen. Die Inhalte der verschiedenen Ursprungsnotizen müssen dabei durch einen Zeilenvorschub voneinander getrennt werden, es wird empfohlen, diese Trennung durch einen zweiten Zeilenvorschub noch deutlicher zu machen. Verschiedene Notizen werden beim Packen also mit Hilfe des Kennzeichens CONT verknüpft.


E5 Querverweise aus verschiedenen Datensätzen auf einen Notiz-Datensatz

Es ist zulässig, aus verschiedenen Datensätzen (z.B. Personen- oder Familien-Datensätzen) mit Querverweis-Zeigern auf ein gemeinsames Notiz-Datenfeld zu verweisen.

Vereinbarungen für den Import zu NOTE

I1 Umgang mit dem Inhalt von Notizen

Der Inhalt ("<SUBMITTER_TEXT>") von Notizen muss unverändert importiert werden. Dies gilt auch für führende und abschließende Leerzeichen und Leerzeilen sowie für jede Art des Inhaltes. Die dafür erforderliche Vorgehensweise bei einer Aufteilung auf Folgezeilen regeln die Vereinbarungen zu den Kennzeichen CONC und CONT. Eine mögliche Interpretation von Inhalten der Notizen (wie z.B. Texte nach der Tilde ~ als vertraulichen Text einstufen, HTML- oder HML-Stukturen interpretieren) wird hier als interne Funktion des importierenden Programmes eingestuft und daher nicht behandelt.


I2 Eingebettete Notizen und Notiz-Datensätze

Sowohl eingebettete Notizen als auch Notiz-Datensätze mit entsprechenden Querverweis_Zeigern oder eine Mischung aus beiden müssen beim Import unterstützt werden. Der Inhalt ("<SUBMITTER_TEXT>") muss in jedem Fall unverändert importiert werden.


I3 Optionale Importeinstellungen

Dem Anwender dürfen Importoptionen angeboten werden, führende und/oder abschließende Leerzeichen oder Leerzeilen beim Import zu entfernen.


I4 Mehrfache Notizen zu einem Ereignis, Packen von Notizen

Mehrfache Notizen bzw. Querverweise auf Notiz-Datensätze müssen entweder als solche Mehrfachverknüpfungen zu einem Ereignis importiert werden oder (insbesondere bei Programmen, die intern keine Mehrfachverknüpfung unterstützen) die Inhalte der mehrfachen Notizen zu einem Ereignis ("<SUBMITTER_TEXT>") müssen in eine Notiz gepackt werden. Das Packen erfolgt identisch zu dem unter E4 beschriebenen Verfahren.


I6 Kopien von Notiz-Datensätzen bei fehlender Unterstützung der Mehrfachverknüpfung

Unterstützt das importierende Programm keine Querverweise aus verschiedenen Datensätze auf einen Notiz-Datensatz, so müssen beim Import entsprechend Kopien des Notiz-Datensatzes angelegt werden bzw. der Inhalt des Notiz-Datensatzes an der Stelle der jeweiligen Querverweis_Zeiger eingefügt werden.

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.

Zulässige Zeichen ( UNICODE ) und Behandlung des Zeichens @

Dieses Thema ist unter GEDCOM/Syntax_GEDCOM-Zeile behandelt.

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:

Entscheidungsvorschlag formuliert


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:

Entscheidungsvorschlag formuliert


Eingebettete Notizen versus Notiz-Datensätze beim Import

Es gibt Programme, die entweder nur eingebettete Notizen oder nur Notiz-Datensätze mit zugehörigen Querverweisen exportieren. Solche Programme können beim Import von GEDCOM-Dateien aber auch die jeweils andere Möglichkeit in der Datei finden. Hierzu wird vorgeschlagen, beim Import den Inhalt der Notiz auf jeden Fall zu übernehmen, unabhängig von der Darstellung in der GEDCOM-Datei.

Die inhaltlich gleichen Aussagen:

  • 1 BIRT
  • 2 NOTE Text

und

  • 1 BIRT
  • 2 NOTE @N1@
  • ...
  • 0 @N1@ NOTE Text

sollen auf jeden Fall von allen Programmen beim Import verstanden werden.

Dies ist im Vorschlag I2 abgebildet.

Der weitergehende Vorschlag I5 wurde wieder herausgenommen, da er weniger den Inhalt, als Eigenschaften des importierenden Programmes beschreibt. Er lautete in der ursprünglich vorgeschlagenen Form:

I5 Wandlung zwischen eingebetteten Notizen und Notiz-Datensätzen

Unterstützt das importierende Programm keine Notiz-Datensätze, so müssen die Inhalte ("<SUBMITTER_TEXT>") der zu importierenden Notiz-Datensätze aus der zu importierenden GEDCOM-Datei vollständig in eingebettete Notizen überführt werden, d.h. an Stelle eines jeden Querverweis-Zeigers ist der vollständige Inhalt ("<SUBMITTER_TEXT>") aus dem zugehörigen Notiz-Datensatz einzufügen. Unterstützt dagegen das importierende Programm keine eingebetteten Notizen, so müssen eingebettete Notizen aus der Importdatei vollständig in Notiz-Datensätze überführt werden.


Status:

Entscheidungsvorschlag formuliert

Unterstruktur des Notiz-Datensatzes

Beim Export eines Notiz-Datensatzes läßt der Standard eine Unterstruktur zu, z.B.

  • 0 @N1@ NOTE Text
  • 1 TYPE Notiz zum Geburtseintrag
  • 1 REFN N-G-0001
  • 1 SOUR @S001@
  • 1 CHAN
  • 2 DATE 26 JAN 2010
  • ...
  • 0 @S001@ SOUR
  • 1 TITL Geburtseinträge im Zivilregister...

Diese Unterstrukturen werden nicht von allen Programmen unterstützt. Es gibt bislang auch keine einheitliche Vorgehensweise, wie damit beim Import umgegangen wird, wenn das importierende Programm Notiz-Datensätze nicht unterstützt und intern diese Unterstruktur nicht abbildet.

In der Gedcom-L wird daher diskutiert, ob auf die Unterstruktur möglicherweise verzichtet werden kann.

Status:

In Diskussion


Mehrfache Verknüpfungen von Notizen in einem Ereignis

Der GEDCOM-Standard läßt zu, dass zu Ereignissen mehrere Notizen zugeordnet werden: Die Notiz-Struktur wird regelmäßig mit der zulässigen Anzahl {0:M} angegeben.

Also ist folgendes Standard-konform (am Beispiel einer Geburtseintragung):

  • 1 BIRT
  • 2 NOTE Text1
  • 2 NOTE @N2@
  • 2 NOTE @N3@
  • ...
  • 0 @N2@ NOTE Text2
  • 0 @N3@ NOTE Text3

Nicht alle Programme unterstützen diese Möglichkeit der mehrfachen Verknüpfung von Notizen zu einem Ereignis. In diesem Fall könnten bei einem Import Inhalte der Notizen aus mehrfachen Verknüpfungen verloren gehen. Vorgeschlagen wurde daher, dies durch ein sogenanntes "Packen" der Notizen beim Import zu vermeiden. Programme ohne Unterstützung von mehrfachen Notizen zu einem Ereignis packen dann in obigen Beispiel die Notizinhalte in eine gemeinsame Notiz:

  • 1 BIRT
  • 2 NOTE Text1
  • 3 CONT
  • 3 CONT Text2
  • 3 CONT
  • 3 CONT Text3

oder

  • 1 BIRT
  • 2 NOTE @N1@
  • ...
  • 0 @N1@ NOTE Text1
  • 1 CONT
  • 1 CONT Text2
  • 1 CONT
  • 1 CONT Text3

In der Gedcom-L wird diskutiert, ob dies in einer "MUSS"-Vereinbarung für den Import festgeschrieben soll werden für Programme ohne Unterstützung von mehrfachen Verknüpfungen. Die CONT Leerzeile zwischen den Textblöcken 1, 2 und 3 wurde auf Vorschlag der Liste hinzugfügt, um die einzelnen, aus verschiedenen Notizen stammenden Texte nach dem Packen besser auseinanderhalten zu können.

Status:

Entscheidungsvorschlag formuliert

Abgerufen von „https://wiki-devel.genealogy.net/index.php?title=GEDCOM/NOTE-Tag&oldid=2415766“