Ahnenblattportal

Hallo,

ich bin gerade dabei mich mal etwas intensiver mit der GEDCOM-Standard zu beschäftigen. Dabei bin ich über den Tag ²ANCESTRAL_FILE_NUMBER" gestolpert:
ANCESTRAL_FILE_NUMBER:= {Size=1:12} (Nummer im Ancestral File) Eine eindeutige und permanente Datensatznummer eines Personendatensatzes aus dem Ancestral File der Familiengeschichtlichen Abteilung (Family History Department)

Dazu 2 Fragen:
1) Wird dort die Personenkennung, wie sie auf www.familysearch.org zu finden ist, eingetragen?
2) Gibt es dazu ein Feld bei Ahnenblatt wo man diese eintragen kann? (Ich gehe davon aus, daß die Benutzdefinierte-ID nicht das richtige Feld dazu ist)

Gruß Ulf

Hallo Ulf,

torgau hat geschrieben: ↑27.06.2025, 18:25 1) Wird dort die Personenkennung, wie sie auf www.familysearch.org zu finden ist, eingetragen?

ANCESTRAL_FILE_NUMBER ist ein veraltetes Nummernsystem von FamilySearch.
Siehe hier: https://www.familysearch.org/de/search/ ... llection/2
Dieses Feld wird rein intern von der Genealogie-Software genutzt, also nichts, wo man als Anwender etwas eintragen kann.

torgau hat geschrieben: ↑27.06.2025, 18:25 2) Gibt es dazu ein Feld bei Ahnenblatt wo man diese eintragen kann? (Ich gehe davon aus, daß die Benutzdefinierte-ID nicht das richtige Feld dazu ist)

Kann man durchaus als Benutzerdefinierte ID hinterlegen oder auch unter Notizen eintragen.

- Dirk

DirkB hat geschrieben: ↑29.06.2025, 14:36 ...
Kann man durchaus als Benutzerdefinierte ID hinterlegen oder auch unter Notizen eintragen.

Wobei man mit Notizen wieder das Problem hat, dass sie von Ancestry... ggf. nicht übernommen werden.
Ich praktiziere es (unabhängig von Ahnenblatt) ganz einfach:
FamilySearch ist eine Quelle und die ANCESTRAL_FILE_NUMBER halt ein Verweis (in GEDCOM = PAGE).
Und fertig ist die Laube.

Jo301 hat geschrieben: ↑29.06.2025, 17:50 Wobei man mit Notizen wieder das Problem hat, dass sie von Ancestry... ggf. nicht übernommen werden.

Genau genommen hat Ancestry hier ein Problem.
Da würde ich als regelmäßig zahlender Kunde mal nachfragen, ob die sich dieses Fehlers bewusst sind und wann mit Abhilfe zu rechnen ist.
Oder wurde das bereits gemacht?

- Dirk

DirkB hat geschrieben: ↑30.06.2025, 11:57 Genau genommen hat Ancestry hier ein Problem.

Ja, aber praktisch hat es der User des Genealogieprogramms, das übermäßig viel in Kommentare verlagert / konvertiert.
Du solltest Dir mal überlegen, ob es sinnvoll ist mit Deiner Kommentar-Affinität die betroffenen Benutzer bei Ancestry ... auflaufen zu lassen.

DirkB hat geschrieben: ↑30.06.2025, 11:57 Da würde ich als regelmäßig zahlender Kunde mal nachfragen, ob die sich dieses Fehlers bewusst sind und wann mit Abhilfe zu rechnen ist.

Ich zahle nur gelegentlich zur Einsicht in Quellen und überlasse Ancestry prinzipiell nicht meine Daten, die dort monetarisiert werden.
Die restlichen Nachteile dort sind bekannt.

DirkB hat geschrieben: ↑30.06.2025, 11:57 Oder wurde das bereits gemacht?

Ich habe das Problem nicht und setze nur noch auf Programme, die GEDCOM als Primärdatenformat nutzen.
Das hat auch damit zu tun, dass sicher die meisten proprietären DB-Formate irgendwann unlesbar werden.
Der Autor lebt nicht mehr, die Lizenz ging mit Opas PC verloren, Windows 17 meckert... ja schade um tausende Stunden Arbeit.

Als Langzeit-, Archiv- und Austauschformat ist nur valides GEDCOM geeignet, alles andere läuft auf Datenverlust hinaus, dereinst...

-Joachim

Hallo

"""Der Autor lebt nicht mehr, die Lizenz ging mit Opas PC verloren, Windows 17 meckert... ja schade um tausende Stunden Arbeit. """

Dass Win 17 meckert glaube ich gernae.

Mann könnte noch probieren FDD ausbauen und mit seperaten kontroler an einen PC anschließen, evt Elektonik PCB tauschen.

Nein hat Man(n), schon desòfferen Daten zurück.

Gold Luck.

@Iemhoff

Iemhoff hat geschrieben: ↑01.07.2025, 20:09 Mann könnte noch probieren FDD ausbauen und mit seperaten kontroler an einen PC anschließen, evt Elektonik PCB tauschen.

Ich wäre dazu beruflich in der Lage (NI), aber meine Nachfahren mit KI?

Aber sie haben die Lizenz von Ahnenblatt verloren, Support war einmal und eine .ahn Datei ist ein Haufen Binärschrott, den keiner mehr verwerten kann. Es gab schon mehr Diskussionen hier, wie man an prähistorische Daten anderer verblichener Programme wieder herankommt.
Viel Spaß unseren Nachfahren und ein ziemlich dummes Gesicht.

Hallo

Aus welche Zeit von AB? 2 oder 3?
Lizenz von Ahnenblatt verloren,kann Dirk nicht helfen?..
Alte AB's sind noch wohl vorhanden.
Ich habe auch noch nie Augetestet alte .ahn (Zbs2.5-3.??) mit 4.28 einzulesen.
Wenn das Gewitter vorbei ist werde in mal testen gehen.
Temperatur zurück gegangen 19.8

Iemhoff hat geschrieben: ↑02.07.2025, 18:57 ...Aus welche Zeit von AB? 2 oder 3?...

Ich glaube Du hast das eigentliche Thema nicht verstanden.
Es geht um Langzeitarchivierung und Verfügbarkeit der Daten in einer Zeit nach Dirk, ja so deutlich muss man das sagen.

Jegliche proprietäre Binärdaten sind dann gefährdet und nicht mehr verfügbar, sofern man sich nur auf das .ahn File verlässt.
Unser Hobby dreht sich um die Endlichkeit des Lebens und was von ihm bleibt.
Ohne geeignete Vorkehrungen sind alle binären und nicht textuellen Formate akut gefährdet.
Dafür sind mehrere Gründe denkbar.

Guten Abend Joachim,
teils Du uns die Gründe für den Datengau mit?
Mfg. Klaus

Hallo Klaus,

mit s.g. Langzeitformaten soll die Lesbarkeit und Archivierung binär repräsentierter Daten über die "Ewigkeit" garantiert werden, ja sagen wir mal etliche Generationen. PDF/A vs. PDF ist ein prominentes Beispiel.

Bei proprietär definierten Formaten wie bei Ahnenblatt, Heredis und allerlei eingegangenen älteren Genealogieprogrammen existiert in der Regel keine öffentlich einsehbare Datenstrukturbeschreibung. Diese wäre allenfalls per Reverse-Engeneering in der Zukunft erschließbar, diese Mühe wird sich aber kaum jemand machen.

Ein Fortschritt bzgl. der Überlebensfähigkeit unserer Forschungen sind textuell definierte Formate. Wie der "Zufall" es will gibt es ein solches Format, das einem Normungsgremium untersteht (GEDCOM).
Dieses Format wurde aktuell in der Version 7 spezifiziert und wird weiter gepflegt.

Deine Auffassung, es wäre ein "Hype" weise ich mit aller Entschiedenheit zurück!

Die Gefahr des langfristigen Datenverlustes (abseits jeglicher Backup-Fragen) besteht regelmäßig, wenn:

- der Autor, insbesondere bei Verwendung proprietärer Datenstukturen, seine Tätigkeit einstellt oder einstellen muss (dafür gibt es mehrere Gründe),
- der Vertrieb des Programmes de facto ausläuft,
- die Lizenz verloren geht und nicht wieder zu erlangen ist oder
- spätere Betriebsssystemversionen den Support von Win32-Programmen oder benutzter Bibliotheken ... einstellen ...

Unabhängig vom Datenformat können Daten aus Gründen der Ignoranz, Unwissenheit, mangels testamentarischer Regelungen untergehen.

Dem gegegnet man durch Veröffentlichung auf geeigneten Plattformen, ich habe ein OFB bei CompGen online gestellt.
Aber auch hier gilt: Dreh- und Angelpunkt ist eine gute GEDCOM-Kompatiblität.

Es gibt beim Ahnenblatt-Import/Export Tendenzen, diese Kompatiblität doch sehr eigen zu interpretieren und valide GEDCOM-Tags anderer Programme in Kommentare zu wandeln. Das hat bei mir dazu geführt, dass ich Ahnenblatt aus der Auswahl eines Nachfolgeprogramms zu Ages! gestrichen habe. Das ist aber kein Problem, da Ages! immer nur GEDCOM benutzt hat. Insofern ist die Einstellung des Supports unschön, aber kein Beinbruch.

Ich kann alle nur ermuntern, über den "Tellerrand" zu schauen. Aber jeder darf das für sich selbst beantworten oder auf St.-Nimmerlein vertagen.

Von der Endlichkeit des Lebens bleibt letztlich nur die Erinnerung -
und sei es vom Wissen über ehemals existierende mühsam erarbeitete, aber nun verblichene Daten.

-Joachim

Hallo Joachim,

deinen Ausführungen zu GEDCOM als zukunftsfähiges "Archivierungsformat" würde ich weitestgehend unterstützen.

So wird mittels "Tools / CD brennen" u.a. auch immer eine GEDCOM-Datei erzeugt, um eine Komplettsicherung zu haben (auch wenn man heutzutage keine CDs mehr brennt - dann kopiert man die damit erzeugten Daten eben auf einen externen Datenträger).

Jo301 hat geschrieben: ↑03.07.2025, 09:02 Ich kann alle nur ermuntern, über den "Tellerrand" zu schauen. Aber jeder darf das für sich selbst beantworten oder auf St.-Nimmerlein vertagen.

Das ist in ähnlicher Form auch das Fazit meines Vortrages zum Thema GEDCOM: https://www.youtube.com/watch?v=ViT1WxEKPHk

Ob eine Genealogie-Software, die nur mit dem GEDCOM-Format arbeitet es per se besser macht (statt regelmäßig selbst GEDCOM-Dateien zu erzeugen), sehe ich ein wenig anders.

Aus meiner Sicht wären folgende Punkte zu berücksichtigen:

[optional] speichern nur im GEDCOM Format (Ahnenblatt speichert eine Ahnenblatt-GEDCOM mittels "Speichern" ohne Nachfrage wieder im GEDCOM-Format - also Arbeiten nur mit GEDCOM-Datei möglich)

kein Überschreiben einer GEDCOM aus "Fremdsoftware" ohne Hinweis (wobei Besonderheiten der Ursprungssoftware verloren gehen können)

GEDCOM-Version berücksichtigen (nicht eine GEDCOM7 Datei kommentarlos öffnen, aber intern wie eine 5.5.1 GEDCOM behandeln und dabei unbekannte Daten ignorieren)

hohe GEDCOM-Kompatibilität (eine gespeicherte GEDCOM-Datei sollte nicht mehr Struktur-Fehler enthalten als die Ausgangs-GEDCOM - mit einem GEDCOM-Validator testbar)

vorhandene GEDCOM-Datei vor dem Speichern als Sicherung aufheben (idealerweise mehrere)

beim Speichern auf USB-Medium auch Bilder kopieren (sonst gehen diese womöglich verloren)

Von daher sehe ich Ahnenblatt im Vergleich zu anderen Programmen sehr gut aufgestellt.

Jo301 hat geschrieben: ↑01.07.2025, 15:19 Du solltest Dir mal überlegen, ob es sinnvoll ist mit Deiner Kommentar-Affinität die betroffenen Benutzer bei Ancestry ... auflaufen zu lassen.

Eine Umkehr der Realität: Ancestry ist es, welches die betroffenen Benutzer (aller Programme!) auflaufen lässt ...

Bestimmte Daten in Notizen zu verschieben, um sie sichtbar und editierbar zu machen, halte ich für ein probates Mittel.
Obwohl ich zugegebenermaßen mit der Meldung von Ages! ...

Ages! hat geschrieben:Die Datei enthält unbekannte Elemente. Sollen diese in Notizen umgewandelt werden?

... auch nicht so wirklich etwas anfangen kann.

- Dirk

Hallo Dirk,

DirkB hat geschrieben: ↑05.07.2025, 12:15 So wird mittels "Tools / CD brennen" u.a. auch immer eine GEDCOM-Datei erzeugt, um eine Komplettsicherung zu haben (auch wenn man heutzutage keine CDs mehr brennt - dann kopiert man die damit erzeugten Daten eben auf einen externen Datenträger).

die Einordnung unter "Tools / CD brennen" empfinde ich als antiquiert und verschleiert die Möglichkeiten.

Vorschlag:
Bringe es als "Vollsicherung" unter "Datei" prominenter und aussagefähiger unter.
Was man damit macht, kann jeder selbst entscheiden.

Idee:
Wenn Du zukünftig ein Hybrid-Format etablierst (*.ahn + *.ged), z.B. als *.abz (Ahnenblatt-Zipped), wäre immer beides vorhanden. Das könnte man zyklisch oder auf Request auf ein irgendwie gemountetes "Laufwerk" sichern. Das würde auch helfen Eingabefehlern nachzukommen. Es muss ja nicht gleich eine richtige Versionsverwaltung sein, obwohl das auch kein Hexenwerk ist. Vergleichen ginge dann aber nur mit dem textuellen GEDCOM-Format.

...

DirkB hat geschrieben: ↑05.07.2025, 12:15 [optional] speichern nur im GEDCOM Format (Ahnenblatt speichert eine Ahnenblatt-GEDCOM mittels "Speichern" ohne Nachfrage wieder im GEDCOM-Format - also Arbeiten nur mit GEDCOM-Datei möglich)

Ja sicher geht das, kann aber im "Flow" verwirrend sein.

DirkB hat geschrieben: ↑05.07.2025, 12:15 kein Überschreiben einer GEDCOM aus "Fremdsoftware" ohne Hinweis (wobei Besonderheiten der Ursprungssoftware verloren gehen können)

Ist selbstverständlich, noch besser wäre <GEDCOM-File>.ahnenblatt.ged, damit wird ein versehentliches Überschreiben immer vermieden.

DirkB hat geschrieben: ↑05.07.2025, 12:15 GEDCOM-Version berücksichtigen (nicht eine GEDCOM7 Datei kommentarlos öffnen, aber intern wie eine 5.5.1 GEDCOM behandeln und dabei unbekannte Daten ignorieren)

Das hätte ich jetzt nicht erwartet von Dir, versteht sich doch von selbst.

DirkB hat geschrieben: ↑05.07.2025, 12:15 hohe GEDCOM-Kompatibilität (eine gespeicherte GEDCOM-Datei sollte nicht mehr Struktur-Fehler enthalten als die Ausgangs-GEDCOM - mit einem GEDCOM-Validator testbar)

Klar, oberstes Ziel! Das mit dem GEDCOM-Validator (egal welcher) sehe ich kritischer.
Mir kommt es vor, dass zuerst nur die Syntax der Zeile geprüft wird und nicht immer die Semantik in der Sequenz. So werden in Kommentare gewandelte GEDCOM-Tags nie beanstandet, im NOTE darf alles stehen.
Man darf sich dann auch nicht wundern, wenn Ancestry das beim Import nicht vorhersehen kann.

DirkB hat geschrieben: ↑05.07.2025, 12:15 vorhandene GEDCOM-Datei vor dem Speichern als Sicherung aufheben (idealerweise mehrere)

Gerne, das korrespondiert mit meiner Äußerung zu Vollsicherungen (quasi versioniert mit Datum/Uhrzeit) oben.

DirkB hat geschrieben: ↑05.07.2025, 12:15 beim Speichern auf USB-Medium auch Bilder kopieren (sonst gehen diese womöglich verloren)

Warum differenzieren bei USB, siehe Vollsicherung.

DirkB hat geschrieben: ↑05.07.2025, 12:15 Eine Umkehr der Realität: Ancestry ist es, welches die betroffenen Benutzer (aller Programme!) auflaufen lässt ...

Im Prinzip ja, aber wer hat den längeren Hebel, Du als einer von vielen Autoren oder Ancestry?

DirkB hat geschrieben: ↑05.07.2025, 12:15 Bestimmte Daten in Notizen zu verschieben, um sie sichtbar und editierbar zu machen, halte ich für ein probates Mittel.

Das gilt nur für Ahnenblatt so, dem möglicherweise Datenstrukturen fehlen, um AGE, AGNC ... direkt abbilden zu können. Oder ist *.ahn tatsächlich eine richtige Datenbank, die man einfach reorganisieren könnte?

DirkB hat geschrieben: ↑05.07.2025, 12:15 Obwohl ich zugegebenermaßen mit der Meldung von Ages! ...Die Datei enthält unbekannte Elemente. Sollen diese in Notizen umgewandelt werden? ... ... auch nicht so wirklich etwas anfangen kann.

Ages! zeigt optional einen kompletten Importbericht an, wo man alle Zeilen ersehen kann und dann weiter entscheidet.

Den Importbericht von Ahnenblatt (hier mein OFB) muss man nicht lieb haben:
"Optimierter GEDCOM-Import für das Programm Ages!:
Es wurden 4.686 Korrekturen durchgeführt."

A ja, da weiss man wirklich gut Bescheid.

-Joachim

Hallo Joachim,

du hättest nicht jeden Punkt der Aufzählung kommentieren müssen.
Es ist nur eine Aufzählung von Punkten, die ich beim reinen Speichern im GEDCOM-Format für wichtig halte - in anderen Programmen aber nicht vorhanden sind (auch nicht in Ages!).

Der Import-Bericht von Ages! zeigt mir, was beim GEDCOM-Import nicht erkannt wurde. Entscheiden kann man da nichts mehr. Schon gar nicht wird mir gezeigt, was auf Nachfrage in Notizen gewandelt wurde. Intern wird noch mehr geändert, so dass die Ergebnis-GEDCOM aus Ages! mehr Strukturfehler enthält als die Ausgangsdatei aus Ahnenblatt.

- Dirk