Speicherung/Kennzeichnung von Rufnamen

Hallo,
gesucht wird eine möglichst "programmunabhängige" Speicherungsmöglichkeit bzw.
Kennzeichnungsmöglichkeit des Rufnamens.
D.h. wenn ich einen Datenbestand via Gedcom-Datei von einem Programm zum
nächsten übernehme, soll die Information "dies ist der Rufname" erhalten
bleiben. Also keine programmspezifischen Lösungen.

Ich habe die Gedcom-Spezifikation quergelesen und bin nicht draus schlau
geworden, ob dieser überhaupt sowas vorsieht
(The GEDCOM Standard Release 5.5: Chapter 2).
Speziell ist mir unklar, warum man den Namen einerseits im Tag NAME speichert
(Nachname in Schrägstrichen), zusätzlich (redundant) dann aber noch die
untergeordneten Tags GIVN und SURN hat).

Inwieweit ist es sinnvoll, die Information "Rufname" in einem
benutzerdefinierten Tag (z.B. _RUFN) zu speichern?
Ich nehme an, dies können die gängigen Programme zwar importieren, aber
'wissen' dann nicht, was dieses Feld bedeutet.

Speziell von den hier auf der Liste mitlesenden Programmierern wüßte ich
gerne, wie diese das Rufnamenproblem gelöst haben.

(Den Erweiterungsvorschlag von
GEDCOM 5.5EL – GenWiki für
die Rufnamen kann/möchte ich aus Kompatibilitätsgründen nicht nutzen.)

Grüße
Ulrich Kretschmer

Moin Ulrich Kretschmer,

zur Mail vom Mon, 8 Aug 2005 18:00:22 +0200:

Ich habe die Gedcom-Spezifikation quergelesen und bin nicht draus schlau
geworden, ob dieser �berhaupt sowas vorsieht
(The GEDCOM Standard Release 5.5: Chapter 2).

IMHO nicht... Die international n�chste Version w�re 5.5.1 (Draft), und die
zumindest sieht folgendes vor (aber ob es �berhaupt Programme gibt, die die
implementiert haben?):

PERSONAL_NAME_STRUCTURE:=
n NAME <NAME_PERSONAL> {1:1} p.54
+1 TYPE <NAME_TYPE> {0:1} p.56
+1 <<PERSONAL_NAME_PIECES>> {0:1} p.37

NAME_TYPE:= {Size=5:30}
[ aka | birth | immigrant | maiden | married | <user defined>]
Indicates the name type, for example the name issued or assumed as an
immigrant.
[...]
user_defined= other text name that defines the name type.

und f�r letzteres w�re dann Rufname zu setzen.

Speziell ist mir unklar, warum man den Namen einerseits im Tag NAME speichert
(Nachname in Schr�gstrichen), zus�tzlich (redundant) dann aber noch die
untergeordneten Tags GIVN und SURN hat).

Vielleicht nicht redundant, sondern alternativ? Ich knne zuminest ein
programm, da� standardm��ig keine getrennten Felder f�r Vor- und Nachnamen
vorsieht, sondern letzteren aus dem Gesamtnamen entnimmt (ggf. nach
bestimmten Regeln oder Kennzeichen, z.B. von/de usw.) und dann auch nur als
ein Feld an Gedcom �bergibt. Ich find's auch nicht so toll, aber es
funktioniert und ist konform...

Gru�
Gerd (Schmerse)

Gerd Schmerse wrote:

IMHO nicht... Die international nächste Version wäre 5.5.1 (Draft), und die
zumindest sieht folgendes vor (aber ob es überhaupt Programme gibt, die die
implementiert haben?):

In Familienbande ist es folgendermaßen implementiert:

1 NAME Ilse Ida Henriette /Hamann/
2 GIVN Ilse
3 TYPE RUF
2 GIVN Ida
2 GIVN Henriette
2 SURN Hamann

Ich meine, das wäre mal in der Mailingliste programmierer@genealogy.net so besprochen worden.

MfG, Metti.

Ulrich Kretschmer schrieb:

Hallo,
gesucht wird ...

[...]

Klaus Vahlbruch wrote:

1. WEM gegenüber wurde dieser Vorschlag gemacht? (Adressat)

Die Definition Gedcom 5.5EL (extended location) wurde aufgrund fehlender Möglichkeiten des Gedcomstandards 5.5 erarbeitet, da die Mormonen keinerlei Interesse an solchen Erweiterungen erkennen ließen (Gedcom 5.5 ist von 1995) und auf Vorschläge nicht reagierte.

Beteiligt waren/sind die genannten Hersteller (und weitere Interessierte?).

Gerichtet ist diese Definition an alle, die Gedcom benötigen, mit den Möglichkeinen von 5.5 nicht vollständig zufrieden sind. Gedcom 5.5EL ist somit ein offener "Standard", der von jedem genutzt werden darf.

2. Hat der (Haben die) gegenüber dem/denjenigen, die den Vorschlag
gemacht haben, in irgend einer Weise reagiert?

Da jeder gemeint sein kann, ist eine Antwort nicht zwingend notwendig.
Ich habe zumindest Teile der Definition in meinem Programm genutzt.

3. Wissen die nicht genannten Programmhersteller von dem Vorschlag?

Ich denke schon. Soweit ich weiß, erwähnen sie in ihren Programmen Gedcom 5.5EL.

5. Gibt es den Kreis/das Gremium der Vorschlagenden noch?

Soweit ich weiß, ja.
Ich denke, es können dort auch weitere Vorschläge gemacht werden.
So wie ich das verstanden habe, dient die Definition dazu, dass sich die Programme weiterhin untereinander austauschen können. Häufig genug kommt es vor, dass ein Programm eigene Tags nutzt, aber kein anderes Programm ohne Versuche herausbekommt, wozu die gut sind. Genau das soll vermieden werden. (IMHO)

6. Wann und wo wird der Vorschlag weiter erörtert / befördert?

In programmierer@genealogy.net wurde mal darüber diskutiert. Mir ist eine Diskussion über die Darstellung des Rufnamen in Erinnerung.

7. Gibt es Ergebnisse der Umseztungen bei den o.g. Herstellern?

Das Ergebnis ist die Definition von gedcom 5.5EL.

8. Gibt es eine Zeitperspektive wann der Standard 'Verkehrsgeltung'
erlangt haben sollte?

Nie.
Das Problem ist, Gedcom 5.5 ist ein Standard. Die Erweiterung ist aus der Not entstanden, weil Gedcom sich nicht weiterentwickelt und zumindest die deutschen Programmentwickler weitere Möglichkeiten benötigten. Gedcom 5.5EL ist somit ein Vorschlag wie man mit Daten umgehen soll, die im bisherigen Standard nicht abgebildet werden können. Es ist gewährleistet, dass Programme, die Gedcom 5.5 importieren können, dies auch mit 5.5EL können. Lediglich die zusätzlichen Möglichkeiten bleiben auf der Strecke.

9. Gibt es eine Beschreibung, die im Detail auch einfache
Benutzer lesen und nachvollziehen können?

Ja.
<http://wiki.genealogy.net/index.php/Gedcom_5.5EL&gt;

10. Wer ist der Ansprechpartner für diese Initiative?

Kann ich nicht genau sagen. Geh doch oben mal in den Bereich Mailinglisten und melde Dich bei Programmierer an. Dort solltest Du eine passende Antwort finden (falls sich hier keiner melden sollte)

Wichtg! Ich habe nach bestem Wissen geantwortet. Sollte es jemand besser wissen, möge er mich korrigieren.

MfG, Metti.

Hallo, Herr Kretschmer!

Da speziell Programmierer angesprochen sind, m�chte ich als Programmierer von "Ahnenblatt" dazu antworten.
Ahnenblatt kann seit ca. einer Woche (Version 1.34) mit Rufnamen umgehen und ich habe mich w�hrend der Programmierung intensiv mit der Gedcom-Thematik besch�ftigt, bin also noch "voll im Thema".

Vorab: Rufnamen sind ein v�llig unamerikanisches Thema (daf�r gibt es nicht einmal eine englische �bersetzung!) und daher im Gedcom-Standard
(5.5) gar nicht vorgesehen. Es muss also ein Sonderkonstrukt her!

Einen Versuch in diese Richtung gab es mit Gedcom 5.5 EL (siehe GEDCOM 5.5EL – GenWiki).

Dort wird folgende Kennzeichnung vorgeschlagen (Rufname "Ernst"):

   1 NAME Hieronimus Ernst-R�diger Hermann-Josef/Pockenfurth/
     2 GIVN Hieronimus
     2 GIVN Ernst
       3 TYPE RUF
     2 GIVN -R�diger
     2 GIVN Hermann-Josef
     2 SURN Pockenfurth

Meines Wissen von Dynas-Tree, RS-Ahnen und (wie wir lesen konnten) von Familienbande verwendete Rufnamen-Kennzeichnung.

Entscheidende Nachteile dieser Variante:
- "TYPE" geh�rt nicht zum Standard 5.5, sondern "lediglich" zum Entwurf 5.5.1 (OK, im Ernstfall nicht weiter tragisch)
- GIVN kommt mehr als einmal vor (laut Standard nur 0- oder 1-mal erlaubt! - das wird in der vormals genannten Doku unter The GEDCOM Standard Release 5.5: Chapter 2
mit "{0:1}" dargestellt)

Effekt: einige Programme lesen beim Import entweder nur die erste oder nur die letzte GIVN-Zeile. Die �brigen Angaben werden ignoriert und pl�tzlich ist z.B. nur noch "Hieronimus" der Vorname!

Ahnenblatt verwendet beim Export statt dessen die Kennzeichnung mittels Unterstrichen, also:

   1 NAME Hieronimus _Ernst_-R�diger Hermann-Josef /Pockenfurth/

Diese Kennzeichnung verst��t nicht gegen den Standard, wird schon seit Jahren so von Ages! verwendet und ist selbst f�r amerikanische Programme importierbar und f�r den Anwender lesbar und eingebbar.
Ich habe mich aufgrund der Robustheit f�r diese Variante entschieden (ich kenne kein Programm, dass Unterstriche aus den Vornamen filtert), die auch (nach kurzer Konfiguration) vom Programm "Stammbaumdrucker" erkannt wird.

Bei meinen Experimenten war Stammbaumdrucker das einzige Programm, das einen benutzerdefinierten Tag ("_RUFNAME") benutzt (ich wei� nicht mehr, ob beim Im- oder Export). Viele Programme werden diese Angabe aus Unwissenheit schlichtweg ignorieren oder als fehlerhaft melden.

Weiterhin noch h�ufig anzutreffen eine Kennzeichnung mit "Grad-Zeichen":

   1 NAME Hieronimus � Ernst �-R�diger Hermann-Josef /Pockenfurth/

(keine �berfl�ssigen Leerzeichen - das geh�rt wirklich so ...!)

Verwendet von GF-Ahnen, Ahnenchronik, Stammbaumdrucker (nur Import) und GenProfi-Stammbaum.

Seltene exportierte Rufnamenvariante vom Stammbaumdrucker:

   1 NAME Hieronimus Ernst-R�diger Hermann-Josef /Pockenfurth/
     2 SURN Pockenfurth
     2 GIVN Hieronimus Ernst-R�diger Hermann-Josef
   1 EVEN Ernst
     2 TYPE Rufname

Und als letztes auch eine sch�ne Variante von "der AhnenManager":

   1 NAME Ernst /Pockenfurth/
     2 TYPE user_defined
     2 GIVN Hieronimus Ernst-R�diger Hermann-Josef
     2 SURN Pockenfurth

Also insgesamt ein Wust an zumeist zueinander inkompatiblen Varianten.

Um auf die Ausgangsfrage zur�ckzukommen, w�rde ich die Unterstriche als Kennzeichnung w�hlen, da diese die Anforderung am besten erf�llen ...

gesucht wird eine m�glichst "programmunabh�ngige" Speicherungsm�glichkeit bzw. Kennzeichnungsm�glichkeit des Rufnamens.
D.h. wenn ich einen Datenbestand via Gedcom-Datei von einem Programm zum n�chsten �bernehme, soll die Information "dies ist der Rufname" erhalten bleiben. Also keine programmspezifischen L�sungen.

Gru�, Dirk B�ttcher.

P.S.: Sollte jemand noch eine Rufnamenkennzeichnung kennen, die ich hier nicht erw�hnt habe, so m�ge er mir diese melden (evtl. auch privat), damit ich auch diese noch bei dem Gedcom-Import in Ahnenblatt ber�cksichtigen kann.

Hallo,
das ist ja hochinteressant! Damit sollte auch das Problem der Darstellung des
Nachnamenswechsels (Ehenamen usw.) "erschlagen" sein.
Gibt es einen Link, wo man diesen Entwurf im einzelnen nachlesen kann?
Und vor allem, ist eine Verabschiedung dieses Entwurfes in Sicht, bzw. welchen
Stand hat dieser?
Grüße
Ulrich Kretschmer

Moin Herr Kretschmer,
liebe Listenleser

die in der 5.5EL genannte L�sung zum Thema Rufnamen erscheint mir nicht optimal, die Gr�nde sind fast deckungsgleich mit den von Dirk B�ttcher genannten. Obwohl Ages 1.40 ansonsten GEDCOM 5.5 EL ausgiebig nutzt, markiert es den Rufnamen durch Unterstriche, also:

1 NAME Hieronimus _Ernst_-R�diger Hermann-Josef /Pockenfurth/

Diese L�sung hat den Vorteil, dass die Markierung auch in solchen Programmen erhalten bleibt, die keine Rufnamen unterst�tzen, die GEDCOM-Originaldokumentation nicht verletzt wird (mehrere GIVN), und sogar einige amerikanische Programme das verarbeiten k�nnen. Amerikaner unterstrechen n�mlich bisweilen auch Vornamen, wenngleich aus anderem Grund.

Da ist nat�rlich auch gleich der Nachteil: Die Namen k�nnen in anderen Programmen durch die Unterstriche etwas merkw�rdig aussehen, der Sinn bleibt aber erhalten.

GEDCOM 5.5EL ist ein Entwurf, und eine Diskussionsgrundlage, nicht das Ende einer Debatte - allein die Ausgangslage k�nnte bereits kaum unterschiedlicher sein, genauso sind es nat�rlich dann auch die L�sungsvorschl�ge. Allein dass �berhaupt etwas Dokumentiert wird ist bereits ein fortschritt.

Mit freundlichem Gru�

J�rn Daub

Ahnenblatt verwendet beim Export statt dessen die Kennzeichnung mittels
Unterstrichen, also:

   1 NAME Hieronimus _Ernst_-Rüdiger Hermann-Josef /Pockenfurth/

(...)

Weiterhin noch häufig anzutreffen eine Kennzeichnung mit "Grad-Zeichen":

   1 NAME Hieronimus ° Ernst °-Rüdiger Hermann-Josef /Pockenfurth/

(keine überflüssigen Leerzeichen - das gehört wirklich so ...!)

(...)

Um auf die Ausgangsfrage zurückzukommen, würde ich die Unterstriche als
Kennzeichnung wählen, da diese die Anforderung am besten erfüllen ...

Hallo,
diese "Markierungsvarianten" funktionieren aber nur, wenn der Rufname mit
einem der Taufnamen identisch ist.
Gegenbeispiele somit: Taufname Friedrich -> Rufname Fritz; ebenso für Eleonore
-> Lore (und vermutlich gibt es noch zahlreiche weitere solche)
In diesen Fällen hilft dann doch nur ein eigenes Datenfeld, so man nicht im
Namensfeld mit Klammern arbeitet möchte (unschön).
Grüße
Ulrich Kretschmer

Hallo Herr Kretschmer,

ich kann mich erinnern, dass wir seinerzeit bei der 5.5EL Diskussion dar�ber sprachen,
einen Tag "KOSE" einzuf�hren, um derartige F�lle abzudecken,

der Gedanke wurde wieder verworfen, zugunsten des Vorschlags, Kosenamen wie Spitznamen "NICK" zu behandeln.

ich pers�nlich h�tte mit dem "KOSE" Tag keine Probleme, weil er gut in 5.5EL hineingepasst h�tte

1 NAME Anselm /Hettenkofer/
2 GIVN Anselm
3 TYPE RUF
2 KOSE Semmerl

oder sogar

1 NAME Anselm /Hettenkofer/
2 GIVN Anselm
2 KOSE Semmerl
3 TYPE RUF

wenn ich jetzt was neues zu programmieren h�tte, w�rde ich um alles in der Welt sowas wie Sonderzeichen in
Datenfeldern vermeiden. Metadaten (beschreibende und steuernde Daten) geh�ren von den Nutzdaten getrennt.

> diese "Markierungsvarianten" funktionieren aber nur, wenn der Rufname mit

einem der Taufnamen identisch ist.
Gegenbeispiele somit: Taufname Friedrich -> Rufname Fritz; ebenso f�r Eleonore
-> Lore (und vermutlich gibt es noch zahlreiche weitere solche)
In diesen F�llen hilft dann doch nur ein eigenes Datenfeld, so man nicht im
Namensfeld mit Klammern arbeitet m�chte (unsch�n).
Gr��e
Ulrich Kretschmer
_____________________________________________
An-, Abmelden bzw. persoenliche Einstellungen aendern
genealogie-programme - genealogy.net

mit freundlichen Gruessen
Gerhard Bauch Software Entwicklung
http://www.dynas-tree.de
neue email Adresse :
mailto:gb@gerhardbauch.de

Ulrich Kretschmer wrote:

Gibt es einen Link, wo man diesen Entwurf im einzelnen nachlesen kann?

Wenn Du das nirgends findest (sicher irgendwo bei den Mormonen) kann ich Dir die PDF-Datei schicken.

Und vor allem, ist eine Verabschiedung dieses Entwurfes in Sicht, bzw. welchen Stand hat dieser?

Gedcom 5.5.1 draft ist vom 2.10.1999, mittlerweile gibt es noch Gedcom XML Relese 6.0 draft vom 28.12.2001. Wie schon erwähnt, sind die Mormonen recht gemächlich mit den Umsetzungen. Von beiden gibt es (meines Wissens) keine endgültige Version.

MfG, Metti.

Daub Support wrote:

Allein dass überhaupt etwas Dokumentiert wird ist bereits ein fortschritt.

Genau das sehe ich hier auch.

Für Familienbande werde ich die von Dirk Böttcher erwähnten Möglichkeiten beim Import berücksichtigen und für den Export die Variante mit Unterstrich für den normalen Export vorsehen, wer möchte, kann auf Gedcom EL umstellen. (in einer der kommenden Versionen)

MfG, Metti.

Moin Ulrich Kretschmer,

zur Mail vom Mon, 8 Aug 2005 22:20:10 +0200:

Gibt es einen Link, wo man diesen Entwurf im einzelnen nachlesen kann?

Ich wei� leider nicht mehr, wo ich das herhabe; die Datei hei�t
ged551-5.pdf - also mal googlen.
Aber:
Dieser Entwurf ist vom 2.10.1999 und wird wohl nicht mehr intensiv
weiterverfolgt... (vorsichtig ausgedr�ckt)

Gru�
Gerd (Schmerse)

Moin Ulrich Kretschmer,

zur Mail vom Tue, 9 Aug 2005 01:09:52 +0200:

diese "Markierungsvarianten" funktionieren aber nur, wenn der Rufname mit
einem der Taufnamen identisch ist.

Das ist er per definition.

Gegenbeispiele somit: Taufname Friedrich -> Rufname Fritz; ebenso f�r Eleonore
-> Lore (und vermutlich gibt es noch zahlreiche weitere solche)

Das sind keine "Rufnamen", sondern Kurznamen. Der Rufname war zu bestimmter
Zeit amtlich in Geburts- oder anderen Dokumenten als der von den Taufnamen
bevorzugte zu unterstreichen.

Gru�
Gerd (Schmerse)

Gerd Schmerse wrote:

diese "Markierungsvarianten" funktionieren aber nur, wenn der Rufname mit einem der Taufnamen identisch ist.

Das ist er per definition.

Gegenbeispiele somit: Taufname Friedrich -> Rufname Fritz; ebenso für Eleonore -> Lore (und vermutlich gibt es noch zahlreiche weitere solche)

Das sind keine "Rufnamen", sondern Kurznamen. Der Rufname war zu bestimmter
Zeit amtlich in Geburts- oder anderen Dokumenten als der von den Taufnamen
bevorzugte zu unterstreichen.

Rufname = Vorname, der von den Eltern als der bevorzugt benutzte Name genannt wird (Beispiel: Friedrich _Wilhelm_ Karl, um ihn von seinem Vater mit den gleichen Vornamen zu unterscheiden)

Nickname (Spitzname, Kurzname) = Kurzform des Ruf- oder Nachnamen, teilweise auch Eigenschaftsbezogen (Beispiel: Ursula Gerda -> Uschi, Stefan Mettenbrink -> Metti)

Kann man das so definieren?

MfG, Metti.

Moin Stefan Mettenbrink,

zur Mail vom Tue, 9 Aug 2005 10:14:27 +0200:

Kann man das so definieren?

Rufname: ja; bei "Nickname" werden die Ansichten m�glicherweise
auseinandergehen. BK kann zwischen Kurz- und Nick- unterscheiden:

1 NAME Hubertus Rufus /Magnus/
2 _SHON Rufus
2 NICK Rufi

ein
2 _RUFN
ist noch nicht implementiert, aber es w�rde IMHO auch nicht wirklich
helfen...

Gru�
Gerd (Schmerse)

Dirk Böttcher wrote:

- GIVN kommt mehr als einmal vor (laut Standard nur 0- oder 1-mal erlaubt! - das wird in der vormals genannten Doku unter The GEDCOM Standard Release 5.5: Chapter 2
E_STRUCTURE
mit "{0:1}" dargestellt)

Wenn man dor nachliest, steht dort:
NAME_PIE
[ <NAME_PIECE> | <NAME_PIECE_GIVEN>, <NAME_PIECE> ]
Given name or earned name. Different given names are separated by a comma.

Also müsste es doch folgendermaßen aussehen:

   1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef/Pockenfurth/
     2 GIVN Hieronimus, Ernst,-Rüdiger, Hermann,-Josef
     2 SURN Pockenfurth

Wenn nun der Rufname gekennzeichnet werden soll, könnte das so aussehen:

   1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef/Pockenfurth/
     2 GIVN Hieronimus, Ernst,-Rüdiger, Hermann,-Josef
     2 _RUF Ernst
     2 SURN Pockenfurth

Ich bin eigentlich davon ausgegangen, dass die Definition von Gedcom EL sich an die Vorgaben von Gedcom 5.5 hält und habe das ungeprüft übernommen.

Seltene exportierte Rufnamenvariante vom Stammbaumdrucker:

1 NAME Hieronimus Ernst-Rüdiger Hermann-Josef /Pockenfurth/
2 SURN Pockenfurth
2 GIVN Hieronimus Ernst-Rüdiger Hermann-Josef
1 EVEN Ernst
2 TYPE Rufname

Ein Ereignis vom Typ "Rufname".
Finde ich nicht sonderlich sinnvoll.
Ich sehe den Rufnamen als zusätzlichen Bestandteil der Pesonal_Name_Structure und würde dashalb dort einen benutzerdefinierten Tag einfügen (s.o.).

Und als letztes auch eine schöne Variante von "der AhnenManager":

1 NAME Ernst /Pockenfurth/
2 TYPE user_defined
2 GIVN Hieronimus Ernst-Rüdiger Hermann-Josef
2 SURN Pockenfurth

Das ist nicht Gedcomkonform. Mehrere Vornamen sind beim Tag GIVN durch Kommata zu trennen (s.o.). Ansonsten wäre das auch möglich.

So, jetzt werde ich in ich gehen und mal schauen, was ich davon problemlos in den Import einbauen kann.

Was ich als Exportvariante anbieten werde (außer der genannten) weiß ich auch noch nicht. Sehr wahrscheinlich die Variante mit den Unterstrichen (macht bei keinem Import wirklich Probleme, sieh aber nicht sonderlich schön aus).

Gefallen würde mir auch die von mir oben angezeigte Variante "2 _RUF Ernst". Das wäre wohl auch GedcomKonform. Ich möchte aber nicht noch mehr Varianen erzeugen.

Meinungen?

MfG, Metti.