GEDCOM ist ein seit Jahrzehnten etablierter Standard für den Austausch genealogischer Daten. Alberogen setzt auf GEDCOM als Format für den Import und Export von Daten. Das bedeutet, dass alle Daten, die Alberogen selbst verarbeiten und darstellen kann, vollständig und korrekt in GEDCOM exportiert und importiert werden. Dabei wird großer Wert darauf gelegt, dass der offizielle GEDCOM Standard eingehalten wird.
Insbesondere bedeutet dies, dass Sie Ihre in Alberogen erfassten Daten vollständig als GEDCOM exportieren können. Wird dieser Export erneut in Alberogen importiert, gehen keine Daten verloren. Sie können diesen Export aber auch in anderen GEDCOM konformen Diensten oder Programmen wie webtrees oder Ahnenblatt importieren und können dort mit dem vollständigen Datenbestand weiterarbeiten.
Felder und Daten aus GEDCOM Dateien anderer Genealogie Programme, die Alberogen selbst nicht verarbeitet, werden jedoch nicht importiert - und in Folge dessen auch nicht exportiert.
Warum ist das so?
Bei Alberogen haben wir großen Respekt vor der Arbeit von FamilySearch und der Kirche Jesu Christi der Heiligen der letzten Tage, die den GEDCOM Standard mit großer Umsicht pflegen.
Wir sind jedoch der Ansicht, dass dieser Standard nicht unerhebliche Schwächen hat:
Als Leitgedanke orientieren wir uns daran, dass Nutzer all die Informationen, die sie über ihre Vorfahren und erweiterte Verwandtschaft ermitteln, dokumentieren können: Die Personen und die für sie relevanten Ereignisse und Merkmale, die Beziehungen in Form von Eltern-Kind-Beziehungen, Partnerschaften und Heiraten, sowie Dokumente wie z.B. Fotos und Urkunden.
All dies lässt sich mit Alberogen hervorragend dokumentieren, und per GEDCOM auch importieren und exportieren.
Wir möchten hier auch kurz den Hintergrund zu o.g. Schwächen erläutern:
Unklare Positionierung: Der Schwerpunkt von GEDCOM liegt offenkundig darin, über Personen gesammelte genealogische Daten in Form eines Datenmodells abzubilden und serialisiert, also als Datenstrom speicherbar, darzustellen.
Daher sind zentrale Elemente das "INDI" Element, das Informationen zu einer Person aufnimmt und innerhalb dieses Elements z.B. das "BIRT" Element, das als Inhalt das Geburtsdatum "DATE" enthalten kann. Zusammen mit dem Heiratselement "MARR" als Teil des "FAM" Elemnts, das ebenfalls ein "DATE" als Zeitpunkt der Heirat enthalten kann, ist somit klar, wie alt die Person war, sofern beide Daten bekannt sind.
GEDCOM kann jedoch ebenso bei der Heirat das Alter der Person als "AGE" dokumentieren. Dies ist eine andere Weise, die selbe Information zu dokumentieren. GEDCOM legt nicht fest, welche Weise die richtige ist oder ob gar beide Weisen verwendet werden. Natürlich findet man in manchen Dokumenten nicht den Zeitpunkt der Heirat sondern nur das angegebene Alter. Möchte man dies dokumentieren, dann zielt man jedoch weniger auf die Dokumentation der Personen Eigenschaften ab, sondern vielmehr auf die Dokumentation von Quellen. GEDCOM legt sich hier nicht fest, mit der Folge, dass beim Import von GEDCOM Daten Interpretationsspielraum besteht: Soll das Alter zum Heiratszeitpunkt zum Geburtsdatum addiert werden und damit der Heiratszeitpunkt ermittelt werden? Was, wenn zusätzlich auch das Heiratsdatum in der GEDCOM Datei steht, davon jedoch abweicht? Wenn aber nur das Alter zum Zeitpunkt der Heirat bekannt ist, und weder das Datum der Heirat selbst noch das Geburtsdatum, was nutzt es wenn dieser Fakt als explizite Zahl modelliert ist, die Software mit dieser Information (genau wie der Nutzer selbst) jedoch nichts weiter anfangen kann? Dann könnte das Alter genauso gut im Notiztext stehen und wäre damit dem geneigten Leser zugänglich.
Ein weiteres Beispiel für redundante Information sind die Verweise auf Familienmitgliedschaften in beide Richtungen: Von der Familie zu den Kindern und Eltern, wie auch von den Eltern und Kinder-Elementen zu den Familienelementen. Wenn beide Verweise jeweils paarweise korrekt sind, ist einer davon überflüssig. Wenn sie sich aber widersprechen: Was soll ein Import dann tun?
Würden GEDCOM Dateien manuell erstellt und interpretiert, wären solche Hilfestellungen von Nutzen. Beim Lesen der Kommunikation rund um GEDCOM erhält man den Eindruck, dass manche GEDCOM Experten diese Dateien tatsächlich manuell pflegen. Dies erscheint uns in Anbetracht heutiger Software-Möglichkeiten nicht mehr zweckdienlich. Software jedoch benötigt diese Doppel-Verweise aus o.g. Gründen nicht. Auch hier positioniert sich GEDCOM nicht: Handelt es sich um ein reines Maschine-zu-Maschine Format oder um ein Format, das manuell erstellt und verarbeitet wird?
Auch das Argument, dass diese Doppelverweise und Redundanzen irrtümliche Veränderungen absichern, ist nicht stichhaltig: Moderne Formate verwenden zu diesem Zweck Prüfsummen. Spätestens mit dem Einführen von .gdz in GEDCOM 7 ist die Konsistenz durch die Validität des zip Containers abgesichert.
Historisch gewachsen, fehlende Modernität:
Das GEDCOM Format erinnert in zahlreichen Aspekten an Begrenzungen, die in Informationssystemen vor 40 Jahren gängig waren: Die Verschachtelung mithilfe von Ziffern an Stelle 1 jeder Zeile, (beinahe) fixe Breite von Feldbezeichnern auf 4 Zeichen ("BIRT" statt "BIRTH"), eine Begrenzung der Zeilenlänge auf 80 Zeichen, Verwendung unterschiedlicher Zeichencodierungen und BOM (Byte-Order-Marks). Glücklicherweise hatte FamilySearch den Mut, mit einigen dieser Relikte zu brechen (Festlegung auf UTF-8, keine Obergrenze für Zeilenlängen). Der konsequente Schritt, die Modellierung von Genealogiedaten und die Serialisierung zu trennen und für die Serialisierung moderne, etablierte Standards zu verwenden, den GEDCOM 6 / GEDCOM X mit XML und JSON verfolgte, konnte sich jedoch leider nicht durchsetzen. Er hätte vielen Entwicklern moderner Genealogie Software viel Arbeit erspart und unnötige Fehlerquellen vermieden!
Auch die Verwendung eigener Serialiserungsstandards für z.B. die Codierung von Datums-Daten ist zwar historisch erklärbar. Heute existieren jedoch sehr breit etablierte Standards für die Serialisierung solcher Daten. Auch wenn genealogische Anforderungen wie unscharfe Daten (z.B. nur Monat und Jahr, nicht aber der Tag bekannt) dort nicht abgebildet werden, so wäre doch eine Anlehnung oder Erweiterung dieser Standards möglich, wiederum mit enormer Vereinfachung und Reduktion von Fehlerquellen für die Entwicklung von Genealogie Software.
strukturierte Modellierung ohne Mehrwert:
Unter strukturierter Modellierung versteht man, einen logischen Sachverhalt in einer standardisierten Form, die die Bedeutung des Sachverhalts wiederpsiegelt, abzubilden.
Ein Beispiel ist das "PLAC" Element, das den Ort eines Ereignisses beschreibt. Jede Software "weiß" somit, dass der Text hinter "PLAC" die Beschreibung eines Ortes ist und kann entsprechend damit umgehen, ihn z.B. in einer Datenbank suchen und die Geo-Koordinaten daraus ableiten. Dies ist sinnvoll, da Software damit aus den Daten Informtationen ableiten kann, und mit "PLAC" Daten im Sinne von Orts-Daten umgehen kann, im Unterschied zu "DATE" Daten, die ein Datum wiedergeben, also einen Zeitunkt, auf einen Tag genau (oder entsprechend unschärfer, je nachdem).
Schwer nachzuvollziehen ist jedoch, warum zusätzlich zu "PLAC" noch ein "ADDR" Datensatz angegeben werden kann, sowie Kontaktdaten mit Extra Elementen wie "PHON", "EMAIL", "FAX", "WWW" - im ersten Fall ist die Abgrenzung von PLAC unklar, im zweiten Fall wäre eine besser Modellierung "CONTACT" und dann die Angabe eines URL in Form von z.B. "tel:+1 555 555-1212" besser.
Auch die Modellierung des Alters bei einem Ereignis oder unterschiedliche Ehemänner und -Frauen in einer Familie werfen die Frage auf, welchen Mehrwert eine Software aus diesen strukturierten Informationen ziehen kann: Solche Informationen anders darzustellen als in einem schlichten Text, ist im allgemeinen kaum möglich. Alberogen sieht solche Informationen daher besser in einer Notiz aufgehoben.
Generell wirft auch die Modellierung von Familien als "FAM" mehr Fragen auf, als sie zu einer strukturierten Darstellung von Informationen beiträgt. Gerade im Zeitalter von Patchworkfamilien ist unklar, wie eine Familie korrekt und sinnvoll modellierbar ist. Was hingegen sehr klar ist: Jeder Mensch hat einen Vater und eine Mutter, egal ob bekannt oder nicht. Alberogen setzt daher zentral auf die Eltern-Kind-Beziehung und verwendet das FAM Element in GEDCOM lediglich zur Dokumentation dieser Beziehung sowie von Heiraten.
Und wenn Sie GEDCOM Dateien vollumfänglich bearbeiten möchte?
Sollten Sie GEDCOM Dateien vollumfänglich bearbeiten wollen, empfehlen wir Ihnen eine der o.g. Software.
Dennoch sind wir der Ansicht, dass die Dokumentation von Genealogiedaten mit Alberogen umfassend und ohne Abstriche und aus den genannten Gründen ohne den vollen GEDCOM Umfang sehr gut möglich ist. Es gibt lediglich eine Lücke in Alberogen: Die Dokumenation von Quellen Angaben (SOUR Element in GEDCOM). Das ist aber bereits auf der Wunschliste und wird in 2024 umgesetzt.