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 Kennzeichen dem Kennzeichen 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 Kennzeichen NAME diese Bestandteile höchstens einmal zu {0,1}; nur NOTE und SOUR dürfen beliebig oft zugeordnet werden {0,M}.

Vereinbarungen zu NAME

In drei Abstimmrunden wurden bisher 17 Vereinbarungen zu NAME und zusätzlich Vereinbarungen zu Rufname verabschiedet. Diese sind im folgenden dargestellt.

Die Vereinbarungen E10, E11, E13 und I5 sind nur für Programme relevant, die Mehrfachnamen programmintern unterstützen.

Bei E12 und I7 besteht noch Diskussionsbedarf.

Die Vereinbarungen beziehen sich bislang auf Name im Kontext von Personen-Datensätzen, mit den zugeordneten Kennzeichen

• GIVN, NICK, NPFX, NSFX, SPFX, SURN

Vereinbarungen zum Export von NAME

E1 Syntax zu 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 sind das Leerzeichen und das geschützte Leerzeichen U+00A0

E3 Unterstruktur zu NAME

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

• GIVN, NICK, NPFX, NSFX, SPFX, SURN, TYPE, _RUFNAME ( jeweils maximal einmal {0,1} )
• FONE, NOTE, ROMN, 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 Kennzeichen GIVN, NICK, NPFX, NSFX, SPFX, SURN zugeordnete Einzelfelder an, so sollte das Kennzeichen NAME wie folgt zusammengesetzt sein (Standardversion für westliche Kulturen):

• 1 NAME NPFX GIVN NICK /SPFX SURN/ NSFX

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

E7 Export der Unterstruktur von NAME

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

E8 Verwendung von Komma in Namensteilen

Im Gegensatz zum Kennzeichen 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.

E10 Mehrfachnamen

Das Kennzeichen 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 sieht der Standard das dem Kennzeichen untergeordnete Kennzeichen TYPE vor. Diese Art der Kennzeichnung wird hier empfohlen.

In den Fällen, wo der Standard 5.5.1 konkrete Werte für das Kennzeichen TYPE nennt, dürfen keine anderen Werte zu TYPE benutzt werden (ggfs. Ausnahme: Anwendereingaben nach E12). Dies gilt also für die Werte:

• aka ( "also known as", auch bekannt als, weiterer Name für die Person)
• birth ( Geburtsname )
• immigrant ( bei oder nach Einwanderung angenommener Name )
• maiden ( Name vor erster Heirat; Verwendung, wenn Geburtsname nicht sicher belegt )
• married ( Ehename aus einer vorhergehenden Ehe )

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.

Vereinbarungen zum Import von NAME

I1 Mindestanforderung an den Import

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

I2 Behandlung von Widersprüchen zwischen NAME und Namensteilen

Die Angaben im Kennzeichen NAME sollten mit den Angaben in den untergeordneten Namensteilen wie GIVN, NICK, NPFX, NSFX, SPFX, SURN, _RUFNAME zusammenpassen. Werden beim Import jedoch Widersprüche zwischen diesen Angaben festgestellt, sollte dies als Fehlermeldung dem Anwender bekanntgegeben und geeignet (z.B. in einem Bemerkungsfeld) abgelegt 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, _RUFNAME 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.

Die Information aus Namensteilen dürfen 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.

Vereinbarung zu Rufnamen

1. Vorbemerkung: In diesem Punkt geht es um den Datentransfer der Information des Rufnamens. Hierbei wird unter Rufname die in Deutschland zeitweise amtlich vorgeschriebene Vorgehensweise verstanden, bei mehreren Vornamen einer Person einen dieser Vornamen durch Unterstreichen als Rufnamen festzulegen. Daraus folgt auch, dass der Rufname immer einer der amtlich dokumentierten Vornamen ist. Dies ist deutlich zu unterscheiden vom Spitznamen (englisch: nickname, Kennzeichen NICK), der im Familien- oder Freundeskreis verwendet wird, meist aber nicht einer der amtlichen Vornamen ist.

2. Vorbemerkung: Der Datentransfer zum Rufnamen ist im GEDCOM-Standard 5.5.1 nicht explizit geregelt. Damit war es erforderlich, eine mit dem Standard kompatible Lösung zu erarbeiten und zu vereinbaren:

Ruf.B2 Kennzeichnung des Rufnamens mit nutzerdefiniertem Kennzeichen _RUFNAME

Die Kennzeichnung erfolgt mittels eines dem Kennzeichen NAME zugeordneten nutzerdefinierten Kennzeichens n+1 _RUFNAME. Dabei muss das exportierende Programm sicherstellen, dass der mit diesem Kennzeichen exportierte Rufname einer der Vornamen aus NAME bzw GIVN ist.

Wird beim Import eine fehlerhafte GEDCOM-Datei vorgefunden, wo der als Rufname angebene Name nicht einer der Vornamen ist, so wird empfohlen, eine Fehlermeldung auszugeben oder die entsprechende Information als Bemerkung dieser Person zuzuordnen.

Beispiel:

• 1 NAME Maria Elisabeth Johanna /Alt/
• 2 _RUFNAME Elisabeth

Entscheidungsvorschläge für Vereinbarungen zu NAME

Vorbemerkung

Auf der Basis der Diskussion in der Gedcom-L werden im nachfolgenden noch nicht entschiedene Entscheidungsvorschläge zu Vereinbarungen zum Kennzeichen NAME formuliert.

Der Umfang orientiert sich an den Themen, die in der Liste bislang diskutiert wurden, und wo die Diskussion im wesentlichen abgeschlossen ist bzw in einer Abstimmung keine eindeutige Mehrheit erzielt wurde.

Noch nicht in Entscheidungsvorschlägen abgebildet sind:

• Verwendung Kennzeichen NAME in anderem Kontext als zur Beschreibung von Personen

Der Entscheidungsvorschläge E12 ist nur für Programme relevant, die Mehrfachnamen programmintern unterstützen.

Entscheidungsvorschläge zum Export von NAME

E12 Weitere TYPE-Kennzeichnungen für Mehrfachnamen

Es wird empfohlen, folgende weiteren TYPE-Kennzeichnungen zu verwenden:

• adoption ( Name nach Adoption )
• divorce ( Name nach Scheidung )
• estate ( Hausname, Hofname, Name nach Einzug oder Einheirat in ein Haus / einen Hof )
• pseudonym ( Künstlername, als Künstler angenmmener Name )
• religious ( Ordensname, nach Eintritt in einen Orden angenommener Name )
• unified ( Stammname, vereinheitlichte Schreibweise für einen Familiennamen )
• variant ( abweichende Schreibweise für einen Namen, auch an andere Sprachen wie Latein, Französisch angelehnte Schreibweisen )

Bietet das Programm dem Anwender die Eingabe für TYPE als eigenes Datenfeld an, so muss die Anwendereingabe exportiert werden.

Entscheidungsvorschläge zum Import von NAME

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

Zu den Bezeichnungen und Definitionen zum Thema Namen einer Person findet man hier einen eigenen Wiki-Artikel.

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

Zusammensetzung von NAME

Der Standard gibt dem Kennzeichen 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 Kennzeichen 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 Kennzeichen 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:

Vereinbarung getroffen

Verwendete Zeichen in NAME

Im Kennzeichen 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:

Vereinbarung getroffen

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.

In der ursprünglichen Diskussion in der Gedcom-L kam der Vorschlag, diese Vorgehensweise aus dem Standard als Empfehlung zu übernehmen. Die weitere Diskussion führte dann zu der Auffassung, dass ein Programm in der Regel bei den Anwendereingaben nicht unterscheiden kann, ob es sich um eine Kennzeichnung einer unleserlichen Stelle der Quelle oder um die Übernahme einer Originalmarkierung aus der Quelle handelt. Die Diskussion führte also zu folgendem Entscheidungsvorschlag:

E14(alt) 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+002E U+002E U+002E

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

Im weiteren Ablauf der Diskussion in der Liste wurde dann argumentiert, dass diese Vereinbarung nicht notwendig sei, da das Prinzip Anwendereingaben werden unverändert ausgegeben grundsätzlich Vorrang habe. Der Punkt wurde somit aus dem Abstimmungsumfang zum Kennzeichen NAME herausgenommen.

Status:

Vereinbarung geroffen

Verwendete Zeichen in NAME: Einzelpunkte

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:

Vereinbarung getroffen

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 das Kennzeichen NAME mehrfach genutzt werden kann. Zur Unterscheidung dieser Namen wird unter NAME das Kennzeichen 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 Kennzeichen wie _MARN 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 Kennzeichens NAME, andererseits die Verwendung Nutzer-definierter Kennzeichen 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.
• 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 Kennzeichen 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

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:

Vereinbarung getroffen

Verknüpfung von Mehrfachnamen mit Ereignissen

Die im März 2010 fortgesetzte Diskussion zu Mehrfachnamen hat intensiv die Frage aufgegriffen, ob eine Verknüpfung von einzelnen Mehrfachnamen mit Ereignissen möglich ist. Hintergrund sind Personen, die aufgrund bestimmter Ereignisse wie Adoption, Heirat oder Auswanderung mehrfach ihren Namen im Laufe des Lebens wechseln. Für Programme, die die Dokumentation solcher Lebensläufe mit Mehrfachnamen unterstützen, wird nun nach der Möglichkeit gesucht, auch im GEDCOM Transfer zu vermitteln, dass z.B. der Name x mit der zweiten Heirat (und damit ab Datum dieser Heirat) angenommen wurde. Die einfache Kennzeichnung dieses Namens als

• n+1 TYPE married

reicht dafür nicht aus, da unklar bleibt, welcher Heirat dieser Name zuzuordnen ist.

Die Diskussion ist noch voll im Gange und wird in Kürze an dieser Stelle zusammengefasst.

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.

Das Kennzeichen 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 Diskussion in der Gedcom-L hatte sich zuletzt auf 5 Vorschläge konzentriert, wie die Information über den Rufnamen in der GEDCOM-Datei dargestellt werden kann. Dies sind die im folgenden detaillierter dargestellten Vorschläge (Elisabeth ist der Rufname in den Beispielen):

• A1 "Elisabeth"
• A2 _Elisabeth_
• A4 Elisabeth*
• B2 2 _RUFNAME Elisabeth
• B4 1 NAME Elisabeth 2 TYPE Rufname

Die Kennzeichnungen des Rufnamens nach A1, A2, A4 waren alle drei in jeweils einigen der hier beteiligten Programmen realisiert. Diese untereinander nicht kompatible Vorgehensweise war eines der Datentransfer-Probleme, welches mit diesem GEDCOM-Projekt gelöst und durch eine einheitliche Vorgehensweise ersetzt werden soll.

Ruf.A1 Kennzeichnung des Rufnamens mit Anführungszeichen

Die Kennzeichnung des Rufnamens erfolgt durch Anführungszeichen am Anfang und am Ende des Rufnamens. Diese Kennzeichnung muss einheitlich in NAME und in GIVN exportiert werden, wenn das optionale GIVN exportiert wird.

Beim Import muss dem Anwender die optionale Möglichkeit gegeben werden, der Kennzeichnung mit Anführungszeichen eine andere Bedeutung zu geben ( z.B. als Spitzname gemaess GEDCOM 5.4 )

Beispiel:

• 1 NAME Maria "Elisabeth" Johanna /Alt/

Folgende Argumente wurden in der Liste dem Vorschlag mit den Anführungszeichen zugeordnet:

• PRO: bleibt auch bei Datentransfer zu und von anderen, nicht an der Vereinbarung beteiligte Programmen erhalten
• CONTRA: in Drittprogrammen wird diese Rufnamenkennzeichnung oft als Klartext angezeigt. Wenn der Anwender das löscht, löscht er damit ggfs. unbewusst die Strukturinformation.
• CONTRA: Verwechslung mit Eingaben des Anwenders möglich, diese werden ggfs umgedeutet (Mischung von Inhalt und Struktur)
• CONTRA: fehlende Unterscheidung zur alten Spitznamen-Kennung aus GEDCOM 5.4 durch Anführungszeichen "...", die von Anwendern mit Programmen ohne Datenfeld für Spitzname oft weiterverwendet wird. Dies erfordert eine zusätzliche Importregel.

Ruf.A2 Kennzeichnung des Rufnamens mit Unterstrichen

Die Kennzeichnung des Rufnamens erfolgt durch Unterstriche am Anfang und am Ende des Rufnamens. Diese Kennzeichnung muss einheitlich in NAME und in GIVN exportiert werden, wenn das optionale GIVN exportiert wird.

Beispiel:

• 1 NAME Maria _Elisabetha_ Johanna /Alt/

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

• PRO: Einfache Realisierung in den Programmen
• CONTRA: in Drittprogrammen wird diese Rufnamenkennzeichnung manchmal als Klartext angezeigt. Wenn der Anwender das löscht, löscht er damit ggfs. unbewusst die Strukturinformation. Andere Drittprogramme löschen diese Strukturinformation ohne Warnung.
• CONTRA: führt in Drittprogrammen teilweise zu Veränderungen des Rufnamens, z.B. Kleinschreibung
• CONTRA: Verwechslung mit Eingaben des Anwenders (z.B. Kennzeichnung unleserlicher Stellen) möglich, diese werden ggfs umgedeutet (Mischung von Inhalt und Struktur)

Ruf.A4 Kennzeichnung des Rufnamens mit Stern am Ende

Die Kennzeichnung des Rufnamens erfolgt durch einen Stern am Ende des Rufnamens. Diese Kennzeichnung muss einheitlich in NAME und in GIVN exportiert werden, wenn das optionale GIVN exportiert wird.

Beispiel:

• 1 NAME Maria Elisabeth* Johanna /Alt/

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

• PRO: Einfache Realisierung in den Programmen
• PRO: bleibt auch bei Datentransfer zu und von anderen, nicht an der Vereinbarung beteiligte Programmen erhalten
• CONTRA: in Drittprogrammen wird diese Rufnamenkennzeichnung oft als Klartext angezeigt. Wenn der Anwender das löscht, löscht er damit ggfs. unbewusst die Strukturinformation.
• CONTRA: Verwechslung mit Eingaben des Anwenders möglich, diese werden ggfs umgedeutet (Mischung von Inhalt und Struktur)

Ruf.B2 Kennzeichnung des Rufnamens mit nutzerdefiniertem Kennzeichen _RUFNAME (vereinbarte Version)

Die Kennzeichnung erfolgt mittels eines dem Kennzeichen NAME zugeordneten nutzerdefinierten Kennzeichens n+1 _RUFNAME. Dabei muss das exportierende Programm sicherstellen, dass der mit diesem Kennzeichen exportierte Rufname einer der Vornamen aus NAME bzw GIVN ist.

Wird beim Import eine fehlerhafte GEDCOM-Datei vorgefunden, wo der als Rufname angebene Name nicht einer der Vornamen ist, so wird empfohlen, eine Fehlermeldung auszugeben oder die entsprechende Information als Bemerkung dieser Person zuzuordnen.

Beispiel:

• 1 NAME Maria Elisabeth Johanna /Alt/
• 2 _RUFNAME Elisabeth

Folgende Argumente wurden in der Liste diesem Vorschlag zugeordnet:

• PRO: Saubere Trennung von Dateninhalt und Struktur
• PRO: Autor von Brother's Keeper hat bereits angekündigt, diese Variante zu übernehmen
• PRO: Drittprogramme geben oft qualifizierte Fehlermeldungen aus oder speichern in Bemerkungen um, so dass der Hinweis auf den Rufnamen vorhanden ist
• PRO: Fehlerhafte Rufnamen Interpretationen von Drittprogrammen können beim Import erkannt werden, da sie meist einhergehen mit einem von den Vornamen abweichenden Rufnamen.
• CONTRA: Nutzerdefiniertes Kennzeichen wird in anderen, in dieser Liste nicht beteiligten Programmen meist nicht verstanden, Datentransfer bedeutet damit oft Verlust der strukturierten Information
• CONTRA: Zusätzlicher Programmaufwand zur Sicherung der Übereinstimmung des Rufnamens mit einem der Vornamen, wenn Rufname und Vornamen in getrennten Datenfeldern Klartext-Eingabemöglichkeiten bieten

Ruf.B4 Kennzeichnung des Rufnamens mit Mehrfachname / TYPE Rufname

Die Kennzeichnung des Rufnamens erfolgt durch Anlegen einer zusätzlichen PERSONAL_NAME_STRUCTURE mit dem Rufnamen als Name und der zugeordneten <user-defined> TYPE Rufname.

Beispiel:

• 1 NAME Maria Elisabeth Johanna /Alt/
• 1 NAME Elisabeth
• 2 TYPE RUFNAME

Folgende Argumente wurden in der Liste diesem Vorschlag zugeordnet:

• PRO: Diese Variante entspricht am ehesten dem Standard 5.5.1, da eine Mehrnamensstruktur mit Differenzierung über TYPE im Standard berücksichtigt ist
• PRO: Saubere Trennung von Dateninhalt und Struktur
• PRO: Fehlerhafte Rufnamen Interpretationen von Drittprogrammen können beim Import erkannt werden, da sie meist einhergehen mit einem von den Vornamen abweichenden Rufnamen.
• CONTRA: Zusätzlicher Programmaufwand zur Sicherung der Übereinstimmung des Rufnamens mit einem der Vornamen, wenn Rufname und Vornamen in getrennten Datenfeldern Klartext-Eingabemöglichkeiten bieten
• CONTRA: es wird ein neuer NAME aufgemacht, obwohl es sich nicht um einen eigenständigen Zweitnamen der Person handelt
• CONTRA: das Problem mit unvollständigen NAME Zeilen (hier ohne Nachnamen und ohne die anderen Vornamen) tritt auf
• CONTRA: diese Version wäre für Programme außerhalb der hier vertretenen Programme nicht lesbar
• CONTRA: in Drittprogrammen ohne Mehrfachnamenunterstützung wird evtl nur der Rufname, aber nicht der gesamte Name der Person importiert
• CONTRA: für diese Version müssen Programme Mehrfachnamen unterstützen. Dies ist jedoch nur bei einem Teil der beteiligten Programme vorgesehen. Für die restlichen Programme wird eine der anderen Lösungen gebraucht.

Status für Rufname insgesamt:

Vereinbarung getroffen

Kennzeichnung Spitznamen in NAME

Problem:

Der Standard sieht das Kennzeichen NICK als optionales Kennzeicheng 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 Kennzeichen NAME exportieren, sondern ausschließlich über das Kennzeichen NICK (und damit das Kennzeichen NICK nicht mehr optional zufügen, sondern zwingend zu verwenden bei Vorhandensein eines Spitznamens):

1 NAME Ursula /Riem/

2 NICK Uschi

Status:

Vereinbarung getroffen

Beziehung zwischen NAME und TITL

Das Kennzeichen TITL ist ein eigenständiger Teil der Personenbeschreibung auf gleicher Ebene 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:

Vereinbarung getroffen

Nicht angenommener Entscheidungsvorschlag

Als Alternative zu E5 wurde mit dem folgenden Entscheidungsvorschlag E6 eine andere Einordnung von SPFX in NAME zur Abstimmung gestellt. Diese Alternative bekam deutlich weniger Zustimmung als die verabschiedete Version E5. Sie steht hier nur noch zur Information und Rückverfolgbarkeit der Vorgehensweise:

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

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