Rufnamen und GEDCOM

Metti hat geschrieben:
Da die Gedcomdefinition von den Mormonen herausgegeben wird und die
nichts ändern (GdcomXML liegt als Entwurf seit mindestens 2001 vor)
kann man nur in einem begrenzten Rahmen agieren. Wenn ein Großteil der
deutschen Genealogieprogramme mitziehen ist das schon gut. Leider wird
man wohl nie alle unter einen Hut bringen.

Das wäre doch eine Riesen Chance für die deutschen Programme, wenn sie einen eigenen verbesserten excellenten Export- und Import Standard anbieten würden. Warum kann man nicht zwei Ex- und Import Formate anbieten.
Dann hätte man dieses vermaledeite Mormonen Gedcom los mit den verbundenen Datenverlusten los.

Viele Grüße
Thomas Landsgesell

thomas@landsgesell.net wrote:

Warum kann man nicht zwei Ex- und Import Formate anbieten.
Dann hätte man dieses vermaledeite Mormonen Gedcom los mit den verbundenen Datenverlusten los.

Der Datenverlust liegt nicht nur am Gedcomformat. Die meisten Probleme bestehen durch die Programmstrutur. In meinem Programm gibt es z.b. keine Tempelcodes und keine Konfirmation. Somit kommen diese Daten in die Bemerkung. Beim erneuten Export und Übernahme in ein anderes Programm landen die natürlich nicht auch dort in der Bemerkung, weil sie als Bemerkung exportiert werden.

So gibt es sicherlich viel Fälle, wo Probleme auftauchen. Das lässt sich durch ein weiteres Format nicht ändern. Da finde ich die Erweiterung deutlich sinnvoller, weil auch Programme, die die Erweiterung nicht kennen, die Daten importieren. (natürlich ohne die Erweiterungen)

MfG, Metti.

Metti hat am Mittwoch den 27. Oktober 2004 geschrieben:
"Da finde ich die Erweiterung deutlich sinnvoller, weil auch Programme, die
die
Erweiterung nicht kennen, die Daten importieren. (natürlich ohne die
Erweiterungen)"

Hallo,
damit würde sich gut leben lassen, wenn möglichst alle deutschen und soweit
möglich europäischen Programmhersteller diesen Erweiterungsstandard in ihr
Programm einbauen und ihn weiterentwickeln. Vielleicht wurde es hier schon
einmal beantwortet und ich habe es verpasst, aber wie sieht der aktuelle
Stand gerade aus? Gibt es da eine große Gruppe, die für dieses Ziel
zusammenarbeitet? Wann bekommt Gedcom 5.5 EL "Gesetzeskraft"?

Viele Grüße Thomas Landsgesell

Thomas Landsgesell wrote:

Wann bekommt Gedcom 5.5 EL "Gesetzeskraft"?

Gar nicht.
Gedcom wird/wurde von den Mormonen entwickelt (1995?) und eine Erweiterung 2001 entworfen. Dabei ist es geblieben :frowning:

Jeder der möchte kann die Erweiterung Gedcgom EL einsehen und implementieren.

MfG, Metti.

Metti hat geschrieben:
"Gedcom wird/wurde von den Mormonen entwickelt (1995?) und eine
Erweiterung 2001 entworfen. Dabei ist es geblieben :frowning:
Jeder der möchte kann die Erweiterung Gedcgom EL einsehen und
implementieren."

Aber das war ja das Ausgangsstatement. Warum ergreifen nicht die deutschen
Programmhersteller die Initiative, bilden ein Konsortium und bauen diese
Erweiterung ein. Das wäre doch die beste Werbung für ihre Programme und eine
Weiterentwicklung, Verbesserung des Standards wäre gegeben.

Viele Grüße
Thomas Landsgesell

Thomas Landsgesell wrote:

Aber das war ja das Ausgangsstatement. Warum ergreifen nicht die deutschen
Programmhersteller die Initiative, bilden ein Konsortium und bauen diese
Erweiterung ein.

So ist der Stand der Dinge.
Es scheinen sich nicht viele Hersteller darum zu bemühen.
Möglicherweise, weil sie von den Kunden nicht darauf angesprochen werden.

MfG, Metti.

Hi,

[..]

Gerhard Schmidt-Wagner wrote:

Es wird wahrscheinlich trotzdem von einigen Herstellern nicht
umgesetzt werden (können).
1) weil sie eventuell ihre komplette Programmstruktur
ändern müssten. 5.5 EL kann z.B. nur mit einer zentralen
Ortsverwaltung realisiert werden.

Ich sehe noch einen ganz anderen Punkt. Alles was ich nicht benötige unterstütze ich nicht beim Export. Wozu die Arbeit machen?
Beim Import die gleiche Situation. Wenn es mir nicht hilft und es mir nichts bringt, mach ich mir doch lieber nicht die Arbeit.

Erst wenn in genalogischen Zeitschriften und bei Programmtests darauf hingewiesen wird und die Konkurrenz dadurch Pluspunkte erhält, werden manche Hersteller etwas ändern. Es könnten ja Kunden abwandern, weil sie etwas besseres gefunden haben (oder auch nur darauf aufmerksam werden).

MfG, Metti.

Moin allerseits,

an dieser Stelle m�chte ich alle Programmierer,
die nicht von Anfang an an der GEDCOM 5.5EL
Diskussion beteiligt waren, einladen, sich dem
Vorschlag anzuschliessen.

Die WIKI-Seite
http://wiki.genealogy.net/index.php/Gedcom_5.5EL
kann von allen nach Einloggen bearbeitet werden
und ich m�chte alle Programmhersteller die sich
dem Vorgehen anschliessen m�chten, sich dort auf
der Seite bei den Vorschlagenden mit einzutragen.

Na dann mach ich doch mal den Vorschlag, dass jeder, der unbedingt
Gedcom 5.5 EL haben will, dem Hersteller seines benutzten Programms
"Dampf macht" und ank�ndigt, k�nftige Updates/Upgrades nicht mehr zu
erwerben, wenn Gedcom 5.5 EL nicht "eingebaut" wird.
Angeblich gibt es ja so etwas wie eine "Macht der Verbraucher".

Supi, dann bin ich ja mal gespannt, was da auf mich zukommt ... :wink:

Es wird wahrscheinlich trotzdem von einigen Herstellern nicht
umgesetzt werden (k�nnen).
1) weil sie eventuell ihre komplette Programmstruktur
   �ndern m�ssten. 5.5 EL kann z.B. nur mit einer zentralen
   Ortsverwaltung realisiert werden. Nur wer nur ein bisschen
   Ahnung vom Programmieren hat, kann erahnen wieviel Arbeit
   hinter einer derartigen Umstrukturierung steckt.

Ich glaube, das ist eines der wenigen Male, dass im Zusammenhang mit EL der Begriff Ortsverwaltung f�llt. Und genau das ist es auch schon. Alle �brigen Mails gehen mir zu sehr in die Richtung "Hurra, mit dem neuen Standard werden jetzt alle Programme noch GEDCOM-kompatibler!".

Es geht doch nur darum zus�tzliche Ortsinformationen ins GEDCOM zu packen, die dort vorher gar nicht enthalten waren.

Man sollte sich nichts vormachen: f�r den Anwender bedeutet das Mehrarbeit. Man kann nicht mehr einfach nur einen Ort, wie "Neustadt" eingeben, sondern muss aus einer Liste von FOKO-K�rzeln, Postleitzahlen oder �hnliches den Ort noch konkreter beschreiben. Und wehe man vertut sich, weil man gerade nicht die richtige Postleitzahl von Stettin oder die L�ngen- und Breitengrade von Stuttgart zur Hand hat ... :wink:
Dann ist der GEDCOM-Export am Ende doch wieder so ungenau wie vorher.

Umsetzen werden das nur die Programmierer, die auch voll hinter der Thematik "Ortsverwaltung" stehen. Eine internationale Umsetzung scheint mir h�chst unwahrscheinlich, da GEDCOM 5.5 EL sehr stark mit GOV verbunden ist, also einer Datenbank von rein deutschen (auch ehemaligen) Orten.

Die zwei Punkte bzgl. Taufpaten und Trauzeugen haben damit relativ wenig zu tun. Da wurde nur mal schriftlich festgehalten, was einzelne Programme ohnehin schon seit Jahren verwenden (_GODP gibt es in Ahnenblatt schon seit mindestens zwei Jahren - EL-Standard w�rde ich das noch nicht nennen).

2) Weil dann jeder Nutzer uneingeschr�nkt sein Programm wechseln
   k�nnte und dann vielleicht bei der Konkurrenz "h�ngenbleibt"

Och, menno! Da kommt schon wieder dieses "GEDCOM wird kompatibler!" ...
Das hat doch mit EL ( = Extended Locations ) gar nichts zu tun.

Gru�, Dirk (www.ahnenblatt.de).

Klaus-Peter Wessel wrote:

an dieser Stelle möchte ich alle Programmierer,
die nicht von Anfang an an der GEDCOM 5.5EL
Diskussion beteiligt waren, einladen, sich dem
Vorschlag anzuschliessen.

Danke.
Da ich noch nicht auf Unzulänglichkeiten bei Gedcom gestoßen bin (mein Gedcombereich ist noch langen nicht fertig), werde ich sicher später darauf zurückkommen.

MfG, Metti.

Dirk Böttcher wrote:

Man sollte sich nichts vormachen: für den Anwender bedeutet das Mehrarbeit. Man kann nicht mehr einfach nur einen Ort, wie "Neustadt" eingeben, sondern muss aus einer Liste von FOKO-Kürzeln, Postleitzahlen oder ähnliches den Ort noch konkreter beschreiben. Und wehe man vertut sich, weil man gerade nicht die richtige Postleitzahl von Stettin oder die Längen- und Breitengrade von Stuttgart zur Hand hat ... :wink:
Dann ist der GEDCOM-Export am Ende doch wieder so ungenau wie vorher.

Ich habe das so gelöst, das ich eine Combobox für den Ort biete. Dort kann ich den Ort so eingeben, wie ich möchte (oder der Gecomimport ihn bekommt). Wenn der Nutzer möchte, kann er den Ort in der Ortsverwaltung genauer beschreiben, dann kann er den Ort in einem Auswahlmenü raussuchen. Das ist für den Nutzer flexibel genug und führt nicht zwangsläufig zu mehr Arbeit.

Umsetzen werden das nur die Programmierer, die auch voll hinter der Thematik "Ortsverwaltung" stehen. Eine internationale Umsetzung scheint mir höchst unwahrscheinlich, da GEDCOM 5.5 EL sehr stark mit GOV verbunden ist, also einer Datenbank von rein deutschen (auch ehemaligen) Orten.

Deine Einschätzung teile ich.

MfG, Metti.

Hi,

[...]

Betreff: Re: AW: [Gen-Programme] GEDCOM Erweiterung

Dirk B�ttcher wrote:

[...]

Umsetzen werden das nur die Programmierer, die auch voll hinter der
Thematik "Ortsverwaltung" stehen.

Kommt man ohne Ortsverwaltung �berhaupt weiter? F�r mich ist das �hnliche
wichtig wie eine Verwaltung der Quellenangaben.

Eine internationale Umsetzung scheint
mir h�chst unwahrscheinlich, da GEDCOM 5.5 EL sehr stark mit GOV
verbunden ist, also einer Datenbank von rein deutschen (auch ehemaligen)
Orten.

Das GOV ist nicht unbedigt auf deute Orte beschr�nkt. Die Schweiz ist schon
jetzt dabei, �sterreich kommt vermutlich demn�chst dazu.

Auch die Aufnahme weiterer Staaten ist nicht ausgeschlossen. Ich habe
dahingehend schon einige Kontakte gekn�pft.

Gru�
Jesper

- --
Jesper Zedlitz eMail : jesper@zedlitz.de
                  Homepage : http://www.zedlitz.de
                  ICQ# : 23890711

Moin Klaus-Peter Wessel,

zur Mail vom Wed, 27 Oct 2004 21:54:55 +0200:

GEDCOM 5.5EL
Diskussion

Eines hab ich noch nicht verstanden:
Beruht 5.5EL tats�chlich auf 5.5 oder auf 5.5.1? Ich habe den Eindruck,
ersteres ist der Fall. Ist das nicht eine sch�dliche Parallelentwicklung?
F�r die k�rzlich geforderte "Gesetzeskraft" ist es wirklich gleichg�ltig,
ob man sich auf den bestehenden Standard oder einen neueren Entwurf st�tzt.

Wenn es in 5.5.1 schon gibt
1 MAP
2 LATI <PLACE_LATITUDE>
2 LONG <PLACE_LONGITUDE>
warum dann neu erfinden
1 MAP 50.1234N 128.9876E
Alternative Bezeichnungen k�nnten doch auch zus�tzlich als
1 MAP
2 MAID JO99HZ
eingef�hrt werden.

Gru�
Gerd (Schmerse)