Für alle, denen mein Name nicht sofort bekannt vorkommt (ich schreibe hier nicht oft): Ich bin Autor des Programms Ages!.
Nachdem ich einen Teil der Debatte (ich lese ab und an Gen-Programme mit) verfolgt habe, möchte ich einmal etwas eigenen "Senf" dazu loswerden.
Beispiel aus der Zeit der "guten alten Währung", der DM:
-------------------------------------------------------
Wenn man damals 100 DM der Reihe nach in englische Pfund,
dänische Kronen, östereichische Schilling u.s.w. umgetauscht
hätte und nach diesem Durchlauf über die 16 verschiedenen
Länder und Währungen Europas dann wieder in "gute" DM
eingetauscht hätte, dann wären vermutlich bei jedem Tausch
Einbußen zu verzeichnen gewesen - ob wohl noch 50 DM übrig wären?Unser Ziel um die Kompatibilität der Programme bezüglich GEDCOM:
----------------------------------------------------------------
Wenn wir ein- und denselben Datenbestand der Reihe nach über
alle Genealogie-Programme exportieren, importiern, exportieren,
importieren, exportieren, usw.....,dann MUSS gewährleistet sein, dass *nach* diesem Duchlauf
im *ersten* Programm alles wieder so dargestellt/abgebildet wird,
wie es urspünglich im ERST-Export dieses verlassen hat.
Der Vergleich mit dem Geldwechsel ist nicht so weit hergeholt wie er zunächst scheint. Problem dabei: Wenn in der Geldwechsel in fünfzehn der sechzehn Umtauschstellen kostenlos wäre, und nur ein einziges Mal Geld für den Umtausch verlangt wird, bleiben nur noch 95 DM nach. Wenn die Programmkompatibilität an einem solchen "Umlauf" getestet werden sollte, könnten nur entweder *alle* Programme diesen bestehen, oder per Definitionem keines. Als Testkriterium ist das nicht praktikabel.
Zudem ist die Komplexität des GEDCOM-Transfers nicht zu unterschätzen. Es gibt gleich eine ganze Reihe von Problembereichen, die dabei eine Rolle spielen. In vielen Bereichen liegt es an den Programmierern, die Barrieren auszuräumen, aber längst nicht in allen. Zumindest ein Bereich bleibt quasi unlösbar übrig, weshalb ich darauf hier näher eingehen möchte:
** Unterschiede der Datenmodelle in verschiedenen Programmen. **
Als relativ einfaches Beispiel hierfür können die Taufpaten dienen. Einige Programme verwalten diese gar nicht, andere haben ein Textfeld, wiederum andere verknüpfen die Taufpaten mit Personendatensätzen. Selbst mit optimalen Im- und Exportroutinen auf beiden Seiten entsteht foglendes Dilemma:
Programm A hat einen Datenbestand mit zwei Personen. Klaus Meier *1960 (Datensatz 1) und dessen Taufpaten Kurt Schmitt *1935 (Datensatz 2). Diese Informationen werden als GEDCOM exportiert.
Programm B liest diese Daten ein, hat aber ein Textfeld für den Taufpaten, statt eines Verweises. Idealerweise erkennt dies Programm den Paten in der Datei, und hat nun: Klaus Meier *1960 (Datensatz 1), und die Information "Kurt Schmitt" im Textfeld für Taufpaten. Wenn zu Kurt Schmitt sonst nichts bekannt ist, könnte das Programm dessen Datensatz verwerfen, in unserem Beispiel ist jedoch das Geburtsdatum vorhanden, weshalb der Datensatz erhalten bleiben muss: Kurt Schmitt *1935 (Datensatz 2)Import erfolgreich. Für den Anwender sieht alles Optimal aus - tatsächlich ist aber eine Information verloren gegangen. Wirklich bemerken wird der Anwender dies jedoch erst später. Jetzt werden diese Daten wiederum als GEDCOM exportiert.
Programm A liest die Daten wieder ein. Es wird zwei Personen vorfinden: Klaus Meier *1960 und Kurt Schmitt *1935. Zudem erkennt es den Taufpateneintrag "Kurt Schmitt", und benötigt jetzt (da es Taufpaten als Verweise verwaltet) diesen wiederum als Datensatz. Damit wären es jetzt 3 Personen - denn woher soll Programm A jetzt wissen, dass dieser Kurt Schmitt identisch ist mit dem aus Datensatz 2? Alternativ kann die Information "Klaus Meier hat einen Taufpaten namens Kurt Schmitt" als "Notiz" weitergeführt werden.
Egal was Programm A hier tut, es kann den Verlust von Information beim Import in Programm B nicht wettmachen. Das gleiche kommt im Übrigen auch dabei heraus, wenn man bei diesem Szenario bei Programm B beginnt.
Ich bitte zu bemerken, dass dies als Beispiel dienen soll. Es ist keine Beteuerung, dass die Verwaltung von Paten als Personenverweis "richtiger" wäre, als die per Textfeld. Entscheidend ist, dass Programm A eine Information hat, die Programm B nicht verwalten kann: Dass "Kurt Schmitt", der Taufpate von Klaus Meier, und die Person "Kurt Schmitt" (Datensatz 2) ein und die selbe Person sind.
** Fazit **
Es ist richtig, dass viele Programme GEDCOM-Dateien produzieren, die nicht so dicht am Standard sind, wie sie sein könnten - Ages! ist hiervon nicht ausgennommen. Es wäre sinnvoll, deren Hersteller auf die Mängel hinzuweisen. Programmhersteller, die etwas auf sich halten werden ihr Produkt verbessern wollen.
Es ist ebenfalls richtig, dass viele Programme beim Import von GEDCOM-Dateien nicht so flexibel sind, wie sie sein könnten - auch hiervon ist Ages! nicht ausgennommen. Auch da ist es sinnvoll, die Programmhersteller auf Mängel hinzuweisen.
Hingegen ist es falsch, davon auszugehen, dass man Forschungsdaten nach dem "Stille-Post-Prinzip" zwischen den Anwendungen hin- und hertauschen könnte, ohne dabei Daten zu verlieren. Selbst bei idealen Bedingungen und optimaler Kooperation der Programmhersteller ist dies zum Scheitern verurteilt. Dies trotzdem zu von den Programmherstellern zu fordern führt zu: nichts.
Für viele Ahnenforscher hat sich folgende Lösung als gangbar erwiesen: Man wählt *ein* Programm, in dem man die Daten pflegt. Beliebig viele weitere Programme importieren dann den aktuellen Datenbestand, um diesen weiterzuverarbeiten - sei es in Form von Listen, Diagrammen, Webseiten, oder Statistik. Bei diesem Szenario gibt es natürlich nach wie vor Importverluste. Da der Import aber immer in der gleichen Richtung erfolgt (Export aus Hauptprogramm, Import im Zweitprogramm, aber *nicht* Re-export und Re-import) schreitet der Verlust nicht fort.
Mit freundlichem Gruß
Jörn Daub
P.S. Für die Mathematiker under den Lesern: Im- und Exportfunktionen von Programmen können als Abbildungen verstanden werden. Die dazugehörige Abbildungsmatrix ist nicht in jedem Falle invertierbar. q.e.d.
P.P.S. Für die Grafiker unter den Lesern: Wer eine JPG Datei öffnet, speichert, und wieder öffnet, und wieder speichert, und sich dann wundert, dass das Bild fürchterlich aussieht, hat nicht verstanden, was eine JPG Datei ist. Okay, der Vergleich hinkt.
