Gedcom 5.5 und UTF-8

Hallo Stefan, liebe Mitleser,

ich schreibe hier als Programmnutzer, nicht als Programmautor - weil ich von der Listenbeschreibung auch davon ausgegangen bin, dass sich diese Liste an Nutzer richtet, nicht an Programmierer - dass diese hier auch präsent sind, ist sicher hilfreich.

Insofern geht es, lieber Hans Selbach, auch nicht ums Streiten, sondern um einen Austausch über Fragen im Zusammenhang mit genealogischer Software.

Offensichtlich gibt es unterschiedliche Auffassungen darüber - und das können wir nicht weiter klären, da scheint jeder seine Position zu haben -, ob die Spezifikationen von Gedcom 5.5 aus dem Jahr 1996 wörtlich zu lesen sind oder dem Sinn nach.

Mir ist durchaus bewusst, dass Unicode und UTF-8 nicht identisch sind, wobei aber "UTF-8 die am weitesten verbreitete Kodierung für Unicode-Zeichen" ist (UTF-8 – Wikipedia).

Im Jahr 1996 - da steckte ja selbst das Internet noch in den Kinderschuhen - war noch nicht absehbar, dass UTF-8 einmal eine Standard-Zeichencodierung sein würde.

Ja, in Gedcom 5.5 wird Unicode genannt und nicht UTF-8 - es erscheint mir aber aber einigermaßen einleuchtend, dass Programmierer dem Sinn der Festlegungen von 1996 nach auch UTF-8 als zulässig erachten. Es geht ja auch schlicht nicht anders, wenn man in einem Programm alle notwendigen Zeichen häufiger wie seltener Sprachen und Schriftsysteme zulassen will. Wie soll man codieren - wenn nicht in UTF-8?

Und natürlich kann man sich auf diesen Standpunkt stellen:

Wenn im Header also GEdcom 5.5 vorgegeben ist, aber CHAR UTF8 benutzt
wird, kann es sich nicht um eine korrekte Gedcomdatei handeln.

Aber ganz offensichtlich wird diese Auffassung nicht allgemein geteilt; TNG kombiniert 5.5 mit UTF-8, Heredis macht es auch so.

Peter Schulz schreibt gestern Abend in der gedcom-l: "Ein Blick auf eine Statistik bei genealogieonline.nl zeigt, dass bei annähernd 10.000 GEDCOM-Dateien sich 92% auf die GEDCOM-Version 5.5 beziehen und nur 4% auf die 5.5.1."

Ich nehme an, dass ein großer oder ganz überwiegender Teil dieser 10.000 Gedcom-Datei 5.5 gleichzeitig UTF-8 verwendet - also "nicht korrekt" wären im Sinne der buchstabengenauen Auslegung von Gedcom 5.5.

Aus meiner Sicht als Nutzer, dessen Interesse vor allem eins ist, nämlich dass sich Daten, die ich an Forscherkollegen weitergebe, problemlos exportieren und wieder importieren lasse, ist es allerdings sehr bedauerlich, wenn viele Programme in Deutschland (es scheint mir nach den Zahlen von Peter Schulz schon so etwas wie ein deutscher Sonderweg zu sein) eine Datei, die in der Struktur und Syntax Gedcom-5.5-konform ist, aber aus logischen Gründen UTF-8 verwendet, als "nicht korrekt" betrachten. Noch ärgerlicher ist es natürlich, wenn Spezifikationen von 5.5 nicht ordentlich eingelesen werden mit der Begründung, erwartet würde halt 5.5.1.

Ich würde hier davon ausgehen, dass der Entwickler Gedcom 5.5.1 kennt
(wegen UTF8) und dabei ist, seinen Export darauf umzustellen (warum
sonst sollte er UTF8 nutzen?).

Weil man viele Zeichen nur in UTF-8 darstellen kann.

Aber das mögen die Programmautoren entscheiden. Ich als Nutzer habe ein INteresse an einem reibungslosen Datenaustausch zwischen verschiedenen Programmen und würde mich wünschen, dass Kinkerlitzchen wie die Kombination von 5.5 und UTF-8 kein Hindernis darstellen würden.

Aber viel interessanter für mich ist die Frage nach der rein praktischen Erfassung von Quellentexten zu Ereignissen, wozu Du, Stefan, dankenswerterweise als einziger geantwortet hast. Vielleicht ist diese meine Frage etwas untergegangen.

Die Quellentexte in den Erläuterungen zu einer Quelle zu vergraben, erscheint mir für die Datenausgabe wenig hilfreich, wo ich doch die VOlltexte bei der Person stehen haben möchte. Aber vielleicht erfasst auch keiner außer mir solche umfassenderen Texte udn Erläuterungen.

Ich komme darauf gerne separat zurück, weil mir das schon eine zentrale Frage zu sein scheint.

Viele Grüße

TK

Hallo Tobias,
und ich antworte Dir in der Doppelrolle als Programmautor und Nutzer. Erst war ich Nutzer, dann mutierte ich auch zum Programmautor, um mir das zu schaffen, was ich selber in dem Bereich brauche.

Ich gebe Dir Recht: Es ist schon fast zweitrangig, ob nun UTF-8 in GEDCOM 5.5 erlaubt ist oder nicht. GEDCOM ist hoffnungslos veraltet, aber leider hat es bislang keiner geschafft, einen besseren Standard zu entwickeln (oder GEDCOM wirklich weiterzuentwickeln). UTF-8 ist heute die Standard-Kodierung, und es wäre völlig am Thema vorbei, wegen historischer Vorgaben in GEDCOM 5.5 diese Kodierung nicht zu nutzen. Die Welt hat sich weitergedreht, wir wollen nicht nur englische, sondern auch die Texte vieler europäischer und zunehmend auch außereuropäischer Staaten verarbeiten können.

GEDCOM ist veraltet - GEDCOM 5.5 noch mehr als GEDCOM 5.5.1. Deswegen finde ich Deinen Seitenhieb auf die Programme, die weiter gehen und die Möglichkeiten von GEDCOM 5.5.1 nutzen, und sogar diese noch weiterentwickeln, etwas befremdlich.

Nur mal so als Frage: Wie gibst Du in Deinem Programm den Rufnamen ein (nicht den Spitznamen, sondern den in offiziellen Dokumenten unterstrichenen Vornamen, der als Rufname gegenüber den anderen Vornamen der Person hervorgehoben wird)? Dafür bietet GEDCOM 5.5 keine Lösung, auch GEDCOM 5.5.1 nicht. Also hat die Gedcom-L und die darin versammelten Programmautoren sich vereinbart, wie dieses - konform zum Standard, einheitlich in den beteiligten Programmen, unter Verwendung des Nutzerdefinierten Kennzeichens _RUFNAME - über GEDCOM-Dateien ausgetauscht werden kann. Inzwischen steigen auch erste Programme des nicht-deutschen Sprachraumes mit ein. So werden neue Datenfelder austauschbar zwischen Programmen geschaffen.

Ich kenne keine andere Organisation, die sich um die Pflege und Anwendung des GEDCOM-Standards so gekümmert hat, wie die Gedcom-L. Und wir haben diese Ergebnisse auch in die FHISO eingebracht, wo zum ersten Mal aus meiner Sicht ein realistischer Ansatz läuft, einen - zu GEDCOM in den Versionen 5.5 UND 5.5.1 kompatiblen - neuen Standard zu entwickeln.

Aus meiner Erfahrung (und die ist aufgrund der Pflege mehrerer Datenbanken, die von Forschern mittels unterschiedlichster Programme gespeist wird, nicht ganz klein) scheitern die vollständigen Datentransfers vornehmlich an drei Dingen:
- am häufigsten am unterschiedlichen Funktionsumfang der Programme. GEDCOM (egal welcher Stand) ist so mächtig, dass es fast kein Programm gibt, welches das wirklich abbilden kann. Und jedes Programm hat da so seinen Ausschnitt, den es kann - und den Rest, den es nicht kann.
- dann daran, dass sehr viele Programme in der Interpretation des GEDCOM-Standards sehr großzügig sind, und eben ihre mehr oder weniger eigenen Sonderlösungen zu eigentlich standardisierten Wegen bauen - eins der Kernthemen in der Gedcom-L, wo wir zumindest unter den beteiligten Programmen aufgeräumt und viele Irrtümer beseitigt haben. Das beginnt schon bei so trivialen Themen wie dem Datumsformat, welches im GEDCOM-Standard ganz eindeutig vorgegeben ist. Sehr viele Programme pfeifen darauf, schreiben in ihren HEADer munter GEDCOM 5.5(.1) rein und exportieren alles Mögliche unter DATE, was da so auf keinen Fall zugelassen ist. Man hat sich einfach erspart, eine Transformation Nutzerüblicher Datumsangaben in die GEDCOM-Form zu machen. Peinlich nur, dass insbesondere das im angloamerikanischen Raum beliebte Datumsformat 2/3/2000 uns nun vor die Frage stellt, ob hier nun der 2. März oder der 3. Februar gemeint ist. Viele falsche Daten kommen allein aus dieser Verwechslung! Man findet es u.a. in den GEDCOM-Dateien - gegen alle Regeln des Standards.
- und drittens, aber fast noch schlimmer bei der Abstellung, durch die fast unendliche Kreativität, mit der Anwender ihre Daten in irgendwelche Datenfelder packen, nur nicht dahin, wohin sie gehören. Was ich alleine im Kennzeichen PLAC inzwischen alles schon gefunden habe (und was damit in der Ortsverwaltung aufschlägt), was mit Orten rein gar nichts zu tun hat, ist unglaublich. Besonders beliebt scheint BURI.PLAC zu sein, statt dem Begräbnisort bringt man hier alle möglichen Bemerkungen, Berufe, vollständige Abschriften von Quellenzitaten usw usw unter.

Ja, es ist nicht einfach, daraus dann eine stimmige, aus verschiedenen Quellen, Forschern, Programmen gespeiste Gesamtdatenbank zu machen, ohne alles noch einmal abzuschreiben. Die drei genannten Themen verlangen dazu viel Kreativität und noch mehr Zeit...

Was Deine Frage nach den Quellenangaben zu Bemerkungen betrifft:
a) als Nutzer halte ich es vorrangig so, dass ich zu einem Ereignis / Attribut (z.B. Beruf) eine oder mehrere zusammenfassende Bemerkungen mache, das Ereignis / Attribut mit entsprechenden Quellenangaben versehe, inkl. der Originalzitate aus den Quellen. Die (oft in unterschiedlichen Sprachen verfassten) Originalzitate gehören bei mir nicht in die zentrale Berichterstattung, sondern das daraus gebildete Konzentrat. Die Originalversion ist dann nachschlagbar (in den Fußnoten oder im Anhang, je nach Berichtsform), z.B. zur Verifikation. Daher brauche ich die Quellen zu Bemerkungen eigentlich nur dann, wenn ich in den Bemerkungen sehr unsichere Zuordnungen kommentiere, erläutere, wie ich trotz fehlender direkter Quellenaussagen zu bestimmten Schlüssen komme. Da kann man dann zu den einzelnen Bemerkungen die Quellen inkl. ihrer Originaltexte angeben; in neuerer Zeit habe ich meine Arbeitsweise dazu noch weiter umgestellt: Als erstes kommt die vollständige Erfassung der Quellenzitate inkl. der buchstabengetreuen Abschriften, erst danach werden die Personen und Familien zu jeweils einem Quellenzitat gebildet, und erst im letzten Schritt werden dann die Personen, die in mehreren Quellenzitaten genannt werden, zusammengeführt;
b) als Programmautor habe ich meinem Programm (GEN_DO!) die Quellenzitate unter den Bemerkungen spendiert. Aber ohne die theoretisch möglichen Schleifen: Die Bemerkungen, die selber schon in einem Quellenzitat oder einer Quelle stehen, können nicht noch einmal mit Quellenangaben versehen werden. Das wäre nach Standard auch noch möglich (der erlaubt Iterationen bis zur Ebenennummer 99 hin!!), aber auch mein Programm hat irgendwo Grenzen gesetzt. Aber OCCU.NOTE.SOUR z.B. ist problemlos möglich.

Was mich bei Quellenzitaten viel mehr umtreibt, ist der Umstand, dass ein Zitat meist an mehreren Stellen eingesetzt wird (bei einer Taufe z.B. beim Täufling, bei beiden Eltern, bei den Paten), aber im GEDCOM jedesmal in voller Länge wieder eingebaut wird. Das führt dazu, dass in den meisten Programmen das gesamte Zitat an jeder Stelle neu eingegeben werden muss - und eine nachträgliche Pflege dann natürlich sehr schwer ist. Das ist eines der Themen, die ich ganz weit oben auf meiner TODO-Liste stehen habe, hier das gesamte Quellenzitat (mit Ausnahme der Rolle der zitierten Person, die ist in der Regel für jede Person unterschiedlich) in einen Quellen-Zitat-Datensatz zu packen und den für alle aufrufenden Stellen einheitlich bearbeiten zu können. Und dann in den Berichten auch diese Quellenzitate nicht jedesmal wiederholen, sondern an zentraler Stelle ausgeben: Macht es wirklich Sinn, den Taufeintrag in einer Familie gleich dreimal auszugeben (bei Vater, Mutter und Täufling)?? Auch das spricht dagegen, die Quellenzitate in ihrer ganzen Länge (vor allem mit ihren Originaltexten) in die Bemerkungen der einzelnen Personen zu schieben!

Viele Grüße
Albert (Emmerich)

Ja, in Gedcom 5.5 wird Unicode genannt und nicht UTF-8 - es erscheint
mir aber aber einigermaßen einleuchtend, dass Programmierer dem Sinn der
Festlegungen von 1996 nach auch UTF-8 als zulässig erachten. Es geht ja
auch schlicht nicht anders, wenn man in einem Programm alle notwendigen
Zeichen häufiger wie seltener Sprachen und Schriftsysteme zulassen will.
Wie soll man codieren - wenn nicht in UTF-8?

Unicode bietet das ebenfalls. Es hätte gereicht.

Und natürlich kann man sich auf diesen Standpunkt stellen:

Wenn im Header also GEdcom 5.5 vorgegeben ist, aber CHAR UTF8 benutzt
wird, kann es sich nicht um eine korrekte Gedcomdatei handeln.

Es kann schon eine korrekte Gedcomdatei sein. Nach Gedcom 5.5.1.

Aber ganz offensichtlich wird diese Auffassung nicht allgemein geteilt;
TNG kombiniert 5.5 mit UTF-8, Heredis macht es auch so.

Das hat nichts mit Auffassung zu tun. Es ist halt fehlerhaft.

Aus meiner Sicht als Nutzer, dessen Interesse vor allem eins ist,
nämlich dass sich Daten, die ich an Forscherkollegen weitergebe,
problemlos exportieren und wieder importieren lasse, ist es allerdings
sehr bedauerlich, wenn viele Programme in Deutschland (es scheint mir
nach den Zahlen von Peter Schulz schon so etwas wie ein deutscher
Sonderweg zu sein) eine Datei, die in der Struktur und Syntax
Gedcom-5.5-konform ist, aber aus logischen Gründen UTF-8 verwendet, als
"nicht korrekt" betrachten. Noch ärgerlicher ist es natürlich, wenn
Spezifikationen von 5.5 nicht ordentlich eingelesen werden mit der
Begründung, erwartet würde halt 5.5.1.

Ich glaube, hier unterliegst Du einem Irrtum.
Zumindest für mich kann ich sagen, dass es meinem Import egal ist, ob
Gedcom 5.5 oder 5.5.1 geliefert wird. Ich bin bemüht, alle gelieferten
Informationen im Programm unter zu bringen.
Jeder Entwickler ist sicher daran interessiert, dass die Anwender
möglichst wenig Probleme beim Import haben. Da werden mitunter sogar
Sonderlocken für einzelne Programme eingebaut, die etwas völlig eigenes
im Export erzeugen.

Unsere Intention bei Gründung der Gedcom-Liste war (und ist), dass wir
beim Export alle etwas einheitliches exportieren und diese Daten beim
Import identisch behandeln.

Soltest Du also bei eine Import feststellen, dass irgendwelche Daten
nicht importiert werden, hast Du hier ein offenens Ohr. Die
Programmierer sindgut erreichbr und bemüht, Problem zu beheben. Egal ob
die Gedcomdatei sich in allen Punkten an den Standard hält. UTF-8 in
einer Gedcom 5.5 Datei ist da ganz sicher kein Hindernis.

Ich würde hier davon ausgehen, dass der Entwickler Gedcom 5.5.1 kennt
(wegen UTF8) und dabei ist, seinen Export darauf umzustellen (warum
sonst sollte er UTF8 nutzen?).

Weil man viele Zeichen nur in UTF-8 darstellen kann.

Geht genauso mit Unicode.

Aber das mögen die Programmautoren entscheiden. Ich als Nutzer habe ein
INteresse an einem reibungslosen Datenaustausch zwischen verschiedenen
Programmen und würde mich wünschen, dass Kinkerlitzchen wie die
Kombination von 5.5 und UTF-8 kein Hindernis darstellen würden.

Ist es nicht.
Ich wollte nur daruaf hinweisen, dass es merkwürdig ist, sich auf den
Standpunkt zu beziehen, dass man nach 5.5 exportiert und sich dann nicht
daran hält. Das finde ich inkonsequent.

Um das Thema Gedcom 5.5 mit UTF-8 zu beenden:
Niemand, der sich mit Gedcom ernsthaft auseinander gesetzt und
verstanden hat, wird UTF-8 für eine gültige Codierung in einer Gedcom
5.5 Datei ansehen. Ein Problem beim Import stellt das (die
Definitionsfrage; Programme, die intern UTF-8 nicht vollständig
unterstützen mag es noch geben) aber nicht dar.

Gruß, Stefan Mettenbrink.

Hallo Stefan, liebe Mitleser,

> Aber viel interessanter für mich ist die Frage nach der rein praktischen
> Erfassung von Quellentexten zu Ereignissen, wozu Du, Stefan,
> dankenswerterweise als einziger geantwortet hast. Vielleicht ist diese
> meine Frage etwas untergegangen.
Offensichtlich. Ich habe etwas gebraucht, da ich das nicht von Unterwegs
machen wollte. Das war zu umfangreich und ich musst auch erst nachsehen,
wie das exakt aussieht.
> Die Quellentexte in den Erläuterungen zu einer Quelle zu vergraben,
> erscheint mir für die Datenausgabe wenig hilfreich, wo ich doch die
> VOlltexte bei der Person stehen haben möchte. Aber vielleicht erfasst
> auch keiner außer mir solche umfassenderen Texte udn Erläuterungen.

Ich denke schon.
Das ist aber, wie erwähnt, kein Problem von Gedcom. Das ist ein Problem
der Darstellung von Daten im Programm.

Für mich gibt es ein Ereignis/einen Fakt, die Quellendaten (das
Dokument, dem ich die Information entnehme), die Quelle (wo diese
Information/das Dokument enthalten ist) und den Fundort (wo ich es
einsehen konnte). All das kann man genau so in Gedcom abbilden:

EVEN, SOURCE_CITATION, SOURCE_DESCRIPTION und REPO. Zusätzlich kann man
zu allem(?, schau ich jetzt nicht nach) eine Bemerkung NOTE hinzufügen.

Nach meinem Kenntnisstand (Ende letzten Jahres habe ich meinen
Gedcomexport dahingehend angepasst und diesbezügich nachgefragt) ist
diese Einteilung auch die Ansicht der übrigen Entwickler. Man möge mich
ggf. korrigieren. Dann habe ich es bislang falsch verstanden.

Wenn Du als Nutzer eine andere Vorgehensweise nutzen möchtest, ist das
Deine Entscheidung (die sicher auch abhängig von dem Möglichkeiten des
Programms ist).

Gruß, Stefan Mettenbrink.

Nur weil es alt ist, ist es nicht schlecht.
Gedcom bietet alle erforderlichen Möglichkeiten. Den einzigen
Kritikpunkt, den ich anbringen würde sind die ungeklärten
Doppeldeutigkeiten.

Ich weiß nicht, warum Du Gedcom als veraltet ansiehst.

Gruß, Stefan Mettenbrink.