Ahnenblattportal

Verfasst: **02.07.2024, 23:53**

Hallo Jo,

Jo301 hat geschrieben: ↑02.07.2024, 20:59
DirkB hat geschrieben: ↑01.07.2024, 18:41 Die INDI-Nummern in einer GEDCOM-Datei sind von der Sache her temporär. Das Zielprogramm merkt sich diese Info in den seltensten Fällen.
Dem stimme ich nicht zu. Das mag stimmen, wenn das Zielprogramm eine Konvertierung in ein Datenbankformat vornimmt, wie Ahnenblatt.

Bei den Programmen, die in GEDCOM speichern / es als Primärformat nutzen ist es nicht so.

Vielleicht reden wir aneinander vorbei oder du meinst irgendetwas anderes ...

Ich hänge hier mal eine GEDCOM-Datei an, die als INDI-Referenz @abc123@ nutzt ...

Code: Alles auswählen

0 @abc123@ INDI

Das ist GEDCOM-technisch in Ordnung - die Kennung muss nur innerhalb der GEDCOM-Datei eindeutig sein und mit einem Buchstaben beginnen.

Ich habe die Datei mal auf die Schnelle mit 7 Genealogie-Programmen geöffnet bzw. importiert und wieder exportiert.
Nur bei Ahnenblatt blieb die INDI-Referenz erhalten. Alle anderen Programme haben neu nummeriert und aus @abc123@ wurde ein @I1@ bzw. @I0@ (letzteres nur MyFamilyTree).
Das ist das, was ich mit "Die INDI-Nummern in einer GEDCOM-Datei sind von der Sache her temporär." meinte. Außer Ahnenblatt scheint sich kaum ein anderes Programm diese INDI-Nummer zu merken.
Dass die Personen in der GEDCOM-Datei fortlaufend mit I1 ... Ix durchnummeriert sind und dann in der importierenden Software Datensatznummern 1 ... x erhalten mag vielleicht oftmals funktionieren, kann aber beim Löschen von Personen auch schon mal durcheinandergeraten.

Wenn ich das mit dem "Primärformat GEDCOM" richtig verstehe, meinst du ein Programm, das nur mit GEDCOM-Dateien arbeitet.
Da kenne ich als einziges Programm nur Ages!, das so verfährt. Und auch Ages! hat eine neue INDI-Referenz erzeugt (was mich persönlich überrascht hat).

RIN-Kennungen wurden überwiegend kommentarlos weggeschmissen. Nur Ahnenblatt, Ages! und MyFamilyTree haben diese wieder exportiert.

Mit welcher Software hast du Erfahrungen? Ist das Verhalten mit dieser Software anders?

Gruß, Dirk

Verfasst: **03.07.2024, 15:12**

DirkB hat geschrieben: ↑02.07.2024, 23:53 Vielleicht reden wir aneinander vorbei oder du meinst irgendetwas anderes ...

Das sollten wir das klären.

DirkB hat geschrieben: ↑02.07.2024, 23:53 Ich hänge hier mal eine GEDCOM-Datei an, die als INDI-Referenz @abc123@ nutzt ...
Code: Alles auswählen
0 @abc123@ INDI
Das ist GEDCOM-technisch in Ordnung - die Kennung muss nur innerhalb der GEDCOM-Datei eindeutig sein und mit einem Buchstaben beginnen.

Technisch naja, alle mir bekannten Programme nutzen das "I" ab Nummer 1 "0 @I1@ INDI" (Ausnahme später).
Lt. GEDCOM-Standard ist es erlaubt, der GEDCOM-Validator bemängelt es nicht.
Aber ich kenne adhoc kein Programm was so etwas "anrichtet".

DirkB hat geschrieben: ↑02.07.2024, 23:53 Ich habe die Datei mal auf die Schnelle mit 7 Genealogie-Programmen geöffnet bzw. importiert und wieder exportiert.
Nur bei Ahnenblatt blieb die INDI-Referenz erhalten. Alle anderen Programme haben neu nummeriert und aus @abc123@ wurde ein @I1@ bzw. @I0@ (letzteres nur MyFamilyTree).

Soviele Programme habe ich nicht mehr, bei mir kommt noch Ages! zum Einsatz, ja es nummeriert wie beschrieben (wie andere auch). Das unterstützt meine Meinung, dass man nicht alles tut, auch wenn es nicht verboten ist.

Das betrifft ebenso MyFamilyTree, der die Nummer einfach als enum von 0 zählen lässt.
Das verstehe ich nicht, da der Autor sonst den großen GEDCOM-Versteher gibt.
MyFamilyTree habe ich nicht nur deswegen verworfen, den GEDCOM-Export "kann man knicken".
MyFamilyTree ist eine ziemliche Einbahnstraße, wenn nach dem Export Verluste auftreten (z.B. nach Ages!) darf man sich nicht wundern.

DirkB hat geschrieben: ↑02.07.2024, 23:53 Das ist das, was ich mit "Die INDI-Nummern in einer GEDCOM-Datei sind von der Sache her temporär." meinte. Außer Ahnenblatt scheint sich kaum ein anderes Programm diese INDI-Nummer zu merken.

Wir reden hier davon, dass ein Programm GEDCOM exportiert und das andere es 1:1 importiert.
Wenn mit "diese INDI-Nummer" "0 @abc123@ INDI" gemeint ist, sehe ich das als Außenseiter-Meinung, die kein "Verdienst" ist.

DirkB hat geschrieben: ↑02.07.2024, 23:53 Dass die Personen in der GEDCOM-Datei fortlaufend mit I1 ... Ix durchnummeriert sind und dann in der importierenden Software Datensatznummern 1 ... x erhalten mag vielleicht oftmals funktionieren, kann aber beim Löschen von Personen auch schon mal durcheinandergeraten.

Ja klar, wenn Personen dazu kommen oder gelöscht werden ändert sich viel.
Wichtig ist dann, dass ein anderes Programm den GEDCOM-Export vernünftig importieren können.

DirkB hat geschrieben: ↑02.07.2024, 23:53 ...
Da kenne ich als einziges Programm nur Ages!, das so verfährt. ...
... auch Ages! hat eine neue INDI-Referenz erzeugt (was mich persönlich überrascht hat).

Ja, aber nur aus der vorgeschlagenen technisch möglichen Form (die ich mir sehr verkneifen würde).
Die Probleme aus den verschiedenen Interpretationen von GEDCOM-Details sind schon ausreichend genug.
Weitere "Sonderschnitze" sollte man sich einfach ersparen, wo es mit GEDCOM eh mehr stagniert denn voran geht.
Der 5.5.x Standard ist in meinen Augen immer noch der gemeinsame Nenner, auch wenn man manches heutztage anders löst.

Übrigens gibt es auch Ancestris als freies Genealogieprogramm, dass nur auf GEDCOM setzt.

Freilich kann man datenbankbasiert mehr anstellen, aber ich meine, dass ein kleinerer gemeinsamer Nenner im Austausch mehr Vorteile bringt.
Wenn man die jeweiligen Einschränkungen kennt, kann man oft auch ohne "Spezialitäten" auskommen.

DirkB hat geschrieben: ↑02.07.2024, 23:53 RIN-Kennungen wurden überwiegend kommentarlos weggeschmissen. Nur Ahnenblatt, Ages! und MyFamilyTree haben diese wieder exportiert.
...
Mit welcher Software hast du Erfahrungen? Ist das Verhalten mit dieser Software anders?

Daher halte ich von RIN nicht allzu viel, auch wenn mein Ages! es toleriert.
Ich habe mir die Frage noch nicht beantworten können, was ein anderes Programm auf Dauer mit externen RIN anstellen kann.
Meine Frau hatte mal für sich mit MyHeritage FTB angefangen und schleppte die MH: RIN lange Zeit sinnlos herum.

Doch zurück zu INDI, ich würde es als Kompatibilitätsgründen immer primär drinlassen und so verwenden / exportieren, dass es von der Mehrzahl der GEDCOM-Importer verstanden werden kann.

Gruß Jo301

Verfasst: **03.07.2024, 19:45**

Hallo Jo,

Jo301 hat geschrieben: ↑03.07.2024, 15:12 Wir reden hier davon, dass ein Programm GEDCOM exportiert und das andere es 1:1 importiert.

Ich aber nicht.
Für mich ist das Thema eine GEDCOM-Datei zu importieren und sie 1:1 wieder zu exportieren (also nahezu ohne Änderungen).
Ahnenblatt merkt sich dabei die INDI- und RIN-Nummern und kann die RIN-Nummer auch zur Anzeige bringen.
Der letzte Punkt war dir laut Ausgangsbeitrag sogar besonders wichtig.
Können andere Programme überhaupt INDI/RIN-Nummern anzeigen? Wohl nicht, da INDI-Nummern temporär erzeugt werden - also kein dauerhaftes Merkmal einer Person sind und RIN-Nummern in der Regel ignoriert werden.
Du hast mich jedenfalls bislang nicht vom Gegenteil überzeugt, also dass die INDI-Nummern nicht temporär sind.

Jo301 hat geschrieben: ↑03.07.2024, 15:12 Wenn mit "diese INDI-Nummer" "0 @abc123@ INDI" gemeint ist, sehe ich das als Außenseiter-Meinung, die kein "Verdienst" ist.

Das war ja nur ein (funktionierendes) Beispiel, um auf die Schnelle zu zeigen dass die INDI-Nummern beim Export von diversen Programmen immer wieder neu erzeugt werden.

Alternativ kannst du auch eine beliebige GEDCOM-Datei mit x Personen mit Ages! öffnen und wieder speichern, schaust mal nach, welche Person die @I1@ hat und löscht in Ages! diese Person. Dann wieder speichern und alle Personen haben eine neue INDI-Kennung (weil neu durchnummeriert ab @I1@). Also wenn das nicht temporär ist ...

Jo301 hat geschrieben: ↑03.07.2024, 15:12 Ja klar, wenn Personen dazu kommen oder gelöscht werden ändert sich viel.
Wichtig ist dann, dass ein anderes Programm den GEDCOM-Export vernünftig importieren können.

Wenn nur ein vernünftiger GEDCOM-Import wichtig ist, dann wäre eine Anzeige der INDI-Nummer im Programm nicht notwendig.
Ahnenblatt versucht halt, dass auch beim Löschen von Personen sich möglichst nichts ändert.
Eine Person, die die Kennung I1 hat, behält diese auch, selbst wenn Personen gelöscht werden oder Ages! die Datei zwischenzeitlich öffnet und wieder speichert.
Das wird erreicht in dem die Kennung bei der Anlage der Person in das RIN-Feld geschrieben wird. Von daher können INDI- und RIN-Nummer theoretisch auch schon mal auseinanderlaufen. Wenn ich es gewohnt bin, mich als Person immer unter I1 zu finden, dann wird das auch zukünftig klappen.

- Dirk

Verfasst: **04.07.2024, 18:44**

Hallo Dirk,

DirkB hat geschrieben: ↑03.07.2024, 19:45
Jo301 hat geschrieben: ↑03.07.2024, 15:12 Wir reden hier davon, dass ein Programm GEDCOM exportiert und das andere es 1:1 importiert.
Ich aber nicht. ...

ich denke, dass wir teilweise aneinander vorbeireden.
Mein Use Case ist wie folgt:

1.
Ich bearbeite eine GEDCOM-Datei multimodal, d.h. ich bediene mich aus bekannten Gründen mehrerer Programme, bis runter zum Texteditor.
Die Bearbeitung / Ergänzung / Korrektur erfolgt immer in der gleichen Kernanwendung.

2.
Ich validiere zyklisch die GEDCOM-Konformität (Validator).

3.
Ich benutze weitere Genealogie-Anwendungen mit ihren spezifischen Stärken, um Plausichecks auf Dubletten, erlaubte Zeitabstände etc. einzuschieben.

Iterativ werden diese 3 Schritte regelmäßig wiederholt, um in einem OFB-Projekt eine begleitende Qualitätssicherung zu erreichen.
Veränderungen finden nur im Schritt 1 statt.

Alles andere an Darstellungen enthält möglicherweise Missverständnisse und ist nicht relevant.

Wenn eines der Tools der Stufen 2 und 3 eine Neunummerierung vornehmen würde, wären die Prüfergebnisse nur schlecht zu verwerten.

Es ist aber so, dass Ahnenblatt die INDI-Nummer bei jedem neuen Import 1:1 als RIN (whatever) übernimmt und die Prüfergebnisse darauf bezieht, das ist gut und richtig so. Es treten demnach im Use Case keine temporären INDI-Nummern auf, was ansonsten natürlich immer mal der Fall ist.
Eine Diskussion darum ist nicht zielführend und bezwecke ich demnach nicht.

DirkB hat geschrieben: ↑03.07.2024, 19:45
Jo301 hat geschrieben: ↑03.07.2024, 15:12 Wenn mit "diese INDI-Nummer" "0 @abc123@ INDI" gemeint ist, sehe ich das als Außenseiter-Meinung, die kein "Verdienst" ist.
Das war ja nur ein (funktionierendes) Beispiel, um auf die Schnelle zu zeigen dass die INDI-Nummern beim Export von diversen Programmen immer wieder neu erzeugt werden.

Das ist ganz dumm gelaufen und erweckte bei mir den Eindruck, dass andere Programme regelmäßig eine Neunummerierung vornehmen.
Dabei ist die friedliche Koexistenz via GEDCOM zumeist gewährleistet, sofern man nicht INDI bei 0 als enum starten lässt.
Von solchen Schwein-Igeleien darf keine regulärer Import erwartet werden.

DirkB hat geschrieben: ↑03.07.2024, 19:45 Wenn nur ein vernünftiger GEDCOM-Import wichtig ist, dann wäre eine Anzeige der INDI-Nummer im Programm nicht notwendig.

Das ist ein Irrtum wenn man z.B. validiert, ein GEDCOM-Validator hat keine andere Referenz als INDI oder FAM.
Wenn Plausichecks (letztlich) INDI mit ausgeben (wie auch bei Ahnenblatt), ist es schon sehr "vorteilhaft", wenn man die INDI / referenzierte Person oder Familie direkt ansteuern kann.

DirkB hat geschrieben: ↑03.07.2024, 19:45 Ahnenblatt versucht halt, dass auch beim Löschen von Personen sich möglichst nichts ändert.
...

Der Ansatz ist gut, aber wie Du schreibst ein Versuch.

Ich würde mich einfach freuen, wenn Ahnenblatt bzgl. der (auch externen) Verwertung der Prüfergebnisse / einheitlicher Herangehensweise beim Goto (Name oder Nummer) für große Projekte noch flexibler wäre. Eine Umstellung auf Ahnenblatt breche ich nicht übers Knie.
Ich werde weiter über meine Beobachtungen berichten.

Danke und Gruß
Jo

Ahnenblattportal

Fehlende Anzeige der I-Nummer in Ahnenblatt4

Re: Fehlende Anzeige der I-Nummer in Ahnenblatt4

Re: Fehlende Anzeige der I-Nummer in Ahnenblatt4

Re: Fehlende Anzeige der I-Nummer in Ahnenblatt4

Re: Fehlende Anzeige der I-Nummer in Ahnenblatt4