ich möchte folgendes nur kurz bzgl. der Version 4.24 aktualisieren.
Jo301 hat geschrieben: ↑07.03.2025, 08:51
c)
Es gibt Autoren, die wandeln vorhandene "2 AGE STILLBORN" beim Import eines GEDCOM-Files in einen Kommentar um.
"2 NOTE Alter: STILLBORN". ...
Vorheriges war der Stand zur Version 4.22, die 4.23 konnte ich ohne Hast zum Glück überspringen.
In der Version 4.24 wird die im importierten GEDCOM-File enthaltene Information zur Totgeburt im Export ganz unterdrückt und ist nicht mehr enthalten.
Die "Optimierung" des Alters in einen Kommentar wie "2 NOTE Alter: 1 Tage" wurde so beibehalten.
Nebenbei wird das Alter im Kommentar bei der Wandlung auch nicht nachgerechnet, falls es trotz genauer Angaben nicht stimmt.
Noch logisch hätte ich bei der Totgeburt empfunden, wenn "2 NOTE Totgeburt" draus geworden wäre.
Tja weg ist weg und kommt nicht wieder, das ist (leider erneut) eine "Optimierung" die keiner braucht.
Sorry Dirk, die letzten Versionen wirken teils erratisch und könnten als Softwareerosion gedeutet werden (siehe Wikipedia).
Gibt es kein Beta-Test-Team, das neue Versionen vorab testet?
nochmal zum Thema Totgeburt, die in der Version 4.25 als "2 AGE STILLBORN" wieder drin ist.
Hurra könnte man denken, aber mir kommen immer mehr Zweifel an den "Optimierungen" der letzten Zeit.
Bezogen auf die Möglichkeiten des GEDCOM-Standards wird (in der V4.25) aus:
a) 2 AGE INFANT =
"2 NOTE Alter: jünger als 1 Jahre"
b) 2 AGE CHILD =
"2 NOTE Alter: jünger als 8 Jahre"
und c) 2 AGE STILLBORN bleibt zu:
"2 AGE STILLBORN"
Zuvor hatte ich knurrend erwähnt, das ich verstanden hätte:
"2 NOTE Alter: Totgeburt" draus zu machen (um die Optimierung endlich abzuschließen).
"2 AGE STILLBORN" wird nun lediglich nicht mehr im Export unterdrückt wie in der Version 4.24, aber der neueste Zustand hinterlässt nur Kopfschütteln. Eine Visualisuierung findet nicht statt. Dabei wäre das Datum und der Umstand der Totgeburt anzuzeigen. Das trifft genau genommen auch auf ungefähre Datumsangaben bei "AGE INFANT" und "AGE CHILD" zu.
Noch ein anderer Spezialfall ist mir aufgefallen:
Derzeit wird übrigens aus den nicht GEDCOM-konformen Angaben (selbst gebastelt),
wie DATE INFANT, DATE STILLBORN oder DATE CHILD:
- Kleinkind
- Totgeburt
- Kind
Das ist genaui genommen eine GEDCOM-Textphrase:
"DATE_PHRASE:= <TEXT>
Eine beliebige Aussage zum Datum, wenn das Jahr nicht durch einen Datums-Parser
erkannt werden konnte, welche aber Informationen darüber gibt, wann das Ereignis
stattfand."
Hier könnte z.B. auch stehen: "auf der Flucht gestorben"
Eine Anwendung / Interpretion von INFANT, STILLBORN oder CHILD zusammen mit "DATE" gestattet der Standard aber m.E. nach nicht.
Hmmmm... tiefe Ratlosigkeit bei mir, mein Fazit heute:
- man kann manche GEDCOM-standardkonforme Dinge Ahnenblatt nicht mehr anvertrauen
- die Art der Konvertierung in Kommentare oder auch nicht ist fragwürdig
- wann werden diese Optimierungen denn mal stabil?
Wie soll diese Geschichte denn mal zu Ende gehen?
Mein Meinung dazu ist klar, die Optimierungen hätten nie durchgeführt werden dürfen.
Damit wird die Interoperabilität über sprachneutrale Schlüsselworte abgeschafft.
Das Ganze trifft bei Ages! z.B. auch "AGNC" (zuständige Stelle), eine durchaus wichtige Information, wo man Schulabschlüsse erworden hat, im Krankenhaus verstorben, geheiratet, gearbeitet etc. hat.
Alles um AGE und AGNC wird von den CompGen-OFB richtig in eine wählbare Zielsprache umgesetzt.
Warum werden von Ahnenblatt manche Angaben in deutsche Kommentare gewandelt?
Ich kann nur empfehlen, den Import seitens anderer Genealogieprogramme kritisch zu betrachten, die von den Optimierungen betroffen sind. Dies unter der Maßgabe, dass man über den privaten Tellerand hinaus denkt.
Genealogen respektieren die Erfassungen anderer, auch wenn sie Elemente selbst nicht benutzen oder es ihnen nicht in den Kram (resp. DB) passt.
Die Gründe hatte ich schonmal erläutert, GEDCOM als zentrales Austauschformat muss für den Fall der Fälle vollständig (wieder) erzeugbar sein.
Denn sollte es notwendig sein, muss man einfach den Rucksack packen können.
Im Märchen hieße es:
Und wenn sie nicht gestorben sind, dann optimieren sie noch heute.
Gruß Joachim
P.S.
Eigentlich bin ich enttäuscht, dass Ahnenblatt in eine Richtung davonzieht, die gemessen an GEDCOM (trotz mancher Interpretationen) kontraproduktiv ist. Jahrelang war die Kapselung seltenerer GEDCOM-Tags in Ahnenblatt gewährleistet und sie blieben im Export erhalten. Warum geht das jetzt nicht mehr?
Jo301 hat geschrieben: ↑24.03.2025, 16:29
Jahrelang war die Kapselung seltenerer GEDCOM-Tags in Ahnenblatt gewährleistet und sie blieben im Export erhalten. Warum geht das jetzt nicht mehr?
Wer zu Ahnenblatt umsteigt, bekommt nun seine Daten in editierbare Felder (betrifft aber wirklich nur die beiden genannten Datenfelder AGE und AGNC). Daten, für die es keine Eingabefelder gibt, in Notizen zu bringen, ist dabei ein gängiger Weg.
Ansonsten werden beim optimierten GEDCOM-Import hauptsächlich fehlerhafte oder programmspezifische GEDCOM-Strukturen korrigiert.
interessanter ist (mal wieder) wozu Du nichts sagst und trotzdem änderst.
Kurz gesagt unterstützte Ahnenblatt bestimmte GEDCOM-Tags nicht, die aber anderweitig durchaus und lange üblich sind (hier AGE und AGNC).
Diese sind weder fehlerhaft noch programmspezifisch, außer, dass Ahnenblatt sie immer noch nicht beherrscht.
Sie in Notizen zu "quetschen" ist nicht wirklich fein, auch wenn andere wenige Anbieter es gelegentlich tun.
Die tatsächlich fehlerhaften oder programmspezifischen GEDCOM-Strukturen solltest Du in einem Beitrag einfach mit "Roß und Reiter" benennen.
Dann könnte jeder Anwender beurteilen, ob er betroffen ist und wie wichtig es ihm ist.
Zurück zu AGE und AGNC:
Muss man diese GEDCOM-Tags in (deutsche) Kommentare verbiegen und so wieder exportieren?
Und dann noch hervorheben, dass diese nun (als Kommentare) editierbar sind?
Aber berechenbar ist das Alter scheinbar nicht, ach ja, auch das noch in den 2020-er Jahren.
Hier stimmt irgendetwas nicht:
- entweder fehlt der Respekt vor der Leistung anderer Autoren,
- und/oder der Erfassungsleistung der beteiligten Genealogen,
- und/oder der zentralen Rolle des GEDCOM-Standards (= Interface), das man sich nicht nach Lust und Laune passend schleift
Ich frage mich, ob das Software-Design von Ahnenblatt möglicherweise keine einfachen Erweiterungen mehr zulässt. Es ist ein absolutes No-Go dann ein standardisiertes Interface (GEDCOM) zu verbiegen, statt die eigenen Hausaufgaben zu machen.
Fragen über Fragen, mit meiner jahrzehntelangen beruflichen Software-Erfahrung gäbe es allerlei Deutungen. Das ganze Hin und Her bzgl. der "Optimierung" spricht für sich, danke. Naja, im Zweifel zugunsten des Entwicklers.
Manchmal kann man nach vielen Jahren getrost mehr als ein Redesign vornehmen.
Grundsätzlich macht man Änderungen der interen Datenformate besser zu einem Major-Release-Wechsel (z.B. Ahnenblatt 5.x), anstatt mitten im 4-er Release. Neben der internen und gekapselten Datenrepräsentation, die nicht offengelegt werden muss, ist korrektes GEDCOM grundsätzlich unantastbar.
Es bleiben trotzdem genug Baustellen, man bleibe bei der Datenbank und dem User-Interface (GUI).
Man kann alles weiter schönreden, ist es aber und wird es so nicht.
