Fehlende Anzeige der I-Nummer in Ahnenblatt4

[Jo301]

Gegenüber der Version 3 wird weder in der Baumansicht, noch bei "Bearbeiten-Gehe zu"
oder "Gemeinsamer Vorfahr" die INDI-Nummer angezeigt, z.B. [AB:I1234].

Ich arbeite mit einem großen Datenbestand und multimodal, d.h. es kommen verschiedene Tools zur Prüfung (z.B. GEDCOM-Validator) oder Visualisierung zum Einsatz. Das Austausch- oder Importformat wird daher immer GEDCOM bleiben.
Teils nutze ich auch einen Texteditor, um Korrekturen vor dem Import einfach zu bewerkstelligen. Dabei ist es einfach nach z.B @I1234@ zu suchen.

Bei den Prüfergebnissen aus dem GEDCOM-Validator ist ebenso die INDI- oder FAM-Nummer der Dreh- und Angelpunkt.
Daher fehlt mir die Anzeige der INDI-Nummer zu allererst.
Es wäre nicht notwendig [AB:I1234] zu schreiben, es ginge evtl. auch kürzer wie [I1234], [INDI1234] oder @I1234@.

Sehe ich das richtig, dass es keine Funktion Goto-INDI-Nummer gibt?

Gruß Jo301

[ahnenarmin]

Hallo Jo301,

das interne Personenkennzeichen kann in AB 4 ebenso wie in AB 3 angezeigt werden.
Du musst es nur aktivieren unter Extras > Optionen > Namensdarstellung

Gruß
Armin

[Jo301]

Hallo Armin,

danke, das funktioniert!
Ich war in den Optionen zuvor, hatte aber nicht bemerkt, dass mit "Internes Personenkennzeichen (RIN)" eigentlich der INDI-Tag aus GEDCOM gemeint ist. Hmmm... vielleicht könnte man das auch anders bezeichnen, dann wäre das klarer.

War das in der Version 3 per Default aktiviert?

Ich kenne den GEDCOM-Standard hinreichend gut, RIN ist nach Version 5.5+ eigentlich:
RIN <AUTOMATED_RECORD_ID>
A number assigned to a record by an originating automated system that can be used by a
receiving system to report results pertaining to that record.

RIN ist demnach nicht INDI und meine GEDCOM-Files enthalten kein RIN-Tag.
Offenbar übernimmt Ahnenblatt INDI aus GEDCOM als RIN, ohne ein Wort darüber zu verlieren.

Wie stehst Du zu der möglichen Funktion "Goto-INDI-Nummer" oder RIN, wie auch immer?

Meine Idee dazu:
Man müsste in der "Gehe zu"-Maske lediglich numerische Angaben machen können und diese als INDI/RIN interpretieren.
Bisher kommt dabei: "Die eingetragene Person ist nicht erkannt worden."
Oder gibt es dafür eine spezielle Eingabesyntax?

Gruß Jo301

[ahnenarmin]

Hallo Jo301,

die GEDCOM-Dateien enthalten doch für jede Person einen RIN-Tag:
Beispiel:
0 @I5@ INDI
1 RIN AB:I5

Für mich ist die RIN nur eine interne Nummer, die das Programm braucht um eine Person eindeutig zu identifizieren zu können auch für die Übergabe mit GEDCOM an andere Programme. Vergabe der Nummern erfolgt im Zuge der Erfassung der Personen. Somit sind die Nr. für den Anwender ohne großen Nutzen.
Interessanter ist für den Anwender die "benutzerdefinierte ID". Hier kann der Anwender nach eigenem System - frei definiert- ein Kennzeichen bzw. eine Kennnummer" für jede Person vergeben. Dann hat man ein System drin in dem man selsbst zurechtkommt. (z. B. KEKULE).

Gruß
Armin

[Fridolin]

Wieso du nicht nach der RIN suchen kannst, ist mir nicht klar. Laut Handbuch sollte das funktionieren:

AB 4.x Suche.jpg

Da kann man doch einstellen, dass man nach der RIN suchen will, oder? Und wenn du nur Ziffernfolgen eingibst, wird das Programm automatisch alle RIN anzeigen, die diese Ziffernfolge als Teil enthalten. Siehe Handbuch 4.0 S. 40f.

[Deleted User 8441]

Meine Idee dazu:
Man müsste in der "Gehe zu"-Maske lediglich numerische Angaben machen können und diese als INDI/RIN interpretieren.
Bisher kommt dabei: "Die eingetragene Person ist nicht erkannt worden."
Oder gibt es dafür eine spezielle Eingabesyntax?

Der ganze "Gehe zu"-Dialog ist meiner Meinung nach sehr rudimentär gestrickt und ich habe in der Vergangenheit auch schon mehrfach Ergänzungswünsche zum Filtern dazu geäußert. Dirk sieht hier aber scheinbar keinen Handlungsbedarf, obwohl auch andere Anwender hier, wie Du, Wünsche äußern. Ich denke mir, das Dirk sein Programm primär an Anfänger richtet und die arbeiten nicht wie Du, ich und viele Andere auch, mit mehreren Programmen, um die Lücken von Ahnenblatt anderweitig zu schließen. Den nur wer seine Daten auch extern bearbeitet benötigt die RIN.

@Fridolin, der "Gehe zu"-Dialog ist nicht suchen.

Gruß
Martin

[Fridolin]

@Fridolin, der "Gehe zu"-Dialog ist nicht suchen.

Stimmt. Aber mit der Option, die Suche mit der RIN-Nummer zu machen, ist es doch so gut wie ein Gehe zu..., oder?

[Deleted User 8441]

@Fridolin, der "Gehe zu"-Dialog ist nicht suchen.

Stimmt. Aber mit der Option, die Suche mit der RIN-Nummer zu machen, ist es doch so gut wie ein Gehe zu..., oder?

Hallo Fridolin, wie selbst oft schreibst, gibt es bei Ahnenblatt viele Wege um zum Ziel zu kommen. Ich persönlich verwende den "Gehe zu"-Dialog deutlich öfter als den Suchen-Dialog, da er auch direkter ist. Ein Arbeiten ohne Einschränkung der dort angezeigten Personen ist bei über 60.000 Eintragungen sehr erschwert. Das geht nur vernünftig bei wenig Personen aus einem Ort.

Gruß
Martin

[Jo301]

Hallo Armin,

...
die GEDCOM-Dateien enthalten doch für jede Person einen RIN-Tag:
Beispiel:
0 @I5@ INDI
1 RIN AB:I5

Dem ist nicht so, ich spreche jetzt mal nicht von Ahnenblatt, es ist eine OPTION.

Für mich ist die RIN nur eine interne Nummer, die das Programm braucht um eine Person eindeutig zu identifizieren zu können auch für die Übergabe mit GEDCOM an andere Programme. Vergabe der Nummern erfolgt im Zuge der Erfassung der Personen. Somit sind die Nr. für den Anwender ohne großen Nutzen.

Es ist nur für die Übergabe an andere Programme relevant, sofern ein Re-Import organisiert werden muss.
Das wird aber von der Palette von Programmautoren sehr wahrscheinlich nicht einheitlich gehandhabt oder sehr unterschiedlich interpretiert. Meine derzeitige Haupt-App hat GEDCOM als originäres Format und benutzt RIN nicht.

Für Spezialaufgaben habe ich einen eigenen GEDCOM-Parser, wenn es bei tausenden Personen diffizil wird und ich Dinge herausziehen will, wie alle Registernummern einer Quelle. Daher ist INDI der Dreh- und Angelpunkt, wie ich schon schrieb.

Interessanter ist für den Anwender die "benutzerdefinierte ID". Hier kann der Anwender nach eigenem System - frei definiert- ein Kennzeichen bzw. eine Kennnummer" für jede Person vergeben. Dann hat man ein System drin in dem man selsbst zurechtkommt. (z. B. KEKULE).

KEKULE etc. werden nur in Diagrammausgaben generiert, eine feste Vergabe ist allenfalls im kleinen Familienstammbaum möglich. Aber darüber sind wir alle hier doch weit hinaus.

Gerade dann ist der zielgenaue Zugriff über Name oder INDI lebensnotwendig.

Gruß Jo301

[Fridolin]

... Gerade dann ist der zielgenaue Zugriff über Name oder INDI lebensnotwendig.

Ich schätze mal, in diesem Satz steckt das Grundproblem.

Der Programmautor von Ahnenblatt geht davon aus, dass INDI für die programminterne Organisation notwendig ist und genau deswegen eben nicht von Nutzern zugreifbar sein soll. Was hindert dich daran, in Ahnenblatt über RIN zuzugreifen? Das verstehe ich nicht.

[Jo301]

... Gerade dann ist der zielgenaue Zugriff über Name oder INDI lebensnotwendig.

Ich schätze mal, in diesem Satz steckt das Grundproblem.

Der Programmautor von Ahnenblatt geht davon aus, dass INDI für die programminterne Organisation notwendig ist und genau deswegen eben nicht von Nutzern zugreifbar sein soll. Was hindert dich daran, in Ahnenblatt über RIN zuzugreifen? Das verstehe ich nicht.

Aus dem bisherigem Verlauf hier schlussfolgere ich, dass der Autor einfach die INDI nimmt und eine RIN draus macht... aha...
Das "Grundproblem" besteht darin, dass dies nicht ohne weiteres transparent wird, aber gut das wäre scheinbar geklärt.
Nur so erklärt sich [AB:I1234], aber sollte es dann in dieser Denke nicht lauten: [AB:R1234]?

Das andere Problem sind die parallelen Zugriffsmöglichkeiten per (beschränktem) "Goto" und "Suche". Ich selbst bevorzuge das "Goto", es ist ein Klick weniger und ergonomischer. Hier sollte der Autor mehr Flexibilität reinbringen, einen Vorschlag hatte ich gemacht.

Meine Anforderung lautet daher, dass man nach einem GEDCOM-Import fix auf INDI oder FAM zugreifen können sollte.
Ich arbeite an einem OFB-Projekt und prüfe nach bestimmten Abschnitten regelmäßig auf GEDCOM-Konformität, Widerspüche, Dubletten etc.
Für die Interoperabilität und Weitergabe ist der Standard GEDCOM und wird es bleiben, das sollte man im Hinterkopf behalten.

Dazu täte eine Klärung rund um INDI und/oder RIN gut.

[Deleted User 8441]

Wie die RIN erzeugt wird ist doch egal, wichtig ist nur sie ist eindeutig. Und wie INDI und RIN funktionieren ist doch auch eindeutig geklärt. Nur die Handhabung lässt zu wünschen übrig.

Gruß
Martin

[Fridolin]

... Nur so erklärt sich [AB:I1234], aber sollte es dann in dieser Denke nicht lauten: [AB:R1234]? ...

Da hat vermutlich jeder seine eigenen Gedanken. Mir leuchtet es ein, wenn aus einem Primärschlüssel für Individuen (INDI) eine RIN mit dem Inhalt AB:I1234 gemacht wird. Statt AB:F1234, wenn man den Primärschlüssel für Partnerschaften (FAM) nehmen würde (was natürlich Quatsch wäre).

Die Wünsche wird DirkB sich sicherlich gern angucken.

[Jo301]

Wie die RIN erzeugt wird ist doch egal, wichtig ist nur sie ist eindeutig. ...

Ganz egal ist das nicht, die Übernahme von INDI nach RIN und zurück muss eindeutig sein.
Darauf muss jegliche Software der Interoperabiltät wegen bauen können (nach Export und Re-Import).