welches Programm unterstützt welche Gedcom-Tags

[Markus]

Liebe Genealogen,

Gedcom ist ja ein genormtes Datei-Format.
Die meisten Genealogie-Programme arbeiten mit Gedcom (Import, intern,
Export).

Jedes Programm scheint aber eine andere Schnittmenge der Tags zu
benutzen...

Wo finde ich eine Matrix, in der die Schnittstellen definiert sind?
(welches Programm verarbeitet welche TAGs)

Gibt es einen "Standard hinter dem Standard Gedcom55",
der die Mindest-Schnittmenge beschreibt?

Mit herzlichem Gruss,
Markus

[Sigbert Helle]

Post by Markus
Gibt es einen "Standard hinter dem Standard Gedcom55",
der die Mindest-Schnittmenge beschreibt?

Daran anschließend die Frage an unsere GedCom-Experten:
Was macht eigentlich die XML-Version von Gedcom?
Ist die fertig?
Gibt es schon Gen-Programme, die sie benutzen?
Gibt es eine deutschsprachige Dokumentation dieses Standards?

Fragen über Fragen ...


Gruss

Sigbert

www.in-der-helle.de

[Stefan Mettenbrink]

Post by Sigbert Helle
Was macht eigentlich die XML-Version von Gedcom?
Ist die fertig?

Nein.
Wird sie wohl auch nicht :-(

Post by Sigbert Helle
Gibt es schon Gen-Programme, die sie benutzen?

Ja.

Post by Sigbert Helle
Gibt es eine deutschsprachige Dokumentation dieses Standards?

Nein.

MfG, Metti.

[Gerd Schmerse]

Post by Markus
Wo finde ich eine Matrix, in der die Schnittstellen definiert sind?
(welches Programm verarbeitet welche TAGs)

http://wiki-de.genealogy.net/wiki/GEDCOM-Test


Gruß
Gerd (Schmerse)

[Markus]

Hallo Gerd,

danke für den Link

Post by Gerd Schmerse
http://wiki-de.genealogy.net/wiki/GEDCOM-Test

Ich bin weder Genealoge, noch Datenbank-Spezialist - sondern simpler
Anwender.

Ich habe die Aufgabe übernommen, 3000 Ahnen aus einer Word-Datei nach
Gedcom zu überführen, für die weltweite Verbreitung innerhalb
unserer Familie und ggf. für die Forschung.

Nun gibt es zwar einen internationalen Standard "Gedcom55",
aber jeder scheint ihn in seinem Programm ziemlich willkürlich zu
verwenden.

Bei so viel Wildwuchs wird es doch wenigstens (so hoffe ich!) eine
Handvoll Genealogen geben, die sich auf einen "Standard hinter dem
Standard" einigen können?!

Wenn ich diesen wüsste - und welche Programme diesen auch verwenden -
dann könnte ich die 3000 Daten meiner alten Tante entsprechend
umstricken.

Und dann könnte jeder die Daten mit den diesem "Standard hinter dem
Standard" entsprechenden Programmen lesen, prüfen, korrigieren,
ergänzen - und sich weltweit daran erfreuen...

Ich mache mir gern die Mühe für meine Tante, unsere Familie und auch
für die Genealogie.

Aber ich habe weder Lust, einem "Standardisierungsgremium" beizutreten
(und mitzuarbeiten) noch die Datenstruktur mehrerer Programme zu
vergleichen (und schon gar nicht alle Programme zu installieren oder
gar zum "Programmtester" zu werden).
Das ist Aufgabe der Genealogen und der Programmentwickler.

Ich brauche eine Norm
und eine Auswahl von Programmen, die sie erfüllen.

Was also tun?

Mit herzlichem Gruss,
Markus

[Stefan Mettenbrink]

Post by Markus
Bei so viel Wildwuchs wird es doch wenigstens (so hoffe ich!) eine
Handvoll Genealogen geben, die sich auf einen "Standard hinter dem
Standard" einigen können?!

Leider scheint das nicht der Fall zu sein.
Ganz zu schweigen von den Fällen, wo die Programme unterschiedlich viele
Möglichkeiten haben.

Es gibt Gedcom 5.5EL. Das wurde als "Gemeinschaftsarbeit" von
Programmierern deutscher Genealogieprogramme erarbeitet. Es dient
überwiegend dem Zweck, bessere Möglichkeiten zu Ortsangaben machen zu
können.

Ich habe versucht, Informationen zur Darstellung von Adoptionen in
Gedcom zu erhalten. Du glaubts gar nicht, was da alles herauskommt.

Auch so vermeintlich einfache Erweiterungen wie Rufnamen sind schwere
Geburten. So ist die Variante, auf die man sin in Gedcom 5.5EL geeinigt
hat, nicht konform zu Gedcom 5.5 :-(

Post by Markus
Wenn ich diesen wüsste - und welche Programme diesen auch verwenden -
dann könnte ich die 3000 Daten meiner alten Tante entsprechend
umstricken.

Kannst Du vergessen.
Du kannst versuchen die Daten in das Programm Deiner Wahl einzupflegen.
Sobald Du die Daten über gedcom in angere Programme bringen möchtest,
erkennst Du die Unzulänglichkeiten des von Dir genutzen Programm, die
des importierenden Programm und die von Gedcom.

Post by Markus
Und dann könnte jeder die Daten mit den diesem "Standard hinter dem
Standard" entsprechenden Programmen lesen, prüfen, korrigieren,
ergänzen - und sich weltweit daran erfreuen...

Es gibt als einzigen verabschiedeten, öffentlich zugänglichen Standard
Gedcom 5.5 (vorherige versionen unberücksichtigt). Dieser ist von 1995!

Ob und wieweit irgendwelche Programme das unterstützen wissen allenfalls
die Programmierer.
Und da baut jeder nur das ein, was er für sein Programm braucht.

Post by Markus
Ich brauche eine Norm
und eine Auswahl von Programmen, die sie erfüllen.
Was also tun?

Es gibt nur Gedcom.
Du wirst Dich für ein Programm entscheiden müssen und hoffen, möglichst
spät auf Einschränkungen zu stoßen.

Alle die von Dir Daten haben möchten, müssen entweder mit den von Dir
gelieferten Daten leben oder dasselbe Programm nutzen.

Möglicherweise wäre für Dich
<http://www.phpgedview.net/de/about.php>
die richtige Wahl.

MfG, Metti.

[Friedrich Lehmkühler]

On 2 Jan 2006 04:22:41 -0800, "Markus"

Post by Markus
Ich brauche eine Norm
und eine Auswahl von Programmen, die sie erfüllen.

Hallo Markus,

die teilweise beklagenswerte Situation hast Du ja
mittlerweile beschrieben bekommen. Das ist _ein_ Grund,
warum ich nach wie vor mit PAF arbeite, obwohl einen
das eine oder andere Feature auch bei anderen
Programmen reizen könnte.

Bei PAF, so meine ich, habe ich aufgrund der
Urheberschaft und weltweiten Verbreitung die größte
Gewähr, dass dieses Programm und sein Dateiformat eine
gute Überlebenschance haben, während manches andere
Programm, das vom Enthusiasmus seines Entwicklers
und/oder dem wirtschaftlichen Erfolg einer im
Zweifelsfall eher recht kleinen wirtschaftlichen Basis
abhängt, immer zur Disposition steht. Ein solches
Programm käme für mich nur dann in Frage, wenn es die
Einhaltung eines klar, verbindlich und umfassend
definierten gemeinsamen Standard garantierte. Bei PAF
hat man nach heutigem Stand abseits aller GED-Klimmzüge
meines Erachtens die größte Gewähr für eine
langfristige Nutzbarkeit der Daten.

Solange die "kleinen" Hersteller nicht verstanden
haben, dass eines der wichtigsten Kaufargumente nicht
dieses oder jenes noch so tolle Alleinstellungsmerkmal
ist, sondern die Garantie für eine _umfassende_ und
_langfristige_ Nutzbarkeit aller erfassten Daten auch
nach einem (ja nicht völlig ausgeschlossenen)
Verschwinden des einzelnen Programmes vom Markt,
solange werde ich - unabhängig vom letztlich
zweitrangigen Preis - für die langfristige Haltung und
Verwaltung der Daten beim - zufällig kostenlosen - PAF
bleiben. Das muss nicht ausschließen, dass man für
bestimmte Spezialanwendungen (z.B. bestimmte Ausdrucke)
über die jeweils verfügbare Schnittstelle auch andere
Programme nutzt.

Solange aber nicht der Vatikan, die UNO oder die
Open-Souce-Gemeinde ein Konkurrenzprodukt zu PAF
vorlegen oder solange es keinen umfassenden und von
allen relevanten Anbietern anerkannten und
unterstützten GEDCOM-Standard gibt, bleibe ich deshalb
bei PAF, denn meine Daten sollen mich ja überleben.

Viele Grüße,
Friedrich

[Stefan Mettenbrink]

Post by Friedrich Lehmkühler
Solange die "kleinen" Hersteller nicht verstanden
haben,

...

Das habe die sicher verstanden. (ich zumindest)
Das Problem ist ganz einfach, dass mein Programm nicht alles kann
(ebenso PAF) und maches, was mit Gedcom nicht darstelbar ist, zusätzlich
bietet. Wie soll ich das exportieren können, wenn der Standard das nicht
hergibt? Oder beim Import. Wie soll ich etwas Importieren, das ich nicht
unterstütze? Ich kann z.B. die Templecodes nur in irgendeine Bemerkung
schreiben. Dann wird daraus nie wieder ein Tempelcode esportiert.

Dieses Problem hat auch PAF! So werden mit meinem Programm Rufnamen
exportiert und können auch impoertiert (und als solche erkannt) werden.
Es gibt auch andere Programme, die Rufnamen auf gleicer Weise erkennen.
Bei PAF gibt es IMHO keinen Rufnamen. Somit ist diese Information weg.

Das Problem sind meiner Meinung nach nicht die "kleinen Programme"
sondern die Unmöglichkeit, Daten untereinander zu tauschen, wenn keine
gemeinsame Schnittstelle existiert. Jedes Programm bietet halt manches
an, manches nicht.

Post by Friedrich Lehmkühler
Solange aber nicht der Vatikan, die UNO oder die
Open-Souce-Gemeinde ein Konkurrenzprodukt zu PAF
vorlegen oder solange es keinen umfassenden und von
allen relevanten Anbietern anerkannten und
unterstützten GEDCOM-Standard gibt, bleibe ich deshalb
bei PAF, denn meine Daten sollen mich ja überleben.

Dar Standard ist vorhanden. Er wird auch genutzt.
Je nach dem, welche Daten Du in PAF eingegeben hast, kann es durchaus
sein, dass Du gar keine Probleme mit dem Ex-/Import haben wirst.
Solange Du nur Daten eingibst, die in allen Programmen ohnehin
zwangsläufig vorkommen, hast Du kein Problem.
Probleme fangen erst an, wenn Du Quellenangaben in PAF eingibst und Dein
neues Programm nicht einmal die Eingabe von Quellenangaben vorsieht.

Diese Diskusion zeigt ganz deutlich, dass man sich erst seiner
Bedürfnisse, bezüglich der einzugebenden Daten, sicher sein muss. Danach
das Programm wählt und dabei bleibt (für die Dateneingabe und
-verwaltung). Für bestimmte Aufgaben kann man sicher andere Programme
zusätzlich nutzen.

Vergleiche den Umzug Deiner Daten mit dem Umzug in eine andere Wohnung.
Du wirst immer irgendwelche Möbel anders stellen müssen als in der alten
Wohnunng. Wenn die neue Wohnung weniger Platz hat, musst Du zwangsläufig
etwas wegwerfen. So brauchst Du z.B. den Kleiderschrank nicht mehr, weil
Du jetzt einen begehbahren Wandschrank hast.
Ziehst Du zurück in die alte Wohnung bleiben Stellen leer. Hattest Du in
der neuen Wohnung einen begehbaren Wandschrank, musst Du in der alten
wieder darauf verzichten. Leider ist der ehemals vorhandene
Kleiderschrank entsorgt worden.

Ähnlich ist das bei Gedcom.

MfG, Metti.

[Friedrich Lehmkühler]

Ja, Du hast sicher recht mit Deinen Einwürfen. Aber das
widerspricht ja nicht meiner Haltung, sondern stützt
sie letztlich. Die Quintessenz ist doch, dass GEDCOM
eben kein Standard ist, von mir aus auch nicht sein
kann, der alle (oder wenigstens viele) Programme
miteinander kompatibel macht.

Solange ich (oder irgendwann mein Enkel) mit den Daten
aus einem (irgendwann nicht mehr mit der dann üblichen
Hardware kompatiblen) Programm nicht ohne lange
Klimmzüge in ein dann angemessenes Programm umziehen
kann, bin ich eben beim Quasi-Standard PAF-Format am
besten aufgehoben, da die Wahrscheinlichkeit relativ
hoch ist, dass man dort ohne Datenverlust durch alle
noch kommenden Hardware- und OS-Modernisierungen
hindurchkommt. Und selbst wenn PAF eines Tages, aus
welchen Gründen auch immer, nicht mehr existieren
würde, wird es immer Konvertierungsmöglichkeiten für
die gigantischen PAF-basierten Datenbestände geben -
sub conditione Iacobi ;-)

Friedrich

[Stefan Mettenbrink]

Post by Friedrich Lehmkühler
Ja, Du hast sicher recht mit Deinen Einwürfen. Aber das
widerspricht ja nicht meiner Haltung, sondern stützt
sie letztlich. Die Quintessenz ist doch, dass GEDCOM
eben kein Standard ist, von mir aus auch nicht sein
kann, der alle (oder wenigstens viele) Programme
miteinander kompatibel macht.

Genau da bin ich anderer Meinung.
Gedcom ist eine offene Definition. Alle Programme die es unterstützen
können darüber Daten tauschen. Probleme die dabei auftreten liegen zum
Teil an den unzureichenden Möglichkeiten von Gedcom, zum Teil aber
daran, das die unterschiedlichen Programme nur jeweils eine Teilmenge
von Gedcom nutzen (eben den Teil, der für das jeweilige Programm
sinnvoll ist).

Du sieht das Programm, welchest Du nutzt als Maßstab. Mit welcher
Begründung? Jemand, der ein anderes Programm nutzt wird ebenso
argumentieren, PAF unterstützt ja dieses oder jenes nicht, ich kann
meine Daten gar nicht verlustfrei übernehmen.

PAF ist unbestritten ein gutes Genealogieprogramm mit vielen Funktionen.
Machen erschlägt es aber einfach.

Post by Friedrich Lehmkühler
Solange ich (oder irgendwann mein Enkel) mit den Daten
aus einem (irgendwann nicht mehr mit der dann üblichen
Hardware kompatiblen) Programm nicht ohne lange
Klimmzüge in ein dann angemessenes Programm umziehen
kann, bin ich eben beim Quasi-Standard PAF-Format am
besten aufgehoben, da die Wahrscheinlichkeit relativ
hoch ist, dass man dort ohne Datenverlust durch alle
noch kommenden Hardware- und OS-Modernisierungen
hindurchkommt. Und selbst wenn PAF eines Tages, aus
welchen Gründen auch immer, nicht mehr existieren
würde, wird es immer Konvertierungsmöglichkeiten für
die gigantischen PAF-basierten Datenbestände geben -
sub conditione Iacobi ;-)

Wenn Du meinst, in 15 Jahren hast Du noch Hardware, mit der Du CDs/DVDs
lesen kannst.

Wie sieht denn die Realität aus?

Du machst jetzt Genealogie, weil Du z.B. den Ahnenpass findest, den Dein
Opa angelegt hat. Der ist sicher 60 oder 70 Jahre alt. Dazwischen hat
sich niemand darum gekümmert. Wenn Du mal eine 8-Zoll Dikette in die
Hand bekommst oder eine Datenkassette vom C64 hast Du im Regelfall schon
Probleme die nötige Hardware zusammen zu bekommen. Solche Hardware ist
gerade 30 Jahre alt. Im Regelfall werden die Sachen entsorgt.

Ich gehe davon aus, dass Deine Enkel sich nicht die Mühe machen, in
Deinen Daten rumzustöbern, wenn sie nicht ohne Hlfsmittel ersichtlich
sind. Vermutlich wirst Du jemanden einweisen und für Dein Hobby
begeistern müssen oder die Daten sind in der derzeitigen Form verloren.
Es bleibt allenfalls die Möglichkeit, die Daten auszudrucken (was ich
nur empfehlen kann).
Wenn Du dann noch ein CD mit den Daten dazulegst und auf einem Zettel
dabeischreibst, was darauf zu finden ist, musst Du noch Glück haben,
dass die CD überstanden hat.

MfG, Metti.

[Gerd Schmerse]

Post by Friedrich Lehmkühler
Bei PAF, so meine ich, habe ich aufgrund der
Urheberschaft und weltweiten Verbreitung die größte
Gewähr, dass dieses Programm und sein Dateiformat eine
gute Überlebenschance haben,

Diese Argumentationslinie wird ja immer wieder für PAF und gegen
"Alleinentwickler" gebracht, aber so ganz einsichtig ist sie mir trotzdem
noch nicht geworden. Wenn das Programm, das ich seit einem Dutzend Jahren
nutze (also viele Daten eingegeben habe), jetzt das kann, was ich haben
will, dann kann es mir auch egal sein, ob es morgen vom Markt verschwindet.
(Zum Vergleich: zu meinen wichtigsten Programmen gehören immer noch die
DOS-Oldies WordStar 7.0 von 1992 und dBase III plus von 1987 - ich habe
keine Ahnung, ob es Unterstützung dafür oder die Hersteller selbst
überhaupt noch gibt) Nur wenn ich etwas anderes will, als mein Programm
macht, muß ich mich um Export überhaupt kümmern. Und mit bestehendem,
sicher nicht optimalem, Gedcom-Standard (und zusätzlich vielleicht noch
CSV-Listing, wie BK es kann) bekomme ich sicherlich auch knapp 100 % der
Daten wieder raus, die ich da reingegeben habe - da sollte man Dateiformat
und Austauschformat auch nicht zum allein selig machenden Kriterium
erheben.

Ich habe jedenfalls Gedcom noch nie wirklich gebraucht in all den Jahren -
höchstens mal zur Übergabe an Spezialprogramme wie DftCom2, Gedcom2Map oder
Stammbaumdrucker, die dann auf die paar exotischen Daten, die eventuell
nicht gedcom-kompatibel ausgegeben werden können, sowieso verzichten
können.


Gruß
Gerd (Schmerse)

[Stefan Mettenbrink]

Post by Gerd Schmerse
Wenn das Programm, das ich seit einem Dutzend Jahren
nutze (also viele Daten eingegeben habe), jetzt das kann, was ich haben
will, dann kann es mir auch egal sein, ob es morgen vom Markt verschwindet.
(Zum Vergleich: zu meinen wichtigsten Programmen gehören immer noch die
DOS-Oldies WordStar 7.0 von 1992 und dBase III plus von 1987 - ich habe
keine Ahnung, ob es Unterstützung dafür oder die Hersteller selbst
überhaupt noch gibt) Nur wenn ich etwas anderes will, als mein Programm
macht, muß ich mich um Export überhaupt kümmern

Einen wesentlichen Punkt übersiehst Du hier aber.
Wenn es den Hersteller nicht merh gibt oder er die Entwicklung
einstellt, kann es mit der nächsten Version Deines Betriebssystems
unmöglich sein, Dein Programm weiter einzusetzen. Das würde mich schon
sehr stören.

MfG, Metti.

[Gerd Schmerse]

Post by Stefan Mettenbrink
Wenn es den Hersteller nicht merh gibt oder er die Entwicklung
einstellt, kann es mit der nächsten Version Deines Betriebssystems
unmöglich sein, Dein Programm weiter einzusetzen.

Im Prinzip richtig - nur: wenn sogar heute noch DOS-Programme laufen, wird
es nicht künftig sogar wahrscheinlicher sein, ein Windows-Programm von
heute (von denen es sicher inzwischen mehr gibt) noch zum Laufen zu
bringen?


Gruß
Gerd (Schmerse)

[Stefan Mettenbrink]

Post by Gerd Schmerse

Post by Stefan Mettenbrink
Wenn es den Hersteller nicht merh gibt oder er die Entwicklung
einstellt, kann es mit der nächsten Version Deines Betriebssystems
unmöglich sein, Dein Programm weiter einzusetzen.

Im Prinzip richtig - nur: wenn sogar heute noch DOS-Programme laufen, wird
es nicht künftig sogar wahrscheinlicher sein, ein Windows-Programm von
heute (von denen es sicher inzwischen mehr gibt) noch zum Laufen zu
bringen?

Sehe ich noch nicht. Was alles mit Vista machbar und bewusst
verhinderbar wird, ist noch nicht abzusehen.

Das Problem ist, über welchen Zeitraum reden wir? Alles was Du nutzt,
kannst Du ggf. konvertieren. Bleiben die Daten aber lange liegen (20
Jahre) dann sind sie wohl in den meisen Fällen verloren :-(

MfG, Metti.

[Friedrich Lehmkühler]

On Sat, 07 Jan 2006 12:59:23 +0100, Gerd Schmerse

Post by Gerd Schmerse

Post by Friedrich Lehmkühler
Bei PAF, so meine ich, habe ich aufgrund der
Urheberschaft und weltweiten Verbreitung die größte
Gewähr, dass dieses Programm und sein Dateiformat eine
gute Überlebenschance haben,

Diese Argumentationslinie wird ja immer wieder für PAF und gegen
"Alleinentwickler" gebracht, aber so ganz einsichtig ist sie mir trotzdem
noch nicht geworden. Wenn das Programm, das ich seit einem Dutzend Jahren
nutze (also viele Daten eingegeben habe), jetzt das kann, was ich haben
will, dann kann es mir auch egal sein, ob es morgen vom Markt verschwindet.

Solange Du noch eine Hardware und ein Betriebssystem
vorhältst, die damit etwas anfangen können, mag das
stimmen. Zukunftssicherheit ist allerdings etwas
Anderes. Oder werden Deine Enkel, selbst wenn sie
können, immer noch mit Deinem alten Programm erbeiten
wollen?

Post by Gerd Schmerse
(Zum Vergleich: zu meinen wichtigsten Programmen gehören immer noch die
DOS-Oldies WordStar 7.0 von 1992 und dBase III plus von 1987 - ich habe
keine Ahnung, ob es Unterstützung dafür oder die Hersteller selbst
überhaupt noch gibt) Nur wenn ich etwas anderes will, als mein Programm
macht, muß ich mich um Export überhaupt kümmern.

Nichts gegen WordStar und dBase III, aber gehe mal noch
weiter zurück. Mit Daten auf Hollerith-Karten,
TTY-Lochstreifen, HP- oder TI-Magnetstreifen kämst Du
heute schon ins Schwitzen, und das haben wir doch
selbst noch alles erlebt! Textverarbeitung und
Datenspeicherung auf Computern betreibe ich selbst seit
den 1980er Jahren. Ich habe mir nicht gemerkt, wie oft
ich manche Texte und Daten zwischenzeitlich
konvertiert habe, um sie nicht zu verlieren. Und wenn
die Daten mal zehn, fünfzehn Jahre unkonvertiert liegen
blieben, weil sich vorübergehend niemand dafür
interessierte, dann käme wieder jemand ins Schwitzen,
wenn die Zukunftssicherheit nicht bedacht worden wäre.
Und wenn wir mal kurz wieder ans Urpsrungsposting
denken, dann erscheint genau dieses Szenario für die
3000-Tanten-Datensätze des Nicht-Genealogen Markus gar
nicht so unwahrscheinlich. Deshalb bleibe ich dabei,
PAF zu empfehlen.

Post by Gerd Schmerse
Und mit bestehendem,
sicher nicht optimalem, Gedcom-Standard (und zusätzlich vielleicht noch
CSV-Listing, wie BK es kann) bekomme ich sicherlich auch knapp 100 % der
Daten wieder raus, die ich da reingegeben habe - da sollte man Dateiformat
und Austauschformat auch nicht zum allein selig machenden Kriterium
erheben.

Das hat niemand getan. Ich darf mich ausnahmsweise
selbst zitieren: "Das ist _ein_ Grund,
warum ich nach wie vor mit PAF arbeite [...]"
(Hervorhebung auch im Original)

Post by Gerd Schmerse
Ich habe jedenfalls Gedcom noch nie wirklich gebraucht in all den Jahren -
höchstens mal zur Übergabe an Spezialprogramme wie DftCom2, Gedcom2Map oder
Stammbaumdrucker, die dann auf die paar exotischen Daten, die eventuell
nicht gedcom-kompatibel ausgegeben werden können, sowieso verzichten
können.

Da stimme ich Dir zu.

Viele Grüße,
Friedrich

[Gerd Schmerse]

Post by Friedrich Lehmkühler
Und wenn
die Daten mal zehn, fünfzehn Jahre unkonvertiert liegen
blieben, weil sich vorübergehend niemand dafür
interessierte, dann käme wieder jemand ins Schwitzen,
wenn die Zukunftssicherheit nicht bedacht worden wäre.

Heutiges Gedcom *und* CSV, das ich ja auch nannte, sollte ohne allzugroßes
Schwitzen nutzbar sein, und wenn ein bißchen Nacharbeit nötig ist, weil
dies nur 99 % der Information umfaßt, dann ist das ja auch nicht zuviel
verlangt. Den Rest findet man dann hoffentlich in den veröffentlichten
Daten (also gedruckt) - das sollte man auf keinen Fall vergessen, sonst ist
nämlich vielleicht auch 100 % weg... ;-))


Gruß
Gerd (Schmerse)

[Stefan Mettenbrink]

Post by Friedrich Lehmkühler
Und wenn wir mal kurz wieder ans Urpsrungsposting
denken, dann erscheint genau dieses Szenario für die
3000-Tanten-Datensätze des Nicht-Genealogen Markus gar
nicht so unwahrscheinlich. Deshalb bleibe ich dabei,
PAF zu empfehlen.

Du wirst mit PAF die gleichen Probleme bekommen. Oder welches aktuelle
Programm kann heute noch Dateien (die nicht nur ASCII sind) noch lesen.
Gerade PAF ist nicht gleich Gedcom! Im Regelfall ist die PAF-Datei nicht
mit einem Texteditor lesbar.

Du wirst in 20 Jahren mit PAF die Gleichen Probleme haben wie mir
Dateien aller anderen Programme. Di Probleme werden mit Gedcomdateien
von PAF ebenfalls dieselben Probleme sein, wie mit Gedcomdateien anderer
Programme.

Meine Meinung, Du darfst Diene ruhig behalten :-)

MfG, Metti.

[clemens pongratz]

Post by Gerd Schmerse
(Zum Vergleich: zu meinen wichtigsten Programmen gehören immer noch die
DOS-Oldies WordStar 7.0 von 1992 und dBase III plus von 1987 - ich habe
keine Ahnung, ob es Unterstützung dafür oder die Hersteller selbst
überhaupt noch gibt)

Hallo Gerd,

ich bin mit dir vollkommen einer Meinung, wenn ein Programm fehlerfrei
und zu meiner Zufriedenheit läuft, gibt es keinen Grund alle paar Jahre
einen Systemwechsel zu machen.
Ich habe durch die neuen PCs zusammen mit den alten Programmen einen
rasanten Geschwindigkeitsfortschritt geniesen können.
Bei einem Datenbestand von zZ. 330.000 Personennamen und Indizierungen
in alle möglichen Richtungen gehen meiner Erfahrung nach alle
Windowsprogramme in die Knie, im MSDOS Fenster mit einem nur mässig
neuen PC geht das ruck-zuck.
Hinzu kommt noch die sehr leichte Programmierbarkeit von Dbase, das mir
erlaubt noch im Archiv bei Bedarf schnell eine neue Unterroutine zu
tippen, wenn ich eine benötige.
Und dann können sowohl Excel als auch Access alle Dbaseformate
importieren, damit sollte die Übertragbarkeit für längere Zeit
gewährleistet sein.
Das Problem, welches Interesse und Detailwissen die nachfolgenden
Generationen haben, kann so oder so nicht gelöst werden.

Zum Originalposter:
ich habe mir vor Jahren eine Routine geschrieben um einen Gedcomimport
aus Dbase hinüber zu GF-Ahnen zu ermöglichen, die Übertragung der
Standarttags war problemlos, trotzdem mußte ich einige/Viele Daten
nachtragen, weil ich in meinem Datenbestand weniger erfasst hatte, als
GF-Ahnen speichern wollte und ich in meinen schriftlichen Unterlagen
hatte. Dies stammte noch aus der Zeit als in den 80er Jahren der
Speichplatz knapp und teuer war und zur leichteren Bearbeitungen von mir
nur die wichtigsten Daten abgelegt worden waren.
In der Umstellungsphase hatte ich von PAF bis BK, Legacy und noch zwei
drei andere Programme testweise ausprobiert und bin dann bei GF-Ahnen
gelandet. Ein Programm sehr komplex mit einer sehr aktiven und
engagierten Benutzerschar, das nun im März ein jährliches Update erfährt.
Um keinen WIderspruch zum obig geschriebenen zu haben. Es gibt im
Bereich der Familien und Heimatforschung so viele Spezialanwendungen,
dass man wahrscheinlich das EINE Programm kaum finden wird, auch für den
Datentransfernicht.
Um ein Beispiel zu geben wird im GF-Ahnenforum derzeit heiß die Art der
Quellenbearbeitung diskutiert, die im Prinzip eine wissenschaftliche
Veröffentlichung möglich machen würde. So etwas gibt es im GEDCOM nicht.
In vielen Programmen sind die Genealogen viel viel weiter, als es die
Standartersteller sich damals vorstellen konnten
mfg

[Stefan Mettenbrink]

Post by Markus
Jedes Programm scheint aber eine andere Schnittmenge der Tags zu
benutzen...

Leider :-(
Liegt ganz einfach an den Möglichkeiten der Programme.

Post by Markus
Wo finde ich eine Matrix, in der die Schnittstellen definiert sind?
(welches Programm verarbeitet welche TAGs)

Nirgends.
Nur die Tags aufzulisten hift auch nicht, da die Tags in
unterschiedlichen Strukturen auftauchen können.
So kann NOTE zwar generell erkannt werden, wenn aber das Ereignis im
Programm nicht vorgesehen ist, wird die NOTE zu diesem Ereignis nicht
berücksichtigt.

Post by Markus
Gibt es einen "Standard hinter dem Standard Gedcom55",
der die Mindest-Schnittmenge beschreibt?

Nein.

MfG, Metti.

[Bjoern Thomsen]

Hallo,

Post by Markus
Gedcom ist ja ein genormtes Datei-Format.

Naja. Nennen wir es Quasistandard.

Post by Markus
Die meisten Genealogie-Programme arbeiten mit Gedcom (Import, intern,
Export).
Jedes Programm scheint aber eine andere Schnittmenge der Tags zu
benutzen...

Was ich ganz natürlich finde. Alle Programme wären sonst gleich. Es
gäbe keine neuen Ideen, wenn alles nur auf GEDCOM basieren würde.

Post by Markus
Wo finde ich eine Matrix, in der die Schnittstellen definiert sind?
(welches Programm verarbeitet welche TAGs)

Selbst erstellen. Besorge Dir alle Programme. Finde die Gemeinsamkeiten
und Unterscheidungen. Liste Deine Ergebnisse in einer Tabelle. Die Welt
wird es Dir danken.

Post by Markus
Gibt es einen "Standard hinter dem Standard Gedcom55",
der die Mindest-Schnittmenge beschreibt?

Nein. Wenn GEDCOM55 "Dein" Standard ist, so ist er auch "Deine"
Schnittmenge. Mit einer "Mindestschnittmenge" bist Du sicher nicht
zufrieden.

In diesem Thread wurde bisher viel über "Haltbarkeit" gesprochen.

Vor einigen Jahren wurde mal Tesa-Film als das Speichermdium der Zukunft
voraussagt. Ist das eigentlich schon marktreif? Egal.

Richtig sicher vor Verfall scheint mir nur Mikrofilm zu sein.

Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.

Nun werden viele sagen: XML kann ich nicht, mein Programm kann XML nicht.
Stimmt! Aber es besteht keine Eile. XML kommt. Ganz sicher.

Das Programm GRAMPS (http://gramps-project.org/) setzt schon länger auf
das XML-Format. Es importiert GEDCOM- und GeneWeb-Dateien. Export nach
GEDCOM, GeneWeb, vCard, vCalender, Web Family Tree und XML ist IMO kein
Problem. Desweiteren erstellt GRAMPS Berichte in Formaten wie OpenOffice,
LATEX, HTML, AbiWord, PDF, RTF. Allerdings läuft GRAMPS nur unter Linux,
BSD oder Solaris. Also Pech f. die Windowsanwender.

GRAMPS ist OpenSource. Jeder kann seine Ideen einbringen. Ob er/sie jetzt
Programierer ist oder nicht, ist nebensächlich. Die Erfahrung vieler
Genealogen kann dazu beitragen, dass dieses Programm eines Tages wirklich
alle Aspekte der Forschung abdecken kann.

Gruß, Björn
--

[Stefan Mettenbrink]

Post by Bjoern Thomsen
Richtig sicher vor Verfall scheint mir nur Mikrofilm zu sein.

Auch nicht unbedingt. So hat man festgestellt, das ältere Materialien
dazu neigen sich zu zersetezen. Mittlerweile hat man das wohl im Griff,
da man sogar auf staatlicher Seite in irgendeinem Stollen hunderte
versiegelter Spezialbehälter einlagert, die "überdauernswerte"
Informationen auf Microfilm enthalten.

Post by Bjoern Thomsen
Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.

Welchen Vorteil bietet XML gegenüber Gedcom?
Es gibt, meiner Kenntnis nach, keine gültige Definition.

MfG, Metti.

[Detlev E. Deipenau]

On Sun, 8 Jan 2006 06:58:33 +0100, Stefan Mettenbrink

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Richtig sicher vor Verfall scheint mir nur Mikrofilm zu sein.

Auch nicht unbedingt. So hat man festgestellt, das ältere Materialien
dazu neigen sich zu zersetezen. Mittlerweile hat man das wohl im Griff,
da man sogar auf staatlicher Seite in irgendeinem Stollen hunderte
versiegelter Spezialbehälter einlagert, die "überdauernswerte"
Informationen auf Microfilm enthalten.

Post by Bjoern Thomsen
Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.

Welchen Vorteil bietet XML gegenüber Gedcom?
Es gibt, meiner Kenntnis nach, keine gültige Definition.
MfG, Metti.

Hallo Leute.

Eure Suche nach einem Programm oder Medium, dass genealogische
Datensammlungen dauerhaft haltbar machen kann, in allen Ehren,
aber....
eine aller Wahrscheinlichkeit nach eintretenden Verschlechterung des
Ist-Zustand des Raumschiff Erde vorausgesetzt, wird es in spätestens
100 Jahren weder möglich, noch nötig sein, überhaupt irgendwelche
Daten konservieren zu müssen. Ganz bestimmt aber keine Daten, die die
Familiengeschichtliche Aufarbeitung von Mayer, Müller, Schulz
....Deipenau, etc. zum Inhalt haben.

Schwacher Trost: Wir kriegen das nichtmehr mit.

MfG
Detlev E.

[Bjoern Thomsen]

Hallo,

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Richtig sicher vor Verfall scheint mir nur Mikrofilm zu sein.

Auch nicht unbedingt. So hat man festgestellt, das ältere Materialien
dazu neigen sich zu zersetezen.

Und Papier zersetzt sich nicht?

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.

Welchen Vorteil bietet XML gegenüber Gedcom?

Einfacher und klarer strukturiert.
Flexibler.
Genealogiedaten im XML-Format können auch von nicht-Genealogieprogrammen
angezeigt werden. Beisplw. Tabellekalkulationen, Texteditoren,
Grafikprogrammen.

Post by Stefan Mettenbrink
Es gibt, meiner Kenntnis nach, keine gültige Definition.

Was heisst schon gültige Definition?

Allgemein:
http://de.selfhtml.org/xml/intro.htm
http://de.wikipedia.org/wiki/XML

Genealogie:
http://xml.coverpages.org/genealogy.html

Gruß, Björn
--

[Stefan Mettenbrink]

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Auch nicht unbedingt. So hat man festgestellt, das ältere Materialien
dazu neigen sich zu zersetezen.

Und Papier zersetzt sich nicht?

Sicher.
Wenn ich aber höre, das Filmrollen (jetzt nicht direkt Microfilme)
bereits nicht mehr abspielbar sind, wie sie bei Berührung zerfallen,
deutet das auf eine deutlich kürzere Haltbarkeit hin. Wie auch immer,
wie lange Papier hält ist bekannt. Die Haltbarkeit von Microfilem muss
sich noch zeigen. Wir werden es wohl nicht erleben.

Post by Bjoern Thomsen
Einfacher und klarer strukturiert.

Hilft nicht.

Post by Bjoern Thomsen
Flexibler.

Stört ebenfalls eher, da schon heute nur eine Teilmenge der Daten bei
einem Wechsel zu einem anderen Programm "überlebt". Wenn dann das
Austauschformat noch flexibler ist, bekommen wir nur mehr Wildwuchs.
Meine Meinung.

Post by Bjoern Thomsen
Genealogiedaten im XML-Format können auch von nicht-Genealogieprogrammen
angezeigt werden. Beisplw. Tabellekalkulationen, Texteditoren,
Grafikprogrammen.

Das ist ein Argument, über das sich reden läßt.

Ich kenn mich in der materie XML nicht sonderlich aus.
Was für Vorteile hätte ich, wenn ich eine solche XML-Datei in eine
Tabelenkalkulation übernehme (was ich auch mit CSV-Dateien kann)?
Was soll ich mit Genealogischen Daten (mehrerer(?) Personen) in einem
Texteditor?
Was kann ein Grafikprogramm mit diesen Daten?

Ich kann nachvollziehen, das XML *eine* Möglichkeit wäre, die Daten zu
sichern. Den Vorteil gegenüber Gedcom sehe ich derzeit nicht. Das kann
aber durchaus an meiner Unkenntnis liegen, dann würde ich gern
dazulernen.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Es gibt, meiner Kenntnis nach, keine gültige Definition.

Was heisst schon gültige Definition?

Gecom XML 6.0 liegt meiner Kenntins nach in der Version vo 28 Dezember
2001(!) als Entwurf vor. Dieser Entwurf wurde nie verabschiedet.
Die letzte abgeschlossene Gedcomversion ist IMHO Gedcom 5.5 von 1995.

Post by Bjoern Thomsen
http://de.selfhtml.org/xml/intro.htm
http://de.wikipedia.org/wiki/XML

Ließt sich gut, verstehe ich. (denke ich)
Es fehlt die DTD.

Post by Bjoern Thomsen
http://xml.coverpages.org/genealogy.html

Aha, hier haben wir gleich mehrere. Mir gefällt am ehesten (von der
Kurzbeschreibung) GenXML.

Warum das aber nun in XML sein muss, habe ich aber noch nicht
verstanden. Misr ist nur eines klar geworden. XML gibt es in
verschiedenen miteinander nicht vergleichbaren Definitionen an einen
einfachen Datenaustausch ist so nicht zu denken.

So schön flexibel XML auch sein mag, ist das wohl der größte Nachteil.
Außerdem geht es weniger um XML als um die nötige Definition (DTD). Hier
gibt es scheinbar mehrere verschiedene und nicht miteinander kompatible
Vorschläge. Bisher hat sich scheinbar keiner durchgesetzt.

Ich sehe derzeit keinen Bedarf, XML (in welcher Definiton auch immer) in
mein Programm einzubauen.

Ich lasse mich aber gern von den Vorteilen überzeugen, es müssen nur
klar ersichtliche Vorzüge erkennbar sein.

MfG, Metti.

[Bjoern Thomsen]

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Einfacher und klarer strukturiert.

Hilft nicht.

Wem hilft das nicht?

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Flexibler.

Stört ebenfalls eher, da schon heute nur eine Teilmenge der Daten bei
einem Wechsel zu einem anderen Programm "überlebt". Wenn dann das
Austauschformat noch flexibler ist, bekommen wir nur mehr Wildwuchs.
Meine Meinung.

Ich sah "flexibler" eher Allgemein. Aber egal.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Genealogiedaten im XML-Format können auch von nicht-Genealogieprogrammen
angezeigt werden. Beisplw. Tabellekalkulationen, Texteditoren,
Grafikprogrammen.

Das ist ein Argument, über das sich reden läßt.
Ich kenn mich in der materie XML nicht sonderlich aus.

Aha!

Post by Stefan Mettenbrink
Was für Vorteile hätte ich, wenn ich eine solche XML-Datei in eine
Tabelenkalkulation übernehme (was ich auch mit CSV-Dateien kann)?

Nun, man hätte die Daten in einer Tabelle. :-)
Man würde kein weiteres Programm zur Konvertierung benötigen. Genauso
gibt es ja auch den umgekehrten Weg: Tabellenkalkulation zu
Genealogieprogramm.

Wie kommen wir jetzt auf CSV?
XML kann ich, im Gegensatz zu CSV, auch Stil-Informationen mitgeben.

Post by Stefan Mettenbrink
Was soll ich mit Genealogischen Daten (mehrerer(?) Personen) in einem
Texteditor?

Editieren, was sonst.

Post by Stefan Mettenbrink
Was kann ein Grafikprogramm mit diesen Daten?

Einen Stammbaum zeichen.

Post by Stefan Mettenbrink
Ich kann nachvollziehen, das XML *eine* Möglichkeit wäre, die Daten zu
sichern. Den Vorteil gegenüber Gedcom sehe ich derzeit nicht. Das kann
aber durchaus an meiner Unkenntnis liegen, dann würde ich gern
dazulernen.

Es hat sicher seine Gründe, warum inzwischen immer mehr Anwendungen das
XML-Format anbieten. z.B. Openoffice ist schon länger dazu übergegangen.
MS-Office wird folgen. Auch einige Genealogieprogramme beherrschen
zumindest den XML-Export.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
http://de.selfhtml.org/xml/intro.htm
http://de.wikipedia.org/wiki/XML

Ließt sich gut, verstehe ich. (denke ich)
Es fehlt die DTD.

Falls Du es nicht selbst gefunden hast:
http://de.selfhtml.org/xml/dtd/index.htm
http://de.wikipedia.org/wiki/DTD

Post by Stefan Mettenbrink
So schön flexibel XML auch sein mag, ist das wohl der größte Nachteil.
Außerdem geht es weniger um XML als um die nötige Definition (DTD). Hier
gibt es scheinbar mehrere verschiedene und nicht miteinander kompatible
Vorschläge. Bisher hat sich scheinbar keiner durchgesetzt.

Nichts hält dich als Entwickler ab, an diesem "Standard" mitzuwirken.
Schliesslich hast Du grosse Erfahrung mit diesem Thema.

Post by Stefan Mettenbrink
Ich sehe derzeit keinen Bedarf, XML (in welcher Definiton auch immer) in
mein Programm einzubauen.

Dann wirst Du mit den Gedcom5.5-Einschränkungen leben müssen.

Post by Stefan Mettenbrink
Ich lasse mich aber gern von den Vorteilen überzeugen, es müssen nur
klar ersichtliche Vorzüge erkennbar sein.

http://www.google.de/search?hl=de&q=vorteile+xml&btnG=Google-Suche&meta=lr%3Dlang_de%7Clang_en

ungefähr 2.160.000 Seiten auf Deutsch

Vielleicht ist etwas für Dich dabei.

Gruß, Björn
--

[Stefan Mettenbrink]

Post by Bjoern Thomsen

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Einfacher und klarer strukturiert.

Hilft nicht.

Wem hilft das nicht?

Es ging ursprünglich um einen gemeinsamen Standard, bzw. eine
Schnittmenge der zu übermittelten Daten. Also hilft es nicht, wenn etwas
klarer und einfacher ist.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Was für Vorteile hätte ich, wenn ich eine solche XML-Datei in eine
Tabelenkalkulation übernehme (was ich auch mit CSV-Dateien kann)?

Nun, man hätte die Daten in einer Tabelle. :-)

Warum arbeiten dann die wenigsten Genealogen mit einer
Tabellenkalkulation?
:-)

Post by Bjoern Thomsen
Genauso gibt es ja auch den umgekehrten Weg: Tabellenkalkulation zu
Genealogieprogramm.

Warum wohl? Weil man schnell den Nutzen eines Speziellen Programms
erkennt. Man kann auch Briefe und Bücher mit einer Tabellenkalkulation
schreiben. Man kann auch Briefe in einem Malprogramm schreiben.

Es macht aber keinen Sinn.

Post by Bjoern Thomsen
Wie kommen wir jetzt auf CSV?
XML kann ich, im Gegensatz zu CSV, auch Stil-Informationen mitgeben.

Was meinst Du mit Stilinformationen? Fett, Schriftart, etc.?
Das hat mit dem Austausch genealogischer Daten nichts zu tun und gehört
meiner Meinung nach nicht in ein Austauschformat. Das gehört in den
Bereich Datenausgabe. Da wäre PDF meine Wahl.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Was soll ich mit Genealogischen Daten (mehrerer(?) Personen) in einem
Texteditor?

Editieren, was sonst.

Wozu exportieren? Editieren kann ich auch im Genealogieprogramm.

Ich denke wir driften auseinander. Du hattest XML im Zusammenhang mit
dem Export von Daten in ein anderes Programm erwähnt. Macht generell
Sinn. Es macht keinen Sinn genealogische Daten (sofern sie nicht nur zum
Drucken exportiert werden sollen) in einen Editor zu laden. Wenn ich
etwas ansehnlich drucken möchte gibt es für genealogische Daten besser
geeignete Werkzeuge.
Bei den Daten, die ich von einem Genealogieprogramm in einen
Editor/Textverarbeitung lade, handelt es sich im Regelfall um RTF, DOC
oder Textdateien, die ich zuvor auf geeignete Weise exportiert habe.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Was kann ein Grafikprogramm mit diesen Daten?

Einen Stammbaum zeichen.

Ich glaube, wir reden aneinander vorbei.
Sicher kann ich mit XML-Dateien eine Grafik beschreiben, die ein
Grafikprogramm ausgeben kann.

Wir sprachen ursprünglich von genealogischen Daten. Ich glaube nicht,
dass ein Grafikprogramm eine
XML-Datei mit einer Gedcom-DTD interpretieren kann. Dann wäre es nämlich
ein Genealogieprogramm.

Post by Bjoern Thomsen
Es hat sicher seine Gründe, warum inzwischen immer mehr Anwendungen das
XML-Format anbieten. z.B. Openoffice ist schon länger dazu übergegangen.
MS-Office wird folgen. Auch einige Genealogieprogramme beherrschen
zumindest den XML-Export.

Richtig.
XML macht für Textverarbeitungen Sinn, weil alle Textverarbeitungen
Texte verarbeitet und sich auf die DTD geeinigt haben. Wenn Du einer
Textverarbeitung eine XML-Datei mit genealogischer DTD vorwirfst, kann
die sicher herzlich wenig mit den Daten anfangen.

So wie ich XML verstanden habe, ist XML ein Art, wir man Daten
exportiert. Dazu gehört immer eine Definition, wie die enthaltenen Daten
interpretiert werden müssen. Wenn ein Programm das nicht weiß, kann es
die Daten nach Gusto zuordnen und Du kannst wieder nicht viel damit
anfangen.

Post by Bjoern Thomsen
http://de.selfhtml.org/xml/dtd/index.htm

Deine Links sind sehr informativ. Ich werde mir sicher noch einiges mehr
dazu ansehen. Vielen Dank dafür.

Aus dem zitiertem Link:
"Vor allem, wenn Datenbestände über einen längeren Zeitraum aufbewahrt
und von verschiedenen Personen weiterverarbeitet oder weitergepflegt
werden, ist eine DTD eine wichtige normative Grundlage für die
Korrektheit und Einheitlichkeit der Daten."

Genau hier ist der wesentliche Punkt genannt. Ich kann sicher die Daten
in irgendeiner Form als XML sichern. Ohne Definition muss ich das aber
per Hand bei einem Import wieder zusammensuchen. Wenn der Erzeuger dann
mit den Bezeichnern sehr kreativ war (oder jemand, dessen Sprache ich
nicht spreche) bekomme ich schnell Probleme. Auch die vielen
verschiedenen XML-Varianten, die auf
<http://xml.coverpages.org/genealogy.html> genannt werden sind alle
unterschiedlich und können untereinander nicht ausgetauscht werden.
Genau das ist aber der Hauptgrund, ein neues Austauschformat auf
XML-Basis zu entwickeln.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Außerdem geht es weniger um XML als um die nötige Definition (DTD). Hier
gibt es scheinbar mehrere verschiedene und nicht miteinander kompatible
Vorschläge. Bisher hat sich scheinbar keiner durchgesetzt.

Nichts hält dich als Entwickler ab, an diesem "Standard" mitzuwirken.
Schliesslich hast Du grosse Erfahrung mit diesem Thema.

Ich habe nicht die Eefahrung mit XML, nur Erfahrung mit Programmierern
deutscher Genealogieprogramme. Es sit schon schwer, sich auf eine
gemeinsame Syntax für den Export von Rufnamen in Gedcom festzulegen. Ich
befürchte, etwas so großes wie Gedcom auf XML umzusetzen, wird sehr
schwer.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Ich sehe derzeit keinen Bedarf, XML (in welcher Definiton auch immer) in
mein Programm einzubauen.

Dann wirst Du mit den Gedcom5.5-Einschränkungen leben müssen.

Nicht wirklich. Gedcom dient nur zum Austausch der Daten. Solange meine
Anwender nur mit meinem Programm arbeiten, brauchen sie kein Gedcom.
Allenfalls beim Import und da bemerken sie die Einschränkungen bereits
beim Export aus ihrem bisherigen Programm.

Ich gebe Dir völlig Recht, das Gedcom viele Einschränkungen hat.
Ich bin allerdings der Meinung, Gedcom ist flexibel genug, es
entsprechend zu erweitern. Das Problem ist nur, man muss diese
Erweiterungen veröffentlichen! Nur dann können andere Nutzen daraus
ziehen. Dafür braucht es kein XML.

Ein Ansatz ist Gedcom 5.5EL
<http://wiki.genealogy.net/index.php/Gedcom_5.5EL>.

Sollte sich irgendwann XML durchsetzen und Vorteile gegenüber Gedcom
ersichtlich sein, baue ich das gern ein. Sonderlich schwer scheint mir
das nicht zu sein.

Post by Bjoern Thomsen
ungefähr 2.160.000 Seiten auf Deutsch
Vielleicht ist etwas für Dich dabei.

Ich habe die allgemeinen Vorzüge durchaus erkannt und stimme dem zu. Ich
sehe nur keine Vorteile von XLM gegenüber Gedcom. Gedcom ist ebenfalls
mit jedem Editor/Textverarbeitung lesbar. Allerdings ist der einzige
(aber entscheidende) Vorteil von Gedcom, dass es von allen namhaften
Programmen unterstützt wird und zwar in der öffentlich zugänglichen
Definition 5.5.

Wenn sich eine Mehrheit (von mir aus nur mehrere) Programmhersteller auf
eine XML-DTD einigen, bin ich gern dabei.

MfG, Metti.

[Bjoern Thomsen]

Hallo,

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Nun, man hätte die Daten in einer Tabelle. :-)

Warum arbeiten dann die wenigsten Genealogen mit einer
Tabellenkalkulation?
:-)

Evtl. fangen einige so an, und stehen dann dumm da, wenn das gewünschte
Genealogieprogramm keine Excel-Importfunktion hat. Dafür gibt es dann die
Excel-zu-Gedcom-Makros. Wie auch immer.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Genauso gibt es ja auch den umgekehrten Weg: Tabellenkalkulation zu
Genealogieprogramm.

Warum wohl? Weil man schnell den Nutzen eines Speziellen Programms
erkennt. Man kann auch Briefe und Bücher mit einer Tabellenkalkulation
schreiben. Man kann auch Briefe in einem Malprogramm schreiben.
Es macht aber keinen Sinn.

http://sites.inka.de/mips/unix/unixphil.html

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Wie kommen wir jetzt auf CSV?
XML kann ich, im Gegensatz zu CSV, auch Stil-Informationen mitgeben.

Was meinst Du mit Stilinformationen? Fett, Schriftart, etc.?
Das hat mit dem Austausch genealogischer Daten nichts zu tun und gehört
meiner Meinung nach nicht in ein Austauschformat. Das gehört in den
Bereich Datenausgabe. Da wäre PDF meine Wahl.

Du musst nicht _jedes_ Wort auf die Genealogie beziehen. Ich schrieb: Man
kann. Natürlich ist es sinnlos, einem Nachnamen die Stilinformation
"Fett" beim Export mitzugeben.

Ausschliesslich PDF für die Ausgabe? Gerade XML wäre da eine nette
Alternative. Das könnte man dann in OOo oder in einem Webbrowser anzeigen.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Was soll ich mit Genealogischen Daten (mehrerer(?) Personen) in einem
Texteditor?

Editieren, was sonst.

Wozu exportieren? Editieren kann ich auch im Genealogieprogramm.

Wir reden doch hier von Austauschdaten. Evtl. hat der Empfänger kein
Genealogieprogramm. Soll ja vorkommen. :-)

Post by Stefan Mettenbrink
Bei den Daten, die ich von einem Genealogieprogramm in einen
Editor/Textverarbeitung lade, handelt es sich im Regelfall um RTF, DOC
oder Textdateien, die ich zuvor auf geeignete Weise exportiert habe.

Auf geeignete Weise. Was soll das heissen?
Seit wann beschreibt die Dateiendung den Inhalt einer Datei?
Aber gerade der Export von Daten in ein proprietäres Dateiformat scheint
mir die schlimmste aller Lösungen.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Was kann ein Grafikprogramm mit diesen Daten?

Einen Stammbaum zeichen.

[...]

Post by Stefan Mettenbrink
Wir sprachen ursprünglich von genealogischen Daten. Ich glaube nicht,
dass ein Grafikprogramm eine
XML-Datei mit einer Gedcom-DTD interpretieren kann. Dann wäre es nämlich
ein Genealogieprogramm.

Du wolltest ein Beispiel, ich gab Dir eines. Um beisplw. einen Stammbaum
zu zeichnen, benötigt ein Grafikprogramm nicht sehr viele Informationen.
Und hier könnten dann auch Stilelemente beim Export beigelegt werden.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Es hat sicher seine Gründe, warum inzwischen immer mehr Anwendungen das
XML-Format anbieten. z.B. Openoffice ist schon länger dazu übergegangen.
MS-Office wird folgen. Auch einige Genealogieprogramme beherrschen
zumindest den XML-Export.

Richtig.
XML macht für Textverarbeitungen Sinn, weil alle Textverarbeitungen
Texte verarbeitet und sich auf die DTD geeinigt haben.

OpenOffice besteht nicht nur aus einer
Textverarbeitung und einer Tabellenkalkulation. Es enthält noch eine
Präsentations-, Zeichen- und Datenbankanwendung. Und ALLE Anwendungen
verwenden das OpenDocument-Format.

http://de.wikipedia.org/wiki/OpenDocument

Post by Stefan Mettenbrink
Wenn Du einer
Textverarbeitung eine XML-Datei mit genealogischer DTD vorwirfst, kann
die sicher herzlich wenig mit den Daten anfangen.

Da liegst Du leider falsch.

Post by Stefan Mettenbrink
So wie ich XML verstanden habe, ist XML ein Art, wir man Daten
exportiert. Dazu gehört immer eine Definition, wie die enthaltenen Daten
interpretiert werden müssen. Wenn ein Programm das nicht weiß, kann es
die Daten nach Gusto zuordnen und Du kannst wieder nicht viel damit
anfangen.

DTD und XML sind NICHT voneinander abhängig.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
http://de.selfhtml.org/xml/dtd/index.htm

"Vor allem, wenn Datenbestände über einen längeren Zeitraum aufbewahrt
und von verschiedenen Personen weiterverarbeitet oder weitergepflegt
werden, ist eine DTD eine wichtige normative Grundlage für die
Korrektheit und Einheitlichkeit der Daten."

Und? Was hindert einen XML-Anwender seinen Daten eine DTD beizulegen?
Im Prinzip ist JEDER Genealoge mittels einer XML-fähigen Anwendung in der
Lage sein eigenes Genealogieprogramm zu entwerfen. Er kann dort
Vorkommnisse, Quellen oder sonstwas hinterlegen, wozu bis heute kein
bekanntes Genealogieprogramm in der Lage.
Ich kenne schon Dein Gegenargument: Datenverlust bei Datenaustausch. Aber
wenn juckt das schon.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Nichts hält dich als Entwickler ab, an diesem "Standard" mitzuwirken.
Schliesslich hast Du grosse Erfahrung mit diesem Thema.

Ich habe nicht die Eefahrung mit XML, nur Erfahrung mit Programmierern
deutscher Genealogieprogramme. Es sit schon schwer, sich auf eine
gemeinsame Syntax für den Export von Rufnamen in Gedcom festzulegen. Ich
befürchte, etwas so großes wie Gedcom auf XML umzusetzen, wird sehr
schwer.

Du hast Erfahrung, welche Daten in einem Genealogieprogramm vorkommen
sollten. Darum ging es mir.

Wieso Gedcom auf XML umsetzen? Wenn Gedcom Schwächen hat, warum
diese nach XML transportieren?

Post by Stefan Mettenbrink
Nicht wirklich. Gedcom dient nur zum Austausch der Daten. Solange meine
Anwender nur mit meinem Programm arbeiten, brauchen sie kein Gedcom.

Genau so hält man seine Benutzer bei der Stange. :-)

Post by Stefan Mettenbrink
Ich habe die allgemeinen Vorzüge durchaus erkannt und stimme dem zu.
Ich sehe nur keine Vorteile von XLM gegenüber Gedcom. Gedcom ist
ebenfalls mit jedem Editor/Textverarbeitung lesbar.

Ausgesprochen "lesbar" finde ich Gedcom nicht. Um einen Eintrag zu
editieren, muss man schon mit diesem Format vertraut sein. XML finde ich
da um einiges intuitiver.

Post by Stefan Mettenbrink
Allerdings ist der
einzige (aber entscheidende) Vorteil von Gedcom, dass es von allen
namhaften Programmen unterstützt wird und zwar in der öffentlich
zugänglichen Definition 5.5.

Das ist in der Tat ein KO-Argument. Das könnte sich aber in absehbarer
Zeit ändern. Gerade Du als Programmentwickler könntest massgeblich daran
beteiligt sein. ;-)

Post by Stefan Mettenbrink
Wenn sich eine Mehrheit (von mir aus nur mehrere) Programmhersteller auf
eine XML-DTD einigen, bin ich gern dabei.

Ein Anfang ist gemacht. Die Entwickler von GRAMPS haben sich einen Menge
Mühe gemacht.

http://gramps-project.org/xml/1.1.0/grampsxml.dtd

Gruß, Björn

[Klaus-Peter Wessel]

Moin,

zum Thema passt auch sehr schön die Webseite
von Thorsten Riemer:

http://www.riemerundco.de/xml/

Unter: http://www.riemerundco.de/xml/index.htm#6
"Gibt es bereits XML-Konvertierungen, die nutzbar sind?"
sind auch sehr schöne Anwendungsbeispiele zu finden.

Gruss,
Peter

[Stefan Mettenbrink]

Post by Klaus-Peter Wessel
zum Thema passt auch sehr schön die Webseite
http://www.riemerundco.de/xml/

Ja, ganz interessant.
Sowas: <http://www.riemerundco.de/xml/tabelle.htm>
kann durchaus mit meinem Programm erzeugt werden. Eine entsprechde
Vorlage ist in 10 Minuten erstellt.

Dafür benötige ich nicht extra einen XML-Export.

MfG, Metti.

[Bjoern Thomsen]

HAllo,

Post by Stefan Mettenbrink
Sowas: <http://www.riemerundco.de/xml/tabelle.htm>
kann durchaus mit meinem Programm erzeugt werden. Eine entsprechde
Vorlage ist in 10 Minuten erstellt.
Dafür benötige ich nicht extra einen XML-Export.

Wenn Du ihn aber so nennst, hast Du einen. :-)

Gruß, Björn

[Stefan Mettenbrink]

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Sowas: <http://www.riemerundco.de/xml/tabelle.htm>
kann durchaus mit meinem Programm erzeugt werden. Eine entsprechde
Vorlage ist in 10 Minuten erstellt.
Dafür benötige ich nicht extra einen XML-Export.

Wenn Du ihn aber so nennst, hast Du einen. :-)

:-)
In Zukunft heißt es nur noch "Ausgabe" und je nach Vorlage ist es dann
ein HTML- oder XML- oder Sonstwas-Export.

MfG, Metti.

[Gerhard Bauch]

Guude (hessisches Äquivalent für "Moin")

Post by Klaus-Peter Wessel
Moin,
zum Thema passt auch sehr schön die Webseite
http://www.riemerundco.de/xml/
Unter: http://www.riemerundco.de/xml/index.htm#6
"Gibt es bereits XML-Konvertierungen, die nutzbar sind?"
sind auch sehr schöne Anwendungsbeispiele zu finden.

In der Tat.

Allerdings hantiert die Seite ein wenig "auf der Grünen Wiese". Vielleicht
ist das aber ein Fingerzeig, was da auf uns zukommt : jede Menge privater,
propriäterer, komplexer und einfacher, genealogisch "richtiger" und eben
anderer Definitionsversuche (Heiratsdatum im Individualsatz !).

Wir haben dann in Zukunft (hoffentlich nicht !) Dutzende verschiedene
genealogische XML Dialekte, die wir dann alle implementieren dürfen ?

Egal, die Seite zeigt durchaus die Stärken genealogischer XML Anwendungen :
Auswertungen, Displays, interaktive Präsentationen. Sehr schön. Dafür ist
auch ein GEDCOM 5.5 orientiertes XML sehr gut zu gebrauchen.

Die Seite erwähnt merkwürdigerweise aber kein einziges Genealogieprogramm,
das XML Dateien erzeugen kann. Gibt's dafür einen Grund ?

Gerhard Bauch
Autor von DYNAS-TREE (das Programm mit dem GEDML Export)....

http://www.dynas-tree.de

[Stefan Mettenbrink]

Post by Gerhard Bauch
und eben
anderer Definitionsversuche (Heiratsdatum im Individualsatz !).

Na und?
Das Individuum hatte ein Ereignis Ehe.
Dazu die Angabe mit wem. Reicht doch. Mache ich in meinem Programm
intern genauso.

MfG, Metti.

[Stefan Mettenbrink]

Post by Bjoern Thomsen
Ausschliesslich PDF für die Ausgabe? Gerade XML wäre da eine nette
Alternative. Das könnte man dann in OOo oder in einem Webbrowser anzeigen.

Nein. PDF für Ausgaben, die nicht mehr bearbeitet werden und allen zur
Verfügung stehen sollen. hauptsächlich für Druckerzeugnisse.
Für den Export in eine Textverarbeitung würde ich derzeit RTF nehmen,
kann mir aber vorstellen, dass XML hier sehr wohl geeignet (und mit
meinem Programm bereits möglich) ist. Für Webbroser ist der HTML-Export
vorgesehen.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Wozu exportieren? Editieren kann ich auch im Genealogieprogramm.

Wir reden doch hier von Austauschdaten. Evtl. hat der Empfänger kein
Genealogieprogramm. Soll ja vorkommen. :-)

Dann braucht er keine genealogischen Daten, sondern Texte. Die sind
natürlich über definierte Ausgaben erforderlich. Von mir aus auch in
Form von XML.

Ich lade Dich ein, Dir den Export meines Programm anzusehen. Damit ist
ein Export in XML sicher machbar, Du musst nur eine entsprechende
Vorlage erstellen.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Editor/Textverarbeitung lade, handelt es sich im Regelfall um RTF, DOC
oder Textdateien, die ich zuvor auf geeignete Weise exportiert habe.

Auf geeignete Weise. Was soll das heissen?
Seit wann beschreibt die Dateiendung den Inhalt einer Datei?
Aber gerade der Export von Daten in ein proprietäres Dateiformat scheint
mir die schlimmste aller Lösungen.

Da gebe ich Dir Recht. DOC habe ich nur aufgeführt, weil danach gefragt
wird. Ich empfehle denen RTF.

Wie zuvor geschildert, kann man mit meinem Programm Vorlagen (eine Art
Batchdatei) erstellen, die beim Export Platzhalter durch die
eigentlichen Daten ersetzt. Im Prinzip ähnlich wie HTML.

So wird aus
<Vornamen> <Nachname>, geb. am <GDatum> in <GOrt>

z.B. die Ausgabe:
Stefan Mettenbrink, geb. am 11.11.1911 in Musterhausen

Je nach Vorlage gedruckt oder als Text in eine Datei geschrieben (dann
mit wählbarer Umlautkodierung).

Post by Bjoern Thomsen
Und? Was hindert einen XML-Anwender seinen Daten eine DTD beizulegen?
Im Prinzip ist JEDER Genealoge mittels einer XML-fähigen Anwendung in der
Lage sein eigenes Genealogieprogramm zu entwerfen. Er kann dort
Vorkommnisse, Quellen oder sonstwas hinterlegen, wozu bis heute kein
bekanntes Genealogieprogramm in der Lage.

Warum nutzt das dann keiner?
Dann brauchten die Genealogen doch nur eOpenOffic. Das ist XML-fähig und
"besteht nicht nur aus einer
Textverarbeitung und einer Tabellenkalkulation. Es enthält noch eine
Präsentations-, Zeichen- und Datenbankanwendung. Und ALLE Anwendungen
verwenden das OpenDocument-Format."

Wozu dann ein Genealogieprogramm? Noch dazu, wenn es nicht mal XML
beherrscht.

Post by Bjoern Thomsen
Ich kenne schon Dein Gegenargument: Datenverlust bei Datenaustausch. Aber
wenn juckt das schon.

Nein, das ist nicht mein Argument. Auch mich interessiert (als
Programmierer) der Datenaustausch nicht soderlich. Ich möchte ein
Programm, dass den Anwender unterstützt und seinen Bedürfnissen
entspricht. Wenn ich dann beim Export nicht alles exportieren kann, weil
es kein entsprechenes Austauschformat gibt oder das importierende
Programm die Möglichkeiten nicht bietet, ziehe ich mir den Schuh nicht
an.

Aber, Ursprungsthema war der Datenaustausch.
Du meintest XML wäre hier sinnvoll. Ich denke, XML ist eine gute und
flexible Möglichkeit für einen Datenaustausch. Meiner Meinung nach setzt
es sich nicht in naher Zukunft durch. Zum einen, weil ein keine global
genutze große Anwendung gibt, die das durchsetzen möchte. (PAF wäre in
der Lage, die Mormonen haben aber kein Interesse daran). Selbst wenn
sich alle Programmierer deutschsprachger Programme insetzen und etwas
derartiges auf die Beine stellen (was ich mir derzeit leider nicht
vorstellenkann), glaube ich nicht, dass sie damit bis auf den
amerikanischen Markt vordringen.

Im übrigen ist es einfacher, den vorhandenen Standard Gedcom 5.5, der
Definition entsprechend mit eigenen Tags zu erweitern und die
Erweiterungen öffentlich zu dokumentieren. Dann kann ich alles
exportieren und derjenige, der meine Exporte importieren möchte, findet
die nötigen Informationen.
Hierfür muss ich keinen zusäzlichen XML-Export schreiben und der Import
in andere Programme funktioniert zumindest, soweit das Programm Gedcom
5.5 unterstützt.

Post by Bjoern Thomsen
Wieso Gedcom auf XML umsetzen? Wenn Gedcom Schwächen hat, warum
diese nach XML transportieren?

GEDCOM=GEnealogical Data COMmunication
Das kann auch in Form von XML sein. Gedcom 6.0 Draft sieht genau das
vor. (ich habe es vorliegen aber noch nicht reingesehen, weiß also nicht
welche Probleme damit bestehen blieben)

Im Prinzip suche ich das
(von:<http://xml.coverpages.org/genealogy.html>):
"GenXML is a file format for exchange of data between genealogy
programs. It is based on XML and defined by a XML schema. It is not
intended to be used as an internal format of any genealogy programs,
although it may be possible. It is an alternative to Gedcom 5.5. The
idea of GenXML is that: (1) it shall be easy to read by most
genealogical programs; (2) it shall be easy to write by most
genealogical programs; (3) it shall be easy to manipulate by third party
programs; (4) all kinds of information shall fit into one and only one
place... GenXML is mainly inspired by the theoretical Gentech Data Model
(see www.gentech.org) and Gedcom Future Directions, which is an
unfinished replacement of Gedcom 5.5."

Das hört sich für mich sehr interessant an. Das werde ich mir auch noch
mal in Ruhe näher ansehen.

Post by Bjoern Thomsen
Ausgesprochen "lesbar" finde ich Gedcom nicht. Um einen Eintrag zu
editieren, muss man schon mit diesem Format vertraut sein. XML finde ich
da um einiges intuitiver.

Da kann ich Dir nur Recht geben.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Wenn sich eine Mehrheit (von mir aus nur mehrere) Programmhersteller auf
eine XML-DTD einigen, bin ich gern dabei.

Ein Anfang ist gemacht. Die Entwickler von GRAMPS haben sich einen Menge
Mühe gemacht.

Ja, GRAMPS kam mir auchschon in den Sinn. Da ich hier nur ein LiveLinux
habe, hatte ich bisher noch nicht das Verlangen, das zu testen.
Allerdings halte ich den Weg, GRAMPS als OpenSource-Software, mit XML
auszustatten und die XML-DTD gut dokumentiert zu veröffentlichen für
einen Schritt in die Richtige Richtung. Leider ist GRAMPS nicht
übermäßig verbreitet :-(
Schön wäre es, wenn man von GRAMPS auch eine Mac- und Windows- Version
hätte, das würde einiges erleichtern.

Ich werde das weiter beobachten.

MfG, Metti.

[Bjoern Thomsen]

Hallo,

Post by Stefan Mettenbrink
Ich lade Dich ein, Dir den Export meines Programm anzusehen. Damit ist
ein Export in XML sicher machbar, Du musst nur eine entsprechende
Vorlage erstellen.

Wenn Du nach HTML exportieren kannst, da sicher auch nach XML. :-)
XHTML würde dem schon sehr nahe kommen:
http://de.selfhtml.org/html/xhtml/index.htm
http://www.w3.org/

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Und? Was hindert einen XML-Anwender seinen Daten eine DTD beizulegen?
Im Prinzip ist JEDER Genealoge mittels einer XML-fähigen Anwendung in der
Lage sein eigenes Genealogieprogramm zu entwerfen. Er kann dort
Vorkommnisse, Quellen oder sonstwas hinterlegen, wozu bis heute kein
bekanntes Genealogieprogramm in der Lage.

Warum nutzt das dann keiner?

Weil es nicht trivial ist. ;-(

Post by Stefan Mettenbrink
Wozu dann ein Genealogieprogramm? Noch dazu, wenn es nicht mal XML
beherrscht.

Fangfrage?

Post by Stefan Mettenbrink
Auch mich interessiert (als
Programmierer) der Datenaustausch nicht soderlich. Ich möchte ein
Programm, dass den Anwender unterstützt und seinen Bedürfnissen
entspricht. Wenn ich dann beim Export nicht alles exportieren kann, weil
es kein entsprechenes Austauschformat gibt oder das importierende
Programm die Möglichkeiten nicht bietet, ziehe ich mir den Schuh nicht
an.

Ein Standpunkt, den ich nachvollziehen kann.

[...]

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Ein Anfang ist gemacht. Die Entwickler von GRAMPS haben sich einen
Menge Mühe gemacht.

Ja, GRAMPS kam mir auchschon in den Sinn. Da ich hier nur ein LiveLinux
habe, hatte ich bisher noch nicht das Verlangen, das zu testen.

Unter

http://gramps-project.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=19&MMN_position=33:9

bzw. unter: http://ftp.gwdg.de/pub/linux/gramps/

finden alle Interessierten eine "Linux Genealogy Live CD". Dieses
LiveLinux basiert auf Ubuntu.

Auf er CD sind folgende Genealogie-Programme enthalten:
- GRAMPS
- GeneWeb
- LifeLines
- PhpGedView

ausserdem:
OpenOffice.org - Office-Applikation
Evolution - E-Mail-Programm
GIMP - Grafikeditor
Firefox - Webbrowser
GAIM - Chat- Anwendung

Post by Stefan Mettenbrink
Allerdings halte ich den Weg, GRAMPS als OpenSource-Software, mit XML
auszustatten und die XML-DTD gut dokumentiert zu veröffentlichen für
einen Schritt in die Richtige Richtung. Leider ist GRAMPS nicht
übermäßig verbreitet :-(

Was wohl daran liegt, dass Linux ebenfalls nicht übermäßig verbreitet
ist.

Post by Stefan Mettenbrink
Schön wäre es, wenn man von GRAMPS auch eine Mac- und Windows- Version
hätte, das würde einiges erleichtern.

Bisher gibt es GRAMPS nur f. Linux, BSD, und Solaris.
Wer sich auskennt, wird es aber auch unter Mac X OS zum Laufen bekommen.

Gruß, Björn

[Stefan Mettenbrink]

Post by Bjoern Thomsen
Wenn Du nach HTML exportieren kannst, da sicher auch nach XML. :-)

XHTML geht auch.
Da Du als Anwender die Ausgabe durch die Vorlage selbst bestimmen
kannst, hängt die Ausgabe (fast ausschließlich) von Deinen Fähigkeiten
ab.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Schön wäre es, wenn man von GRAMPS auch eine Mac- und Windows- Version
hätte, das würde einiges erleichtern.

Bisher gibt es GRAMPS nur f. Linux, BSD, und Solaris.
Wer sich auskennt, wird es aber auch unter Mac X OS zum Laufen bekommen.

Genau hier sehe ich das größte Hindernis einer weiteren Verbreitung.
Wenn man sich nicht so sehr an linuxspezifische Eigenschaften gekoppelt
(ich glaube es waren GUI-Libraries) und etwas mehr auf Protabilität
geachtet hätte, wäre nicht nur die Anwenderzahl höher. Auch die
Mitprogrammierer wären mehr.

MfG, Metti.

[Bjoern Thomsen]

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Wenn Du nach HTML exportieren kannst, da sicher auch nach XML. :-)

XHTML geht auch.

Und diese Ausgabe hält einen Validator stand?
http://validator.w3.org/

Post by Stefan Mettenbrink
Da Du als Anwender die Ausgabe durch die Vorlage selbst bestimmen
kannst, hängt die Ausgabe (fast ausschließlich) von Deinen Fähigkeiten
ab.

Ok. Wenn ich besser Python proggen könnte, dann könnte ich auch (noch)
bessere Ausgaben in GRAMPS hinbekommen. Zum Glück gibts reichlich
gute Vorlagen. Diese lassen sich auch vor der Ausgabe, auch ohne
Sonderkenntnisse in Meta- und Beschreibungssprachen, anpassen.

Leider kann ich Dein Programm nicht testen, da ich kein Windows habe.

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Bisher gibt es GRAMPS nur f. Linux, BSD, und Solaris.
Wer sich auskennt, wird es aber auch unter Mac X OS zum Laufen bekommen.

Genau hier sehe ich das größte Hindernis einer weiteren Verbreitung.
Wenn man sich nicht so sehr an linuxspezifische Eigenschaften gekoppelt
(ich glaube es waren GUI-Libraries) und etwas mehr auf Protabilität
geachtet hätte, wäre nicht nur die Anwenderzahl höher. Auch die
Mitprogrammierer wären mehr.

Die Ports werden wohl kommen:
http://blog.gramps-project.org/?p=34

Gruß, Björn

[Stefan Mettenbrink]

Post by Bjoern Thomsen

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Wenn Du nach HTML exportieren kannst, da sicher auch nach XML. :-)

XHTML geht auch.

Und diese Ausgabe hält einen Validator stand?

Wenn Du die Vorlage valide erstellst. Sicher.

Post by Bjoern Thomsen
Leider kann ich Dein Programm nicht testen, da ich kein Windows habe.

Wenn REALSoftware es schafft, eine brauchbare Linuxversion zu erzeugen,
kommt auch Familienbande für Linux.

MfG, Metti.

[Thomas Hechelhammer]

Post by Bjoern Thomsen

Post by Stefan Mettenbrink

Post by Bjoern Thomsen
Ein Anfang ist gemacht. Die Entwickler von GRAMPS haben sich einen
Menge Mühe gemacht.

Ja, GRAMPS kam mir auchschon in den Sinn. Da ich hier nur ein LiveLinux
habe, hatte ich bisher noch nicht das Verlangen, das zu testen.

Unter
http://gramps-project.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=19&MMN_position=33:9
bzw. unter: http://ftp.gwdg.de/pub/linux/gramps/
finden alle Interessierten eine "Linux Genealogy Live CD". Dieses
LiveLinux basiert auf Ubuntu.
- GRAMPS
- GeneWeb
- LifeLines
- PhpGedView
OpenOffice.org - Office-Applikation
Evolution - E-Mail-Programm
GIMP - Grafikeditor
Firefox - Webbrowser
GAIM - Chat- Anwendung

Post by Stefan Mettenbrink
Allerdings halte ich den Weg, GRAMPS als OpenSource-Software, mit XML
auszustatten und die XML-DTD gut dokumentiert zu veröffentlichen für
einen Schritt in die Richtige Richtung. Leider ist GRAMPS nicht
übermäßig verbreitet :-(

Was wohl daran liegt, dass Linux ebenfalls nicht übermäßig verbreitet
ist.

Linux geht im Gegensatz zu Windows aber nicht so oft kaputt.
Erlebe ich mittlerweile fast jeden Tag im Umfeld.

Genealogen scheinen in Bezug auf Software eher etwas unbedarft zu sein
und daher lieber mit dem *einfachen Windows* anstelle mit Linux arbeiten
zu wollen.
Die Life-CD ist aber ein guter Anfang, wobei ich das System Knoppix dem
Ubuntu bevorzuge.

Post by Bjoern Thomsen

Post by Stefan Mettenbrink
Schön wäre es, wenn man von GRAMPS auch eine Mac- und Windows- Version
hätte, das würde einiges erleichtern.

Bisher gibt es GRAMPS nur f. Linux, BSD, und Solaris.
Wer sich auskennt, wird es aber auch unter Mac X OS zum Laufen bekommen.

Laut den Programmierern ist GRAMPS zu sehr Gnome-Library-lastig.
Daher kann es auch unter Debian mit KDE als Desktop Probleme geben.

Ein Windows-Port ist lt. Forum derzeit nicht geplant, es arbeiten auch
zu wenige Programmierer im Projekt mit um sowas zu leisten.

*Q: Does GRAMPS run under Windows?
*
*A: GRAMPS is not supported under Windows. GRAMPS is a GNOME
*application, and will run under environments that support the GNOME
*libraries. At this point, the GNOME libraries have not been ported to
*Windows.
*
*The GRAMPS development team does not anticipate porting GRAMPS to
*Windows at any time in the future for various other reasons such as not
*having access to Windows machines, a lack of time and a lack of any
*desire to support Windows.
*
*However, if some brave soul is willing to port GRAMPS to this legacy
*operating system, we will not stand in their way. GTK has already been
*ported to Windows, so most of the work would involve porting the GNOME
*support libraries or providing equivalent replacements. Some of this
*work has already been started by Novell in their efforts to port
*Evolution to Windows.
*
*As an alternative for Windows users, the gramps-tk project is a project
*that was started to attempt to port a simplified version of GRAMPS to
*legacy systems.

Als Linux-User bin ich auf Gramps angewiesen und hatte bislang mit
GEDCOM-Importen keinerlei Probleme (und wohl nicht mitbekommen wenn
Daten nicht importiert wurden).

Ich empfehle aber ausschließlich die Version 2.0.9r2, läuft bei mir
fehlerfrei. Die alte 2.0.8 hatte mehrere Bugs.

-- Thomas

[Bjoern Thomsen]

Hallo Thomas,

Post by Thomas Hechelhammer
Linux geht im Gegensatz zu Windows aber nicht so oft kaputt.
Erlebe ich mittlerweile fast jeden Tag im Umfeld.

Auf jeden Fall muss eine Windows ständig "überwacht" werden. Das muss
aber nicht so bleiben. Sobald Linux weiter verbreitet ist, werden sich
die Hacker und Virenprogrammierer auch auf Linux stürzen.

Post by Thomas Hechelhammer
Genealogen scheinen in Bezug auf Software eher etwas unbedarft zu sein
und daher lieber mit dem *einfachen Windows* anstelle mit Linux arbeiten
zu wollen.

Viele scheuen eine Umstellung, da sie nicht ganz trivial ist. Auch
scheint es nicht sehr bekannt zu sein, daß man Windows und Linux
nebeneinander betreiben kann. Und das inkl. Datenaustausch.

Anscheinend kann sich auch niemand mehr daran erinnern, daß
er/sie mehr als zwei Tage brauchten, um Windows zu erlernen.

Ein Bekannter mit Linuxerfahrung, ein örtlicher Computerverein oder eine
lokale LinuxUserGroup (LUG) können hier sehr hilfreich sein.

Post by Thomas Hechelhammer
Die Life-CD ist aber ein guter Anfang, wobei ich das System Knoppix dem
Ubuntu bevorzuge.

GRAMPS ist eher eine Gnome-Anwendung, da kann es schon mal zu Problemen
unter KDE kommen.

Post by Thomas Hechelhammer
Ein Windows-Port ist lt. Forum derzeit nicht geplant, es arbeiten auch
zu wenige Programmierer im Projekt mit um sowas zu leisten.

Siehe dazu:
http://blog.gramps-project.org/?p=34

Post by Thomas Hechelhammer
Als Linux-User bin ich auf Gramps angewiesen und hatte bislang mit
GEDCOM-Importen keinerlei Probleme (und wohl nicht mitbekommen wenn
Daten nicht importiert wurden).

Auch der GEDCOM-Export (PhpGedView, GenJ) war immer einwandfrei.

Post by Thomas Hechelhammer
Ich empfehle aber ausschließlich die Version 2.0.9r2, läuft bei mir
fehlerfrei. Die alte 2.0.8 hatte mehrere Bugs.

Joo.
Ganz Mutige können auch den CVS repository probieren:
http://cvs.sourceforge.net/viewcvs.py/gramps/gramps2/

Gruß, Björn

[Stefan Mettenbrink]

Post by Bjoern Thomsen
Sobald Linux weiter verbreitet ist, werden sich
die Hacker und Virenprogrammierer auch auf Linux stürzen.

Sagt wer?
Ich sage das Gegenteil.

MfG, Metti.

[Gerhard Bauch]

Tach,

Post by Bjoern Thomsen
Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.

die Diskussion um XML oder nicht in Genealogieprogrammen wird oftmals auf
einer sehr ideologischen Ebene geführt, mir nicht klar, warum, vielleicht
aus Technikverliebtheit ?. Bitte doch bei der gesamten Unterhaltung
folgendes nicht vergessen :

- XML ist eine Meta Markup Language. XML beschreibt, wie eine Markup
Language auszusehen hat. XML ist vergelichbar mit einer Verordnung, die
beschreibt, wie ein Bauplan auszusehen hat, es ist nicht etwa der Bauplan
selber, und schon garnicht der Neubau daselbst.

- XML alleine nützt also garnüscht. Es muß eine nach XML Regeln definierte
Markup Language erstellt werden, es gibt da wohl schon welche, z.B. GEDML
von Michael Kay. (Ist seit mehr als 3 Jahren in DYNAS-TREE als
Ausgabe-Option implementiert, wird aber abgesehen von ein paar
Stylesheetanwendungen nicht benutzt (soviel ich weiß).)


genealogische XML Sprachen :

- es ist wurscht, ob Programmierer vor der Frage stehen, "welchen GEDCOM
Standard implementiere ich ?" oder "welchen genealogischen XML Dialekt
implementiere ich ?"

- auch wenn es nun nur GEDML gäbe : auch GEDML löst folgende Probleme
definitiv nicht :

-- Programm kennt einen Tag nicht. Es ist wurscht, ob ein Programm "1 SELI"
nicht versteht oder <SELIGSPRECHUNG Wunder=Lahmensehung> nicht versteht.

-- Programm exportiert, vielleicht, weil es eine GEDML Datei als alleinige
Datenbasis verwendet, haufenweise "private" GEDML Tags : <_BLDRBERKU> mit
dem kein anderes Programm was anfangen kann. (Blutdruck beim ersten Kuss)

-- Es ist wurscht, ob ein Programm statt

1 SELI
2 WUNDER

die falsche Folge

1 SELI
1 WUNDER

exportiert.

oder statt <SELIGSPRECHUNG><WUNDER>Lahmensehung</WUNDER><SELIGSPRECHUNG>

die falsche Sequenz

<SELIGSPRECHUNG/><WUNDER>Lahmensehung></WUNDER>

ausgibt.

Da nützen alle DTD's und Language Definitions nicht, wenn das einlesende
oder ausgebende Programm Defizite hat.

Nach wie vor stehen wir Programmierer in der Pflicht, sowohl die GEDCOM
Ein-Ausgabe, als auch eine etwaige XML Ein-Ausgabe korrekt zu
implementieren. XML nimmt uns hier nix ab.

GEDCOM Parser sind in der Regel implementiert, Exporter ebenfalls.

Machen wir uns doch erstmal daran :

- den GEDCOM Standard einheitlich zu interpretieren,

- den GEDCOM Standard, wenn schon nicht komplett (wer braucht schon
Templecodes), so doch die vorhandene Implementierungsmenge gemäß der noch zu
findenden einheitlichen Interpretation richtig zu implementieren.

Eine Stärke der GEDML Definition (oder anderer genealogischer XML Languages)
ist nun aber schon, daß man Stylesheetanwendungen oder XML basierte
Datenbanken drauf ansetzen kann. Einweganwendungen sozusagen. Export aus dem
Genealogieprogramm, Import in ein Displaysystem.

Nicht empfehlen würde ich, eine GEDML Datei extern zu bearbeiten und dann
wieder in's Programm zu versuchen zu reimportieren. Es ist einfach die
Gefahr zu groß, daß die externe Bearbeitungsmethode die Datei in zum
originalen Programm inkonsistenter Weise verändert.

Fazit für DYNAS-TREE :

GEDML Export ja, wird eventuellen neuen GEDCOM Tags angepaßt,

GEDML Import zunächst nicht.

GEDCOM Import : soviele Ungereimtheiten (ich glaube derzeit 2 Dutzend)
anderer Programme wieder gerade biegen,

GEDCOM Export : so nahe wie möglich am Standard orientiert zu exportieren,

aber auch optional : die Erweiterungen gemäß der GEDCOM 5.5EL mit
exportieren.

Aber die Frage des OP lautete ja, welche Programme unterstützen welche
GEDCOM Tags :

Hier ein Versuch, diese Antwort für DYNAS-TREE zu geben : (Export Option =
GEDCOM 5.5 )

0 HEAD
1 SOUR
2 VERS
2 NAME
2 CORP
3 ADDR
4 CONT
1 DATE
1 CHAR
1 NOTE
2 CONT
1 FILE
1 GEDC
2 VERS
2 FORM

0 @U1@ SUBM
1 NAME

0 @I1@ INDI
1 NAME
2 GIVN
2 SURN
2 SOUR @S455@
3 PAGE
3 QUAY
3 DATA
4 DATE
1 REFN
1 SEX
1 NMR
1 NCHI
1 ASSO @I14@
2 RELA

1 BIRT /DEAT/CHR/BURI/....
2 DATE
2 PLAC
2 SOUR @S25@
3 PAGE
3 EVEN
4 ROLE
3 QUAY
3 DATA
4 DATE
4 TEXT
3 OBJE
4 FORM
4 TITL
4 FILE
1 RESI
2 DATE
2 ADDR
3 CONT
3 ADR2
3 CITY
3 POST
1 OBJE
2 FORM
2 TITL
2 FILE
1 FAMS @F1@
1 FAMC @F4@
1 CHAN
2 DATE
0 @F1@ FAM
1 HUSB
1 WIFE @I2@
1 CHIL @I1@

1 MARR / ENGA / DIV / ......
2 DATE
2 PLAC
2 SOUR @S39@
3 PAGE
3 EVEN
3 QUAY 3

1 OBJE
2 FORM
2 TITL
2 FILE

0 @N2679@ NOTE
1 CONT

0 @S3@ SOUR
1 DATA
2 EVEN
3 DATE
3 PLAC
2 AGNC
1 TITL
1 ABBR
1 PUBL
1 REPO @R13@
1 CHAN
2 DATE

0 @R92@ REPO
1 NAME
1 ADDR
2 CONT
2 ADR1
2 ADR2
2 CITY

0 TRLR

[Stefan Mettenbrink]

Post by Gerhard Bauch
Nach wie vor stehen wir Programmierer in der Pflicht, sowohl die GEDCOM
Ein-Ausgabe, als auch eine etwaige XML Ein-Ausgabe korrekt zu
implementieren. XML nimmt uns hier nix ab.

Genau meine Meinung!
Hier versuche ich zumindest keine eigenen Wege zu gehen sondern mich
umzuhören, ob andere Programme schon gelöst haben und implementiere dann
diese.

Post by Gerhard Bauch
- den GEDCOM Standard einheitlich zu interpretieren,

Wobei die Definition eigentlich wenig interpretationsspielraum läßt. Das
ist schon recht konkret. Nur leider nicht immer leicht verständlich.
Allein die Umlautkodierung die nur ASCI, ANSEL und UNICODE (bei Gedcom
5.5.1 noch UTF-8) vorsieht wird von vielen Programmen schlicht
fehlerhaft genutzt. :-(

Post by Gerhard Bauch
- den GEDCOM Standard, wenn schon nicht komplett (wer braucht schon
Templecodes), so doch die vorhandene Implementierungsmenge gemäß der noch zu
findenden einheitlichen Interpretation richtig zu implementieren.

Ja.

Post by Gerhard Bauch
Eine Stärke der GEDML Definition (oder anderer genealogischer XML Languages)
ist nun aber schon, daß man Stylesheetanwendungen oder XML basierte
Datenbanken drauf ansetzen kann. Einweganwendungen sozusagen. Export aus dem
Genealogieprogramm, Import in ein Displaysystem.

Das ist doch mal etwas konkretes!
Dafür habe ich Verständnis. Genau deswegen habe ich den Export bei mir
über die Vorlagen (Batchdatei) gelöst. Da kann jeder die Ausgabe
erstellen, wie er sie braucht.

Post by Gerhard Bauch
GEDCOM Import : soviele Ungereimtheiten (ich glaube derzeit 2 Dutzend)
anderer Programme wieder gerade biegen,

Ja, leider :-(

Post by Gerhard Bauch
GEDCOM Export : so nahe wie möglich am Standard orientiert zu exportieren,
aber auch optional : die Erweiterungen gemäß der GEDCOM 5.5EL mit
exportieren.

Wahlweise abschaltbar. Es soll Programme geben, die Problem bekommen.

Post by Gerhard Bauch
Hier ein Versuch, diese Antwort für DYNAS-TREE zu geben : (Export Option GEDCOM 5.5 )

Das ist doch mal ein brauchbarer Ansatz. Leider ist bei mir Import und
Export unterschiedlich weit. Mal schauen, ob ich Morgen dazu komm, die
Liste ebenfalls zusammen zu stellen.

MfG, Metti.

[Thomas Hechelhammer]

Meiner Meinung nach braucht XML kein Mensch wirklich, genauso wenig wie
HTML.

Die einfachste Konvertierebene ist immer noch ASCII, mit UTF-8 als
Zeichensatzstandard oder wenigstens -option.

Ich hatte bislang auf meinem alten Win98 mehrere Genealogieprogramme im
Einsatz:

- Familienstammbaum 7.5

- Ahnengalerie 3.0

- PAF 5

- Mein Stammbaum 2 Deluxe

- Stammbaumdrucker

- Adam

- Winahnen

und unter Linux GRAMPS 2.0.9 sowie Geneweb

Allen diesen Programmen ist gemeinsam dass sie irgendeinen Vorzug bieten:

- Komfortable Eingabe

- Ausgabe ähnlich der Wunschvorstellung

- einfacher Zugriff auf Daten und keine ewige Suche in verschachtelten
Bäumen

Das Riesenproblem: Kein Programm ist bezüglich der Datenbankstruktur
kompatibel zum anderen, noch nicht mal die gemeinsame Schnittstelle
Gedcom funktioniert.

Und an diesem Standard sollte dringend gearbeitet werden.

XML ist eine Beschreibungssprache ähnlich HTML.
Schön für eine einheitliche Darstellung von Inhalten unter verschiedenen
Plattformen, aber keine Lösung für das Gedcom-Problem.

Jeder Programmierer unterstützt nur *seine* Tags, ihm unbekannte oder
nicht verwendete läßt er unter den Tisch fallen.

(Die könnte er wenigstens als ASCII-Text im jeweiligen Datensatz als
Gedcom-Zusatz speichern damit nichts verloren geht).
Und später wieder mit exportieren.

-- Thomas

[Bjoern Thomsen]

Hallo,

Post by Thomas Hechelhammer
Meiner Meinung nach braucht XML kein Mensch wirklich, genauso wenig wie
HTML.

Um es nochmal in Erinnerung zu rufen:
Ich schrieb in <dppt10$f6q$02$***@news.t-online.com>:
---------------------
In diesem Thread wurde bisher viel über "Haltbarkeit" gesprochen.

[...]

Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.
---------------------

Es ging mir eigentlich darum, ein Format zu erwähnen, mit dem man sich
seine Daten auch ohne Genealogieprogramm ansehen kann. Und zwar nicht nur
maschinenlesbar, sondern auch menschenlesbar.

IMO wird XML länger Bestand haben als GEDCOM.

Gruß, Björn

[Thomas Hechelhammer]

Post by Bjoern Thomsen
Hallo,

Post by Thomas Hechelhammer
Meiner Meinung nach braucht XML kein Mensch wirklich, genauso wenig wie
HTML.

---------------------
In diesem Thread wurde bisher viel über "Haltbarkeit" gesprochen.
[...]

Und hier sind wir uns einig: Nichts geht über die Papierlösung oder
Keilschrift in Granitblöcke. ;-)

Post by Bjoern Thomsen
Wer es dennoch im EDV-Bereich versuchen möchte, dem kann ich nur das
XML-Format ans Herz legen.
---------------------

IMO sind über 90% aller HTML-Webseiten fehlerhaft. Und es gibt bereits
mehrere HTML-Versionen.

Ich sehe bei XML, welches ich als eine Ergänzung zu HTML sehe, das
Risiko dass diverse Hersteller den Standard wieder verwässern und jeder
sein eigenes Süppchen kocht. -> CD, -> DVD usw.

Post by Bjoern Thomsen
Es ging mir eigentlich darum, ein Format zu erwähnen, mit dem man sich
seine Daten auch ohne Genealogieprogramm ansehen kann. Und zwar nicht nur
maschinenlesbar, sondern auch menschenlesbar.

AKK.

Post by Bjoern Thomsen
IMO wird XML länger Bestand haben als GEDCOM.

Das kann durchaus sein.
Bis wieder ein neues Format kommt.

Ich verfolge den EDV-Bereich seit 1981 (CBM3032) und habe sehr viele
Formate und Medien kommen und gehen sehen.

-- Thomas

Post by Bjoern Thomsen
Gruß, Björn

[Stefan Mettenbrink]

Post by Thomas Hechelhammer
Ich sehe bei XML, welches ich als eine Ergänzung zu HTML sehe, das
Risiko dass diverse Hersteller den Standard wieder verwässern und
jeder sein eigenes Süppchen kocht. -> CD, -> DVD usw.

Ich nicht. Es gibt nur immer wieder Firmen/Personen, die sich nicht an
den Standard halten. Dadurch ändert sich nicht der Standard.
Nur weil viele schneller fahren als erlaubt, ändert sich ja auch nicht
die Straßenverkehrsordnung.

Es ist alles eine Frage, was sich der Kunde gefallen läßt.

MfG, Metti.

[Stefan Mettenbrink]

Post by Bjoern Thomsen
IMO wird XML länger Bestand haben als GEDCOM.

IHMO wird GEDCOM länger Bestand haben als XML.

MfG, Metti.

[Stefan Mettenbrink]

Post by Thomas Hechelhammer
Meiner Meinung nach braucht XML kein Mensch wirklich, genauso wenig
wie HTML.

Wenn Du Deine Daten ins Internet bringen möchtest, halte ich HTML schon
für nötig. Sonst könnte ich auch sagen, die Daten Verstorbener braucht
auch keiner.

Post by Thomas Hechelhammer
Das Riesenproblem: Kein Programm ist bezüglich der Datenbankstruktur
kompatibel zum anderen, noch nicht mal die gemeinsame Schnittstelle
Gedcom funktioniert.
Und an diesem Standard sollte dringend gearbeitet werden.

Du hattest meine Ausführungen diesbezüglich gelesen?
Das funktioniert nie.

Post by Thomas Hechelhammer
(Die könnte er wenigstens als ASCII-Text im jeweiligen Datensatz als
Gedcom-Zusatz speichern damit nichts verloren geht).
Und später wieder mit exportieren.

Das hilft nicht.
Mein Programm fasst alle nicht importierten Zeilen einer Gedcomdatei
(mit Zeilennummer) in einer Protokolldatei zusammen. Daran kann man
erkennen, was nicht übernommen wurde. Selbst wenn ich diese Daten an
einen Export anhänge, fehlt die Verbindug zu den Personen, denen diese
Daten gehören.
Außerdem werden manchmal gar nicht alle Personen exportiert. Soll ich
dann auch allen nicht importierten Zeilen anfügen?
Was ist mit den Daten, die ich zwar importiert habe, diese aber in
irgendwelche Bemerkungen geschrieben habe?
Außerdem kannst Du zu einem Individuum nicht einfach Daten anhängen. Du
müsstest dafür eine Bemerkung anlegen. Könnte man machen, würde aber nur
wieder eine bemerkung sein. Man bekäme die Daten nicht wieder zu dem,
was sie mal waren.
Übrigens gibt es noch Daten, die zu Familien gehören, die kann ich nicht
an ein Individuum hängen.

Deine Überlegungen in allen Ehren, leider sind sie nicht praktikabel.

Das Einzige was funktionieren würde, wäre, wenn alle Programme auf
dieselben Datensätze zugreifen und nur die Feler auslesen und
beschreiben, die sie selber nutzen. Dabei muss aber gewährleistet sein,
dass das Fomat so aufgebaut ist, dass belibig viele neue Felder angelegt
werden können und das man nie den Gesamtdatenbestand ändert.

Nachteil:
Felder, die denselben Inhalt haben, von unterschiedlichen Programmen
aber unterschiedlich bezeichnet werden, sind doppelt vorhanden und
werden wieder nicht von allen erkannt.
Alle Programme müssten immer mit diesem Datenformat arbeiten. Sobald in
ein eigenes Format umgewandelt wird haben wir das gleiche Problem wie
zuvor.

MfG, Metti.

[Gerd Schmerse]

Post by Gerhard Bauch
Aber die Frage des OP lautete ja, welche Programme unterstützen welche
Hier ein Versuch, diese Antwort für DYNAS-TREE zu geben : (Export Option =
GEDCOM 5.5 )

hier für Brother's Keeper (ohne Garantie auf Vollständigkeit):

0 HEAD
0 TRLR
0 @F...@
0 @I...@
0 @R...@
0 @S...@
0 @SUB1
1 ABBR
1 ADDR
1 ADOP
1 AFN
1 ANCI
1 ANUL
1 ASSO
1 AUTH
1 BAPL
1 BAPM
1 BARM
1 BASM
1 BIRT
1 BLES
1 BURI
1 CAST
1 CENS
1 CHAR
1 CHIL
1 CHR
1 CHRA
1 CONF
1 CONL
1 CREM
1 DATE
1 DEAT
1 DESI
1 DEST
1 DIV
1 DIVF
1 DSCR
1 EDUC
1 EMAIL
1 EMIG
1 ENDL
1 ENGA
1 EVEN
1 FAMC
1 FAMS
1 FAX
1 FCOM
1 FILE
1 GEDC
1 GRAD
1 HUSB
1 IDNO
1 IMMI
1 MARB
1 MARC
1 MARL
1 MARR
1 MARS
1 NAME
1 NATI
1 NATU
1 NCHI
1 NOTE
1 OBJE
1 OCCU
1 ORDN
1 PHON
1 PROB
1 PROP
1 PUBL
1 REFN
1 RELI
1 REPO
1 RESI
1 RETI
1 RFN
1 SEX
1 SLGC
1 SLGS
1 SOUR
1 SSN
1 SUBM
1 TEXT
1 TITL
1 WIFE
1 WILL
1 WWW
2 ADDR
2 CALN
2 CONT
2 DATE
2 DESC
2 EMAIL
2 FAX
2 FILE
2 FORM
2 MEDI
2 NICK
2 PHON
2 PLAC
2 PRTY
2 RELA
2 REPO
2 SOUR
2 STAT
2 TITL
2 TYPE
2 VERS
2 WWW
3 CONT
3 DATA
3 NOTE
3 PAGE
3 QUAY
4 TEXT

1 _ADPF
1 _ADPM
1 _BRTM
1 _COML
1 _EYEC
1 _FNRL
1 _HAIR
1 _HEIG
1 _INTE
1 _MARI
1 _MBON
1 _MEDC
1 _MILT
1 _MSTA
1 _NLIV
1 _NMAR
1 _NMR
1 _PRMN
1 _SEPR
1 _TODO
1 _WEIG
1 _YART
2 _ADPN
2 _AKAN
2 _BIRN
2 _CENN
2 _CURN
2 _EVN
2 _FARN
2 _FKAN
2 _FRKA
2 _GERN
2 _HEBN
2 _INDN
2 _LOCL
2 _MARN
2 _OTHN
2 _RELN
2 _SHON
2 _SLDN


Gruß
Gerd (Schmerse)
Moderator BK-L

[Stefan Mettenbrink]

Leider ist eine rein alphabetische Reihenfolge der Tags sinnlos.

So kann das Tag NOTE bei der Taufe ausgelesen und zugeordnet werden ohne
das dadurch zwangsläufig eine Bemerkung zum Tempelcode ebenfalls korrekt
behandelt wird.

Ich sehe keine wirklich sinnvolle Möglichkeit die "verstandenen" Tags
aufzulisten.

MfG, Metti.

[Gerd Schmerse]

Post by Stefan Mettenbrink
Leider ist eine rein alphabetische Reihenfolge der Tags sinnlos.

Die Befürchtung hatte ich beim Posten auch irgendwie :-(

Post by Stefan Mettenbrink
Ich sehe keine wirklich sinnvolle Möglichkeit die "verstandenen" Tags
aufzulisten.

Vielleicht als komplette Gedcom-Datei, die wollte ich aber wegen der Länge
nicht posten. Wenn's jemand interessiert, kann er mir mailen unter
brothers-keeper-l ett genealogy.net

Gruß
Gerd (Schmerse)
Moderator BK-L

[Stefan Mettenbrink]

Post by Gerd Schmerse

Post by Stefan Mettenbrink
Ich sehe keine wirklich sinnvolle Möglichkeit die "verstandenen" Tags
aufzulisten.

Vielleicht als komplette Gedcom-Datei, die wollte ich aber wegen der Länge
nicht posten.

Da wäre es möglicherweise sinnvoll, die Datei tgc55c.ged zu benutzen.
Diese Datei enthält (angeblich) alle Möglichkeiten die Gedcom bietet.
Diese Datei importieren und anschließend exportieren. Dann kann man in
etwa erkennen, was übriggeblieben ist.
Die Datei findet man z.B. bei <http://www.geditcom.com/gedcom.html> oder
auf meiner Homepage.

MfG, Metti.

[Markus]

Liebe Profis,

aus meinem Heimaturlaub zurück lese ich freudig-erstaunt, welch
intensive Arbeit meine Frage bei Euch ausgelöst hat. Offensichtlich
scheint am "Standard" noch einiges zu verbessern zu sein...

Verstanden habe ich (glaub...):
die aus meinen Daten für den Import zu erzeugende Gedcom Datei besteht
aus einem HEAD, meinen 3000 INDI-Sätzen, und vielen FAM-Sätzen (für
jede Beziehung mit Kindern einen).

Also habe ich meine Daten mal aufgedröselt und in 3 Excel-Tabellen
gepackt und dort folgende Spalten erzeugt - ich möchte gern wissen, ob
das so ok ist (bzw. was ich wie verändern muss):

Tabelle Header:

0 HEAD
1 SOUR
2 NAME das ist der der die Datei geschrieben hat
3 ADDR das ist da wo er wohnt
1 DATE das ist das Datum der Dateierstellung, z.B.: 1.1.2006
1 CHAR das ist das Zeichensatzformat, z.B.: ???
1 NOTE hier schreibe ich Bemerkungen zu dieser Datei
2 CONT das ist der Titel/Inhalt der Datei, z.B.: 3000 Nachfahren von...
1 FILE das ist der Dateiname, z.B.: Familie.ged
1 GEDC
2 VERS 5.5


Tabelle Individuum:

0 @I1@ INDI
1 NAME Pfarrer Dr. med. Hans-Peter Fritz MÜLLER-Huber jr.
2 GIVN Hans-Peter Fritz
2 NPFX Pfarrer
2 SPFX Dr. med.
2 SURN MÜLLER-Huber
2 NICK Hansi
2 NSFX jr.
1 SEX M
1 NCHI (Zahl aller Kinder mit allen Frauen)
1 BIRT
2 DATE Geburtstag, z.B. 1.1.1870
1 DEAT
2 DATE Geburtstag, z.B. 1.1.1950
1 OCCU Berufe, z.B.: Maurer, Bau-Ing., Unternehmer
1 RESI München, Bayern / Deutschland, Europa
2 ADDR Königsallee 52
2 POST 80000
2 CITY München
2 STAE Bayern
2 LAND Deutschland
1 NMR (Anzahl der Partnerschaften)
1 FAMS @F1@ (Verweis auf 1. Partnerschaft)
1 FAMS @F1@ (Verweis auf n. Partnerschaft)
1 FAMC @F4@ (Verweis auf: ist-Kind-von-Familie...)
1 NOTE Bemerkungen zu dieser Person
1 CHAN
2 DATE Aktualisierungsdatum


Tabelle Familien:

0 @F1@ FAM (fortlaufende Nummer)
1 HUSB @I1@
1 WIFE @I2@
1 MARR
2 DATE (Heiratsdatum)
2 PLAC Heiratsort
1 DIV
2 DATE (Trennungs/Scheidungsdatum)
1 CHIL @I3@ (1. Kind mit dieser Frau)
1 CHIL @I4@ (2. Kind mit dieser Frau)
1 CHIL @I5@ (n. Kind mit dieser Frau)
1 NCHI (Anzahl Kinder mit dieser Frau)
1 NOTE Bemerkungen zu dieser Familie


Wenn ich bei einer Person in einem Feld keinen Eintrag habe, lasse ich
dann für diese Person den ganzen Tag weg? oder nur den Inhalt dafür
leer?

Womit wird eine Tag-Zeile abgeschlossen (was ist der Trenner)?
Zeischen den Tabellen ist der Trenner dir "Null" von INDI bzw. von FAM?

Zuerst schreibe ich den Header, dann alle Individuen, dann alle
Familien und zum Schluss "0 TRLR" in die Datei?

Entspicht das so der Gedcom-55-Norm?
Welche Programme würden eine solche Datei dann als Inport vollständig
verstehen?

Zusätzlich könnte ich aus meinen Daten noch erzeugen:
Vater-ist @Ixy@
Mutter-ist @Ixy@
Partner-ist @Ixy@
Generation: Zahl für Ebene der Generation
Mädchenname-der-Partnerin

wäre das irgendwie nützlich?
Muss ich sonst noch irgendwas erzeugen?
(für Stammbäume z.B. oder für Ahnentafeln?)

Herzlichen Dank!
Markus

[Stefan Mettenbrink]

Post by Markus
die aus meinen Daten für den Import zu erzeugende Gedcom Datei besteht
aus einem HEAD, meinen 3000 INDI-Sätzen, und vielen FAM-Sätzen (für
jede Beziehung mit Kindern einen).

Ja.

Post by Markus
0 HEAD
1 SOUR
2 NAME das ist der der die Datei geschrieben hat
3 ADDR das ist da wo er wohnt
1 DATE das ist das Datum der Dateierstellung, z.B.: 1.1.2006
1 CHAR das ist das Zeichensatzformat, z.B.: ???
1 NOTE hier schreibe ich Bemerkungen zu dieser Datei
2 CONT das ist der Titel/Inhalt der Datei, z.B.: 3000 Nachfahren von...
1 FILE das ist der Dateiname, z.B.: Familie.ged
1 GEDC
2 VERS 5.5

CHAR ist die Zeichenkodierung. Zulässig nach Gedcom 5.5 sind lediglich
ASCI, ANSEL und UNICODE (ANSI ist verboten). Mit Gedcom 5.5.1 (Entwurf)
wurde noch UTF-8 hinzugefügt.

Post by Markus
1 NCHI (Zahl aller Kinder mit allen Frauen)

Gehört das nicht in den FAM-Record?

Post by Markus
1 NMR (Anzahl der Partnerschaften)

Beide Angabe ergeben sich IMHO zwangsläufig aus den vorhandenen Daten.
Sind also nicht zwingend erforderlich. Es sei denn, Du möchtest irgendwo
festhalten, dass 5 Kinder und 3 Ehen bestanden, Du die genaueren Daten
nicht kennst.

Ansonsten sind Deine Angaben *ein Teil* der Möglichkeiten von Gedcom.

Post by Markus
Wenn ich bei einer Person in einem Feld keinen Eintrag habe, lasse ich
dann für diese Person den ganzen Tag weg? oder nur den Inhalt dafür
leer?

Beides führt zu identischen Ergebnissen.
Ob es Programme gibt, dessen Import bei leeren Tags Probleme macht, kann
ich nicht sagen.

Post by Markus
Womit wird eine Tag-Zeile abgeschlossen (was ist der Trenner)?

Zeilenumbruch.

Post by Markus
Zeischen den Tabellen ist der Trenner dir "Null" von INDI bzw. von FAM?

Keine Leerzeilen.
Eine Zeile
0 @I1@ INDI
kennzeichnet eine neue Person
0 @F94@ FAM
kennzeichnet eine neue Familie.

Also jeweils die Null am Zeilenanfang markiert den neuen Record
(Datensatz)

Post by Markus
Zuerst schreibe ich den Header, dann alle Individuen, dann alle
Familien und zum Schluss "0 TRLR" in die Datei?

Ja.
Wenn Du noch NOTE-, SOUR- oder SUBM-records hast, solltest Du diese
ebenfalls anfügen.
(siehe Seite 24 der Gedcomdefinition)

Post by Markus
Entspicht das so der Gedcom-55-Norm?

Im Groben.

Post by Markus
Welche Programme würden eine solche Datei dann als Inport vollständig
verstehen?

Alle, die Gedcom 5.5 richtig implementiert haben.
Gehört in den FAM-Record.

Post by Markus
Generation: Zahl für Ebene der Generation

Ergibt sich zwangsläufig aus der Angabe des Probanden bzw. Spitzenahn
(je nach dem, wo Du beginnst).

Post by Markus
Mädchenname-der-Partnerin

Beides wird nicht von Gedcom unterstützt.

Post by Markus
Muss ich sonst noch irgendwas erzeugen?

Quellenangabe wären sinnvoll, wenn man sie hat.

Post by Markus
(für Stammbäume z.B. oder für Ahnentafeln?)

Das sollten die Programme aus den Daten selber heraussuchen. Hier kommt
es auf das Können der Programme an.

MfG, Metti.

[Gerd Schmerse]

Post by Stefan Mettenbrink

Post by Markus
1 NCHI (Zahl aller Kinder mit allen Frauen)

Gehört das nicht in den FAM-Record?

Gibt's m.W. beides (Kinder aller Ehen, Kind dieser Ehe)


Gruß
Gerd (Schmerse)

[Gerd Schmerse]

Post by Markus
Liebe Profis,

...ich antworte trotzdem... ;-))

Post by Markus
2 CONT das ist der Titel/Inhalt der Datei, z.B.: 3000 Nachfahren von...

CONT ist einfach continue, Fortsetzung der vorangegangenen Notiz, damit die
Zeile nicht zu lang wird
aber nicht zweimal dieselbe Nr.

Post by Markus
Mädchenname-der-Partnerin

Das ist eigentlich der, den man als Namen einträgt; erforderlich wäre
höchstens der Ehename, den Gedcom aber nicht hat (Brother's Keepr verwendet
_MARN marriage name).


Gruß
Gerd (Schmerse)

[Stefan Mettenbrink]

Post by Gerd Schmerse

Post by Markus
2 CONT das ist der Titel/Inhalt der Datei, z.B.: 3000 Nachfahren von...

CONT ist einfach continue, Fortsetzung der vorangegangenen Notiz, damit die
Zeile nicht zu lang wird

Ach ja, guter Hinweis. Die Zeilenlänge ist begrenzt (länge weiß ich
gerade nicht) und das Tag CONC verlangt zudem die Trennung an einer
Stelle ohne Leerzeichen und die beiden Zeilen werden direkt aneinander
gefügt. CONT ist halt mit Zeilenumbruch.

Post by Gerd Schmerse

Post by Markus
Mädchenname-der-Partnerin

Das ist eigentlich der, den man als Namen einträgt; erforderlich wäre
höchstens der Ehename, den Gedcom aber nicht hat (Brother's Keepr verwendet
_MARN marriage name).

Hattest Du die Diskusion in der Programmierer-Mailingliste verfolgt?
Schade, dass es da keinen Konsens gegeben hat.

MfG, Metti.

[Gerd Schmerse]

Post by Stefan Mettenbrink

Post by Gerd Schmerse

Post by Markus
Mädchenname-der-Partnerin

Das ist eigentlich der, den man als Namen einträgt; erforderlich wäre
höchstens der Ehename, den Gedcom aber nicht hat (Brother's Keepr verwendet
_MARN marriage name).

Hattest Du die Diskusion in der Programmierer-Mailingliste verfolgt?

Ich befürchte, die ganze Liste ist an mir vorbeigegangen...
ich kenne nur genealogie-programme und cg-tester.


Gruß
Gerd (Schmerse)

[Stefan Mettenbrink]

Post by Gerd Schmerse

Post by Stefan Mettenbrink
Hattest Du die Diskusion in der Programmierer-Mailingliste verfolgt?

Ich befürchte, die ganze Liste ist an mir vorbeigegangen...
ich kenne nur genealogie-programme und cg-tester.

Das ist eine geschlossene Gruppe, ich weiß nicht, welche Kriterien die
anlegen, damit Du sie bekommst.

MfG, Metti.

[Markus]

Hallo Gerd und hallo Metti,
hallo andere Profis,

wie ist die Konvention für NAME, SURN:

- das Kind heisst Eva Müller
nach der Heirat heisst die Frau
- Eva MEIER-Müller
aber vielleicht auch
- Eva MEIER
- Eva MÜLLER
- Eva Müller-Meier
und manchmal sieht man auch
- Eva /Müller/

Nimmt man immer den Namen, den der Mensch aktuell grad verwendet?
Und wie findet man dann den Menschen wie er früher mal geheissen hat?

Wie ist die Konvention für DATE:
- 1.1.2006
- 1. Jan. 2006
- 01.01.2006
und wie ist das mit amerikanischem DATE?

Wie ist das mit CHAR:
wenn ich aus Excel per VBA in eine GedcomTextdatei.ged schreibe,
ist das dann das richtige Zeichenformat? welches?
(und falls nicht: was muss ich tun?)

Wie ist das mit NOTE:
kann ich das einfach an INDI bzw. FAM "dranhängen"
oder brauche ich da eine zusätzliche Struktur mit "Verweis"?

Wieviele Zeichen passen in NOTE, bzw. müssen in CONT fortgesetzt
werden?

Herzlichen Dank!
Markus

[Stefan Mettenbrink]

Post by Markus
- das Kind heisst Eva Müller
nach der Heirat heisst die Frau
- Eva MEIER-Müller
aber vielleicht auch
- Eva MEIER
- Eva MÜLLER
- Eva Müller-Meier
und manchmal sieht man auch
- Eva /Müller/
Nimmt man immer den Namen, den der Mensch aktuell grad verwendet?
Und wie findet man dann den Menschen wie er früher mal geheissen hat?

Für Gedcom gibt es in diesem Bereich keine Vorgabe. Ich empfehle jedem,
den Geburtsnamen zu nehmen. Der ist immer der Geburtsname und wird auch
immer der geburtsname bleiben. Wenn Du magst kannst Du bei einer
Änderung des Namens in der entsprechenden Bemerkung auf die Änderung
hinweisen.

Post by Markus
- 1.1.2006
- 1. Jan. 2006
- 01.01.2006
und wie ist das mit amerikanischem DATE?

Für DATE gibt es verschiedene Varianten. Die flexibelste ist "Freitext".

Ansonsten ist gerade der Bereich sehr umfangreich. Es gibt Date,
Date_Aproximated, Date_Calendar, Date_Caledar_Escape, Date_exact,
DateFren, Date_Greg, ...
Am Besten schaust Du mal in der Doku ab Seite 39 nach.

Interessant sind auch die Seiten zur Monatsangabe ab Seite 46.

Das ist leider nicht alles mit zwei Sätzen erklärt und Du wirst nicht
umhinkommen, hier mal in die Dokumentation zu schauen.
Oder Du fragst etwas gezielter.

Post by Markus
wenn ich aus Excel per VBA in eine GedcomTextdatei.ged schreibe,
ist das dann das richtige Zeichenformat? welches?

Ich weiß nicht was Excel kann. Ich befürchte, das kann nur Windows Ansi
Codepage 1252 (jedenfalls wenn Du die deutsche Version benutzt)

Post by Markus
kann ich das einfach an INDI bzw. FAM "dranhängen"
oder brauche ich da eine zusätzliche Struktur mit "Verweis"?

Beides ist möglich.

Post by Markus
Wieviele Zeichen passen in NOTE, bzw. müssen in CONT fortgesetzt
werden?

Habe ich nicht im Kopf und heute Morgen auf die Schnelle nicht gefunden.
Ich habe es aber sicher mal in der Doku gelesen.
Die Anzahl der Bemerkungen ist nicht begrenzt und auch eine
Längenbegrenzung kenne ich nicht. Abgesehen von der Zeilenlänge.
In diesem Zusammenhang vieleicht noch der Hinweis auf das Zeichen @. Es
muss in einer Gedcomdatei immer gedoppelt werden. Also wird aus
"***@aol.de" "ich@@aol.de"
(der Sinn entzieht sich meiner Kenntnis, ist aber so definiert)

MfG, Metti.

[Markus]

Lieber Metti,

Deine Hinweise zu @@ und die einfache NOTE-Version ohne Verweis habe
ich verstanden.
Hinweise auf das englische pdf helfen mir leider nicht.

DATE
ich habe ein Datum (BRD, CH, F)
und kann das in verschiedenem Format darstellen.
Welches Format bevorzugt Gedcom/dieGenealogie ?
TT.MM.JJJJ z.B.: 01.01.2006
T.M.JJJJ z.B.: 1.1.2006

NAME, GIVN, SURN
verheiratete Menschen mit ihrem Taufnamen zu benennen wäre (zumindest
in der Schweiz) ziemlich unüblich. Bei uns sagt man: "Luisa Susanne
MEIER-Müller" oder "Luisa Susanne MEIER, geborene Müller".
welcher Inhalt gehört in welches Feld?
wo brauche ich "/" als Begrenzer/Trenner?

CHAR
Excel verwendet Windows Ansi. Das kann ich in eine Text-Datei
schreiben.
Gedcom braucht aber "UTF-16"?
Wie mache ich das?
Gibts da ein "Übersetzungs-Makro"? wo?

NOTE, CONT
wieviele Zeichen jeweils?

Ist das jetzt genügend gezielt?

Danke,
ein etwas frustrierter Markus

[Stefan Mettenbrink]

Post by Markus
Hinweise auf das englische pdf helfen mir leider nicht.

Du wirst nicht umhinkommen dort nachzulesen. Notfalls musst Du die
entsprehenden Passagen mit z.B. <http://babelfish.altavista.com/tr>
übersetzen lassen.

Post by Markus
Welches Format bevorzugt Gedcom/dieGenealogie ?
TT.MM.JJJJ z.B.: 01.01.2006
T.M.JJJJ z.B.: 1.1.2006

Es gibt in Gedcom kein bevorzugtes Datumsformat.
Aber es gibt Programme, die mit bestimmten Datumsformaten zusätzliche
Funktionen (z.B. eine Plausibilitätsprüfung) bieten. Das ist allerdings
programmabhängig und hat nichts mit Gedcom zu tun.

Ich empfehle die einfachste Variante. Freitext. Übernimm das Datum so,
wie es Dir vorliegt. Im übrigen ist das "amtliche" Datumsformat in
Deutschland nicht TT.MM.JJJJ.

Post by Markus
verheiratete Menschen mit ihrem Taufnamen zu benennen wäre (zumindest
in der Schweiz) ziemlich unüblich. Bei uns sagt man: "Luisa Susanne
MEIER-Müller" oder "Luisa Susanne MEIER, geborene Müller".

Nicht nur bei euch.
Für die Genealogie ist der Geburtsname aber der einzig unveränderliche
Name. Alles andere sind
genaugenommen zusätzliche Ereignsse.

Post by Markus
welcher Inhalt gehört in welches Feld?

Du hatest die verfügbaren Tags bereits aufgezählt. Für einen definierten
Geburts- oder Ehenamen gibt es kein Tag.

Post by Markus
wo brauche ich "/" als Begrenzer/Trenner?

Nur für das NAME-Tag. Dort wird der Nachname in / gesetzt.

Post by Markus
Gedcom braucht aber "UTF-16"?

Gedcom läßt ASCII, ANSEL, UNICODE (UTF-16) nd seit Gedcom 5.5.1 auch
UTF-8 zu.

Post by Markus
Gibts da ein "Übersetzungs-Makro"? wo?

<http://www.familienbande-genealogie.de/tool.htm>

Post by Markus
Ist das jetzt genügend gezielt?

Ja.

MfG, Metti.

[Gerd Schmerse]

Post by Markus
Wo finde ich eine Matrix, in der die Schnittstellen definiert sind?
(welches Programm verarbeitet welche TAGs)

Noch ein Tip dazu:

BK-Nutzer Otto Joergensen aus Norwegen hat eine Webseite, auf der Tags
erklärt sind, die aber auch eine Liste von *User*-Tags enthält mit der
Angabe, welches Programm die nutzt:
http://home.online.no/~otjoerge/bk/gedcom_trans.htm


Gruß
Gerd (Schmerse)
Moderator BK-L