Eingabe von Herat bzw. Trauung

[Dole]

Bei PAF läuft es so, wie es bis AB-Version ? gewesen ist.
Für ein Paar, bei dem keine Daten (Datum, Ort) bekannt sind wird zunächst automatisch eine Ehe angelegt.
Bei Trennung, Scheidung... klicke Scheidung an und kann dazu noch Daten (Datum, Ort) in das Feld Scheidung eintragen.

Bei mir sind es ca. als 1% der Verbindungen, die ausdrücklich nicht verheiratet waren.

Gruß Dole

[bjew]

Na ja, das liese sich vermutlich ganz leicht klären, wenn man wüsste, was in dem PAF-Export-Gut (Gedcom) drin steht .....
so ist man aber nur auf Vermutungen angewiesen

[Dole]

Anbei eine xls Datei. Ursprung ist PAF 5.2.18.

[bjew]

So, hab mir das jetzt nochmals angeschaut.
So wie es in der bereitgestellten Kopie des Gedcom-Ausschnittes ist es eigentlich nicht zulässig:

0 @F2@ FAM
1 _UID D4075AFC0160B341970E 8A65675DC907AE6F
1 HUSB @I1@
1 WIFE @I3@
1 CHIL @I6@
1 MARR hier fehlt Kennzeichen Y
2 DATE 3 Mar 1830

Dazu ist bei Gedcom-l unter F7 vereinbart (daran hält sich Ahnenblatt) GEDCOM/FAM-Tag

F7 Verheiratete und nicht verheiratete Partner, Status der Partnerschaft
Im Standard ist vorgegeben, dass die Aussage, dass zwei Personen verheiratet sind, in der Form

n MARR Y
ohne untergeordnete Kennzeichen exportiert werden kann. Nach den Regeln des Standards darf dies dagegen nicht durch ein

n MARR
ohne untergeordnete Kennzeichen erfolgen, da der Export leerer Kennzeichen ohne Folgezeilen unzulässig ist.

Der Standard untersagt explizit, die Aussage "die Personen sind nicht verheiratet" mit einem Negativargument statt des Y zu exportieren. Es wird daher für Programme, die intern Datenfelder wie "nicht verheiratet" oder "nie verheiratet" oder ein Datenfeld Status führen, vereinbart, ein Nutzerdefiniertes Kennzeichen _STAT direkt unter FAM einzuführen:

<STATUS_STRUCTURE> :=
n _STAT <STATUS_TEXT>
+1 DATE <DATE_VALUE> {0:1}
+1 <<PLACE_STRUCTURE>> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
_STAT kann folgende Werte annehmen:

<STATUS_TEXT> := [NOT MARRIED | NEVER MARRIED | UNKNOWN | <Klartext des Anwenders>]

Ich kann dein Problem vollständig nachvollziehen, es ist unangenehm und ich denke, dass dir da Dirk nicht mit einer Programmänderung weiterhelfen wird/kann ohne die Vereinbarung zu verlassen.

Ich kann dir aber insofern einen Tipp geben (wie in vorhergehendem Post schon hingewiesen).

Nimm einen geeigneten Editor - speziell PSPad oder vergleichbar und ändere mit Suchen/ersetzen/alle

1 MARR

durch

1 MARR Y


also in PSPad mit Häkchen "reguläre Ausdrücke", in anderen Editoren ähnlich

von
^1\tMARR\t\t$
in
1 MARR Y


Wie du schreibst, bleiben dann einige nicht verheiratete zum Nacharbeiten übrig

[Dole]

Moin Bernhard

Ich habe mich dazu entschlossen deinem Rat zu folgen.
PSPad habe ich installiert.

Habe es mit einem Test Gedcom versucht.
Es ändert sich aber nichts, wenn ich ihn anschließend mit AB öffne.
Vermutlich habe ich deine Anleitung:
1 MARR durch 1 MARR Y
zu ersetzen nicht richtig umgesetzt.

Gruß

[bjew]

schade.
Frage dann doch bitte direkt bei Dirk nach, evtl. hat er noch eine Lösung an der Hand. Seine E-Mail-Adresse findest hier im Portal oder seiner Homepage.

[Fridolin]

Tut mir leid, dass ich erst jetzt wieder einsteige - aber deinen Kommentar, Bernhard, verstehe ich nicht: Da fehlt aus meiner Sicht nichts für die Ehe des Paars, die beiden sind eindeutig verheiratet: MARR wird entweder mit Datum/Ort oder mit Y kombiniert, um die Ehe anzuzeigen. In diesem Fall ist doch das Datum in der Folgezeile vorhanden.

So, hab mir das jetzt nochmals angeschaut.
So wie es in der bereitgestellten Kopie des Gedcom-Ausschnittes ist es eigentlich nicht zulässig:

0 @F2@ FAM
1 _UID D4075AFC0160B341970E 8A65675DC907AE6F
1 HUSB @I1@
1 WIFE @I3@
1 CHIL @I6@
1 MARR hier fehlt Kennzeichen Y
2 DATE 3 Mar 1830

Es ist völlig unnötig, hier noch ein Y anzufügen (was ohne das Datum aber tatsächlich der korrekte Weg wäre).

Was mir mehr zu denken gibt, ist der "interessante" Umgang mit einem selbstdefinierten Ereignis bei den Einzelpersonen:
1 EVEN Mustermann
2 TYPE MARR

Was soll man darunter verstehen? Da gibt es keine weiteren Daten zur Ehe und auch kein Y. Was soll das? Würde mich wundern, wenn das standardkonform wäre.

[bjew]

@Frido,
genau das ist das, was mir auch Kopfzerbrechen machte. Könnte durchaus sein, dass das Dirks Konzept aus dem Konzept bringt &#55357;&#56839;.
Evtl. kann Dirk doch eine Sonderlocke finden, die auf PAF reagiert oder kennt einen geeigneten Konverter.

Noch eine Idee dazu, die mir aber ebenfalls Bauchschmerz bereitet:
da in diesem Falle auch mit Stammbaumdrucker experimentiert wird, was kommt raus, wenn das Gedcom von dort wieder exportiert wird, diesbezüglich bereinigt?

[bjew]

Tut mir leid, dass ich erst jetzt wieder einsteige - aber deinen Kommentar, Bernhard, verstehe ich nicht: Da fehlt aus meiner Sicht nichts für die Ehe des Paars, die beiden sind eindeutig verheiratet: MARR wird entweder mit Datum/Ort oder mit Y kombiniert, um die Ehe anzuzeigen. In diesem Fall ist doch das Datum in der Folgezeile vorhanden.

So, hab mir das jetzt nochmals angeschaut.
So wie es in der bereitgestellten Kopie des Gedcom-Ausschnittes ist es eigentlich nicht zulässig:

0 @F2@ FAM
1 _UID D4075AFC0160B341970E 8A65675DC907AE6F
1 HUSB @I1@
1 WIFE @I3@
1 CHIL @I6@
1 MARR hier fehlt Kennzeichen Y
2 DATE 3 Mar 1830

Es ist völlig unnötig, hier noch ein Y anzufügen (was ohne das Datum aber tatsächlich der korrekte Weg wäre).

Was mir mehr zu denken gibt, ist der "interessante" Umgang mit einem selbstdefinierten Ereignis bei den Einzelpersonen:
1 EVEN Mustermann
2 TYPE MARR

Was soll man darunter verstehen? Da gibt es keine weiteren Daten zur Ehe und auch kein Y. Was soll das? Würde mich wundern, wenn das standardkonform wäre.

heisst es nicht oben im 2 Dokument nicht, dass "n MARR" ohne Kennzeichen unzulässig sei? - lese ich das falsch.

Dazu kommt , dass es möglicherweise eine Sonderlocke für Mormonen ist, da die ja nur bedingt auf die formale Eheschließung setzen, sondern bei jedem Kind eine erneute / neue eheliche (eheähnliche?) Verbindung unterstellen

[hieberst]

Hallo zusammen,

jetzt will ich mich auch mal einmischen:

Meines Erachtens ist "n MARR" zulässig, da danach in einer Folgezeile ja das Datum der Heirat als untergeordnetes Kennzeichen folgt. Das macht AB genauso:

1 MARR
2 DATE 11 NOV 2008

LG Steffen

[Fridolin]

Wie ich schon versucht habe zu schreiben:

Nach
n MARR
erwartet GEDCOM eine weitere Angabe; das kann entweder eine weitere Zeile
n+1 DATE bzw.
n+1 PLAC
sein mit Datum und/oder Ort
oder direkt nach dem MARR ein einfaches Y für "yes".

Ein
n MARR N
ist nicht vorgesehen; für "nicht verheiratet" gibt es keine explizite Angabe. Ich finde aber
n _MARR N
für solche Fälle - das wäre dann eine benutzerdefinierte Aussage, die vielleicht manche Programme sinngemäß interpretieren.

[Dole]

Moin

Ich danke euch für die Unterstützung.

Anbei noch einmal der GedCom.

Das Problem sind die HEISE und MEIER Ehen (siehe in den Tafelausgaben).

Bei Paf kann eingestellt werden, wie diese Ehen Dargestellt werden.
SB verfügt über shr feine Einstellmöglichkeiten.

Ich glaube hier ist AB etwas über das Ziel hinausgeschossen.
Verbindungen aus älteren Programmen beim Import pauschal als getrennt darzustellen, ist nicht richtig.
AB stellt den tatsächlichen historischen Umstand des Vorhandenseins einer nicht geschiedenen und nicht getrennten Ehe falsch dar. Damit schreibt AB selbst einen historisch falschen Fakt in meinen Gedcom.
AB selbst gibt bei der Anlage neuer Familien eine Auswahl vor.
Beim Import sollte AB durch eine Einstellmöglichkeit dieses Problem lösen.

LG

[Joe60]

Hallo Dole,
wenn im letzten Beitrag tatsächlich der Inhalt der Gedcom aus PAF steht, frage ich mich, wie Ahnenblatt da eine Ehe erkennen soll. Es ist insgesamt nur einmal ein Eintrag mit dem Tag MARR vorhanden, aber eben nicht bei den Familien Heise und Meier. Wenn PAF beim Export keine Ehe kennzeichnet, kann AB doch auch keine erkennen.

[Dole]

Hallo Joe

Es ist nicht so, das die Beziehung nicht erkannt wird.

Es geht darum, dass AB diese Beziehung unbekannten Charakters von vornherien als "getrennt" ausgibt.
Das ist aus meiner Sicht als Familienforscher nicht richtig.
Mit einer Option beim Import wäre das Problem gelöst.

Gruß