Ahnenblattportal

Da kürzlich das Thema GEDCOM7 hier im Forum aufkam, habe ich mal dazu einiges zusammengeschrieben ...

https://www.ahnenblatt.de/infos/gedcom7/

... und hiermit in einem separatem Thema eingestellt.

Dann landen GEDCOM7 Fragen gesammelt an einer Stelle.

Gruß, Dirk

DANKE für diese umfangreichen Informationen und Erklärungen, das ist wirklich sehr hilfreich.

Danke für die ausführliche Darstellung Deiner Sichtweise.

Die Vermischung der Standards sehe ich eigentlich weniger als Gefahr, da der verwendete Standard im Header der Dateien steht. Natürlich wird es wieder Programmierer geben die sich wie beim alten Standard nicht an die Vorgaben halten, aber dieses Problem gibt es jetzt schon und wird es auch später geben.

Word wird als Beispiel gebracht, doch wie macht es Word. Es speichert als Standard sein neues Format das docx, nur wenn der Anwender dies explizit will, wird das alte Doc-Format verwendet mit ggf. Datenverlust.

Gruß

Martin

Martin-D hat geschrieben:Die Vermischung der Standards sehe ich eigentlich weniger als Gefahr, da der verwendete Standard im Header der Dateien steht. Natürlich wird es wieder Programmierer geben die sich wie beim alten Standard nicht an die Vorgaben halten, aber dieses Problem gibt es jetzt schon und wird es auch später geben.

Es geht darum eine GEDCOM7 Datei mit einem Programm zu öffnen, das auf diesen neuen Standard nicht vorbereitet ist (PAF, eine alte Ahnenblatt-Version, Ages!, ...). Dann wieder speichern im GEDCOM-Format und im Header steht als GEDCOM-Version z.B. 5.5.1.
Die Dateiverweise sehen dann allerdings so aus: Das ist dann eine Vermischung von FILE-Angaben im GEDCOM7-Stil innerhalb einer GEDCOM 5.5.1 Datei.
Die Folge ist, dass Dateien nicht mehr gefunden werden.

In diesem Fall bekam ich keine Meldung des importierenden Programmes, dass es sich um eine GEDCOM 7 Datei handelt. Ich könnte tagelang weitere Daten einpflegen, bis ich irgendwann merke, dass die Bilder nicht mehr funktionieren. Dann hilft nur noch ein Reparatur-Tool (wenn es denn etwas in der Art gibt).

- Dirk

DirkB hat geschrieben:...
Es geht darum eine GEDCOM7 Datei mit einem Programm zu öffnen, das auf diesen neuen Standard nicht vorbereitet ist (PAF, eine alte Ahnenblatt-Version, Ages!, ...). ...

Ja diese Gefahr besteht, das ist ein Versäumnis bei der Programmierung der alten Programme, wo man die Versionsnummer nicht abgefragt hat.

Doch wenn man auf alle alten Programme Rücksicht nimmt, gibt es keine Weiterentwicklung. Man hätte das Problem leicht umgehen können, indem man aus .ged ein .ged7 gemacht hätte.
So verlagert man die Versäumnisse der Vergangenheit in die Verantwortung des Anwenders, sicherlich nicht die beste Entscheidung, aber so ist es nun mal.

Ich finde trotzdem dass Ahnenblatt möglichst schnell die Vorteile der Weiterentwicklung umsetzen sollte. Auch jetzt schon muss der Anwender höllisch aufpassen, wenn er seine Anwendung wechselt, dass er keine Daten verliert, das liegt nun mal in der Verantwortung des Anwenders.

Gruß
Martin

Dirk vorab Dank für Deine Info dazu.
Nun ja, das klingt für mich einleuchtend.
Allerdings "dass er keine Daten verliert, das liegt nun mal in der Verantwortung des Anwenders." ist meiner Meinung nach doch etwas zu kurz gesprungen.
Die wenigsten Anwender sind gleichzeitig IT'ler oder zumindest wissen sie meist nicht um oben beschriebene Zusammenhänge (und GEDCOM Änderungen in der Zukunft).
Damit ist der Anwender dann doch etwas ... angeschmiert.
"GEDCOM ist erst einmal nur ein Dateiaustauschformat zwischen unterschiedlichen Genealogieprogrammen" ..... ja, so hoffte ich zu Beginn meiner Dateneingabe, daß GEDCOM eine "Datensicherung" (nicht im Sinne von Backup!) für die Kinder, ggf für die Enkelkindergeneration sein könnte ... selbige haben heute in ihren relativ jungen Jahren keine Zeit für die Ahnen.
Heute glaube ich daran allerdings nicht mehr und würde eher auf vollumfängliche pdf-Dateien setzen, dann allerdings >4000 Personen.

Das ich die momentane Lösung nicht gut finde habe ich ja oben geschrieben. Wie man es hätte besser machen können auch (.ged7), nur bin ich nicht in den Gremien.

Jürgen_Nordlicht hat geschrieben:...
Allerdings "dass er keine Daten verliert, das liegt nun mal in der Verantwortung des Anwenders." ist meiner Meinung nach doch etwas zu kurz gesprungen. ...

Nun, Du scheinst eine Lösung des Dilemmas zu haben, ich lerne gerne dazu. Springe selbst und teile uns Deine Lösung des Problems mit. Wie kann innerhalb von Gedcom7 sichergestellt werden, dass Anwender beim Einsatz alter Programme keinen Datenverlust erleiden?

Gruß
Martin

Nun Martin, auch wenn obige Zeile Dich zitiert ist es nicht meine Absicht gewesen Dir auf die Zehen zu treten
und nein, eine Lösung habe ich ja auch nicht,
da zitier ich mich denn selbst:
"Die wenigsten Anwender sind gleichzeitig IT'ler oder zumindest wissen sie meist nicht um oben beschriebene Zusammenhänge (und GEDCOM Änderungen in der Zukunft).
Damit ist der Anwender dann doch etwas ... angeschmiert."

Nun, das kann man mit der Brechstange lösen :
Gedcom-Dateien ohne bekannte Version nicht verarbeiten.

Aber:
- das entspricht nicht der Intention von Ahnenblatt. AB will alle Gedcom-Dateien irgendwie verstehen und interpretieren, was bisher als Stärke des Programmes gesehen wurde.
- nicht alle Programme, die irgendeine Version eintragen, haben mit dem gleichen Verständnis die zugrundeliegende Spezifikation gleich interpretiert.
- keine der bisherigen Gedcom-Spezifikationen taugten als "Standard", taugten allenfalls als Quasistandard, so fehler- und lückenhaft sie waren.
- Und genau so waren / sind die einzelnen Programme



Wäre das so, hätten sich die Entwickler 10 Jahre Abstimmungsarbeiten im Rahmen der Gedcom-L sparen können.


Ein Rauskommer wäre eine Abfrage, ob die fragliche Datei wirklich (auf eigenes Risiko) eingearbeitet werden soll/darf.

Genaugenommen, müssten dann Daten anderer Entwickler genauso kritisch behandelt werden, selbst bei gleicher Version.


Ich halte diese Diskussion für müßig.

@Jürgen, danke für die Klarstellung.

@Bernhard
Für "müßig" halte ich die Diskussion nicht. Sie hat aus meiner Sicht zweierlei Nutzen.

Zum Einen schafft sie ein Bewusstsein für die Probleme bei der Einführung des Gedcom7- Standards. Nicht jedem ist die Problematik bekannt und die Risiken beim Wechsel von Programmen und Standards bewusst. Ich finde Dirk Böttcher hat da einen guten Text geschrieben, der als Diskussionsgrundlage einen sehr guten Dienst leistet.

Zum Anderen hat Dirk Böttcher ja diese Diskussion deswegen angestoßen, um Klarheit über sein weiteres Vorgehen im Bezug auf Gedcom7 und Ahnenblatt zu erhalten. Er holt sozusagen damit des Anwenders Meinung ein.

Meine Meinung ist hierzu eindeutig:
1. Standard Gedcom7 unterstützen, bei Ex- und Import, das ist die Zukunft.
2. Dem Anwender die Möglichkeit geben in Gedcom 5.5.1 zu exportieren. Das ist die Brücke in die Vergangenheit.

Das dies die obigen Risiken birgt lässt sich dabei leider nicht vermeiden.

Gruß
Martin

Ich würde es begrüßen, wenn wir die Diskussion in Richtung der einzelnen Änderungen leiten könnten, die die Version 7 beinhaltet. Was bringt diese Wirklich an Nutzen für den Einzelnen Anwender und wo ist es eher Kosmetik.

Gruß
Martin

Ich mache mal einen Anfang.

Es gibt jetzt Strukturen, mit denen dargestellt werden kann, dass ein Ereignis nicht stattgefunden hat bzw. nicht in einem bestimmten Zeitraum.
Das wäre für mich nicht von Bedeutung, das habe ich nie vermisst.

Bilder/Dateien können lokal auf dem Rechner sein, aber auch im Internet.
Das ist eine interessante Neuerung. In Zeiten von Cloudspeicher und wo Familien gemeinsame Stammbäume erstellen, nicht uninteressant.

Datumsangaben kann man auch eine Uhrzeit hinzufügen.
So genau brauche ich die Ereignisse nicht. Was interessiert es mich, ob meine Ahne vor 200 Jahren um halb 11 oder halb 12 getauft wurde. Manch Einer sieht das anders und erfasst das derzeit in den Notizen.

Notizen dürfen auch Formatierungen (HTML/RichText) enthalten.
Für mich großes Kino. Damit lassen sich dann leichter Webseiten oder Drucke erzeugen.

Interne Personenkennzeichen (RIN) werden durch ein neues GEDCOM-Schlüsselwort dargestellt.
Blupp!

Jedem Ereignis lassen sich jetzt Personen(-verweise) zuordnen.
Finde ich super, werde ich gerne nutzen. Stört mich jetzt schon, dass ich nicht bei Taufe, Heirat und Tod immer Zeugen und Paten zuweisen kann. Das alleine wäre für mich schon ein Grund zu Gedcom7 zu wechseln.

Jeder (Person-)Datensatz kann zusätzlich zum Änderungszeitpunkt ein Erstellungszeitpunkt haben.
Kann helfen die Herkunft von Daten zu klären. Nicht jeder pflegt die Quellen von Anfang an.

Die Geschlechtsangabe wurde um „divers“ ergänzt.
Bisher kein Bedarf, aber ist konsequent und richtig.

Jeder Datumsangabe kann man um ein „Sortierdatum“ ergänzen.
Kann z.B. helfen die Reihenfolge von Kindern festzulegen von denen man zwar die Reihenfolge aber nicht das Geburtsdatum kennt. Finde ich nützlich.

Datumsangaben als Freitext, werden mit separatem Schlüsselwort gespeichert.
Unnütz, ging bisher in DATE mit dem Freitext in Klammern.

Als Zeichencodierung ist nur noch UTF-8 erlaubt.
UTF-8 ist der richtige Weg.

Verwendete @ Zeichen in Texten werden nicht mehr gedoppelt.
Ok, muss man halt so oder so festlegen. Ohne Doppelung ist es aber einfacher.

Man kann zu Bildern jetzt auch Positionen eines Bildausschnitts festlegen.
Super, damit kann man in einem Gruppenbild einzelne Personen identifizieren. Darauf warte ich schon lange.

Zeilenlängen sind jetzt unbegrenzt, daher entfällt die Trennung mit CONC.
Macht es einfacher.

Alle Quellen und Dateien/Bilder müssen intern als Verweise dargestellt werden.
So macht man das heutzutage.

Man kann Verweise zu nichtexistierenden Datensätzen einfügen (@VOID@).
Was bringt das? Der Sinn erschließt sich mir nicht.

Neues Dateiformat .gdz, welches in gezippter Form eine GEDCOM 7 Datei und alle enthaltenen Dateien/Bilder enthält.
Mag für den einen oder anderen interessant sein. Bei mir wären das riesige Dateien und macht bei mir nicht wirklich Sinn.

Gruß
Martin

Es gibt übrigens eine Liste von Familysearch mit Programmen die Gedcom7 bereits unterstützen bzw. ab wann diese Gedcom7 unterstützen wollen. Man beachte den Eintrag von Ahnenblatt.

https://www.familysearch.org/en/GEDCOM/ ... n-progress

Gruß
Martin

Martin-D hat geschrieben:Ich mache mal einen Anfang.
...

Solche Diskussionen wollte ich eigentlich vermeiden ...

Der GEDCOM7-Standard legt nur fest, wie diese Daten zwischen unterschiedlichen Programmen ausgetauscht werden können.
Dadurch sind keine Funktionalitäten vorgegeben, die Programme können müssen. Nahezu alle Funktionalitäten lassen sich auch im GEDCOM 5.5.1 Standard austauschen - dann mit ergänzenden GEDCOM-Schlüsselwörtern.

Diverse der neuen Möglichkeiten würden für eine tatsächliche Umsetzung aufwändige Änderungen in der Benutzeroberfläche bedeuten, die Ahnenblatt zudem verkomplizieren und erklärungsbedürftig sind.

Wenn ich den GEDCOM7-Standard als neues Im- und Exportformat umsetzen würde, dann würden damit keine neuen Funktionen entstehen.

Rein aus Programmierersicht ist die Umsetzung des GEDCOM7-Standards ein reiner Zeitfresser ohne Mehrwert für den Anwender. Einziger Gewinn ist ein verbesserter Datenaustausch mit anderen GEDCOM7-fähigen Programmen (so die Theorie). Wer also ständig mit GEDCOM-Problemen kämpft, mag sich auf die Umsetzung des neuen Standards freuen. Dazu muss dann aber auch das zweite Programm den neuen Standard umsetzen.

Ich werde es in Angriff nehmen - sehe aber aktuell keinen großen Zeitdruck.

- Dirk