Danke für diese Spezifizierung. Dass auch 5.5.1 nicht “so optimal wie möglich” unterstützt wird, enttäuscht mich ein wenig, bzw. möchte ich das mit Weile mal genauer überprüfen.
Gramps und Ancestris sind die einzigen ernstzunehmenden freien lokalen Programme laut meiner derzeitigen Einschätzung. Ob ich aber langfristig meine umfangreiche Ages! GEDCOM mit Quellen- und Ortsverwaltung usw. je gut migrieren kann, daran hab ich so meine Zweifel.
Aus Webtrees Handbuch/Allgemeine Erläuterung des Programms – GenWiki
ein Zitat:
Da Gramps sich nicht so strikt am GEDCOM-Standard orientiert wie webtrees, werden einige Kennzeichen nicht korrekt erkannt (Medienobjekte etwa können nur Verweise auf eine Mediendatei enthalten, das Kennzeichen RESN ist nicht implementiert, Verweise auf Trauzeugen und Taufpaten werden nicht korrekt übernommen, …). Die Erweiterungen aus dem GEDCOM-L Addendum werden nicht unterstützt, es gibt jedoch eine Ortsverwaltung auf Basis der hierarchischen Ortsangaben (PLAC-Kennzeichen). In Gramps Web werden keine Kalendersysteme unterstützt.
Ich glaube ASSO bzw. _ASSO wird nicht richtig unterstützt.
1 „Gefällt mir“
Ich habe Datenaustauschformat – GenWiki etwas ergänzt und auch GEDCOM-L – GenWiki
Ist der Webtrees Wiki Hinweis zu Gramps (“Die Erweiterungen aus dem GEDCOM-L Addendum werden nicht unterstützt”) immer noch (oder wieder) aktuell?
Habe gesehen im GEDCOM-L Addendum R2 Dez. 2020 wird Paul Culley als teilnehmender Author / Contact für das Gramps Projekt gelistet? Also informell scheint es einen Austausch zu geben (bzw. gegeben zu haben). Inwieweit in Gramps umgesetzt bleibt die Frage.
Ja. Aber ich bin schon lange in der GEDCOM-L-Gruppe und kann mich an keine Beteiligung von ihm erinnern. Im Gramps Discourse Forum war er vor zwei Jahren zuletzt aktiv.
Meine Hinweise auf Mängel im GEDCOM-Import und -Export sind bei den Gramps-Entwicklern kaum auf fruchtbaren Boden gefallen. Vielleicht habe ich schlecht argumentiert. Zu GEDCOM 7 gibt es nur eine etwas einsame Initiative von David Straub zum Import. Ansonsten eher schlechte Nachrichten: Gramps 6.0 and gedcom 7 - #25 von Nick-Hall - Beta Testing - The Gramps Project (Discourse Forum & Mailing List)
1 „Gefällt mir“
Ok danke. Sehr nützliche Hinweise. Hoffen wir GEDCOM-L und viele der involvierten Autoren bzw. Software schaffen in Zukunft “5.5.1+” auf eine 7.0/7.1(+) Version zu hieven. Denn die Limits des alten Standards sind nunmehr in zu vielen Bereichen zu spüren und ein moderner Austausch sollte doch langsam breiter möglich werden.
Statt Gramps scheinen wohl eher webtrees und Ancestris interessant zu sein; ich hoffe aber nach v2.2 heuer geht auch bei Ages! noch etwas weiter (im Speicherformat). Größtmögliche Interoperabilität ist in jedem Fall auch nur für Nutzung von Ausgabefunktionen verschiedener sonst zur Pflege nicht genutzter Software interessant. Gramps interessiert mich diesbezüglich bezüglich der Plugins (Python).
Gramps und Gramps Web sind ohne Frage tolle Programme mit einer äußerst lebendigen Entwickler-Community Nur hat man sich dort anscheinend daran gewöhnt, dass keiner, der Gramps nutzt, wieder dort weg will. Damit verliert ein Austauschformat wie GEDCOM etwas an Bedeutung. Innerhalb der Gramps-Welt ist das Gramps XML perfekt.
Bitte dort möglichst immer dazu schreiben, ob CompGen dieses Format verarbeitet.
[Sachensucher] Sachensucher <genealogy.net
- Dezember
Bitte dort möglichst immer dazu schreiben, ob CompGen dieses Format
verarbeitet.
Hm, CompGen ist der Verein. Meintest du vielleicht Gedbas, OFB etc?
Und warum nur bezogen auf CompGen? Warum nicht generell welche Software
unterstützt welche Formate?
1 „Gefällt mir“
Ja, das sollten wir aufnehmen: Welches Format wird von welchen Anwendungen unterstützt?
Zum GenWiki-Artikel “Datenaustauschformat” …
Ok, das war wahrscheinlich ein Schnellschuss, aber GEDCOM-L muss aus meiner Sicht nicht explizit erwähnt werden (hier wirkt es fast wie ein eigenes Dateiformat). Es ist letztlich GEDCOM 5.5.1 und es wurde unter deutschen Entwicklern von Genealogieprogrammen das Bewusstsein zur korrekten Einhaltung des Standards geschärft und eine überschaubare Anzahl an Erweiterung beschlossen (wahrscheinlich weniger als so mancher Entwickler für seine eigene Software ergänzt).
GEDCOM 7.1 ist meiner Meinung nach keiner Erwähnung wert, da es diese Standardversion noch nicht gibt. In wie weit es eine markante Erweiterung zu GEDCOM 7 ist, ist aktuell Kaffeesatzleserei.
Gramps XML soll angeblich auch von phpGedView unterstützt werden. Ich kann keinen Beleg dafür finden - weder beim Im- noch Export. Ansonsten wäre es kein “Austauschformat”.
GeneWeb wird am Ende als Software genannt, was aber keinen Bezug zum eigentlichen Titel des Artikels hat.
Mir scheint die Auflistung ziemlich wahllos, wenig zielorientiert und sehr technisch zu sein.
Aus rein technischer Sicht ließen sich z.B. noch .paf (PAF) und .leg (Legacy) ergänzen, die von Family Tree Maker gelesen werden können. Aber was für einen Mehrwert bringt das?
Wobei man schnell beim Thema “Zielgruppe des Artikels” ist. Wenn es darum geht unbedarften Anwendern GEDCOM-Alternativen aufzuzeigen, so wird man letztlich zu dem Fazit kommen, dass es dazu aktuell keine bessere Alternative gibt.
Wenn die Zielgruppe eher technisch-affine Anwender sind, die sich generell über genealogische Dateiformate informieren wollen, dann würde ich nur Dateiformate erwähnen, die auch irgendwo detailliert beschrieben sind (mit Link zur Standard-Doku) - selbst wenn diese nur exportiert und nicht importiert werden können. Dann sollte der Artikel umbenannt werden in z.B. “Genealogische Dateiformate”.
Gruß, Dirk
Als Autor einer Genealogiesoftware kann ich diese Meinung nicht teilen. Die größten Probleme seitens GEDCOM sind unterschiedliche Eingabefelder in Programmen, fehlerhafte Implementierung des GEDCOM-Exports und unvollständiger GEDCOM-Export (auch bei aktueller Software). Das ändert sich auch mit GEDCOM 7 nicht.
GEDCOM 7 kann nun zwar neue Datenkonstrukte abbilden (Ereignis hat nicht stattgefunden, zusätzliches Sortierdatum, Bildausschnitte, …), was man aber in den wenigsten Programmen findet. Solange diese sich nicht in Richtung dieser Funktionen erweitern, besteht auch kein Bedarf an GEDCOM 7. Und falls das doch gebraucht wurde, ließ es sich in GEDCOM 5.5.1 als Unterstrich-Erweiterung implementieren.
GEDCOM 7 ist noch zu wenig verbreitet, als dass es bislang beweisen konnte (bzw. musste), dass es besser als GEDCOM 5.5.1 ist. Wer sagt, dass die bisherigen GEDCOM 7 Implementierungen fehlerfreier sind, als die GEDCOM 5.5.1 Implementierungen? Mir fehlt daran der Glaube … 
Gruß, Dirk
1 „Gefällt mir“
Oh ja, ich habe einfach das KI-Geblubber reinkopiert, damit mal was da steht.
Danach habe ich auch gesucht und nichts gefunden. Es gab mal etwas bei PhpGedView mit XML, aber ob das was mit Gramps zu tun hatte? Weg damit. Aber Gramps XML ist schon ein Austauschformat, nämlich zwischen Gramps Desktop und Gramps Web.
Genau da soll es nicht um GeneWeb gehen, sondern um das Dateiformat. Da will ich noch recherchieren, ob das bei Geneanet unterstützt wird und welche anderen Programme das lesen können.
Ok, Ziel sollte sein, existierende Austauschformate vollständig zu erfassen und kurz zu beschreiben. “Technisch” wird sich kaum vermeiden lassen.
Gut. Der Mehrwert ist: Wenn jemand das Problem hat, Daten aus einem Programm x in ein Programm y zu überführen, dann sollte er erkennen können, welche Möglichkeiten er zum Datenaustausch hat. Deshalb fand ich die Anregung gut noch ein paar Programme aufzulisten, die das jeweilige Format im- und exportieren können. Excel wäre also auch noch so ein Austauschformat.
Ja, ganz klar. Das kann man gleich zu Beginn des Artikels klarmachen.
Das mit den Links zur Doku muss sein und noch kommen. Guter Hinweis. Eine Umbennung in “Genealogische Dateiformate” würde den ursprünglichen Gedanken besser aufgreifen. Warum nicht?
1 „Gefällt mir“
Naja, so Formulierungen wie “es adressiert Lücken wie bessere Unterstützung für nicht-binäre Beziehungen und ist IANA-registriert, wird aber nicht flächendeckend adoptiert“ oder “Andere XML-Formate umfassen FHISO-Standards (JSON/XML-Zip für Konsortien) …” versteht kein Mensch. Du als KI-Experte solltest die KI deiner Wahl mal um Umformulierung und Weglassung von technischen Begriffen bitten. Ich denke, da käme was brauchbares raus …
Wäre mir neu. Stattdessen findet man eher CSV - was aber selten programmübergreifend kompatibel ist. Wäre zumindest zu testen …
Gruß, Dirk
1 „Gefällt mir“
[Hermann_Hartenthaler]
9. Dezember
Format im- und exportieren können. Excel wäre also auch noch so ein
Austauschformat.
Excel ist eine Tabellenkalkulation, kein Austauschformat. Excel bietet
einen tabellarischen Text-Export als csv (comma separated value) an,
welchen man mit jedem beliebigen Editor lesen kann.
Auch manche Programme bieten einen csv-Export (und vielleicht auch einen
Wieder-Import). Der ist allerdings nicht „genormt“ und der Export von
Programm A kann nicht einfach in Programm B eingelesen werden.
Geschweige denn, dass der Export immer vollständig alle Informationen
aus dem Genealogieprogramm enthält. Für mich ist das lediglich ein
Export-Format, kein Austausch-Format.
Für nicht technik-affine Anwender kann das eine unüberwindbare Hürde sein.
Das ist bei GEDCOM nicht anders als bei csv, da es dort die benutzerdefinierten Kennzeichen mit „_“ gibt. Es ist nur graduell verschieden.
Ich gestehe ich habe weder Erfahrung noch Einblick in die White Paper von 5.5.1 oder 7er Versionen genommen und bin auch kein wirklicher Programmierer (nur oberflächliche Kenntnisse).
Ich hatte halt gehofft FamilySearch hätte in 7/7.1 entweder bessere oder überhaupt Definitionen für:
- Ortverwaltung inklusive GPS Koordinaten, Sprach- und zeitliche Versionen, Custom Hierarchien / Pfarren usw.
- Quellenverwaltung inklusive ausführlichem Medienanhang (Pixel, PDF, u.a.)
- Datumangaben: mehr und flexible Angaben, z.B. mehrere Datum mit Wahrscheinlichkeit.
- Bezifferungsfelder: Kekule u.a. z.B. Stammbezogen mit eigenem Kodex, soll Apps ermöglichen dies automatisch ausgehend von einem Probanden zu füllen
- Referenzierung von Personen bei Ereignissen
- DNA-Genealogie Felder: Felder für at, Y, mt - Matches (Referenzierung Personen), Felder für Y, mt - Haplogruppen
- ein Datenformat (wohl XML) was für Software einfacher strukturiert bzw. lesbar ist, unter Umständen auch für Menschen.
- wohl noch einiges was mir jetzt nicht einfällt
Generell: bin auch für Umbenennung nach “Genealogische Dateiformate” und finde es ok, wenn der Artikel eher für fortgeschrittene Nutzer (mehrerer Tools, eigene Skripts) ist. Das kann man ja auch am Anfang erwähnen.
Eine Ortsverwaltung ist eine Funktion eines Genealogieprogramms und gehört nicht in den Standard. Bereits GEDCOM 5.5.1 unterstützt das und hat Koordinaten zu einem Ort.
Das sind tatsächlich Dinge, die derzeit für die nächste Version des Standards diskutiert werden. Das GEDCOM-L-Addendum enthält eine mögliche Lösung dafür und einige Programme wie webtrees unterstützen das bereits seit langem.
Das ist wiederum eine Programmfunktion. Der Standard unterstützt da doch so ziemlich alles, was man braucht. Oder? Mir fällt höchstens eine Hierarchie von Quellen ein. So etwas gibt es in webtrees als Zusatzmodul.
Hmmm. GEDCOM bietet mehr als alle anderen Standards, die ich so kenne. FHISO hatte mal versucht das noch exakter zu definieren. Mehrere Datumsangaben zu einem Ereignis gehen immer. Ok, Wahrscheinlichkeitsangaben fehlen, aber dafür ist das Konzept mit der Unschärfe sehr ausgefeilt und kann das ersetzen.
Das ist schon lange Bestandteil des Standards. Die Kennzeichen nennen sich REFN und RIN und können flexibel belegt werden, etwa für Kekule-Nummern.
Das ist mit GEDCOM 7 gekommen (u.a. ASSO).
Das ist tatsächlich ein offenes Feld. Da basteln manche Programme eine proprietäre Funktion, aber ein Austausch ist so nicht gewährleistet.
Hmmm. Es gibt wohl kein Genealogieprogramm, das kein GEDCOM lesen kann. Sogar die KIs sprechen GEDCOM fliesend. Ok, es gibt Hinweise auf Performance-Effekte, wenn XML statt GEDCOM zum Einsatz kommt. Aber da reden wir von Datenstrukturen von 1 Million Personen oder mehr. Das betrifft nicht viele Nutzer. Ich glaube, dass das Datenformat GEDCOM-Text versus XML oder JSON eher nicht so wichtig ist.
1 „Gefällt mir“
[Hermann_Hartenthaler]
Das ist bei GEDCOM nicht anders, da es dort die benutzerdefinierten
Kennzeichen mit „_“ gibt. Es ist nur graduelll verschieden.
Hm, aber das „_“ ist doch gerade die Norm. Es besagt lediglich, dass es
sich um ein Kennzeichen handelt, das man damals nicht im Standard
definiert hat und vom Benutzer nachträglich eingeführt wurde. Ein
Programm(autor) kann entscheiden, ob er TAG wegwirft, in eine Notiz
pakt, oder „as is“ importiert. Im letzten Fall hätte dieses Kennzeichen
dann bestenfalls lediglich keinen hübschen Anzeigenamen.
Und die erlaubten Unterstrukturen unter "" sind nahezu identisch zu den
Standard-Ereignissen/Fakten, ließen sich also durchaus strukturiert in
eine DB übernehmen.
Für csv habe ich noch keine „Definition“ gesehen, die besagt, wie z.B.
die Tabellenüberschriften lauten sollten, damit die Inhalte von jedem
beliebigen Programm verstanden und importiert werden können. Als Best
Practice scheint sich da durchzusetzen, dass die GEDCOM-Tags mit
Unter-Tags verwendet werden. Aber ich habe das noch nirgendwo offiziell
dokumentiert gesehen. Oder ob das Datum in einer Spalte stehen muss,
oder auf drei Spalten (Tag, Monat, Jahr) aufgeteilt sein darf. Auch
steht nicht geschrieben, ob Informationen redundant auf mehrere Zeilen
verteilt werden dürfen oder nicht, falls die Anzahl Spalten nicht
ausreicht. Und da wäre wohl noch viel mehr zu berücksichtigen/bedenken.
Falls es da irgendwo etwas (auch nur halbwegs offizielles, allgemeines)
dazu gibt, wäre es sicherlich sinnvoll, das mit in den Artikel aufzunehmen.
Gruß
Martina
[Hermann_Hartenthaler]
Eine Umbennung in “Genealogische Dateiformate” würde den ursprünglichen
Gedanken besser aufgreifen. Warum nicht?
Hm, geht es hier um „Austauschformate“ für genealogische Daten, wie
xml/json/GEDCOM? Oder geht es um genealogische Dateiformate? Dann
müssten .ahn, .stb, .fam, und wie die Endungen alle heißen, auch mit
gelistet werden. Die kann man aber nicht einfach xbeliebig in andere
Programme importieren, sondern nur mit dem jeweiligen Programm öffnen.
1 „Gefällt mir“
Das sind alles letztlich Funktionswünsche gerichtet an Genealogieprogramme und keine aktuellen Datenaustauschprobleme, die mit einer neueren GEDCOM-Version gelöst wären. Das sollte man immer klar trennen.
Gruß, Dirk