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 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
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 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:
IN DISKUSSION
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 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 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:
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 eine 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 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.
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 zweiter 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