Um mal wieder zur Gedcom-Frage von Torquatus zurückzukehren ...
Torquatus hat geschrieben:Ist das nun ein Fehler von Ahnenblatt oder sind alle anderen dooof?
Um das zu erklären muss ich ein klein wenig ausholen ...
Bei dem Status "unverheiratet" handelt es sich um die Kennzeichnung eines Ereignisses (Heirat), das nicht eingetreten ist.
Wie würde es z.B. bei einer Taufe aussehen ...?
Taufdatum und/oder -ort in einer Gedcom-Datei bedeutet "getauft".
Aber wenn diese Angaben fehlen, dann kann es sich um eine "ungetaufte" Person handeln oder die Daten sind schlichtweg nur nicht bekannt.
Hier ist der Gedcom-Standard also unvollständig - die Info "diese Person wurde nie getauft" lässt sich nicht darstellen.
Zurück zur Heirat ...
Eine Heirat wird in Gedcom z.B. so dargestellt:
Code: Alles auswählen
1 MARR
2 DATE 29 JUN 1871
2 PLAC Groß Schönfeld/Kreis Pyritz (Pommern)
Wie bei der obigen Taufe, wäre nun das Problem "unehelich" von "Ehedaten unbekannt" zu unterscheiden.
Für diesen Fall hat der Gedcom-Standard aber explizit folgendes vorgesehen:
... was dann soviel bedeutet wie "definitv verheiratet, aber weitere Daten unbekannt".
Somit wäre eigentlich alles klar, wenn man davon ausgeht, dass es sich bei fehlender MARR-Angabe um eine uneheliche Partnerschaft handelt.
Doch nun trifft Gedcom auf Realität ...
Es gibt einige Programme, die kennen den Status "unehlich" gar nicht und lassen selbst bei bekannten Ehen, bei denen allerdings Ort und Datum unbekannt sind, die MARR-Angabe komplett weg.
Ein importierendes Programm hätte gar keine Chance hier zu unterscheiden, was gemeint sein könnte, und macht den Fehler entweder in die eine (immer verheiratet) oder andere Richtung (immer unehelich).
Um hier wirklich eindeutig zu sein verwendet Ahnenblatt den Gedcom-Tag ...
Der führende Unterstrich markiert dabei ein "user-defined tag" und ist im Gedcom-Standard ausdrücklich erlaubt (Programme, die das nicht kennen überlesen es einfach).
Warum ich nicht "MARR" verwende ...?
Dieses erlaubt definitiv kein nachgeschobenes "N" (Bejahung mit "Y" erlaubt - Verneinung mit "N" allerdings nicht!). Daher eine eigendefinierte Abwandlung "_MARR", die dann standardkonform ist.
Somit müsste ich nur noch allen Genealogieprogrammierern dieser Welt mitteilen, dass ich mir ein neues Gedcom-Schlüsselwort ausgedacht habe und was es bedeutet ...
Dieses tat ich übrigens Ende 2005 in einer deutschsprachigen Mailingliste für Genealogie-Programmierer und erhielt einigen Zuspruch (Familienbande, Stammbaumdrucker, ...).
Ahnenblatt ist somit Gedcom-konform!
Wie sieht es nun mit der erwähnten Ages!-Variante aus ...
Sieht zwar komisch aus, würde ich aber zunächst mal auch als Gedcom-konform bezeichnen, wenn ...
... ja, wenn Ages! dieses so einlesen würde, wie es dort steht.
Statt dessen wird der Text "NOT MARRIED" interpretiert und beim Import verschwindet der Text und die Ehe hat den Status "unehelich".
Diese Art der Kennzeichnung wird im Gedcom-Standard mit keinem Sterbenswörtchen erwähnt und ist höchstwahrscheinlich von PAF übernommen worden (dieses macht es nämlich genauso).
Ahnenblatt importiert diese Variante wie vorgesehen korrekt als "unehelich". Andere Programme erkennen daraus eine Ehe mit dem Hochzeitsdatum "NOT MARRIED".
Entsprechend könnte man bei einer ungetauften Person nun das Taufdatum "NOT CHRISTENED" vorsehen ...
Was läge also näher als die Mormonen als die "Hüter des Gedcom-Standards" nach der korrekten Kennzeichnung von "unehelich" zu befragen ...?
Meine Anfrage diesbezüglich ergab, dass derzeit definitiv keiner mehr für den Gedcom-Standard zuständig ist! Nicht umsonst stammt die letzte offizielle Fassung aus dem Jahre 1995!
Der Gedcom-Standard lässt leider an einigen Stellen Interpretationen zu und beschreibt nicht alle möglichen Konstellationen (z.B. fehlen Rufnamen oder uneheliche Partnerschaften). Zudem muss man auch immer die vorhandene Programmrealität im Auge behalten. Was nützt die beste Gedcom-Konformität, wenn kein Programm die Daten nachher korrekt einlesen kann. Das zwingt zu Kompromissen ...
Um doch noch eine Lösung zu schaffen, werde ich mal den Programmierer von Ages! anschreiben, ob er nicht auch die Ahnenblatt-Kennzeichnung "_MARR N" beim Gedcom-Import berücksichtigen kann. Es ist ja nicht so, dass die Programmierer untereinander kein gutes Verhältnis hätten. Vielleicht finde ich ja ein offenes Ohr ...
Gruß, Dirk.
Dann wissen wir ja jetzt, welche beiden Entwickler die Keimzelle für die Weiterentwicklung des Gedcom-Standards sind 