Submitter-Kennzeichen zur Dokumentation der Datenherkunft

genealogie-programme
1

Hallo Thomas,

wenn man die Quellenlage und die Information darüber, wer die Daten bereitgestellt hat, trennen will, dann benötigt man hierfür 2 unterschiedliche Kennzeichen. Die Quellenangaben werden in GEDCOM in der SOURCE-Struktur abgelegt, für die Daten des Einreichers gibt es die SUBMITTER-Struktur. Im GEDCOM-Standard wird der Einreicher "zwingend" in den Kopfdaten ausgewiesen. Das SUBM-Kennzeichen dort ist ein Mussfeld. Der Standard ( 5.5 und 5.5.1 :blush:) sieht auch vor, auf Personen- und Familiensatzebene dieses Feld zu pflegen, aber ich vermute mal, dass die wenigsten Programme dies unterstützen. Was jetzt noch fehlt, ist das SUBM-Kennzeichen auf Ereignisebene.

Zur Umsetzung eines solchen Konzeptes muss der GEDCOM-Standard nicht verbogen werden. Auf Ereignisebene kann hierfür ein benutzerdefiniertes Kennzeichen, z.B. _SUBM verwendet werden. Das Argument, dass benutzerdefinierte Kennzeichen beim Datenaustausch verloren gehen können, kann man hier vernachlässigen, denn Informationen über den Einreicher würde ich bei einem "Standard-"-Export auf Record- und Ereignisebene ausschließen. Warum? Wenn ich einem anderen Forscher meine Daten zur Verfügung stelle, dann bin ich der "Einreicher" und diese Information steht dann im GEDCOM-Header.

Wenn man den im GEDCOM-Standard bereits definierten hierarchischen Ansatz auch auf das Genealogieprogramm überträgt, dann ist es nicht erforderlich, den Verweis zum ursprünglichen Verfasser bei jedem einzelnen Record, Ereignis anzugeben. Eine Kennzeichnung auf Header-Ebene impliziert, dass alle Informationen in der vorliegenden Datei vom selben Verfasser stammen. Eine Kennzeichnung auf Record-Ebene (z.B. Person) impliziert, dass alle Informationen zur Person vom selben Verfasser stammen. Ein Kennzeichen auf Ereignisebene ist nur dann notwendig, wenn das Submitter-Feld vom Record bzw. vom Header abweicht.

Die Verwendung des SUBM-Feldes hätte weiterhin den Vorteil, dass sich dahinter ein kompletter Record mit allen erforderlichen Angaben zum Verfasser befindet (Name, Anschrift, Kommunikationsdaten, ...).

Soviel zu einem möglichen Konzept. Webtrees bietet z.B. das Submitter-Kennzeichen auf Record-Ebene an. Ich kenne aber kein Programm, dass ein Submitter-Feld auf Ereignisebene anbietet oder welches Submitter-Felder bei einer Datenübernahme befüllt.

Viele Grüße
Peter (Schulz)

2

Hallo Peter,

die von Dir skizzierte Vorgehensweise zur Darstellung des "Bereitstellers" der Daten reicht wohl noch nicht aus. Vor allen Dingen dann, wenn mehrere Personen nacheinander an einer Datei / einem Datensatz / einem Ereignis arbeiten. Egal, ob das das gemeinsame Arbeiten in einer Online-Datenbank (webtrees, TNG, GEN_DO!) ist, oder ob zwischendurch per GEDCOM Transfer von einem zum nächsten Bearbeiter weitergegeben wird.

Wie fein das eigentlich sein müsste, kann man an einem Ereignis BIRT beispielhaft aufzeigen: Bearbeiter A wertet das Kirchenbuch aus, legt das Ereignis der Geburt an und packt das Quell-Zitat mit Abschrift dazu. Bearbeiter B wertet die Zivilregister aus und ergänzt das Ereignis um die Angaben (das Quell-Zitat) aus dem Zivilregister. Wenn man später noch erkennen möchte, wer die jeweilige Quelle eingesehen und transkribiert hat, reichte es nicht mehr aus, nur das Ereignis mit einem _SUBM Querverweis zu versehen - es muss dann schon das Quell-Zitat sein, welches entsprechend gekennzeichnet ist. Beides ist aber im GEDCOM-Standard nicht explizit vorgesehen!

So weit die Theorie. In der Praxis läuft das so nicht. Bei den gemeinsamen Transkriptions-Projekten, die wir im NLF durchführen, wird später in der GEDCOM nicht dokumentiert, wer den jeweiligen Eintrag der Quelle bearbeitet hat. Und selbst das ist nicht eindeutig, weil wir einen Erstbearbeiter haben sowie eine Prüfung, bei der durch einen weiteren Bearbeiter ggfs. noch Korrekturen ausgeführt werden. Erst nach der Freigabe des zweiten Bearbeiters fließt der abgeschriebene Umfang in den gemeinsamen Datenpool einer Verkartung ein...

Wieso dann nach einem GEDCOM-Transfer nach Deiner Darstellung die auf Ereignis-Ebene angelegten _SUBM gerne wieder verschwinden dürfen, leuchtet mir nicht ein. Es ist doch nicht nur der eine Bearbeiter, der dann als SUBM der Gesamtdatei weitergegeben wird, sondern es sind eben durchaus verschiedene Bearbeiter je Ereignis / Quellzitat. Wenn denn die Info schon wesentlich sein sollte, dann müsste sie auch einen GEDCOM Transfer überstehen.

Noch spannender wird die Frage, wenn es nicht mehr nur reine Ergänzungen sind, sondern Änderungen / Korrekturen. Wenn also Bearbeiter A z.B. nur den Monat der Geburt angeben konnte, Bearbeiter B dann aber den genauen Tag findet und nachträgt. Dann müsste das Ereignis mit beiden Bearbeitern gekennzeichnet sein und zusätzlich noch mit dem Zeitpunkt, damit erkennbar ist, wer in welcher Reihenfolge beteiligt ist (und insbesondere, wer den letzten Stand erzeugt hat).

Aus meiner Sicht führt das alles aber zu weit: Es reicht m.E. vollkommen, wenn die Quell-Zitate überhaupt da sind (optimalerweise mit dem abgeschriebenen Inhalt aus der Fundstelle). Wer anderen keine sorgfältige Arbeit zutraut, muss da eh nachsehen und sich selber in der Originalquelle vergewissern... Dann ist es auch nicht mehr so wichtig, wer das ursprünglich mal gemacht hat.

In seltenen Fällen wird es in den Bemerkungen eines Quellzitates (also nicht im abgeschriebenen BIRT.SOUR.DATA.TEXT, sondern in der BIRT.SOUR.NOTE) als Klartext dokumentiert, wer es wann abgeschrieben / bearbeitet hat, manchmal sogar mit Hinweisen zur Bearbeitung. Wobei wir wieder an den Punkt kommen, welche Programme so tief die GEDCOM-Struktur umgesetzt haben und ob das dann den Transfer überlebt.

Viele Grüße
Albert (Emmerich)

3

Du vergisst den Bedarf beim Zusammenführen von mehreren Gedcomdateien.
Wenn ein Genealogieverein ein Ortsarchiv einpflegt und mehrere Anwender
unterschiedliche Gedcomdateien erzeugen und diese dann zu einer
Genealogie zusammengefasst werden, dann möchte man vieleicht doch
wissen, wer welchen Datensatz mal eingepflegt hat.

Oder muss ich dann immer alle Gedcomdateien einzeln aufgbewaren und
durchsuchen?

Also ich sehe durchaus Bedarf für SUBM auf Recordebene.

Wenn man überlegt, dass iin der Familie mehrere an derselben Datei
arbeiten (geht bei mir z.B. über ein Cloudlaufwerk) dann möchte man im
Falle von unstimmigkeiten ggf. sogar wissen, wer ein einzelnes Ereignis
zuletzt verändert/eingegeben hat.
Somit wäre hier SUBM (und CHAN) auch auf Event-Ebene wünschenswert.

Gruß, Stefan Mettenbrink.

4

Hallo Peter,

in der Gedcom ist das ausreichend. Nach einem Import einer fremden Gedcom möchte ich als Anwender dann aber in dem von mir verwendeten Programm bei den importierten Daten den Submitter sehen.

Somit müsste das importierende Programm über einen optionalen Parameter den Submitter in den Quelleninformationen an eine geeignete Stelle schreiben, welche dann im Zusammenhang mit der Quellenangabe ausgegeben werden kann.

Viele Grüße,
Thomas

Am 5. Sep. 2019, 22:50, um 22:50, Peter Schulz <pesz@gmx.de> schrieb:

5

Lieber Herr Emmerich

Nach meiner wissenschaftlichen Ausbildung kann Ihr Problem:
" Noch spannender wird die Frage, wenn es nicht mehr nur reine Ergänzungen
sind, sondern Änderungen / Korrekturen. Wenn also Bearbeiter A z.B. nur
den Monat der Geburt angeben konnte, Bearbeiter B dann aber den genauen
Tag findet und nachträgt. Dann müsste das Ereignis mit beiden
Bearbeitern gekennzeichnet sein und zusätzlich noch mit dem Zeitpunkt,
damit erkennbar ist, wer in welcher Reihenfolge beteiligt ist (und
insbesondere, wer den letzten Stand erzeugt hat)."
auch dahingehend interpretiert und gelöst werdenden, dass der Autor, der die Ergebnisse vom Bearbeiter A und B kennt und für sich übernehmen will, entscheidet, dass die Information vom Bearbeiter B besser, richtiger vollständiger ist und damit die Information vom Bearbeiter A ersetzt. Der verschwindet zwar dann in der Versenkung, aber die Angaben in der Datei des Autors sind richtig (hoffentlich) und vollständig.

Wenn man in wissenschaftlichen Texten die Chronologie der Vorergebnisse (~ Quellen) beschreiben will, dann geschieht das in der Einleitung/Literaturübersicht. Das wäre aber für eine GEDCOM etwas zu viel verlangt.

Also kann das Ergebnis des Bearbeiters A in Ihrem Beispiel vom Ergebnis des Bearbeiters B überschrieben/verdrängt/ersetzt werden ohne dass dadurch unser Streben nach Minimierung der historischen Unsicherheit gemindert würde.

Mit freundlichem Gruß
W. v. Restorff

6

Guten Morgen Thomas,

ja, das wären dann programminterne Funktionen/Features der einzelnen Gen-Programme.

Viele Grüße
Peter

7

Hallo,
ich habe das so gelöst, dass
A. bei der Ausgabe der Ersteller der Gedcom-Datei bei jeder Person als Quelle eingefügt werden *kann*. und
B. beim Einlesen jede Person in der Quelle mit einem vom "Übernehmer" frei eingegebenen Text versehen werden *kann*.

Jeden einzelnen Eintrag mit einer nachvollziehbaren Änderungshistorie zu versehen halte ich für nicht praktikabel.

Mit freundlichen Grüßen
Gisbert Berwe

Friedrich-Holthaus-Str. 18
49082 Osnabrück
Tel.: 0541-80 00 79 00
Skype: Gisbert.Berwe

www.Genpluswin.de
www.zufallsfunde.net die Heimat für Zufallsfunde
www.Verdener-Familienforscher.de

"Es gibt keinen Grund, eine gute Theorie aufzugeben, nur weil sie nicht stimmt"

8

Hallo Albert,

wir sollten differenzieren zwischen einer gemeinsamen Bearbeitung einer Online-Datenbank und einer Bearbeitungskette über mehrere GEDCOM-Dateien hinweg.

Ich bezog mich mit meinem Konzept auf den zweiten Fall, da dieser von Thomas hinterfragt wurde. Hier habe ich nicht den Anspruch, historische Einreicher mitzuführen. Wenn ich Daten aus einer Datei im meinen Datenbestand übernehme, dann möchte ich hinterlegen, von wem "ich" diese Daten übernommen habe. Das wäre der Submitter der zur Verfügung gestellten Datei - in dem von Dir skizzierten Fall der NLF.
Hierfür ist der heutige GEDCOM-Standard ausreichend, denn das Submitter-Feld im Header ist ein Mussfeld und beinhaltet die benötigten Informationen (Name, Adresse, Kommunikationsdaten, ...). Bei einer programmgestützten Datenübernahme werden übernommene Datensätze (Records) mit dem Submitter gekennzeichnet. Werden nur einzelne Ereignisse, Fakten in bereits vorhandene Sätze übernommen, dann erfolgt eine Kennzeichnung auf Ereignisebene.

Für den ersten Fall, der gemeinsamen Bearbeitung einer Online-Datenbank gibt es doch bereits diverse Lösungen. webtrees zum Beispiel protokolliert die gemachten Änderungen in Logs
     - Zeitstempel
     - Status
     - Datensatz
     - Daten (alter Wert, neuer Wert)
     - Benutzer
     - Stammbaum
und kennzeichnet auch die Datensätze (letzte Änderung) zusätzlich mit dem programminternen GEDCOM-Kennzeichen: _WT_USER:
     CHANGE_DATE:=
     n CHAN
     +1 DATE <CHANGE_DATE>
     +2 TIME <TIME_VALUE>
     +2 _WT_USER
     +1 <<NOTE_STRUCTURE>>
Ich nehme an, TNG, GEN_DO! und andere machen es ähnlich.
Für mich gehören diese Informationen nicht in den GEDCOM-Export. Aber das kann man ja optional gestalten und somit kann dies jeder selbst entscheiden. Das gleiche gilt auch für die SUBM-Kennzeichnung.

Viele Grüße
Peter

9

Der Submitter kann in Gedcom nur je Record angegeben werden. Bietet das
ein Programm an?

Gruß, Stefan Mettenbrink.

10

Finde ich gut!
Ich plane für die ferne Zukunft, ebenfalls die Datensätze mit SUBM zu
kennzeichnen. Wie detailiert ich das mache weiß ich noch nicht, aber ich
werde das mal in mein ToDo-Liste aufnehmen.

Gruß, Stefan Mettenbrink.

11

Mir ist leider keins bekannt, aber aus meiner Sicht wäre es gut, wenn man die Möglichkeit hätte beim Import automatisch jeder Quelle den Submitter zuzuweisen.

Wenn man feststellt dass jemand bei der Transkription immer wieder Fehler macht, dann sind die Daten zwar aus der angegebenen Quelle, aber halt aus zweiter Hand. Alle Quellenangaben des Submitters würde ich dann eher als "Anhaltspunkt" für weitere Forschungen nehmen, aber nicht als gesicherte Daten.

Gruß,
Thomas

Am 6. Sep. 2019, 19:38, um 19:38, Stefan Mettenbrink <s.metti@gmx.de> schrieb: