Probleme beim GEDCOM-Austausch

genealogie-programme
1

Die eigentliche Botschaft meiner Mail sollte lauten:

"Obwohl das GEDCOM-Format als Standard f�r Ahnendaten gilt, bewahrt es
nicht vor Datenfehlinterpretationen oder gar Datenverlusten.
Dieses Problem ist nicht Ahnenblatt/Ages! spezifisch, sondern kann
jedem Anwender widerfahren, der mit mehreren Genealogieprogrammen
arbeitet."

Dieses wollte ich nur an einem konkreten Beispiel aufzeigen, was
meiner Meinung nach immer anschaulicher ist als blo�es Warnen.
Die Nachricht habe ich an diese Mailingliste geschickt, weil es sich
zum einen um einen programm�bergreifenden Anwenderfall handelt und
weil kurz darauf bei mir die Update-Meldung von Herrn Daub einging,
die auch auf GEDCOM-Verbesserungen hinwies.

... und ich fand dass in letzter Zeit etwas "Flaute" in dieser Liste
war und wollte selbst mal wieder ein neues Thema aufbringen.

Zu den bisherigen Kommentaren ...

- GEDCOM erlaubt doch doppelte NAMEn!

Stimmt. Aufgrund der Hinweise habe ich den entsprechenden Absatz
in der GEDCOM-Spezifikation jetzt auch gefunden (Seite 68 von 101).
Wenn dann ein Anwender "meine" GEDCOM-Dateien in PAF importiert und
den Hinweis ...

  FEHLER 3: datei.ged, Zeile 46: RIN 2:
  PAF kann nur einen Namen pro Person speichern.
  1 NAME VARIATION /BRACHT-ODENWALD/

... bekommt, ist nur schwer zu vermitteln, dass PAF sich nicht an
den GEDCOM-Standard h�lt, obwohl doch beides von den Mormonen stammt.

- NICK nicht gleich Rufname

Stimmt auch wieder. Ich wollte aber nur darauf hinweisen, dass es
immer besser ist, die von GEDCOM vorgegebenen Schl�sselw�rter zu
verwenden, als eigene zu "erfinden".
Statt ...

  1 NAME _Valerie_ Aloisia /MEIER/
  1 NAME VARIATION /BRACHT-ODENWALD/

... w�rde ich ...

  1 NAME _Valerie_ Aloisia /MEIER/
  1 NAME /BRACHT-ODENWALD/
  2 TYPE VARIATION

... vorziehen (wenn ich nicht schon wieder falsch liege :wink: ).

- GEDCOM-Manipulation mit Excel

Interessante M�glichkeit. Ich habe zur Erforschung von GEDCOM-
Problematiken immer ein Tool namens "Notepad" verwendet :wink:

Gerne nehme ich das Angebot von Herrn Daub an und werde mich
separat mit ihm in Verbindung setzen, um den Datenaustausch
zwischen den "einheimischen" Programmen zu optimieren.
Andere Programmierer d�rfen sich gerne anschliessen.

Gru�, Dirk B�ttcher.

2

[ snip ]

- GEDCOM erlaubt doch doppelte NAMEn!

Stimmt. Aufgrund der Hinweise habe ich den entsprechenden Absatz
in der GEDCOM-Spezifikation jetzt auch gefunden (Seite 68 von 101).
Wenn dann ein Anwender "meine" GEDCOM-Dateien in PAF importiert und
den Hinweis ...

  FEHLER 3: datei.ged, Zeile 46: RIN 2:
  PAF kann nur einen Namen pro Person speichern.
  1 NAME VARIATION /BRACHT-ODENWALD/

... bekommt, ist nur schwer zu vermitteln, dass PAF sich nicht an
den GEDCOM-Standard hält, obwohl doch beides von den Mormonen stammt.

Das ist ein Darstellungsproblem der Mormonen. Der GEDCOM-Standard
wird nicht von den Programmierern von PAF gepflegt - das ist wohl
auch besser so, um nicht zu einem PAF-Standard zu werden.

Daß PAF nicht alle GEDCOM-Tags verarbeitet ist den meisten PAF-Usern
anscheinend bekannt - oder aber Ages!-User benutzen kein PAF. Ich kann
mich jedenfalls nicht an Anfragen dieser Art erinnern. Gleichzeitig
ist die Fehlermeldung von PAF doch vorbildlich: "PAF kann nur einen
Namen pro Person speichern".

- NICK nicht gleich Rufname

Stimmt auch wieder. Ich wollte aber nur darauf hinweisen, dass es
immer besser ist, die von GEDCOM vorgegebenen Schlüsselwörter zu
verwenden, als eigene zu "erfinden".

An und für sich haben Sie recht, aber bitte *nicht* bestehende
Tags für sinnfremde Inhalte verwenden! Ein Rufname ist kein Spitzname.

Statt ...

  1 NAME _Valerie_ Aloisia /MEIER/
  1 NAME VARIATION /BRACHT-ODENWALD/

... würde ich ...

  1 NAME _Valerie_ Aloisia /MEIER/
  1 NAME /BRACHT-ODENWALD/
  2 TYPE VARIATION

... vorziehen (wenn ich nicht schon wieder falsch liege :wink: ).

Sie liegen leider falsch. Ja, ich fände das auch besser, ist aber
außerhalb der Specs, TYPE ist innerhalb von NAME nicht erlaubt. Es
sollte also _TYPE heißen, wenn überhaupt. Und da sind wir wieder am
selben Punkt angelangt. Ihre Variante birgt eine höhere
Wahrscheinlichkeit des Datenverlustes bei der Übertragung - daher
die Entscheidung das Schlüsselwort "VARIATION" in das Namensfeld
einzutragen.

Grüße

Jörn Daub

3

Dirk Böttcher schrieb:

Die eigentliche Botschaft meiner Mail sollte lauten:

- NICK nicht gleich Rufname

Stimmt auch wieder. Ich wollte aber nur darauf hinweisen,
dass es
immer besser ist, die von GEDCOM vorgegebenen
Schlüsselwörter zu
verwenden, als eigene zu "erfinden".

Wie erfasse/kennzeichne ich dann den Rufnamen in PAF 5.2?

Gerne nehme ich das Angebot von Herrn Daub an und werde
mich
separat mit ihm in Verbindung setzen, um den

Trotzdem sollten wir so viel wie möglich hier in der Liste und
möglichst wenig per private Mail diskutieren - im Interesse der
Abonnenten.

4

"Michael.Weinert" schrieb:

Dirk Böttcher schrieb:
>
> - NICK nicht gleich Rufname
>
> Stimmt auch wieder. Ich wollte aber nur darauf hinweisen,
> dass es
> immer besser ist, die von GEDCOM vorgegebenen
> Schlüsselwörter zu
> verwenden, als eigene zu "erfinden".
>
Wie erfasse/kennzeichne ich dann den Rufnamen in PAF 5.2?

Eigentlich gar nicht - das ist hier Teil des Problems. Einige PAF-
User benutzen den Unterstrich "_", um den Rufnamen einzurahmen,
also beispielsweise so:

   Anna _Maria_

Das ist aber - wenn überhaupt - nur eine Konvention, und keinesfalls
Standard. Ages! kennzeichnet Rufnamen innnerhalb der GEDCOM genauso.
Wenn Sie also eine Ages!-Datei mit Rufnamen in PAF importieren sehen
Sie die Unterstriche. Andersherum werden Namen, die in PAF so markiert
wurden beim Import in Ages! als Rufnamen erkannt. Innerhalb von Ages!
erscheint der Name dann korrekt unterstrichen.

> Gerne nehme ich das Angebot von Herrn Daub an und werde
> mich
> separat mit ihm in Verbindung setzen, um den
>
Trotzdem sollten wir so viel wie möglich hier in der Liste und
möglichst wenig per private Mail diskutieren - im Interesse der
Abonnenten.

Das letzte Mal, als hier technische Details erörtert wurden hagelte
es allerdings Schelte einzelner Listenteilnehmer :wink:

Grüße

Jörn Daub