GEDCOM/NAME-Tag

Name und Bedeutung

tag

NAME

Formelle Bezeichnung

Name

Deutsche Bezeichnung

Name

Verwendung

Wort oder Wortkombination die hilft, eine Person, Titel, oder Position zu identifizieren. Mehrere NAME-Zeilen sollten benutzt werden, wenn eine Person unter mehreren Namen bekannt ist.

Formale Beschreibung zulässiger Werte

Basis dieser Beschreibung: GEDCOM Standard Draft 5.5.1

Diese Beschreibung enthält vorläufig nur Aussagen zum Einsatz von NAME in Zusammenhang mit Personen.

Die Syntax für Personen ist:

1 NAME <NAME_TEXT> /<NAME_TEXT>/ <NAME_TEXT>

wobei mindestens ein <NAME_TEXT> vorhanden sein muss.

Innerhalb der / -Zeichen steht der Nachname der Person.

Beispiele:

1 NAME Johann /Meyer/

1 NAME Johann /Meyer/ III

1 NAME Johann Michael /Meyer/

Der Standard erlaubt keine Sonderzeichen (außer dem /, dies nur als Trennzeichen für den Nachnamen ) und Ziffern in NAME.

Nach Standard können optional weitere tags dem tag NAME untergeordnet werden, um die Bestandteile in NAME näher zu beschreiben:

GIVN : Vorname

SURN : Nachname

NPFX : vorangestellter Namenszusatz (Titel)

SPFX : Text, der vor dem Nachnamen erscheint

NSFX : Text, der nach dem Namen erscheint

NICK : Nickname, Spitzname

NOTE : Struktur für Bemerkungen

SOUR: Struktur für Quellenangaben

Der Standard läßt unter einem tag NAME diese Bestandteile höchstens einmal zu {0,1}; nur NOTE und SOUR dürfen beliebig oft zugeordnet werden {0,M}.

Entscheidungsvorschläge für Vereinbarungen zu NAME

Vorbemerkung

Auf der Basis der Diskussion in der Gedcom-L werden im nachfolgenden erste Entscheidungsvorschläge zu Vereinbarungen zum tag NAME formuliert. Dieser erste Entwurf steht nun zur weiteren Diskussion an, er kann erweitert und geändert werden.

Der Umfang orientiert sich an den Themen, die in der Liste bislang diskutiert wurden, und wo die Diskussion im wesentlichen abgeschlossen ist (zumindest die erste Diskussionsphase).

Der bisherige Umfang ist wie folgt:

• Verwendung des tag NAME zur Beschreibung von Personen
• Die dem tag NAME untergeordneten tags GIVN, NICK, NPFX, NSFX, SPFX, SURN

Noch nicht in Entscheidungsvorschlägen abgebildet sind:

• Verwendung tag NAME in anderem Kontext als zur Beschreibung von Personen
• Thema Rufname
• Kennzeichnung von Spitznamen und Rufnamen

Export zum tag NAME

E1 Syntax zum tag NAME

Die zur Beschreibung von Personen verwendete Zeile mit NAME muss nach Standard 5.5.1 aufgebaut sein:

• 1 NAME <NAME_TEXT> /<NAME_TEXT>/ <NAME_TEXT>

Dabei muss der Nachname zwischen den Schrägstrichen stehen. Mindestens ein Element <NAME_TEXT> muss vorhanden sein.

E2 Zulässige Zeichen in NAME

Abgestimmt auf die Vereinbarung zu CHAR dürfen folgende Zeichen in den Elementen <NAME_TEXT> verwendet werden:

• Alle Zeichen von UNICODE mit Ausnahme von:
  • Schrägstrich / , dieser ist für die Trennung des Nachnamens von anderen Namensbestandteilen reserviert
  • Komma ,
  • WHITESPACE Zeichen
  • Einzig zugelassen von den WHITESPACE Zeichen ist das Leerzeichen

E3 Unterstruktur zu NAME

Bei der Verwendung des tags NAME zur Beschreibung von Personen dürfen folgende tags unter dem tag NAME angeordnet werden:

• FONE,GIVN, NICK, NPFX, NSFX,ROMN, SPFX, SURN,TYPE ( jeweils maximal einmal {0,1} )
• NOTE, SOUR ( beliebig oft {0,M} )

E4 Zusammensetzung von NAME

Der Inhalt der einzelnen Bestandteile <NAME_TEXT> in der Zeile 1 NAME … richtet sich zu allererst nach den Eingaben des Anwenders. Vom Anwender eingegebene Inhalte dürfen nicht vom Programm in ihrer Reihenfolge verändert werden.

E5 Reihenfolge in NAME bei Zusammensetzung aus Namens-Teilen

Bietet das Programm die Namenseingabe nicht über ein Namensfeld, sondern nur über den tags GIVN, NICK, NPFX, NSFX, SPFX, SURN zugeordnete Einzelfelder an, so sollte der tag NAME wie folgt zusammengesetzt sein (Standardversion für westliche Kulturen):

• 1 NAME NPFX GIVN NICK /SPFX SURN/ NSFX (ggfs geändert durch E6)

Das Programm darf dem Anwender die Option bieten, die Reihenfolge zu ändern, um die Konventionen anderer Kulturkreise abzubilden (z.B. GIVN nach /SURN/).

E6 Position von SPFX in NAME

E5 wird insofern geändert, als der Vorspann zum Nachnamen nicht innerhalb der Schrägstriche, sondern vor dem ersten Schrägstrich steht:

• 1 NAME NPFX GIVN NICK SPFX / SURN/ NSFX

E7 Export der Unterstruktur von NAME

Erfolgt die Anwendereingabe in Felder für GIVN, NICK, NPFX, NSFX, SPFX, SURN, so müssen diese tags auch als Unterstruktur von NAME exportiert werden.

E8 Verwendung von Komma in Namensteilen

Im Gegensatz zum tag NAME schreibt der Standard bei den Namensteilen GIVN, NPFX, NSFX, SPFX, SURN zur Trennung von deren Einzelteilen das Komma vor. Von dieser Vorgabe darf abgewichen werden, insbesondere die Trennung durch Leerzeichen oder ein vom Anwender eingegebener Inhalt wird geduldet.

E9 Weitere Inhalte von NAME

Weitere Strukturinhalte, die nicht zur Namensstruktur innerhalb eines Personendatensatzes gehören, dürfen nicht vom Programm beim Export in die <NAME_TEXT> in NAME integriert werden. Dies betrifft insbesondere Informationen aus den tags OCCU und TITL.

Vom Anwender selbst in die Namensstrukturelemente NAME, GIVN, NICK, NPFX, NSFX, SPFX, SURN eingetragene Inhalte bleiben davon unberührt.

E10 Mehrfachnamen

Der tag NAME mit entsprechender Unterstruktur darf beliebig oft im Personendatensatz verwendet werden {0,M}. Diese mehrfache Verwendung wird im Standard empfohlen, wenn eine Person im Laufe ihres Lebens mehrere Namen trug (z.B. wegen Änderungen durch Adoption, Heirat, Einwanderung etc)

E11 Kennzeichnung bei Mehrfachnamen: TYPE

Zur Kennzeichnung der Bedeutung der einzelnen Namen bei Mehrfachnamen darf der dem tag untergeordnete tag TYPE verwendet werden. Diese Art der Kennzeichnung sollte verwendet werden.

E12 Verwendung der TYPE-Kennzeichnungen aus dem Standard

In den Fällen, wo der Standard 5.5.1 konkrete Werte für den TYPE tag nennt, dürfen keine anderen Werte zu TYPE benutzt werden. Dies gilt also für die Werte:

• aka, birth, immigrant, maiden, married

E13 Reihenfolge der Namen beim Export von Mehrfachnamen

Beim GEDCOM-Export von Mehrfachnamen muss die Reihenfolge so erfolgen, dass der wichtigste Einzelname zuerst, und dann die weiteren Einzelnamen in der Reihenfolge abnehmender Wichtigkeit ausgegeben werden. Kann der Anwender im Programm die Wichtigkeit selbst ordnen, so müssen die Anwendervorgaben beim Export beachtet werden.

Sind vom Anwender keine Angaben gemacht, so sollte - wenn vorhanden - der Geburtsname als der wichtigste Einzelname zuerst exportiert werden.

E14 Auslassungszeichen für unleserliche Namensteile

Für unleserliche Namensteile schreibt der Standard 5.5.1 das Einsetzen des Auslassungszeichens (ellipsis: (…), drei Punkte als ein Zeichen) vor. Unleserliche Namensteile sollten im Export als

• U+2026 (Auslassungszeichen)

oder alternativ als drei Punkte:

• U+002U+002U+002

gekennzeichnet sein. Abweichende Eingaben des Nutzers dürfen nicht vom Programm für den Export verändert werden.

Import zum tag NAME

I1 Mindestanforderung an den Import

Der in den Punkten E1 und E2 beschriebene Umfang muss beim Import unterstützt werden.

I2 Priorität NAME vor Namensteilen

Der tag NAME hat laut Standard Priorität vor den optionalen, ihm untergeordneten Namensteilen wie GIVN, NICK, NPFX, NSFX, SPFX, SURN. Daher muss beim Import vorrangig NAME übernommen werden. Bei Widersprüchen zwischen NAME und den Namensteilen gilt der Inhalt von NAME. Der Widerspruch sollte beim Import erläutert und geeignet abgelegt (z.B. in einem Bemerkungsfeld) werden.

I3 Import in ein Programm mit expliziten Feldern für die Namensteile

Beim Import müssen NAME und die Namensteile GIVN, NICK, NPFX, NSFX, SPFX, SURN unverändert in die entsprechenden Felder übernommen werden, wenn das Programm diese Namensfelder unterstützt. Fehlen die Namensteile in der zu importierenden Datei, dann darf beim Import der Inhalt von NAME interpretiert werden und auf die Namensteile verteilt werden.

I4 Import in ein Programm ohne explizite Feldern für die Namensteile

Beim Import muss der Inhalt von NAME übernommen werden.

Vorhandene Namensteile in der einzulesenden Datei dürfen auf Widersprüche zu NAME untersucht und ggfs als Bemerkung abgelegt werden. Desgleichen dürfen die Namensteile geeignet abgelegt werden, z.B. in Bemerkungen.

I5 Import von Mehrfachnamen

Beim Import in Programme, die Mehrfachnamen unterstützen, dürfen die Angaben unter TYPE

• aka, birth, immigrant, maiden, married

vor einem nachfolgenden Export nur durch den Anwender selbst verändert werden. Einem Namen ohne Deklaration des Types ( durch TYPE oder auf andere Weise) darf nicht vom Programm ein Typ zugewiesen werden.

I6 Import von Mehrfachnamen, Teil 2

Beim Import von Mehrfachnamen in Programme, die diese Mehrfachnamen nicht unterstützen, muss das zuerst im Personendatensatz auftretende, und damit nach Standard wichtigste NAME-Konstrukt ausgewertet werden. Die weiteren Namen dürfen geeignet abgespeichert werden, z.B. als Bemerkungen.

I7 Kompatibilität zu anderen Versionen

Bei Abweichungen der importierten Datei vom Standard 5.5.1 bzw den zum Export getroffenen Vereinbarungen, darf beim Import versucht werden, die abweichenden Teile zu interpretieren und entsprechend intern weiterzuverarbeiten. Insbesondere wird empfohlen, den Umfang früherer Versionen des Programmes beim Import zu unterstützen.

Behandlung/Darstellung schwieriger Situationen

Folgende Themen sind derzeit in der GEDCOM-Arbeitsgruppe von Compgen mit den Programmentwicklern in noch nicht abgeschlossener Diskussion (Diskussionsstand vom 23.12.2009) :

Zusammensetzung von NAME

Der Standard gibt dem tag NAME Priorität vor den optional zugeordneten Namensteilen GIVN, SURN, NICK, NPFX, SPFX, NSFX.

Daraus wurde der Vorschlag abgeleitet, dass alle Namensteile und Namenszusätze (wie: von, van der, Gräfin von, der Dritte, Dr.) im tag NAME aufgenommen werden sollen

Als Reihenfolge innerhalb NAME wird vorgeschlagen:

NAME = NPFX GIVN / SPFX SURN / NSFX

Alternativvorschlag:

NAME = NPFX GIVN SPFX / SURN / NSFX

Problem:

Es gibt Namen, wo der “Vorname” nach dem Familiennamen geführt wird:

/Ho/ Chi Minh

Alternativvorschlag (würde vorgenanntes Problem lösen):

Keine Umsortierung nach Namensbestandteilen: NAME so exportieren, wie der Anwender es eingegeben hat

Weiter wird vorgeschlagen, die optionalen Namenszusätze GIVN, SURN, NICK, NPFX, SPFX und NSFX tatsächlich einzusetzen, wenn der Name die entsprechenden Anteile enthält. Ziel hierbei ist die eindeutige Zuordnung der Namensteile.

Die Information aus dem der Person zugeordneten tag TITL soll nicht zusätzlich in NAME aufgeführt werden. Damit werden auch Zuordnungsprobleme vermieden, wenn der TITL über DATE eine Zeitbestimmung hat, diese aber in einem Mehrfachnamenskonstrukt keine Einordnung zuläßt.

Status:

Entscheidungsvorschlag formuliert

Verwendete Zeichen in NAME

Im tag NAME erlaubt der Standard keine Kommata, keine Ziffern und keine Sonderzeichen. Diese Einschränkung gilt nicht für die untergeordneten Namensteile GIVN, SURN, NPFX, NSFX und SPFX.

Die Arbeitsgruppe ist hier der Meinung, dass diese Beschränkung nicht aufrechterhalten werden soll, weil sie weder erforderlich noch heute in der Praxis eingehalten wird. Hier ist der Vorschlag also, eine Abweichung vom Standard zu dulden.

Vorschlag ist weiter, die zulässigen Zeichen genau zu definieren und dabei den international anerkannten UNICODE-Standard zu zitieren, laut Vorschlag in der Form:

WHITESPACE := ?Pattern_White_Space?; // http://www.unicode.org/reports/tr31/

ALL: = ?ALL_Unicode_Characters? ; // http://unicode.org/charts

NAME_RESERVED := "/" | "," | WHITESPACE

NAME_TEXT := ALL – NAME_RESERVED

Leider führt dieser Vorschlag zum Ausschluß des Leerzeichens, welches aber dringend in NAME gebraucht wird.

Daher wurde der geänderte Vorschlag eingebracht:

In NAME ist die Verwendung aller UNICODE-Zeichen außer dem Komma und den WHITESPACE zugelassen. Als einziges WHITESPACE darf das Leerzeichen verwendet werden. Der Schrägstrich "/" darf ausschliesslich zur Abtrennung des Nachnamens von anderen Namensteilen verwendet werden.

Status:

Entscheidungsvorschlag formuliert

Verwendete Zeichen in NAME: Einzelpunkte

Auslassungszeichen für unleserliche Namensteile

Für unleserliche Namensteile schreibt der Standard 5.5.1 das Einsetzen des Auslassunsgzeichens (ellipsis: (…), drei Punkte als ein Zeichen) vor.

Vorschlag ist, dies zu konkretisieren, dass es als Auslassungszeichen verwendet wird:

U+2026

und alternativ auch drei Punkte zugelassen werden:

U+002U+002U+002

Bindestrich für Namen

Für Vornamen aus dem deutschen Sprachgebrauch wie z.B. Kai-Uwe ist es erforderlich den Bindestrich in NAME zuzulassen. Das gleiche gilt für Nachnamen (Doppelnamen) und einige Namenszusätze.

Dieser Punkt wäre durch den Vorschlag aus dem Abschnitt „Verwendete Zeichen“ abgedeckt.

Komma in Namensteilen

Der Standard schreibt für Namensteile ( GIVN, SURN, NPFX, SPFX, NSFX ) explizit vor, verschiedene Teile innerhalb eines Namensteiles durch Kommata zu trennen. Z.B. soll bei dem Namen "de la Cruz" der Vorspann als

SPFX de, la

angegeben werden.

Die Arbeitsgruppe stellt einhellig fest, dass bislang kein Programm bekannt ist, in dem das umgesetzt wird.

Vorschlag ist, hier in Abweichung vom Standard die Namensbestandteile auch ohne Trennung durch Komma zu dulden.

Status:

Entscheidungsvorschlag formuliert

Mehrfachnamen einer Person

Im Laufe des Lebens kann sich bei verschiedenen Ereignissen der ursprüngliche (Geburts-) Name einer Person ändern. Typische Beispiele sind Adoption, Heirat, Wiederheirat, Immigration (Anpassung an die Sprache des neuen Landes), Künstlernamen.

Der Standard 5.5.1 trägt dem Rechnung, indem im Datensatz einer Person die <<PERSONAL_NAME_STRUCTURE>> und damit der tag NAME mehrfach genutzt werden kann. Zur Unterscheidung dieser Namen wird unter NAME der tag TYPE eingesetzt, für den der Standard die Inhalte aka (genannt, auch bekannt als), birth (Geburtsname), immigrant (bei Einwanderung angenommener Name), maiden (Name vor erster Heirat), married (Name vor Heirat) explizit definiert und zusätzlich <user-defined>, also vom Programmautor gewählte Arten zuläßt.

Die Arbeitsgruppe stellt zunächst fest, dass die heute bekannten Programme von dieser Möglichkeit wenig Gebrauch machen. Stattdessen wird in der Regel beim Export der Nachname mit dem Geburtsnamen gleichgesetzt.

Des weiteren wurden Nutzer-definierte tags wie _MARNM eingeführt, um damit einen geänderten Namen nach Heirat zu beschreiben.

In der Arbeitsgruppe sind sowohl Befürworter der Nutzung von Mehrfachnamen als auch Vertreter, die die Nutzung von Mehrfachnamen nicht umsetzen möchten. Die gemeinsamen Vereinbarungen müssen daher einerseits das Thema Mehrfachnamen abdecken, andererseits aber auch Vorsorge tragen, dass beim Datentransfer von einem Programm mit Mehrfachnamen-Unterstützung auf ein Programm ohne Mehrfachnamen-Unterstützung möglichst viel (und die wichtigste) Information erhalten bleibt. Die Diskussion umfasst derzeit auch inhaltliche Vorschläge zur Behandlung von Mehrfachnamen. Dazu gehört auch die weitere Bewertung der Alternativen, einerseits die im Rahmen des Standards 5.5.1 liegende Lösung mit Mehrfachnutzung des tags NAME, andererseits die Verwendung Nutzer-definierter tags zur Vermeidung von Mehrfachnutzungen des tags NAME.

Diskutiert wird die Nutzung von Mehrfachnamen für eine Person für folgende Fälle:

• Explizite Darstellung des Nachnamens in den Phasen Geburt, Heirat, Wiederheirat etc. wie im Standard vorgesehen.
• Eröffnung der Möglichkeit, den Nachnamen beider Ehepartner nach einer Heirat getrennt darzustellen.
• Kennzeichnung des Rufnamens ( in der Diskussion inzwischen als sehr kritisch eingestuft )
• Aufführung weiterer Namen (bekannt als, alias) bzw. Variation der Schreibweisen

In der Diskussion wurde mehrfach aufgezeigt, dass bei Verwendung mehrfacher Namen immer alle Namensteile angegeben werden sollten. Fehlen einige Namensteile, so wäre unklar, ob die tatsächlich nicht existieren (z.B. bei Ordensschwestern wie "Schwester Gertrude" gibt es keinen Nachnamen) oder stillschweigend aus einem vollständigeren NAME Konstrukt zu übernehmen wären.

Die nachfolgenden Beispiele wurden daher überarbeitet:

Beispiele:

Name vor und nach Heirat, Geburtsname Meyer, nach Heirat Müller (ohne weitere optionale Namensteile):

1 NAME Maria /Müller/

1 NAME Maria /Meyer/

2 TYPE birth

Heiratet die Maria Müller, geb. Meyer, nun ein zweites Mal und nimmt dabei den Namen Schulze an, sieht das Beispiel so aus (ohne weitere optionale Namensteile):

1 NAME Maria /Schulze/

1 NAME Maria /Müller/

2 TYPE married

1 NAME Maria /Meyer/

2 TYPE birth

Bemerkung: Abweichend von der heute in den Programmen enthaltenen Grundannahme, dass als Nachname der Geburtsname eingegeben wird, steht bei Vorgehensweise nach Standard ohne Angabe von TYPE der aktuelle Nachname im tag NAME, und der Geburtsname wird durch

2 TYPE birth

gesondert ausgewiesen.

Kompatibilität mit bisherigen Vorgehem zu NAME

Für eine ganze Reihe von Programmen, die nur einen Namen pro Person unterstützen und auf Mehrfachnamen umstellen wollen, sowie beim Import von Gedcom-Dateien mit NAME ohne TYPE Angabe, stellt sich die Frage, wie die Zuordnung in einem Programm mit Mehrfachnamen erfolgen soll. Da oft stillschweigend der Nachname ohne TYPE dem Geburtsnamen gleichgesetzt wird, käme ggf. eine automatische Zuweisung von TYPE birth in Frage.

Die Arbeitsgruppe diskutiert jedoch eine mögliche Vereinbarung, eine automatische Zuweisung eines bestimmten Namens-Types nicht zuzulassen. Hintergrund ist die Unsicherheit, ob z.B. wegen fehlender anderer Möglichkeiten in das Feld Nachname auch andere Namenstypen eingetragen waren, und die automatische Zuweisung damit dem Anwender nicht bewußt werdende Falschzuordnungen vornimmt.

Offen ist derzeit noch der Umgang beim Import mit Dateien, die mit den bisher sehr unterschiedlichen Exportvarianten bei der Beschreibung von Typen in NAME erzeugt wurden.

Status:

Entscheidungsvorschlag formuliert (Rufname ausgeklammert)

Reihenfolge der Namensangaben bei Mehrfachnamen

Laut Standard ist bei gleicher Ebenen-Nummer und gleichem tag die Reihenfolge der Angaben signifikant: Die wichtigste Angabe kommt zuerst, und dann folgen die weiteren Angaben sortiert nach abnehmender Wichtigkeit.

In der Diskussion ist die Gruppe sich einig, dass dies bei der Verwendung von Mehrfachnamen berücksichtigt werden soll. D.h. der wichtigste der Person zugeordnete Name wird als erste Zeile

• 1 NAME wichtigster Name

darauf folgend die zugeordneten Namensteilen, Bemerkungen und Quellen, und dann folgt der nächst wichtige Name

• 1 NAME zweitwichtigster Name

usw.

Dies erlaubt Programmen, die nur Einfachnamen unterstützen, laut Standard den wichtigsten Namen in ihr Namenfeld einzulesen und die weiteren Namen gesondert zu behandeln (z.B. in einem Bemerkungsfeld abzulegen).

Status:

EINVERNEHMLICH DISKUTIERT

Behandlung von Rufnamen

Der Standard 5.5.1 bietet keine explizite Lösung zur Darstellung / Kennzeichnung von Rufnamen an. Es existieren eine ganze Reihe von Sonderlösungen, die meist untereinader nicht kompatibel sind und damit beim Datentransfer zwischen Programmen Schwierigkeiten bereiten.

Der tag NICK darf nicht für die Kennzeichnung des Rufnamens eingesetzt werden, da der Rufname ein herausgehobener Bestandteil eines aus mehreren Teilen bestehenden Vornamens ist, während der Spitzname nicht zum Vornamen gehört, sondern in vielen Fällen eine Abkürzungs- oder Koseform zum Vornamen darstellt, aber auch völlig eigenständig gebildet worden sein kann.

In der Diskussion der Liste werden folgende Vorschläge zur Behandlung des Rufnamens behandelt (bei allen Beispielen sind aus Gründen der Übersichtlichkeit die optionalen tags GIVN und SURN nicht aufgeführt):

A Gruppe von Vorschlägen mit Kennzeichnung des Rufnamens durch Sonderkennzeichen direkt in NAME

Ähnlich wie in GEDCOM 5.4. der Spitzname könnte der Rufname in der Zeile NAME durch Sonderzeichen hervorgehoben werden:

• Variante A1) Kennzeichnung durch Anführungszeichen
  • 1 NAME Maria "Elisabeth" Johanna /Alt/
• Variante A2) Kennzeichnung durch Unterstriche
  • 1 NAME Maria _Elisabetha_ Johanna /Alt/
• Variante A3) Kennzeichnung durch sonstige Sonderzeichen, z.B. Sternchen
  • 1 NAME Maria *Elisabeth* Johanna /Alt/

Folgende Argumente werden in der Liste dieser Gruppe von Vorschlägen zugeordnet:

• PRO: bleibt auch bei Datentransfer zu und von anderen, nicht an der Vereinbarung beteiligte Programmen erhalten ( nur Varianten A1 und A3 )
• CONTRA: in anderen Programmen unschönes Erscheinungsbild, wird ggfs vom Anwender gelöscht
• CONTRA: Verwechslung mit Eingaben des Anwenders möglich, diese werden ggfs umgedeutet (z.B. die alte Spitznamen-Kennung aus GEDCOM 5.4 durch Anführungszeichen "...")

B Gruppe von Vorschlägen mit Kennzeichnung für den Rufnamen unterhalb von NAME

• Variante B1) Nutzung von NOTE RUFNAME innerhalb NAME
  • 1 NAME Maria Elisabeth Johanna /Alt/
  • 2 NOTE RUFNAME Elisabeth

Folgende Argumente werden in der Liste diesem Vorschlag zugeordnet:

• PRO: Standard 5.5.1 kompatibel, Information bleibt auch in einigen hier nicht vertretenen Programmen erhalten, teilweise sogar korrekt re-exportiert
• CONTRA: Der Nutzer kann in hier nicht vertretenen Programmen die Information in der NOTE Zeile abweichend von den Vornamen in NAME eingeben, Sonderbehandlung dieses Widerspruchs beim Reimport in hier vertretene Programme erforderlich

• Variante B2) Nutzung eines Nutzer-definierten tag _RUFNAME
  • 1 NAME Maria Elisabeth Johanna /Alt/
  • 2 _RUFNAME Elisabeth

Statt _RUFNAME werden auch _CALN, _RUF und andere Alternativen vorgeschlagen.

Folgende Argumente werden in der Liste diesem Vorschlag zugeordnet:

• PRO: Einfache Realisierung in den Programmen
• CONTRA: Nutzerdefiniertes tag wird in anderen, in dieser Liste nicht beteiligten Programmen nicht verstanden, Datentransfer bedeutet oft Verlust der Information

• Variante B3) Nutzung eines Nutzer-definierten tag _RUFNAME unterhalb von GIVN
  • 1 NAME Maria Elisabeth Johanna /Alt/
  • 2 GIVN Maria Elisabeth Johanna
  • 3 _RUFNAME Elisabeth

Statt _RUFNAME werden auch _CALN, _RUF und andere Alternativen vorgeschlagen.

B3 unterscheidet sich von B2 dadurch, dass der Nutzer-definierte tag nicht der NAME, sondern der GIVN-Ebene untergeordnet wird. Folgende Argumente werden in der Liste diesem Vorschlag zugeordnet:

• PRO: Einfache Realisierung in den Programmen
• PRO: Logischere Zuordnung des Rufnamens als Teil der Vornamen
• CONTRA: Nutzerdefiniertes tag wird in anderen, in dieser Liste nicht beteiligten Programmen nicht verstanden, Datentransfer bedeutet oft Verlust der Information
• CONTRA: Erzwingt die Nutzung des eigentlich optionalen tags GIVN

• Variante B4) Verwendung von Mehrfachname NAME plus TYPE RUFNAME
  • 1 NAME Maria Elisabeth Johanna /Alt/
  • 1 NAME Elisabeth
  • 2 TYPE RUFNAME

Hierzu müßte der Typ “RUFNAME” als <user-defined> vereinbart werden (oder eine andere Kennzeichnung anstelle von Rufname. Der englische Sprachraum kennt Rufnamen nicht, am ehesten mit preferred given name zu übersetzen.). Da es sich nicht um ein tag handelt, muss die Bezeichnung nicht mit einem Unterstrich begonnen werden. Der TYPE als NAME_TYPE muss auf Ebene n+1 des Namen definiert werden, d.h. auf derselben Ebene wie GIVN.

Diese Kennzeichnung des Rufnamens wird wegen folgender Probleme von vielen Teilnehmern der Liste abgelehnt:

• CONTRA: es wird ein neuer NAME aufgemacht, obwohl es sich nicht um einen eigenständigen Zweitnamen der Person handelt
• CONTRA: das angesprochene Problem mit unvollständigen NAME Zeilen (hier ohne Nachnamen) tritt auf
• CONTRA: diese Version wäre für Programme außerhalb der hier vertretenen Programme nicht lesbar

C Gruppe von Vorschlägen mit Kennzeichnung ausserhalb des tags NAME

• Variante C1) Verwendung von FACT
  • 1 FACT Elisabeth
  • 2 TYPE Rufname

Diskussion noch nicht erfolgt. Hinweis: FACT wird erst seit Standard 5.5.1 unterstützt.

• Variante C2) Verwendung von EVEN
  • 1 EVEN Elisabeth
  • 2 TYPE Rufname

Nachteil: EVEN ist Ereignis, Elisabeth ist kein Ereignis.

Diskussion noch nicht erfolgt.

Status:

Insgesamt noch IN DISKUSSION

Kennzeichnung Spitznamen in NAME

Problem:

Der Standard sieht den tag NICK als optionalen tag unter NAME vor, mit dem der Nickname = Spitzname eingegeben werden kann.

Die Arbeitsgruppe diskutiert zur Zeit, ob eine Kennzeichnung von Spitzname und Rufname im tag NAME sinnvoll erscheint, z.B. in der Art

1 NAME Ursula (Uschi) /Riem/

für den Spitznamen Uschi

Der Spitzname wird also bei diesem Vorschlag durch Einklammerung hervorgehoben. Problem dabei ist eine mögliche Kollision mit früheren GEDCOM Dateien, in denen Namen mit Klammern aus der Anwendereingabe direkt in den Export gelangten und bei Umsetzung des vorgenannten Vorschlags dann die Klammerinhalte als Spitzname missinterpretiert werden könnten.

Im GEDCOM Standard 5.4 war für den Spitznamen das Zeichen " zur Kennzeichnung des Spitznamens eingeführt:

1 NAME Ursula "Uschi" /Riem/

Dies wurde jedoch mit der Nachfolgeversion GEDCOM 5.5 wieder aufgehoben bei gleichzeitiger Einführung des tags NICK:

1 NAME Ursula Uschi /Riem/

2 NICK Uschi

Ein Alternativvorschlag zu dieser auch im Standard 5.5.1 weiter enthaltenen Darstellung möchte den Nick-/Spitznamen nicht zusätzlich im tag NAME exportieren, sondern ausschließlich über den tag NICK (und damit den tag NICK nicht mehr optional zufügen, sondern zwingend zu verwenden bei Vorhandensein eines Spitznamens):

1 NAME Ursula /Riem/

2 NICK Uschi

Status:

IN DISKUSSION

Beziehung zwischen NAME und TITL

Der tag TITL ist ein eigenständiger Teil der Personenbeschreibung auf gleicher Stufe wie NAME.

Die Arbeitsgruppe verweist darauf, dass erbliche Adelstitel vor 1918 und die Adelsbezeichnung nach 1918 Bestandteile des Namens der Person sind und daher in NAME aufzunehmen sind. Verliehene Titel wie „König von“ sind dagegen in TITL zu beschreiben.

Informationen zu den einzelnen Titeln finden sich hier.

Status:

betrifft programm-interne Gestaltung sowie Eingaben des Nutzers

Behandlung akademischer Titel

Der akademische Titel Dr. wird in Deutschland teilweise mit dem Nachnamen zusammen geführt. In der bisherigen Praxis wurde dieser Titel meist ebenfalls unter TITL geführt. Er würde so in NAME nicht aufgenommen.

Die Diskussion, ob das weiter so empfohlen werden soll oder dieser Titel in den Namensteil NPFX aufgenommen werden soll und damit auch in NAME auftaucht, hat noch zu keiner Einigung geführt.

Status:

Entscheidungsvorschlag formuliert