Hallo zusammen,
aus Anlass der Veröffentlichungsfrage von Andreas Sichelstiel möcht ich fragen ob es irgendein etabliertes .XML oder .json Format für Genealogie-Daten gibt.
Und Programme zur Umwandlung von Gedcom 5…
Danke
Gruß
Mattias (Laage)
Grüße Sie Herr Laage,
Hab die Frage in die Computer Kategorie verschoben…
Herzlich,
AS
Eigentlich sollte ich die Frage zurückziehen, es gibt GEDCOM X von Familysearch.
Gruß
ML
Gramps verwendet ein sehr sauberes XML, in das man exportieren kann und das eine beliebige Weiterverarbeitung erlaubt, wenn man selbst Hand anlegt. Nur kann das natürlich außer Gramps niemand lesen (zumindest ist mir keine Genealogie-Software bekannt, die das kann). Gramps kann auch GEDCOM exportieren, nur unterstützt Gramps wesentlich mehr, als in GEDCOM abgebildet ist, also läuft man sofort in Probleme, wenn man nicht freiwillig Gramps zurechtstutzt auf das, was GEDCOM kann. Das ist wie ein Smart als Transporter: geht natürlich, macht aber herzlich wenig Sinn.
Die ganze Branche hängt leider nach wie vor an der Sofware-Katastrophe namens GEDCOM …
Ulrich
1 „Gefällt mir“
Kann das außer Familysearch auch jemand lesen?
Ulrich
Nachtrag: ich sehe gerade, dass GEDCOM X derzeit nichts weiter ist als eine Website mit jeder Menge Definitionen. Lesen kann das offensichtlich noch niemand und ob das jemals ins Fliegen kommt, wäre noch zu sehen.
Hallo Ulrich,
danke für die Erläuterungen. Sind Gedcom X und das Gramps XML compatibel?
Hintergrund ist, dass ich gerade daran arbeite für meine Datenbank (Eigenbau) eine Ausgabe Richtung LaTeX zu implementieren.
Und nebenbei kam mit dann die Idee das auch aus einer XML oder lieber noch json Datei zu generieren…
Gruß
Mattias
Ich denke nicht. Ich habe mir gerade die GEDCOM X Seite angesehen und bin gestolpert über:
Wenn ich mir das ansehe, dann ist klar, dass man hier die Vorteile von XML alle verschenkt, warum auch immer. Bei Gramps heißt das bespielsweise so:
<dateval val="1860" type="about" quality="estimated"/>
Im Klartext: geschätzt etwa 1860
Das ist präzise, flexibel und auch sehr robust. Dieses führende A in GEDCOM X lädt dazu ein, dass jemand in eine Importroutine einen Bug rein schreibt oder das A komplett ignoriert, so wie es ja mit dem klassischen GEDCOM oft genug passiert.
Ich würde in dieser Situation eher prüfen, ob es nicht möglich ist, die Eigenbau-DB durch Gramps abzulösen und dann von der Gramps-XML-Darstellung aus in Richtung LaTeX zu gehen. Wobei ich ehrlich gesagt noch nie erlebt habe, dass sich der Aufwand für LaTeX (insbesondere auf Windows) wirklich rentiert, wenn man auch Word zur Verfügung hat …
Hallo, als ich vor ein paar Jahren die XML Formate für GEDCOM für mich unpassend und auch nicht mehr zeitgemäss fand, war ich auf der Suche nach einem JSON-Format. Weil es das damals (ca. 2021) nicht gab, habe ich mir ein an den GEDCOM Tags angelehntes JSON Format vorgegeben (ohne die unhandlich Continuation Tags) und mir einen Filter gebaut, der meinen GEDCOM Export nach JSON wandeln konnte (auch einen Filter für die Rückrichtung).
Ich habe es nie veröffentlicht, und es bräuchte sicher Ergänzungen, sobald GED Exports von anderen Programmen verarbeitet werden sollen (bei mir war es PAF).
Das JSON-Ergebnis liess sich super im Browser anzeigen (mit etwas JavaScript drumrum konnte ich Suchfunktionen implementieren, die ich mir immer gewünscht habe).
Die Filter (GED to JSON, JSON to GED) habe ich in Node.js (also JavaScript) implementiert.
Evtl. sind die vorhandenen Filter von Interesse und ich müsste sie unter einer freien Lizenz bereitstellen. Zur Zeit schreckt mich der Aufwand dafür ab. Aber vielleicht liest hier jemand mit, der Node.js und JSON affin ist.
VG
Hartwig (von Essen), Buxtehude
1 „Gefällt mir“
Danke für den Gramps Hinweis - die scheinen inzwischen auch einige Tools um ihr XML-Format herum anzubieten - muss ich mir mal genauer anschauen. Ich bin in beiden Welten - Linux und Windows - unterwegs. in der Reihenfolge 
hmm, ja, mit Word hatte ich vor Jahren auch mal experimentiert. Hat ganz gut geklappt, als die Datenmenge dann auf über 200 Seiten stieg, ist mir Word regelmäßig abgeschmiert - ist keine Option mehr.
Ich vergass den Link - das ist so die Ausgabe die ich mir Vorstelle. Quellen als Fußnoten, Index der Namen und Orte.
desc_56111.pdf (320,0 KB)
Oh, das muss mir dann entgangen sein. Welche wären das? Haben Sie Links dazu?
Vieles davon kann Gramps aus dem Stand. Nur mal meine persönliche Meinung, die Sie natürlich auch jederzeit ignorieren können: das wären Daten, die ich nie in gedruckter Form (egal ob physischer Print oder Pseudo-Print als PDF) von mir geben würde. Die würde ich immer als Datensatz publizieren. Diesbezüglich bietet Gramps einige Reports an, die fertige Websites aus den Daten machen.
Der Report „Dynamischer Webbericht“ in Gramps erzeugt aus den Daten genau eine solche Website, welche JavaScript nutzt, um die Daten im Browser anzeigt. Diese Website hat auch eine Suchfunktion, die aber zumindest bei großen Datenbeständen (in meinem Fall nahezu 100.000 Personen) nicht mehr sauber funktioniert. Diese Website kann man auch in ein ZIP-Archiv packen und so weitergeben, oder natürlich einem Hoster anvertrauen, der sie dann ins Internet stellt. Daneben gibt es noch eine Reihe weiterer Reports, die ebenfalls Websites generieren.
UDl
bei den Tools hat mich der erste Eindruck getäuscht 
Ich dachte da wär mehr dahinter…
Wie sähe das aus? Verstehe ich gerade nicht.
Beispielsweise wie oben beschrieben als JavaScript basierte Website. Entweder als ZIP-Archiv dann packen und verteilen (oder zum Download zur Verfügung stellen) oder bei einem Hoster als echte Website hosten lassen. Als Beispiel meine Daten auf Zenodo. Die Datei DWR.zip ist die Website als ZIP-Archiv. Wenn man lokal einen Webserver laufen hat (wozu es ja genügend freie Tools gibt) und das Archiv in ein Verzeichnis so entpackt, dass es vom Webserver unter einer URL http://localhost/… angezeigt wird, dann hat man den kompletten Datensatz als Website lokal auf seinem PC zur Verfügung.
Es gibt natürlich noch unendlich viele andere Möglichkeiten die ich teilweise auch auf Zenodo nutze, aber die beschriebene ist die einfachste und angenehmste, wenn es nur um das Ansehen der Daten geht.
1 „Gefällt mir“
Die Schemas von schema.org. Die werden bereits weltweit in (modernen 
) Online- und Offlinetools verwendet. Von NextCloud über Google bis zu Microsoft. Vor allem sind die sowohl in XML, als auch in JSON umsetzbar.
Ob es aber genealogische Software, die leider oft sehr konservativ ist, gibt, die diese Schemas unterstützt, kann ich nicht sagen.
Auch natürlich bezüglich der Datensicherheit haben mich seit Beginn meiner Nutzung von Genealogiesoftware die Speicherformate interessiert. Da ich diesbezüglich nun aber schon länger nicht mehr recherchiert habe, habe ich mir ergänzend zur Diskussion hier eine LLM-Zusammenfassung bezüglich Stand der Speicherung genealogischer Daten erstellen lassen in der Hoffnung dies ist auch für andere nützlich:
Die Speicherung genealogischer Daten basiert weiterhin primär auf dem etablierten GEDCOM-Standard, der trotz Kritik an seiner Begrenztheit (z. B. proprietäre Erweiterungen) der De-facto-Standard bleibt. Neuere Entwicklungen wie GEDCOM 7.0 (2021) zielen auf Modernisierungen ab, während XML-basierte Formate wie Gramps XML oder GEDCOM X flexiblere Alternativen bieten. Hier ein Überblick zu den genannten Formaten.
FamilySearch GEDCOM 5.5.1 und ältere Formate
GEDCOM 5.5.1 (finale Version vom 15. November 2019) ist nach wie vor der am weitesten genutzte Standard für den Datenaustausch in der Genealogie-Software. Er unterstützt UTF-8, neue Tags für Attribute und ist in Tools wie Family Historian oder Ancestry integriert. Ältere Versionen (z. B. 5.5 aus 1996) werden seltener, aber noch in Legacy-Systemen verwendet. Der Übergang zu GEDCOM 7.0 (2021) ist langsam; es adressiert Lücken wie bessere Unterstützung für nicht-binäre Beziehungen und ist IANA-registriert, wird aber nicht flächendeckend adoptiert.GEDCOM 5.5.1 GEDCOM-L Addendum R2 (2020-12-01) Status
Das Addendum R2 der GEDCOM-L Working Group (Dezember 2020) erweitert GEDCOM 5.5.1 um benutzerdefinierte Tags (z. B. _STAT für Familienstatus wie „nicht verheiratet“). Es bleibt ein inoffizielles, community-getriebenes Ergänzung und wird in europäischen Tools (z. B. CompGen-Projekten) genutzt, hat aber keinen offiziellen Status bei FamilySearch. Bis 2024/2025 keine Updates; es dient als Brücke zu GEDCOM 7.0.GEDCOM 7.0 vom 15. Mai 2021 von FamilySearch (LDS Church),
ist die aktuelle Major-Version mit UTF-8-Pflicht, erweiterten Tags für nicht-binäre Beziehungen, Medien-ZIP-Paketen und Klarstellungen zu 5.5.1-Ambiguities; die neueste Revision 7.0.16 hat Changelog-Updates bis August 2024. Adoption bleibt begrenzt: Voll unterstützt in Ancestris (seit v12, 7.0-Export/Import), webtrees (Display als Extensions, aber Erstellung in 5.5.1); RootsMagic, Family Tree Maker und Ancestry planen Kompatibilität (seit 2021-Statements), doch Implementierung verzögert – Gramps experimentell (seit 2024, via Addons, aber nicht empfohlen für Transfers aufgrund dünner Branchenadoption). Kein breiter Shift von 5.5.1.GEDCOM 7.1: Entwicklung und Ausblick
seit 2024 in Entwicklung (semantic versioning, Fokus auf weitere Erweiterungen wie bessere XML-Integration und FHISO-Kompatibilität); kein Release-Datum fixiert, aber FamilySearch treibt via GitHub-Repo voran. Wichtige Player: FamilySearch als Lead, mit Input von RootsMagic und Ancestry; Gramps plant Integration post-7.0-Stabilisierung (2025-Wiki-Updates). Erwartet: 2026-Launch für robustere Austausche, doch 5.5.1 dominiert weiter.Gramps XML: Zusatzfelder und Logiken im Vergleich zu GEDCOM
Gramps XML (.gramps oder .gpkg-Archive) ist ein offenes, XML-basiertes Format des Open-Source-Tools Gramps, das GEDCOM übertrifft, indem es komplexe Strukturen wie gruppierte Namen, Koordinaten (via MAP-Tags) und Multimedia nahtlos handhabt. Im Gegensatz zu GEDCOM (das bei Export „lossy“ ist und Zusatzfelder oft verliert) speichert Gramps Logiken für Quellen, Orte und Beziehungen idempotent – ideal für Erweiterungen. Es wird in Gramps und PhpGedView unterstützt, bleibt aber nischig, da GEDCOM die Import/Export-Norm dominiert.Andere Formate: GEDCOM X und weitere XML-Formate
GEDCOM X (seit 2012, gesponsert von FamilySearch) ist ein XML/JSON-basiertes Modell für den Austausch, inklusive Medien und Metadaten; es dient als Backend für FamilySearch APIs, wurde aber nie zum Branchenstandard (2012 umpositioniert). Aktuell (2025) stabil, aber nicht weit verbreitet. Andere XML-Formate umfassen FHISO-Standards (JSON/XML-Zip für Konsortien) und Gramps XML; sie priorisieren Flexibilität, fehlen aber an breiter Adoption. Zukünftig: GEDCOM 7.1 in Entwicklung für bessere XML-Integration.Schlussfolgerung
Während GEDCOM 5.5.1 robust, aber veraltet ist, gewinnen XML-Formate an Relevanz für detaillierte, erweiterbare Speicherung. Für Interoperabilität bleibt GEDCOM essenziell; Tools wie Gramps empfehlen XML für langfristige Archivierung. Empfehlung: Hybrid-Ansatz mit GEDCOM-Export und XML-Backup.
Da jede “Migration” zu einem neueren Format über eine möglichst gute Unterstützung des bzw. der vorhandenen Formate Fahrt aufnehmen kann, interessiert mich besonders diesbezügliche Anstrengungen wie jene der GEDCOM-L group (innerhalb der CompGen). Zuletzt Ende 2020 haben Dr. Albert Emmerich und Diedrich Hesmer im Dez. 2020 das R2.pdf editiert, siehe GEDCOM-L-Addendum.
Ich habe die LLM um Versuch weiterer Klärung gefragt:
Es gibt indirekte und community-basierte Verbindungen zwischen dem Gramps-Projekt und der GEDCOM-L Working Group. Diese dienen der Verbesserung der GEDCOM-Kompatibilität, einschließlich Erweiterungen für benutzerdefinierte Tags und Ortsstrukturen (_LOC), die den Import/Export erleichtern. Direkte offizielle Kooperationen (z. B. gemeinsame Projekte) sind nicht dokumentiert.
Die Entwickler von Gramps diskutieren GEDCOM-Erweiterungen in ihrer gramps-devel-Mailingliste und im Discourse-Forum. Hier werden Features wie das GEDCOM Extensions Addon entwickelt, welches inoffizielle Erweiterungen (ähnlich dem Addendum) für bessere Kompatibilität implementiert, z. B. für Zeugen (Witnesses) oder Patronymika.
Da ich seit 2006 Ages! für die Pflege nutze (zuletzt mit heuer veröffentlichter Version 2.2) interessiert mich besonders ob die GEDCOM-L Gruppe Fortschritte macht, bzw. wie der Austausch zwischen Programmen von zumindest in der Vergangenheit aktiv teilnehmenden Autoren und deren Software (Ages!, Ahnenblatt, webtrees,…) funktioniert. Gibt es dazu und auch zur möglichst verlustfreien Übernahme nach Gramps Erfahrungsaustausch?
Zumindest für die nahe Zukunft scheint die breite Adoption von GEDCOM 7.1 oder eines XML-Formates noch nicht konkret zu werden. Schade dass auch im dritten Jahrzehnt das gemeinsame internationale Interesse an einem modernen und umfangreich unmissverständlich definierten Format immer noch unzureichend scheint.
Die Zusammenstellung und die Aussagen der KI (LLM) sind interessant, aber in etlichen Punkten falsch bewertet. Es fehlt auch ein Hinweis auf das GeneWeb Format .gw (siehe etwa GitHub - Relais4x100a2/geneweb-py: Librairie Python complète pour parser, manipuler et convertir les fichiers généalogiques au format GeneWeb (.gw). Inclut API REST FastAPI, conversion GEDCOM/JSON/XML, et validation de cohérence. ). Wie wäre es die Informationen zu genealogischen Austauschformaten in einem GenWiki-Artikel zu konsolidieren?
2 „Gefällt mir“
Erstellung “Genealogische Austauschformate” (oder ein noch passender benannter GenWiki-Artikel): da wäre ich sehr dafür. Das GenWiki erachte ich als eine der wichtigen Informationsquellen im deutschsprachigen Raum mit vielen auch sehr detaillierten Inhalten.
Und Speicher- und Austauschformate sind langfristig die Basis jeder Computergenealogie. Selbst bei den nun breit verwendeten Onlineportalen ist dies zur Migration entscheidend, habe das schon bei Mitforschern erlebt.
Ich möchte mich zumindest alle 4-5 Jahre mit dem Thema beschäftigen um mittel- und langfristig meine eigene Systematik (z.B. zumindest Backups oder Ablage in alternativen Formaten) anpassen zu können.
”Aussagen der KI (LLM) sind interessant, aber in etlichen Punkten falsch bewertet”:
ist damit vor allem der Bereich Schlussfolgerung gemeint? Würde mich interessieren wo es Berichtigung oder Korrektur braucht.
1 „Gefällt mir“
Im GenWiki habe ich einen Artikel angelegt:
1 „Gefällt mir“
Die müssen sehr indirekt sein. Ich kann mich an nichts erinnern. Gramps hat sein XML-Format und legt auf GEDCOM keinen sonderlichen Wert. Etliche Standardelemente von 5.5.1 werden nicht unterstützt. Die Ortsdatensätze als wesentliches Element des GEDCOM-L-Addendums werden nicht unterstützt.
1 „Gefällt mir“