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 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:
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
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:
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 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 ablehnen. Neben dieser grundsätzlichen Diskussion werden derzeit auch einzelne inhaltliche Vorschläge zur Behandlung von Mehrfachnamen bearbeitet. 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, andereseits 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:
IN DISKUSSION
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
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:
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