EXCEL-Erfassungsmaske

Hallo Friedrich,

meine Anmerkungen im Test.

<Seine h�flichen aber klaren Worte haben mir gefallen.
< ich f�rchte so gibt das nichts. ...
<Mir kam das eher freundschaftlich f�rsorglich vor als harsch.

Das habe ich aus freundschaftlich empfunden und nachgedacht.

<Wir k�nnten aber schon mal M�glichkeiten sammeln, Daten auszutauschen in
<Gedcom und nebenher, wenn Gedcom keinen offiziellen Platz daf�r vorsieht.

Gute Idee, f�r Regesten gibt es so was m. E. bislang nicht.

<Es gibt Ahnenprogramme, die werben damit, dass sie viel mehr verwalten
<k�nnen, als Gedcom hergibt, und die zum Transport eigene Tags als
Erweiterung
<von Gedcom anbieten.

Problem dabei, dass nun wieder nicht alle Programme dies bei der Ausgabe von
Daten verstehen.

<damit wir Dir helfen k�nnen, musst Du Dir und uns diese Fragen beantworten:

Gerne.

<- Regest scheint ein "Ereignis" zu beschreiben.
<Welcher DatenStrukturEinheit wird es zugeordnet: einer "Person", einer
<"Familie" oder einem anderen "Ereignis"?

Geh�rt als Originaltext zu einer Quelle, diese kann einem Ereignis oder
einer Person zugeordnet sein, hier lege ich fest eine Quelle f�t eine
Person!

<- Du willst es transportieren. Hast Du ein bestimmtes Programm, das
<Regesten aufnehmen soll und kann oder willst Du, dass Deinem Programm
Regesten <geliefert werden?

Die Regesten werden aus einer CSV-Datei �ber den Umweg eines
Familienprogramms, das CSV-Import beherrscht, PAF zur Verf�gung gestellt.
Von dort als Gedcom-Export nach PGV zur Ver�ffentlichung.

<- Was soll mit den Regesten geschehen,
<sollen sie in einer Zeitleiste oder einer FamilienChronik auftauchen?

In PGV als Gedcom, siehe www.gb.graenz.name (momentan im Test).

Vielen Dank f�r die konkreten Fragen, ich hoffe auf hilfreiche Antworten.

Mit freundlichem Gru� aus Dresden

Ren�

René Gränz wrote:

<Wir könnten aber schon mal Möglichkeiten sammeln, Daten auszutauschen in
<Gedcom und nebenher, wenn Gedcom keinen offiziellen Platz dafür vorsieht.

Gute Idee, für Regesten gibt es so was m. E. bislang nicht.

Weil Du Anwender bist.

Es gibt auch Foren, die für Programmierer von Genealogieprogrammen sind (man kennt sich). Dort wurde schon mehrfach versucht Vorstöße in diese Richtung zu unternehmen. Bisher leider ohne nennenswerten Erfolg :frowning:

MfG, Metti.

Hallo Metti,

das Geschriebene zeigt doch, dass wir hier in die richtigte Richtung denken.
Diese Info kannte ich bislang nicht.
Was k�nnen wir Anwender tun, um eine L�sung anzuschieben?

Ich freue mich auf eine Antwort.

Mit freundlichem Gru� aus Dresden

Ren�

Ren� Gr�nz
PF 280214
01142 Dresden
Funk: 0162/1 76 53 55

e-Mail: rgraenz@gmx.de
http://www.graenz.name

René Gränz wrote:

Was können wir Anwender tun, um eine Lösung anzuschieben?

Nichts. :frowning:
Die LDS ist nicht an einer Fortentwicklung von Gedcom interessiert und kein anderer hat das Recht dazu.
Der letzte Versuch ging also in die Richtung etwas komplett neues auf die Beine zu stellen. Wir wollte dazu auf GenXML zurückgreifen und das entsprechend erweitern. Leider hat sich der Rechteinhaber nicht gemeldet und wir konnen das ebenfalls nicht als Grundlage nehmen.
Ein komplett neues Datenformat incl. Dokumentation aus dem Boden zu stampfen hat dann keiner mehr gewollt/versucht.

MfG, Metti.

Ren� Gr�nz wrote:

> Wir k�nnten aber schon mal M�glichkeiten sammeln, Daten auszutauschen in
> Gedcom und nebenher, wenn Gedcom keinen offiziellen Platz daf�r vorsieht.

Gute Idee, f�r Regesten gibt es so was m. E. bislang nicht.

Man sollte sich nicht von den begrenzten M�glichkeiten des Gedcom-Formats
einschr�nken lassen. Besonders wenn man eigentlich ganz andere Informationen
als die, f�r die Gedcom entwickelt wurde (n�mlich Forschungs_ergebnisse_ in
Form von Personen und Famliie), vorliegen hat.

> - Regest scheint ein "Ereignis" zu beschreiben.
> Welcher DatenStrukturEinheit wird es zugeordnet: einer "Person", einer
> "Familie" oder einem anderen "Ereignis"?

Geh�rt als Originaltext zu einer Quelle, diese kann einem Ereignis oder
einer Person zugeordnet sein, hier lege ich fest eine Quelle f�t eine
Person!

Zun�chst ist ein Regest erstmal eine Quelle (ganz genau nur eine
Textrepr�sentation einer Quelle). Als solche m�ssen wir sie auch erfassen.
Dann zieht man seine Schlu�folgerungen aus diesem Text: Es tauchen mehrere
Personen auf, diese sind an einem Ereignis beteiligt usw. Dieser Zusammenhang
zwischen Quelle und strukturierten Informationen mu� dokumentiert werden,
insbesondere wer diese Bearbeitung vorgenommen hat. Wichtig ist, da� man die
Daten mehrerer Quellen zun�chst nicht vermischt. Sonst kann man sp�ter nicht
mehr herausbekommen, woher eine Information stammt. (F�r die Erfassung in
Tabellen: pro Quelle eine Zeile, nicht pro Person!)

Das Problem ist im Moment noch, da� wir keine technischen Mittel haben, diese
Erfassung und Dokumentation kontrolliert durchzuf�hren. Solange m�ssen wir
uns wohl mit Tabellen behelfen, in denen wir die Daten erfassen. Es ist
sicherlich nicht sinnvoll, die Informationen in ein ungeeignetes Datenmodell
(wie Gedcom) reinzuquetschen, das daf�r ja gar nicht konzipiert wurde. Das
schafft man Ende nur unn�tig Arbeit, im schlimmsten Fall mu� man alles
nochmal machen.

Jesper

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

Die LDS ist nicht an einer Fortentwicklung von Gedcom interessiert und
kein anderer hat das Recht dazu.

Warum hat niemand das Rechts dazu und wie kommt es zu den
Erweiterung von Gedcom 5.5 EL (oder wie das heißt)?

Gerhard

Gerhard Stoll wrote:

Die LDS ist nicht an einer Fortentwicklung von Gedcom interessiert und
kein anderer hat das Recht dazu.

Warum hat niemand das Rechts dazu und wie kommt es zu den Erweiterung von Gedcom 5.5 EL (oder wie das heißt)?

Urheberrechtsinhaber ist IMHO die LDS. Gedcom 5.5EL ist eine Erweiterung, die nur Zusätze definiert. Man darf das nicht als neuen Gedcomstandard bezeichnen. Die Erweiterungen sind somit nicht im Standard enthalten (und wohl stellenweise nicht standardkonform).

MfG, Metti.

Hallo Jesper,

Du schreibst

Gesendet: Samstag, 9. Juni 2007 09:41

Man sollte sich nicht von den begrenzten M�glichkeiten des Gedcom-Formats
einschr�nken lassen. Besonders wenn man eigentlich ganz andere
Informationen als die, f�r die Gedcom entwickelt wurde (n�mlich
Forschungs_ergebnisse_ in Form von Personen und Famliie), vorliegen hat.

Wenn ich diese Personen und Daten allerdings verkn�pfen will, muss ich
wieder auf ein genealogischer Programm zur�ckgreifen.

Zun�chst ist ein Regest erstmal eine Quelle (ganz genau nur eine
Textrepr�sentation einer Quelle). Als solche m�ssen wir sie auch
erfassen. ...

Danke, besser h�tte ich es nicht formulieren k�nnen.

Das Problem ist im Moment noch, da� wir keine technischen Mittel
haben, diese Erfassung und Dokumentation kontrolliert durchzuf�hren.

Solange

m�ssen wir uns wohl mit Tabellen behelfen, in denen wir die Daten

erfassen. Es >>ist sicherlich nicht sinnvoll, die Informationen in ein
ungeeignetes

Datenmodell (wie Gedcom) reinzuquetschen, das daf�r ja gar nicht

konzipiert

wurde. Das schafft man Ende nur unn�tig Arbeit, im schlimmsten Fall mu�

man >>>>alles nochmal machen.

Liege ich denn so falsch, die Gedcom-Tags SOUR mit DATE und NOTE zu
verbinden oder zu verschachteln, wie es PAF macht?

Wie sieht denn eine Regeste aus:

- Quelle (also Urkundenbeschreibung)
- Erstellungszeitraum der Quelle
- Aufbewahrungsort
- Inhalte (Text) der Quelle

Die darin genannten Personen werden dann manuell in ein genealogisches
Programm �bernommen, um sie verkn�pfen zu k�nnen.

Ich freue mich auf eine Antwort.

Mit freundlichem Gru� aus Dresden

Ren�