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 bis zu 2 Teile mit <NAME_TEXT> auch fehlen können.

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 / ) 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

Behandlung/Darstellung schwieriger Situationen

Folgende Themen sind derzeit in der GEDCOM-Arbeitsgruppe von Compgen mit den Programmentwicklern in noch nicht abgeschlossener Diskussion (Diskussionsstand vom 4.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:

IN DISKUSSION

Verwendete Zeichen in NAME

Im Tag NAME erlaubt der Standard keine Komma, 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

Status:

IN DISKUSSION

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 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, wo das umgesetzt wird.

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

Status:

IN DISKUSSION

Mehrfachnamen einer Person

Im Laufe des Lebens kann bei verschiedenen Ereignissen der ursprüngliche (Geburts-) Name einer Person sich ä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 keinen 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.

Die Arbeitsgruppe trägt derzeit noch die Argumente zusammen, die für eine voll im Rahmen des Standards liegende Lösung mit Mehrfachnutzung des tags NAME sprechen bzw. für die Beibehaltung der heute üblicheren Vorgehensweise, Nutzer-definierte tags einzusetzen und so Mehrfachnutzungen des tags NAME weitgehend zu vermeiden.

Diskutiert wird dabei in der Arbeitsgruppe der Vorschlag, die Mehrfachnamen für eine Person in Zukunft zu nutzen im Rahmen des Standards 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

Aufführung weiterer Namen (bekannt als, alias) bzw. Variation der Schreibweisen

Beispiele:

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

1 NAME Maria /Müller/

1 NAME /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 /Müller/

2 TYPE married

1 NAME /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.

Kennzeichnung eines Rufnamens:

1 NAME Ursula Gundula /Meyer/

2 GIVN Ursula Gundula

1 NAME Ursula

2 TYPE Rufname

2 GIVN Ursula

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.

Kompatibilität mit bisherigen Vorgehen 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 ggfs 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:

IN DISKUSSION

Kennzeichnung von Rufnamen sowie Spitznamen in NAME

Problem:

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

Es fehlt im Standard 5.5.1 eine explizite Beschreibung für die Kennzeichnung des Rufnamens. Für den Rufnamen gibt es im Rahmen der Mehrfachnutzung des tags NAME die Möglichkeit, den Rufnamen eindeutig auszuweisen, siehe Abschnitt „Mehrfachnamen einer Person“.

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 ein Abkürzungs- oder Koseform zum Vornamen darstellt, aber auch völlig eigenständig gebildet worden sein 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 den 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.

Der Alternativ-Vorschlag lautet deswegen, auf alle zusätzlichen Kennzeichnungen in NAME zu verzichten, also obiges Beispiel so darzustellen:

1 NAME Ursula Uschi /Riem/

2 NICK Uschi

Ein 2. Alternativvorschlag 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:

IN DISKUSSION

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:

IN DISKUSSION