GEDCOM-L, FHISO, GEDCOM X, Gramps XML - Export/Import und neue Speicherformate

    Ich möchte diesen Post eröffnen zu fragen, was die Neuigkeiten aus eurer Sicht zu den folgenden Themen sind, bzw. ob ihr diese verfolgt:

    • GEDCOM-L Plattform Deutschsprachiger Genealogie-Software-Autoren zur strikteren GEDCOM-Spezifikation (besserer Datenaustausch)
    • FHISO - Family History Information Standards Organisation, gegründet 2012 auf Basis von Bedürfnissen der Diskussionsgruppe BetterGEDCOM
    • GEDCOM X: Projekt zu Genealogiestandards gegründet Feb. 2012 von FamilySearch (data formats, Apache open source license, online data sharing, API)
    • GRAMPS Data Model (Gramps XML) offenes Datenformat der verbreiteten Open-Source Genealogie-Software

    Meine Sicht als Nutzer und Nicht-Enwickler ...


    GEDCOM-L ist kein Standard, da geht es afaik mehr um Kompatibilität vorhandener Software zu GEDCOM.


    GRAMPS XML ist nett, wird aber nur von Gramps, PGV und einer Handvoll Skripten unterstützt.


    FHISO/BetterGEDCOM scheinen irgendwas anderes zu tun als einen GEDCOM-Standard zu entwickeln/verbessern. Bei FHISO geht's nur um neue Mitglieder oder um das Mitgliederwerben. Bei BetterGEDCOM findet man fast alles zu GEDCOM, aber eigentlich nichts außer Ideen.


    GEDCOM X ist von FamilySearch, da wird dran gearbeitet, man kann auf einfache weise mithelfen, und es gibt einen funktionierenden Draft. Wo ich die Seite gerade lese, überlege ich sogar, ob ich das JSON-Format nicht schon für meine kleine Webseite nutzen könnte.
    Und da dort die LDS Kirche hintersteht, wandert das Format am Ende mit Sicherheit auch in die verbreiteten Genealogieprogramme.

    Warnung, frei laufenden Bären niemals auf die Schnauze hauen!

    Ich hoffe das Beste, aber befürchte, es wird viel heisse Luft um nichts geredet.


    Ich arbeite seit Jahren in der IT-Industrie, und die bemüht sich seit Jahren um Standards. Da gibt es dann tatsächlich Standards, aber viele größere Hersteller machen trotzdem mit ihren haus-eigenen Standards weiter. Damit binden sie die Kunden an ihren Produkte. Es geht nämlich um viel Geld.


    Bei den Genealogen läuft es ähnlich ab: Wir sehen schon, dass viele Ahnenforschungsprogramme "GEDCOM-fähig" sind, aber die meisten haben irgendwelche haus-eigene Kniffe eingebaut, denn auch hier geht es um Geld - man will sein Kundenstamm behalten. Letzendlich wird der kommerziell-trächtigste Standard "gewinnen".


    Bis dahin heisst es: versucht beim Standard "GEDCOM 5.5" zu bleiben, und hütet Euch vor 'Features', die auf haus-eigenen GEDCOM-Zusätze basieren. :D


    Gruß,
    Bob

    Danke für diese Einschätzungen!

    Zitat von Berlin-Bob

    Bis dahin heisst es: versucht beim Standard "GEDCOM 5.5" zu bleiben, und hütet Euch vor 'Features', die auf haus-eigenen GEDCOM-Zusätze basieren. :D

    Dem stimme ich voll zu und daran werde ich mich wohl auch noch einige Jahre halten. Ich wünsche mir aufgrund der unbefriedigenden Speichermöglichkeiten für eine umfassende moderne Genealogieforschung jedoch einen guten offenen Kandidaten als Nachfolger des Datenformats GEDCOM(-L), welcher sich hoffentlich in den nächsten Jahren entwickelt.


    Eines der wenigen Programme welches laut meiner Erfahrung sowohl strikt und direkt in GEDCOM speichert, als auch die Verwendung von zusätzlichen hauseigenen Datenfeldern vermeidet, ist Ages! das ich seit einigen Jahren verwende. Ich habe die gleiche Frage im Ages-Forum auch dem Autor Jörn Daub gestellt, welcher mit einer hochinteressanten Einschätzung der Lage geantwortet hat:
    www.daubnet.com/de/board/viewtopic.php?f=29&t=1261


    Ich kenne die FHISO zwar (noch) nicht wirklich, bzw. keinen der Aktiven dort, aber ich werde sie unterstützen, da deren Ziele auch meine sind und es die einzige internationale offene (Herstellerunabhängge) Initiave dieser Art ist, die ich kenne.

    Hallo Chris,
    ich weiß nicht, ob meine Meinung auch nur ansatzweise repräsentativ für die Anwenderseite ist, aber ich kann die Einschätzung von Jön Daub für mich nur bestätigen.
    Es ist mittlerweile bestimmt 10 Jahre her, dass ich mein erstes Genealogieprogramm installiert habe. Ich weiß noch gut, wie ich damals einige Programme miteinander verglichen habe und ich mich damals schon darüber geärgert habe, dass es jede Menge proprietäre Dateiformate gibt, und eben das Gedcom-Format, mit dem niemand wirklich glücklich war.
    Schon seit damals gibt es Diskussionen und Versuche, das Gedcom-Format zu ersetzen oder zu verbessern, sei es durch XML oder neue Gedcom-Standards. Dabei habe ich als Anwender den Eindruck, dass sich sämtliche Diskussionen darüber unablässig im Kreise drehen.
    Von daher würde es mich zwar freuen, wenn dieser gordische Knoten irgendwann einmal zerschlagen wird, allein, mir fehlt das Vertrauen, selbst aktiv zu werden und auf irgendein anderes Format als Gedcom zu setzen.


    Viele Grüße,
    Rossi

    Ich bin selber Mitglied in der Arbeitsgruppe, die über GEDCOM-L miteinander kommuniziert. Und kann sagen, das die Arbeit absolut produktiv ist. Wir bemühen uns, die in GEDCOM 5.5.1 niedergelegten Kennzeichen so umzusetzen, wie sie von den Autoren wohl angedacht waren, sie sinnvoll sind, und sie möglichst kompatibel sind. Nur in ganz wenigen Ausnahemfällen werden eigene Kennzeichen festgelegt (was ja in GEDCOM erlaubt ist). So z. B. für den nur in Deutschland bekannten und in GEDCOM nicht berücksichtigten Rufnamen.


    Alle aktiv teilnehmenden Mitglieder der Arbeitesgruppe haben seit Beginn der Arbeiten viele Updates ihre Software herausgebracht, in denen die jeweils besprochenen Kennzeichen entsprechend umgesetzt wirden. Da auch über den Tellerrand in andere Programme geschaut wird, ist die Kompatibilität enorm gesteigert worden. Wobei wir uns nichts vormachen müssen: Jeder Export/Import bedeutet immer einen gewissen Datenverlust. Egal wie ausgefeilt die GEDCOM-Schnittstelle beider involvierter Programme ist.

    Ich habe vergessen die sehr ausführliche und interessante Antwort von Herrn Daub, Autor von Ages!, hier zu erwähnen/verlinken - inkludiert Ideen zu langfristiger strategischer Ausrichtung.
    Hier die Essenz (Zwischenfazit) als Zitate:

    Zitat

    GEDCOM-L: Aktive Beteiligung und direkte Umsetzung in Ages!
    FHISO / BetterGEDCOM: Noch zu jung, um Ergebnisse zu erwarten - ist aber hochinteressant und wird weiterhin beobachtet.
    GEDCOM X ist noch unausgereift, und es sieht so aus, als ob niemand GEDCOM X will. Die New FamilySearch API ist da im Moment deutlich interessanter. Wir werden beides weiter beobachten.
    Gramps XML brächte für Ages!-Anwender verhältnismäßig wenig, selbst dann, wenn sie auch Gramps-Anwender sind. Daher ist eine Unterstützung dieses Formates nicht geplant.

    Hallo Chris,


    deine Fragestellung bzw. die Antwort von Herrn Daub sind mittlerweile über ein halbes Jahr alt. Hat sich seither etwas bei der Weiterentwicklung der von dir erwähnten Standards getan?


    FamilySearch setzt ja aktuell recht stark auf seinen online Family Tree. Das spricht wohl eher für eine Weiterentwicklung bzw. Pflege des New FamilySearch API. Die Frage ist nur: Hilft das den Entwicklern von Offline-Programmen? RootsMagic wirbt allerdings mit derSynchronisation zum FamilySearch Family Tree. Viele US-Programmanbieter haben aber eben eine deutlich größere Nähe (nicht nur geographisch) zu den Mormonen als deutsche Programmautoren.


    Gruß
    Reinhard

    Ich konnte keine entscheidenden Schritte beobachten, man müsste wohl Herrn Daub oder andere umtriebige Genealogie-Programmierer fragen. Ich denke aber nicht, dass es Entscheidendes geben wird. Nicht nur die Forschung in den Archiven, auch die Datenformat-Entwicklung geht langsam...

    Ob das wirklich noch ein weitreichendes Echo haben wird, wage ich zu bezweifeln.
    Ich glaube nicht, dass die LDS nach der nicht vorhandenen Pflege des GEDCOM 5.5 und GEDCOM 6 nochmal zugetraut wird, einen Standard zu setzen. Denke, die Chancen stehen gut, dass auch GEDCOM X sang und klanglos in der Versenkung verschwindet.


    Viele Grüße,
    Rossi

    Nun ja das Format ist eng verbunden mit der FamilySearch API. Dass heißt, auf deren Webseite wird es verwendet werden, jede Software und jede andere Webseite, die die API nutzt, wird es mit hoher Wahrscheinlichkeit unterstützen. Man kann ja von Versenkung sprechen, aber spätestens wenn die Kundschaft beim Entwickler anklopft, weil sie LDS-Datensätze importieren will, dann taucht das Problem auf.

    Warnung, frei laufenden Bären niemals auf die Schnauze hauen!

    Nachdem Ancestry beschlossen hat den international sehr bekannten Family Tree Maker (Desktop Software) nicht mehr weiterzuentwickeln (alle Ressourcen in die Online/Cloud-Dienste) und es einen riesigen Aufschrei von tausenden der Anwender gibt, habe ich mich an diesen Thread hier erinnert.
    Soweit ich es beobachten konnte, gibt es wohl keine fühlbaren Fortschritte bezüglich Datenformat/e :-/

    Zitat von Zwobot

    Nun ja das Format ist eng verbunden mit der FamilySearch API. Dass heißt, auf deren Webseite wird es verwendet werden, jede Software und jede andere Webseite, die die API nutzt, wird es mit hoher Wahrscheinlichkeit unterstützen. Man kann ja von Versenkung sprechen, aber spätestens wenn die Kundschaft beim Entwickler anklopft, weil sie LDS-Datensätze importieren will, dann taucht das Problem auf.


    Da muß ich widersprechen. GEDCOM und die FamilySearch-API sind zwei sehr unterschiedliche Sachen. Die API tauscht die Daten per XML oder JSON aus. Also ganz anders als GEDCOM. Die Kennzeichen sind ebenfalls komplett unterschiedlich, auch wenn manche Dinge sich wiederholen.


    Es gibt relativ wenig Programme, die die API verwenden. In den USA sind das relativ viele, wobei die allermeisten davon eher "Spielerei" sind. Aus Deutschland gibt es nur zwei Programme mit der API, eines für Mac und eines für Windows. Das mag daran liegen das die API wirklich aufwändig umzusetzen ist, und man die nicht einfach einbauen kann - es bedarf immer einer abschließenden Zertifizierung durch FamilySearch. Was natürlich eine gewisse Qualität garantiert, im Gegensatz zu GEDCOM, das jeder einfach so einsetzen kann und sagen kann, sein Programm beherrsche das - egal ob es das wirklich tut oder nicht. Ein anderer Grund mag sein das der Bedarf in Deutschland einfach (noch) nicht gweckt ist.


    JanX