GedCOM GES-2000 => TNG

Hallo,

ich möchte meine GES-2010 Daten über GedCom in TNG einpflegen, um diese mit anderen Forschern zu teilen und gemeinsam online zu erweitern.

Jedoch kommen einige Daten nicht in TNG an.
Ahnenblatt schreibt einige Datenfelder in die Notizen, dann müßte ich aber sehr viele Felder manuell korrigieren.
z.B.:
   AUTH wurde ignoriert.
   AUTH.CONT wurde ignoriert.
   EMIG.SOUR wurde ignoriert.
   FCOM.SOUR wurde ignoriert.
   MARC.SOUR wurde ignoriert.
   MARC.SOUR.PAGE wurde ignoriert.
   MARR.SOUR.PAGE wurde ignoriert.
   MARR.SOUR.RFN wurde ignoriert.
...

Kennt jemand einen Weg, wie ich meine Daten evt. über andere Software-Produkte in TNG bekomme?

Vielen Dank und liebe Grüße

  Ulli (Heist)

Hallo,
die obigen Punkte kann ich nicht nachvollziehen, dazu wären konkrete Gedcom-
Beispiel-Ausschnitte besser.
Grundsätzlich ist die Frage, ob das, was Ahnenblatt liefert, korrektes Gedcom
ist oder nicht.
Wenn ja, dann liegt das Problem bei TNG. Wenn nein, dann liegt das Problem bei
Ahnenblatt.
Viele Grüße
Ulrich Kretschmer

Hallo Ulrich,

deine Antwort erschien mir wenig hilfreich und irgendwie am Thema vorbei.

  z.B.:
    AUTH wurde ignoriert.
    AUTH.CONT wurde ignoriert.
    EMIG.SOUR wurde ignoriert.
    FCOM.SOUR wurde ignoriert.

die obigen Punkte kann ich nicht nachvollziehen, dazu w�ren konkrete Gedcom-
Beispiel-Ausschnitte besser.

Was war daran nicht nachvollziehbar?
Ahnenblatt meldet lediglich, dass bestimmte Daten aus der Gedcom-Datei nicht �bernommen wurden (dazu brauche ich auch keinen Beispiel-Ausschnitt).
Wenn es f�r bestimmte Daten keine eigenen Felder gibt, dann kann man diese Daten entweder in die Notizen/Anmerkungen schreiben oder ignorieren.
Hier hat sich der Anwender f�r ignorieren entschieden
Macht das nicht jedes Programm so ...?

Grunds�tzlich ist die Frage, ob das, was Ahnenblatt liefert, korrektes Gedcom
ist oder nicht.

Das w�rde mich jetzt wirklich mal interessieren: Wie kann Ulli pr�fen, ob Ahnenblatt korrektes Gedcom liefert?
Unabh�ngig von Ahnenblatt wird das wohl auch f�r andere interessant sein.

Wenn ja, dann liegt das Problem bei TNG. Wenn nein, dann liegt das Problem bei
Ahnenblatt.

Das Problem liegt in keinem Fall an Ahnenblatt ... :wink:

Wenn ich Daten von Programm A nach Programm B mittels Gedcom transferiere und mir Informationen dabei verloren gehen, dann Programm C dazwischenschalte, das die Daten von Programm A einmal im- und dann wieder exportiert, in der Hoffnung mit Programm B dann weniger oder keine Informationsverluste zu haben, dann kann ich das mangelhafte Endergebnis nicht Programm C (= Ahnenblatt) anlasten.

Gru�, Dirk.

Dirk Böttcher wrote:

FCOM.SOUR wurde ignoriert.

die obigen Punkte kann ich nicht nachvollziehen, dazu wären konkrete Gedcom-
Beispiel-Ausschnitte besser.

Was war daran nicht nachvollziehbar?

Aus dem Originaltext:
Ahnenblatt schreibt einige Datenfelder in die Notizen, dann müßte ich aber sehr viele Felder manuell korrigieren.
z.B.:
   AUTH wurde ignoriert.

Daraus konnte auch ich nicht entnehmen, dass es sich dabei um einen Ausschnitt aus einem Protokoll nach dem Einfügen einer Gedcomdatei in Ahnenblatt handelt.

Ahnenblatt meldet lediglich, dass bestimmte Daten aus der Gedcom-Datei nicht übernommen wurden (dazu brauche ich auch keinen Beispiel-Ausschnitt).

Damit ist die Ursprungsaussage verständlich und Deine weiteren Aussagen ebenfalls.

Wenn ich Daten von Programm A nach Programm B mittels Gedcom transferiere und mir Informationen dabei verloren gehen, dann Programm C dazwischenschalte, das die Daten von Programm A einmal im- und dann wieder exportiert, in der Hoffnung mit Programm B dann weniger oder keine Informationsverluste zu haben, dann kann ich das mangelhafte Endergebnis nicht Programm C (= Ahnenblatt) anlasten.

Das Problem ist, hier diskutieren Anwender, die sich der generellen Probleme beim Datenaustausch nicht bewusst sind. Sie sind der Meinung, Gedcom ist Austauschformat, also exportiere ich meine Daten per Gedcom, dann kann das importierende Programm meine Daten weiter bearbeiten.

Das die Programme aber unterschiedliche Möglichkeiten bieten, die sich nicht verlustlos transferieren lassen, merken sie erst, wenn etwas nicht so ist, wie sie es erwartet haben.

MfG, Metti.

Hallo Ulli,

ich m�chte meine GES-2010 Daten �ber GedCom in TNG einpflegen, um diese
mit anderen Forschern zu teilen und gemeinsam online zu erweitern.

Jedoch kommen einige Daten nicht in TNG an.

In den allermeisten F�llen kommen Gedcom-Daten im Zielprogramm nicht an, weil es daf�r schlichtweg keine Datenfelder gibt.

Als Programmierer eines Gedcom-Imports hat man dann die Wahl:
Man ignoriert die Daten (sollte den Anwender aber auch darauf aufmerksam machen - wie im Auszug des Gedcom-Import-Protokoll aus Ahnenblatt) oder man �bernimmt die Daten ("Gedcom-kryptisch" wie sie sind) in Notiz- oder Anmerkungsfelder.

Da ich TNG und schon gar nicht deine Gedcom-Daten im Detail kenne:
Hat TNG f�r die verlorengegangenen Daten eigene Datenfelder ...?

Wenn Ja: Es gibt Daten (wie z.B. Taufpaten), f�r die Gedcom keine Felder vorsieht. Da verwenden einige Programme eigene Erweiterungen (durchaus zul�ssig), die aber beim Import vom Zielprogramm aus Unwissenheit ignoriert werden. Solche F�lle w�rde ich TNG melden. Die sind sichlerlich �ber solche Hinweise dankbar.

Wenn Nein: in welchen vorhandenen Datenfeldern w�ren die Daten ansonsten zu erwarten gewesen (z.B. Notizfeld) ...?
Dann w�rde ich mich an TNG wenden und denen vorschlagen entweder neue Datenfelder hinzuzuf�gen oder beim Gedcom-Import bestimmte Daten in vorhandene Felder ... zu schreiben statt sie kommentarlos zu ignorieren.

Ahnenblatt schreibt einige Datenfelder in die Notizen, dann m��te ich
aber sehr viele Felder manuell korrigieren.
z.B.:
AUTH wurde ignoriert.
AUTH.CONT wurde ignoriert.
EMIG.SOUR wurde ignoriert.
FCOM.SOUR wurde ignoriert.
...

Kennt jemand einen Weg, wie ich meine Daten evt. �ber andere
Software-Produkte in TNG bekomme?

Man kann nicht erwarten, dass durch "Zwischenschalten" einer dritten Software die Gedcom-Datei derart "repariert" wird, dass dann das Import-Ergebnis in TNG besser wird.
Allermeistens ist das Gegenteil der Fall, denn auch das zwischengeschaltete Programm hat irgendwelche Limitierungen und erkennt bestimmte Daten nicht (Ahnenblatt hat keine eigenen Datenfelder f�r Emigration, Erstkommunion, ...).

Das Problem muss zwischen GES2000 und TNG gel�st werden. Fehlen Daten wom�glich schon beim Gedcom-Export, dann w�re GES2000 der Ansprechpartner, wenn beim Import Daten (zu Unrecht) ignoriert werden, dann w�re TNG anzusprechen.

Gru�, Dirk.

[...]

Aus dem Originaltext:
Ahnenblatt schreibt einige Datenfelder in die Notizen, dann müßte ich
aber sehr viele Felder manuell korrigieren.
z.B.:
AUTH wurde ignoriert.

Im vergangenen Spätsommer/Herbst wurde von vielen Programmentwicklern
aus dem deutschsprachigen Raum der Versuch gestartet, sich zu einigen,
wie man GedCom interpretieren sollte. Der Versuch war aus meiner Sicht
ziemlich erfolgreich.
Als nächsten Schritt hatte ich erwartet, daß man sich auch einigen
würde, wie man mit "weiteren Ereignissen" (erfasste Daten) umgeht.
GFAhnen oder GenealogyJ machen das z. B. (genau so?) wie PAF
- linage linked.

1 EVEN
2 TYPE Diakon-Weihe

oder

1 ORDN
2 TYPE Diakon-Weihe

Ein benutzerdefiniertes Ereignis wird als solches erkannt und aufgrund
seiner Struktur angezeigt. Nichts "verschwindet" in den Notizen. Bei
GenealogyJ habe ich bisher noch nicht heraus bekommen, wie man ein
benutzerdefiniertes Ereignis generiert.

> In GES-2008 habe ich nur Felder für Geburt, Taufe, Kommunion,
> Firmung, Tod, Bestattung.
> In TNG (unterstützt derzeit nur GedCom 5.5) werden obige Strukturen
> nicht unterstützt!

Ahnenblatt meldet lediglich, dass bestimmte Daten aus der Gedcom-Datei
nicht übernommen wurden (dazu brauche ich auch keinen
Beispiel-Ausschnitt).

Deshalb besteht, nicht nur hier, dringender Handlungsbedarf.

Die deutsche Übersetzung des GedCom-Standards:

www.daubnet.com/ftp/gedcom-551-deutsch.pdf

wird zwar oft zitiert, aber damit ist es nicht getan. Diejenigen
Programmentwickler die die von GedCom 551 gebotenen Chancen nutzen,
werden sich zwar einen Vorsprung erarbeiten, aber der verlustlose
Austauch von Daten wird nur zwischen Programmen möglich sein, die
genauso verfahren. Bis dahin wird PAF die komfortabelste Krücke
bleiben - sehr verbesserungsfähig und -würdig.
Als Windows-Nutzer warte ich jedenfalls darauf, was sich bei GFAhnen
tut. GenealogyJ aber hätte das Potential zur größeren Verbreitung.

Mit schönen Grüßen aus Landsberg am Lech,

Reiner (Kerp)

mailto:mail@reiner-kerp.de

im web: http://reiner-kerp.de

Hallo,

   MARC.SOUR.PAGE wurde ignoriert.

Wenn ja, dann liegt das Problem bei TNG.

Das Problem liegt definitv bei TNG, weil es unbekannte tags einfach ignoriert!

Teilweise erwartet es auch die tags in einer anderen 'Anordnung'.

GES-2000 (GedCom 5.5.1)
INDI CHR PAGE

TNG (GedCom 5.5)
INDI CHR SOUR PAGE

Wenn nein, dann liegt das Problem bei Ahnenblatt.

Nein. Ahnenblatt schreibt die unbekannten Einträge in die Notizen. Wenn ich die von Ahnenblatt erzeugte GedCom bei TNG einlese, dann habe ich alle Informationen; jedoch ist ein Teil in den Notizen.

Also keinesfalls ein Ahnenblatt-Problem - da habe ich mich wohl etwas ungeschickt ausgedrückt.

Nachdem was ich gelesen habe, denke ich (mittlerweile), daß es besser ist, wenn ich mich mit dem Programmierer von TNG in Verbindung setzte.

Liebe Grüße und Danke

  Ulli

Hups...

Alle hier erw�hnten Programme, mit Aushahme von PAF sind mit ihren
Autoren an der succesvien Ausarbeitung aller TAGs des erw�hnten
GEDCOM-Standard 5.5.1 in der GEDCOM-Liste aktiv beteiligt.

Wir arbeiten bereits seit mehr als einem vollen Jahr und sind
nicht unt�tig, daher darf nicht der Eindruck erweckt werden,
die Ergebisse lie�en auf sich warten...

Aber selbst so genannte "Drittprogramme" wie z.B. PAF sind immer
wieder Gegenstand der internen Betrachtung bei der fortschreitenden
Arbeit in der Liste, aber eines d�rfte klar sein:

    > Bis dahin wird PAF die komfortabelste Kr�cke
    > bleiben - sehr verbesserungsf�hig und -w�rdig.

PAF wird nicht "verbessert", PAF wird nicht "bleiben", sondern
ersetzt werden von den Herausgebern und wir alle wissen (noch)
nicht, was definitiv und endg�ltig an dessen Stelle tritt.
Die Autoren des PAF halten es offenkundig nicht f�r "w�rdig"!

Wir bitten als ADMINs der GEDCOM-Arbeitsliste alle Leser und
user, Profis wie auch die "einfachen" Anwender, um einige Geduld
und um aktive Mitarbeit, indem sie "Ihren" Programmen den Weg
zum besseren Verst�ndnis des GEDCOM-Standards durch feedback
erm�glichen und erleichtern.

Viele Gr��e
Klaus Vahlbruch

co-ADMIN in der GEDCOM-Liste
initiert und getragen vom Verein f�r Computergenealogie e.V.

Ich m�chte das ausdr�cklich best�tigen!

In den vergangenen Monaten haben wir es geschafft, trotz aller Konkurrenz der verschiedenen Programme (durchaus positiv gemeint!) ein enormes Pensum zu absolvieren. Wir haben uns darauf geeinigt, welchem GEDCOM-Standard wir folgen wollen, haben die Arbeitsweise und Vorgehensweise abgeglichen, und einige der wichtigsten Kennzeichen diskutiert, L�sungen und L�sungswege ausgearbeitet, und abschlie�ende Entscheidungen gemeinschaftlich gef�llt. Das war nicht immer einfach, 23 unterschiedliche L�sungsans�tze und Meinungen unter einen Hut zu bekommen. Aber wir haben es bislang zu jedem der besprochenen Kennzeichen geschfft. Jawoll!

Und wenn ich mir die Dolumentationen der teilnehmenden Programme ansehe, dann wurden die getroffenen Entscheidungen auch umgesetzt!

Ich denke, das sollte durchaus positiv gewertet werden!

Da die meisten Entwickler nicht alleine vom Vertrieb eines Genealogie-Programm leben k�nnen, sondern sich in anderen Jobs oder anderen Projekten einbringen m�ssen, halte ich die Fortschritte f�r �beraus beeindruckend. Es mu� jedem klar sein, das wir nicht jetzt schon alle Kennzeichen abgearbeitet haben k�nnen. Wir werden es schaffen, aber nicht morgen, nihct �bermorgen, udn auch nicht zum Ende dieses Jahres. Aber es wird kommen!

PAF ist ein Programm, das Ma�st�be gesetzt hat. Und auch heute noch �beraus h�ufig genutzt wird. Aber PAF ist tot! Seit vielen Jahren wird es nicht mehr weiterentwickelt, nicht mal kleinste Korrekturen oder Erweiterungen. Aber 23 Entwickler udn drei moderatoren sind HEUTE dabei, eines der gr��ten und wichtigsten Projekte im deutschsprachigen Raum zu verwirklichen. DAS ist es, was z�hlt!

Lassen Sie uns/lasst uns noch ein wenig Zeit. Es lohnt sich definitiv. Und alle Anwender deutschsprachiger Genealogiesoftware k�nnen ungemein davon profitieren. Heute schon.

Jan Escholt

deine Antwort erschien mir wenig hilfreich und irgendwie am Thema vorbei.

<loriot> ach? </loriot>

>> z.B.:
>> AUTH wurde ignoriert.
>> AUTH.CONT wurde ignoriert.
>> EMIG.SOUR wurde ignoriert.
>> FCOM.SOUR wurde ignoriert.
>
> die obigen Punkte kann ich nicht nachvollziehen, dazu wären konkrete
> Gedcom- Beispiel-Ausschnitte besser.

Was war daran nicht nachvollziehbar?
Ahnenblatt meldet lediglich, dass bestimmte Daten aus der Gedcom-Datei
nicht übernommen wurden

aha

(dazu brauche ich auch keinen Beispiel-Ausschnitt).

Schön für dich.
Als TNG-Anwender möchte *ich* aber verstehen, wie dasjenige konkret aussieht,
was da aus Ahnenblatt nicht nach TNG rüberkommt.

Grüße
Ulrich Kretschmer

[...]

Liebe Forscherfreunde,
warum streiten um ein Thema um das es garnicht geht!

In den vergangenen Monaten haben wir es geschafft, trotz aller
Konkurrenz der verschiedenen Programme (durchaus positiv gemeint!) ein
enormes Pensum zu absolvieren. Wir haben uns darauf geeinigt, welchem
GEDCOM-Standard wir folgen wollen, haben die Arbeitsweise und
Vorgehensweise abgeglichen, und einige der wichtigsten Kennzeichen
diskutiert, Lösungen und Lösungswege ausgearbeitet, und abschließende
Entscheidungen gemeinschaftlich gefällt. Das war nicht immer einfach, 23
unterschiedliche Lösungsansätze und Meinungen unter einen Hut zu
bekommen. Aber wir haben es bislang zu jedem der besprochenen
Kennzeichen geschfft. Jawoll!

Dem habe ich mit meiner Aussage:

>>> Der Versuch war aus meiner Sicht
>>> ziemlich erfolgreich.

keinesfalls widersprochen. Im Gegenteil!!!!!

Leider ist zu wenig darüber bekannt. Hier zumindest. Wäre das anders,
hätte es die Diskussion über die Ex-/Importprobleme nicht gegeben.

Was ich mit meinem Beitrag aufzeigen wollte war, wohin es führt,
wenn man sich nicht auch in der Behandlung der benutzerdefinierten
Ereignisse einigt. Diese Einigung auf die einheitliche Interpretation
des GedCom-Standards ist im Gange und wird sicher weitere positive
Folgen haben.

Ich denke, das sollte durchaus positiv gewertet werden!

Und ich denke, es kann garnicht hoch genug gewertet werden.
Troptzdem ist es "NUR" ein Schritt in die richtige Richtung.
Deshab auch meine Betreff-Zeile "GedCom und was dann?". Deshalb
auch mein posting hier in der Liste "Genealogie-Programme".

PAF ist ein Programm, das Maßstäbe gesetzt hat. Und auch heute noch
überaus häufig genutzt wird. Aber PAF ist tot! Seit vielen Jahren wird
es nicht mehr weiterentwickelt, nicht mal kleinste Korrekturen oder
Erweiterungen. Aber 23 Entwickler udn drei moderatoren sind HEUTE dabei,
eines der größten und wichtigsten Projekte im deutschsprachigen Raum zu
verwirklichen. DAS ist es, was zählt!

Genau so ist es! Aber auch andere Programme werden nicht weiter
entwickelt. Was ist mit TMG oder Ahnengalerie?

Trotzdem bleibt für mich PAF vorerst die "komfortabelste Krücke". Vor
allem deshalb, weil es sich an die Vorgaben des GedCom-Standards hält
und dem Anwender mehr Möglichkeiten offen hält als manches andere
Programm. Die Behandlung der Quellen in der HTML-Ausgabe ist sehr
unbefriedigend. Daß das Programm nicht weiter entwickelt wird ist ja
für Programmentwickler nicht unbedingt von Nachteil ;-))))))
Ich jedenfalls nutze es so, daß es mir zu gegebener Zeit nicht allzu
schwer fällt meine Daten vollständig in ein besseres Programm zu
importieren. Notizen MÜSSEN Notizen bleiben, damit ich wählen kann
ob ich sie in eine GedCom-Datei einbeziehe oder nicht.

Lassen Sie uns/lasst uns noch ein wenig Zeit. Es lohnt sich definitiv.
Und alle Anwender deutschsprachiger Genealogiesoftware können ungemein
davon profitieren.

Genau darauf bezog ich meinen Hinweis:

Als Windows-Nutzer warte ich jedenfalls darauf, was sich bei GFAhnen
tut. GenealogyJ aber hätte das Potential zur größeren Verbreitung.

Und wer es als Ahnenforscher nicht gelernt hat sich zu gedulden, dem
ist sowieso nicht zu helfen.

Mit schönen Grüßen aus Landsberg am Lech,

Reiner (Kerp)

mailto:mail@reiner-kerp.de

im web: http://reiner-kerp.de

Reiner Kerp wrote:

Der Versuch war aus meiner Sicht
ziemlich erfolgreich.

keinesfalls widersprochen. Im Gegenteil!!!!!

Leider ist zu wenig darüber bekannt. Hier zumindest. Wäre das anders,
hätte es die Diskussion über die Ex-/Importprobleme nicht gegeben.

Das hier nicht darüber diskutiert wird, hat damit zu tun, dass die Diskusion mglicherweise verlagert wird, Anwender ohne Hintergrundwissen mitdiskutieren und das Ganze unnötig länger dauert. Das ist keine böse Absicht.

Es wird immer Anwender geben, die meinen, dass mit Gedcom der Datenaustausch aller Daten zwischen allen Programmen funktioniert. Das geht definitiv nicht! Nicht mit Gedcom und nicht mit einem anderem Austauschformat.

Was ich mit meinem Beitrag aufzeigen wollte war, wohin es führt,
wenn man sich nicht auch in der Behandlung der benutzerdefinierten
Ereignisse einigt.

Ein schönes Beispiel.

Mein Programm unterstützt derzeit noch keine individuellen Ereignisse. Wie soll ich solche Ereignisse beim Import behandeln?
Selbst wenn ich diese biete, wird dann jeder Name eines Ereignisses von allen anderen Progemmen auch angeboten? Was ist mit fremdsprachigen Eingaben? Wie heißt mein individuelles Ereignis "Namensänderung" in einem spanischen Programm?

Das nur mal angerissen, um zu zeigen, dass die Diskusion bei "solchen Kleinigkeiten" schon vieles berücksichtigen muss.

MfG, Metti.

[...]

Leider ist zu wenig darüber bekannt. Hier zumindest. Wäre das anders,
hätte es die Diskussion über die Ex-/Importprobleme nicht gegeben.

Da habe ich mich offensichtlich mißverständlich ausgedrückt.

Das hier nicht darüber diskutiert wird, hat damit zu tun, dass die
Diskusion mglicherweise verlagert wird, Anwender ohne Hintergrundwissen
mitdiskutieren und das Ganze unnötig länger dauert. Das ist keine böse
Absicht.

Es wurde hier ja über diese Ex-/Importprobleme diskutiert.

Es wird immer Anwender geben, die meinen, dass mit Gedcom der
Datenaustausch aller Daten zwischen allen Programmen funktioniert. Das
geht definitiv nicht! Nicht mit Gedcom und nicht mit einem anderem
Austauschformat.

Warum soll das nicht gehen?
Wenn die "neuen" tags alle zwangsläufig mit Unterstrich beginnen,
funktioniert die Datenübertragung nur dann, wenn die jeweiligen
Programme das tag genau auf dieselbe Weise interpretieren.
Eine GedCom-Datei von MacStammbaum kann wohl kaum ein anderes
Programm fehlerfrei importieren. Dessen tags fangen alle mit
einem Unterstrich an, sogar diejenigen, die im Standard schon
eindeutig definiert sind.

PAF schafft das nicht einmal mit seinem eigenen tag _AKA. Werden zwei
Personen mit je einem _AKA verschmolzen, fällt eines der per _AKA erfasstes Datum (also known as "Name") unter den Tisch. Dies war für
mich Anlass, _AKA durch ein benutzerdefiniertes Ereignis "weitere
Namensschreibweise" zu ersetzen. Jetzt konnte ich "Standardnamen"
vergeben und die gefundenen "weiteren Namensschreibweisen" unter Anführung der jeweiligen Quelle vermerken und zusammen per
"Verschmelzen" zusammen führen. Nur so wurde schließlich:

0 @I5981@ INDI
1 NAME Wilhelm /FROEHLICH/
2 SURN FROEHLICH
2 GIVN Wilhelm
2 _AKA Wilhelm OCHOCINSKI vel FROEHLICH
1 SEX M

zu

0 @I5981@ INDI
1 NAME Wilhelm /FROEHLICH/
2 SURN FROEHLICH
2 GIVN Wilhelm
1 EVEN Wilhelm OCHOCINSKI
2 TYPE weitere Namen

Mein Programm unterstützt derzeit noch keine individuellen Ereignisse.
Wie soll ich solche Ereignisse beim Import behandeln?

Das Ereignis "Lebensphase" von GFAhnen interpretiert PAF (richtig!)
aus der GedCom-Dartei heraus als benutzerdefiniertes Ereignis.

Selbst wenn ich diese biete, wird dann jeder Name eines Ereignisses von
allen anderen Progemmen auch angeboten?

Wenn das benutzerdefinierte Ereignis entsprechend interpretiert wird,
ja!

Was ist mit fremdsprachigen
Eingaben? Wie heißt mein individuelles Ereignis "Namensänderung" in
einem spanischen Programm?

Wie wäre es mit AKA?:

1 EVEN Wilhelm FROEHLICH
2 TYPE (AKA) spanische Übersetzung von "Namensänderung"

Für verschiedene Sprach braucht es jeweils ein entsprechendes
Sprachmodul.

Das nur mal angerissen, um zu zeigen, dass die Diskusion bei "solchen
Kleinigkeiten" schon vieles berücksichtigen muss.

Banal ist das gewiss nicht! Aber wie heißt es doch so schön:
"Wenn´s einfach wär könnt´s jeder"

Mit schönen Grüßen aus Landsberg am Lech,

Reiner (Kerp)

mailto:mail@reiner-kerp.de

im web: http://reiner-kerp.de

Reiner Kerp wrote:

Es wird immer Anwender geben, die meinen, dass mit Gedcom der
Datenaustausch aller Daten zwischen allen Programmen funktioniert. Das
geht definitiv nicht! Nicht mit Gedcom und nicht mit einem anderem
Austauschformat.

Warum soll das nicht gehen?

Einen schönen vergleich bietet ein Umzug. Wenn Du aus einer goßen in eine kleine Wohnung umziehst, bekommst Du zwangsläufig nicht alles untergebracht. Das kann Dir zwischen zwei Genealogieprogrammen ebenfalls passieren.

Oder nimm einfach nur das Datumsfeld. Mache Programme lassen Freitext zu, andere geben Felder für Tag, Monat uns Jahr vor. Wenn ich in meinem Programm nun als Datum "Pfinstmontag 1876" eingegeben habe, kann ein Programm ohne Freitexteingabe dieses Datum nicht importieren. Das liegt nicht an Gedcom.
Mein Programm bietet Freitext, exportiert das Datum aber möglichst in Gedcomschreibweise. Wurde z. B. "ca. 1765" oder "um 1765" eingegeben, wird das in die Gedcomschreibweise "ABT 1765" gewandelt. Mein Programm kann aus "ABT 1765" wieder eine deutsche Schreibweise machen. Wenn jedoch beide Varianten (um und ca.) benutzt wurden, muss man sich beim Import für eine entscheiden.
Das ist nur eine kleine Änderung und an der Aussage des Datums ändert sich nichts, aber es ist eine Veränderung der Daten.

Noch schwere wird es, wenn ein Programm Quellenanngaben per Record exportiert, das importierende aber keine Quellenverwaltung hat.

Für all das kann Gedcom nichts, es liegt an den unterschiedlichen Gegebenheiten der verwendeten Programme.

Dies war für
mich Anlass, _AKA durch ein benutzerdefiniertes Ereignis "weitere
Namensschreibweise" zu ersetzen. Jetzt konnte ich "Standardnamen"
vergeben und die gefundenen "weiteren Namensschreibweisen" unter Anführung der jeweiligen Quelle vermerken und zusammen per
"Verschmelzen" zusammen führen. Nur so wurde schließlich:

Gedcom bietet für Deinen Fall die Möglichkeit, mehrere Namen anzugeben:
0 @I5981@ INDI
1 NAME Wilhelm /FROEHLICH/
2 SURN FROEHLICH
2 GIVN Wilhelm
1 NAME Wilhelm /OCHOCINSKI vel FROEHLICH/
2 SURN FROEHLICH
2 GIVN Wilhelm
1 SEX M

Nur kann damit nicht jedes Programm umgehen.
Auch nicht das Problem von Gedcom.

Was ist mit fremdsprachigen
Eingaben? Wie heißt mein individuelles Ereignis "Namensänderung" in
einem spanischen Programm?

Wie wäre es mit AKA?:

1 EVEN Wilhelm FROEHLICH
2 TYPE (AKA) spanische Übersetzung von "Namensänderung"

Das ist nicht dasselbe.
Ich meinte als Ereignis "Namensänderung" den Fall, dass jemand seinen Namen nicht mehr mag und diesen Ändern lässt. Das ist beim Standesamt hinterlegt. Mit Ort, Datum und ggf hat man sogar einen Scan davon.
AKA fürde ich lediglich für einen Künstlernamen benutzen wollen.

Für verschiedene Sprach braucht es jeweils ein entsprechendes
Sprachmodul.

Ach, und das setzt dann in jedem Programm einen deutschen Ereignisnamen in einen fremdsprachigen um? Du unterschätzt das Problem.
Ich wollte ohnehi nur aufzeigen, dass Gedcom hier mehr bietet, als die Programme umsetzen können. Insbesonderer gilt das für individuelle Tags und individuelle Ereignisse.

Das nur mal angerissen, um zu zeigen, dass die Diskusion bei "solchen
Kleinigkeiten" schon vieles berücksichtigen muss.

Banal ist das gewiss nicht! Aber wie heißt es doch so schön:
"Wenn´s einfach wär könnt´s jeder"

Es geht darum, dass ich als Programmierer für mein Program festlege, was möglich ist und was nicht. Das macht jeder Programmierer. Leider ist die Schnittmenge nie identisch und somit ein vollständiger Datenaustausch unmöglich.

MfG, Metti.

Es wird immer Anwender geben, die meinen, dass mit Gedcom der
Datenaustausch aller Daten zwischen allen Programmen funktioniert. Das
geht definitiv nicht! Nicht mit Gedcom und nicht mit einem anderem
Austauschformat.

Warum soll das nicht gehen?

Jetzt hast du mich schon wieder erwischt! In der Kürze liegt nicht
zwangsläufig die Würze.

Der Austausch kann nur beim identischem Austauschformat gelingen.
Das Austauschformat GedCom kann nur die Daten austauschen, die
in den beteiligten Programmen identisch erfasst/behandelt werden.

Einen schönen vergleich bietet ein Umzug. Wenn Du aus einer goßen in
eine kleine Wohnung umziehst, bekommst Du zwangsläufig nicht alles
untergebracht. Das kann Dir zwischen zwei Genealogieprogrammen ebenfalls
passieren.

Das mit dem Umzug gefällt mir gut.
Wenn z.B. ein Soldat der englischen Streitkräfte von einer
Dienstwohnung in eine andere umzieht, muss er nur das mitnehmen,
was über die Standard-Ausstattung hinaus geht. Das ist für die
Küche recht wenig. Er findet in der Küche der neuen Wohnung nicht
nur Herd und Spülbecken, sondern auch die gewohnten Töpfe, das gewohnte
Geschirr usw. usw.. Für andere Zimmer gilt das änlich.

Auf ein Genealogie-Programm und seinen Entwickler übertragen gilt
demnach - was brauche ich zusätzlich? Soll es überhaupt übertragen
werden oder verwende ich es nur intern? Wenn es übertragen werden soll,
wie stelle ich das an? Per GedCom oder als Excel-Tabelle? Im letzeren
Fall brauche ich zusätzlich ein Tabellenkalkulationsprogramm und
GedTool.

Oder nimm einfach nur das Datumsfeld. Mache Programme lassen Freitext
zu, andere geben Felder für Tag, Monat uns Jahr vor. Wenn ich in meinem
Programm nun als Datum "Pfinstmontag 1876" eingegeben habe, kann ein
Programm ohne Freitexteingabe dieses Datum nicht importieren. Das liegt
nicht an Gedcom.

Ist es nicht so, daß GedCom im Datumsfeld keinen Freitext zulässt?

[...]

Nur kann damit nicht jedes Programm umgehen.
Auch nicht das Problem von Gedcom.

Was ist mit fremdsprachigen
Eingaben? Wie heißt mein individuelles Ereignis "Namensänderung" in
einem spanischen Programm?

Wie wäre es mit AKA?:

1 EVEN Wilhelm FROEHLICH
2 TYPE (AKA) spanische Übersetzung von "Namensänderung"

Das ist nicht dasselbe.
Ich meinte als Ereignis "Namensänderung" den Fall, dass jemand seinen
Namen nicht mehr mag und diesen Ändern lässt. Das ist beim Standesamt
hinterlegt. Mit Ort, Datum und ggf hat man sogar einen Scan davon.
AKA fürde ich lediglich für einen Künstlernamen benutzen wollen.

Unter seinem geänderten Namen ist die Person dann aber "auch bekannt".

Ich hatte mir zuvor nochmals die Diskussionen in der GedCom-L und die
Resultate in Genwiki angesehen:

http://wiki-de.genealogy.net/GEDCOM/_Nutzerdef-Tag

unten in der Tabelle.
Darin sehe ich die Gefahr, daß sich einige Programmentwickler zu sehr
eingeengt fühlen und auf die Implementierung verzichten.

Den geschilderten Weg über benutzerdefinierte Ereignisse und deren
Transport (linage-linked) halte ich für einfacher umsetzbar. Ein
Programmentwickler muss sich dann nur noch darum kümmern, daß sie
Standard-Konform behandelt und die dort enthaltenen Daten korrekt
im-/exportiert werden.

Es geht darum, dass ich als Programmierer für mein Program festlege, was
möglich ist und was nicht. Das macht jeder Programmierer. Leider ist die
Schnittmenge nie identisch und somit ein vollständiger Datenaustausch
unmöglich.

Wie gesagt, "wenn´s einfach wäre". Ich kann´s nicht und für manchen
Programmentwickler ist es auch nicht einfach. Ich erinnere an die
Schwierigkeiten mit Ahnengalerie 3.0. Austauschformat ist nunmal
GedCom. Wer die Schnittmenge möglichst groß haben möchte, muss sich
an den Standard halten. Wie schwierig das ist, zeigt die Diskussion
über das tag ASSO in der GedCom-L.

Mit schönen Grüßen aus Landsberg am Lech,

Reiner (Kerp)

mailto:mail@reiner-kerp.de

im web: http://reiner-kerp.de

P.S.: ich setze jetzt mal aus, damit die Sache nicht ausufert.

Reiner Kerp wrote:

Oder nimm einfach nur das Datumsfeld. Mache Programme lassen Freitext
zu, andere geben Felder für Tag, Monat uns Jahr vor. Wenn ich in meinem
Programm nun als Datum "Pfinstmontag 1876" eingegeben habe, kann ein
Programm ohne Freitexteingabe dieses Datum nicht importieren. Das liegt
nicht an Gedcom.

Ist es nicht so, daß GedCom im Datumsfeld keinen Freitext zulässt?

Ja, das ist nicht so :slight_smile:
Gedcom lässt durchaus Freitext als Datum zu. Das sieht dann so aus:
n DATE (Pfingstsonntag 1898)

Leider versethen das viele Programme nicht. So gehören die Klammern nicht zu Freitext und ssen beim Import entfernt werden.

Was ist mit fremdsprachigen
Eingaben? Wie heißt mein individuelles Ereignis "Namensänderung" in
einem spanischen Programm?

Wie wäre es mit AKA?:

1 EVEN Wilhelm FROEHLICH
2 TYPE (AKA) spanische Übersetzung von "Namensänderung"

Das ist nicht dasselbe.
Ich meinte als Ereignis "Namensänderung" den Fall, dass jemand seinen
Namen nicht mehr mag und diesen Ändern lässt. Das ist beim Standesamt
hinterlegt. Mit Ort, Datum und ggf hat man sogar einen Scan davon.
AKA fürde ich lediglich für einen Künstlernamen benutzen wollen.

Unter seinem geänderten Namen ist die Person dann aber "auch bekannt".

Nein, es handelt sich um ein Ereigns "Namensänderung". Ab diesem Zeitpunkt hat die betreffende Person einen neuen Namen.
Das ist meine Meinung.

MfG, Metti.

Hallo Reiner

...

Ein benutzerdefiniertes Ereignis wird als solches erkannt und aufgrund
seiner Struktur angezeigt. Nichts "verschwindet" in den Notizen. Bei
GenealogyJ habe ich bisher noch nicht heraus bekommen, wie man ein
benutzerdefiniertes Ereignis generiert.

In GenealogyJ kann man das Ereignis-Kennzeichen wie folgt erzeugen:

Im Editor gibt es rechts oben eine Schaltfl�che 'Ereignis hinzuf�gen'. (Eventuell ist das erst in der ganz neuen Version so.)
Oder man schaltet in den GEDCOM Modus und w�hlt aus dem Kontextmen� auf das INDI-Kennzeichen 'Eigenschaft hinzuf�gen...' und dann 'Ereignis (EVEN)'. Dann kann man TYPE, DATE und PLAC eingeben.

Wenn Du Hilfe dazu brauchst, kannst Du mir auch mailen, denn wahrscheinlich sind diese Details zu uninteressant f�r die anderen Leser hier.

Moin,

Es liegt das Problem bei Ahnenblatt, da alles Unbekannte in die Notizen geschrieben wird.
Aber es wurde auch schon in Foren immer der Vorschlag gemacht die Gedcom-Datei in CSV umzuwandeln (durch Ahnenblatt/Home Edition) und dann mit M$Excel oder OpenOffice-Calc zu bearbeiten.
Es gibt viele Wege: http://wiki-de.genealogy.net/Kategorie:Genealogiesoftware oder auch Hilfsprogramme: Kategorie:Hilfsprogramm – GenWiki

Gru�
Olaf (Teige), www.teige.eu
wiki.familiengenealogie.de
TNG 8.1.1