GEDCOM/SOUR-Tag

Name und Bedeutung

Tag

SOUR

Formelle Bezeichnung

SOURCE

Deutsche Bezeichnung

Quelle

Verwendung

Ursprungsmaterial, von dem Informationen herausgezogen wurde

Formale Beschreibung zulässiger Werte

Aussagen des GEDCOM Standards 5.5.1 zu SOUR

zitiert aus der Übersetzung von Jörn Daub

SOUR im Header der GEDCOM-Datei

Die HEADER Struktur bildet den Dateikopf, und beinhaltet Informationen über die gesamte Übertragung. Der Name des Quellsystems (SOUR) identifiziert dabei, welches System die Daten gesendet hat.

• n HEAD {1:1}
• +1 SOUR <APPROVED_SYSTEM_ID> {1:1}
• +2 VERS <VERSION_NUMBER> {0:1}
• +2 NAME <NAME_OF_PRODUCT> {0:1}
• +2 CORP <NAME_OF_BUSINESS> {0:1}
• +3 <<ADDRESS_STRUCTURE>> {0:1}
• +2 DATA <NAME_OF_SOURCE_DATA> {0:1}
• +3 DATE <PUBLICATION_DATE> {0:1}
• +3 COPR <COPYRIGHT_SOURCE_DATA> {0:1}
• +4 [CONT|CONC]<COPYRIGHT_SOURCE_DATA> {0:M}

mit

APPROVED_SYSTEM_ID:= {Size=1:20} (anerkannte System Identifikation) Ein System-identifizierender Name, der durch den GEDCOM-Registrierungsprozess vergeben wurde. Dieser Name muss eindeutig das Produkt von anderen unterscheiden. Leerzeichen innerhalb des Namens müssen durch 0x5F (Unterstrich _) ersetzt werden, so dass ein Wort gebildet wird.

VERSION_NUMBER:= {Size=1:15} (Versionsnummer) Eine Identifikation der Versionsnummer des zugehörigen Produktes. Sie wird vom Hersteller des Produktes zugewiesen und geändert.

NAME_OF_PRODUCT:= {Size=1:90} (Name des Produktes) Der Name des Softwareproduktes, das die Datei (Übermittlung) erstellt hat.

NAME_OF_BUSINESS:= {Size=1:90} (Name des Unternehmens), Name des Unternehmens, der Firma oder der Personen, die das Produkt hergestellt oder kommissioniert hat.

NAME_OF_SOURCE_DATA:= {Size=1:90} (Name der Quelldaten) Der Name der elektronischen Datenquelle, die benutzt wurde, um die Daten in der Datei zu erhalten. Beispielsweise könnten diese von einer CD-Rom stammen, die mit "Volkszählung der USA von 1880 CD-ROM Band 13" bezeichnet war.

PUBLICATION_DATE:= {Size=10:11} <DATE_EXACT> (Veröffentlichungsdatum) Das Datum, an dem diese Quelle veröffentlicht oder erzeugt wurde.

COPYRIGHT_SOURCE_DATA:= {Size=1:90} (Vervielfältigungsrecht, Quelldaten) Eine Aussage, die vom Eigentümer der Daten verlangt wird, von dem die Daten erhalten (oder heruntergeladen) wurden. Beispiel: Wenn eine GEDCOM-Datei von Ancestral File heruntergeladen wird, würde dies als Inhaber des Vervielfältigungsrechtes angegeben, um anzuzeigen, dass die Daten von einer rechtlich geschützten Quelle stammen

Die Address-Struktur wird in einem eigenen Artikel dargestellt. Die angegebenen Feldlängen (Size=...) sind vom GEDCOM-Standard empfohlene Mindestlängen für Datenbanken mit längenbegrenzten Feldern.

Wo wird SOUR verwendet?

Neben der Verwendung von SOUR im Header (mit eigener Struktur in diesem Kontext) wird SOUR als SOURCE_CITATION an vielen Stellen in der GEDCOM-Struktur verwendet. Der GEDCOM-Standard nennt:

• FAM_RECORD
• INDIVIDUAL_RECORD
• MULTIMEDIE_RECORD
• NOTE_RECORD
• ASSOCIATION_STRUCTURE
• EVENT_DETAIL
• LDS_INDIVIDUAL_ORDINANCE (d.h. BAPL, CONL, ENDL, SGLC)
• LDS_SPOUSE_SEALING (d.h. SGLS)
• PERSONAL_NAME_PIECES

Quellzitat-Struktur (SOURCE_CITATION)

SOURCE_CITATION:=

• [ /* Zeiger auf einen Quell-Datensatz (bevorzugt) */
• n SOUR @<XREF:SOUR>@ {1:1}
• +1 PAGE <WHERE_WITHIN_SOURCE> {0:1}
• +1 EVEN <EVENT_TYPE_CITED_FROM> {0:1}
• +2 ROLE <ROLE_IN_EVENT> {0:1}
• +1 DATA {0:1}
• +2 DATE <ENTRY_RECORDING_DATE> {0:1}
• +2 TEXT <TEXT_FROM_SOURCE> {0:M}
• +3 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}
• +1 <<MULTIMEDIA_LINK>> {0:M}
• +1 <<NOTE_STRUCTURE>> {0:M}
• +1 QUAY <CERTAINTY_ASSESSMENT> {0:1}

• | /* Für Systeme, die keine Quell-Datensätze nutzen */
• n SOUR <SOURCE_DESCRIPTION> {1:1}
• +1 [CONC|CONT] <SOURCE_DESCRIPTION> {0:M}
• +1 TEXT <TEXT_FROM_SOURCE> {0:M}
• +2 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}
• +1 <<MULTIMEDIA_LINK>> {0:M}
• +1 <<NOTE_STRUCTURE>> {0:M}
• +1 QUAY <CERTAINTY_ASSESSMENT> {0:1}
• ]

Die Daten in der Quellzitat-Struktur (SOURCE_CITATION) beinhaltet Informationen zu der Quelle im Bezug auf die zitierten Daten. (Siehe GEDCOM Beispiele). Systeme, die keine Quell-Datensätze (SOURCE_RECORD, Systeme mit Quell-Datensätzen bezeichnen diese oft auch als Master-Quellen oder Haupt-Quellen) nutzen, müssen die nicht bevorzugte zweite Variante der Quellzitat-Struktur nutzen. Systeme, die Quell-Datensätze der Ebene null nutzen, müssen dann, wenn sie ein Quellzitat entdecken, das keinen Zeiger auf einen Quell-Datensatz enthält selbständig einen neuen Quell-Datensatz anlegen, und die Beschreibung (SOURCE_DESCRIPTION) des Quellzitates in dessen Titel speichern. Die Quellzitat-Struktur ist zum Speichern (u.A.) folgender Informationen gedacht:

• Ein Zeiger auf den Quell-Datensatz (SOURCE_RECORD), der eine allgemeinere Beschreibung der zitierten Quelle beinhaltet.
• Informationen, wie z. B. eine Seitennummer, die dem Anwender beim Auffinden der zitierten Daten innerhalb der referenzierten Quelle zu helfen. Diese wird im „.SOUR.PAGE“ Kontext gespeichert.
• Eine Abschrift desjenigen Textes der Quelle, der für Annahmen und Schlussfolgerungen genutzt wurde, beispielsweise eine Datumsangabe, wie sie sich tatsächlich in der Quelle findet, oder wichtige Notizen durch den Schreibenden, oder ein zutreffender Satz aus einem Brief. Dies wird im „.SOUR.DATA.TEXT“ Kontext gespeichert.
• Daten, welche Schlussfolgerungen erlauben, einer Quelle den Vorzug vor einer anderen zu geben (Primärquelle, Sekundärquelle, etc.). Zu dessen Ermittlung werden verschiedene Informationen benötigt: Die Zeitspanne zwischen dem Datum des Ereignisses und dessen Aufzeichnung in einer bestimmten Quelle, welche Art von Ereignis zitiert wurde, und welche Rolle diese Person in der zitierten Quelle einnahm.
  • Das Datum, an dem der Eintrag in dem Quelldokument aufgezeichnet wurde, wird im „.SOUR.DATA.DATE“ Kontext gespeichert.
  • Die Art des Ereignisses, welches die Aufzeichnung auslöste, wird im „.SOUR.EVEN“ Kontext gespeichert. Der Wert ist einer möglichen Werte aus <EVENT_TYPE_CITED_FROM>
  • Die Rolle dieser Person in dem Ereignis wird im „.SOUR.EVEN.ROLE“ Kontext gespeichert.

Quell-Datensätze (SOURCE_RECORD)

SOURCE_RECORD:=

• n @<XREF:SOUR>@ SOUR {1:1}
• +1 DATA {0:1}
• +2 EVEN <EVENTS_RECORDED> {0:M}
• +3 DATE <DATE_PERIOD> {0:1}
• +3 PLAC <SOURCE_JURISDICTION_PLACE> {0:1}
• +2 AGNC <RESPONSIBLE_AGENCY> {0:1}
• +2 <<NOTE_STRUCTURE>> {0:M}
• +1 AUTH <SOURCE_ORIGINATOR> {0:1}
• +2 [CONC|CONT] <SOURCE_ORIGINATOR> {0:M}
• +1 TITL <SOURCE_DESCRIPTIVE_TITLE> {0:1}
• +2 [CONC|CONT] <SOURCE_DESCRIPTIVE_TITLE> {0:M}
• +1 ABBR <SOURCE_FILED_BY_ENTRY> {0:1}
• +1 PUBL <SOURCE_PUBLICATION_FACTS> {0:1}
• +2 [CONC|CONT] <SOURCE_PUBLICATION_FACTS> {0:M}
• +1 TEXT <TEXT_FROM_SOURCE> {0:1}
• +2 [CONC|CONT] <TEXT_FROM_SOURCE> {0:M}
• +1 <<SOURCE_REPOSITORY_CITATION>> {0:M}
• +1 REFN <USER_REFERENCE_NUMBER> {0:M}
• +2 TYPE <USER_REFERENCE_TYPE> {0:1}
• +1 RIN <AUTOMATED_RECORD_ID> {0:1}
• +1 <<CHANGE_DATE>> {0:1}
• +1 <<NOTE_STRUCTURE>> {0:M}
• +1 <<MULTIMEDIA_LINK>> {0:M}

Quell-Datensätze werden benutzt, um eine bibliografische Beschreibung der zitierten Quelle zu liefern. (Siehe auch: <<SOURCE_CITATION>>-Unterstruktur, die einen Zeiger auf den Quell-Datensatz enthält.)

Priorität für Quell-Datensätze

Der GEDCOM-Standard macht an mehreren Stellen sehr deutlich, dass statt der einfachen, eingebetteten Quellenzitate die Struktur der Quell-Datensätze (SOURCE_RECORDS) verwendet werden soll. Eine zentrale Stelle hierfür ist die Beschreibung der Quell-Zitate (SOURCE_CITATION, s. dort), wo die Quell-Datensätze (SOURCE_RECORD) als bevorzugte Darstellung für Quellen im GEDCOM ausgewiesen sind. Dennoch sind die einfachen Quellzitate (s. SOURCE_CITATION) auch zugelassen.

Weitere wörtliche Zitate aus dem GEDCOM-Standard 5.5.1:

STRUKTUR DER QUELLEN

GEDCOM 5.x Draft Produkte werden ermuntert, ihre Programme so schnell wie möglich auf The GEDCOM Standard 5.5 zu aktualisieren.

ÄNDERUNGEN, DIE MIT 5.4 DRAFT EINGEFÜHRT ODER MODIFIZIERT WURDEN.

• Der Quelldatensatz (siehe <SOURCE_RECORD>) wurde in fünf Bereiche vereinfacht: Daten oder Klassifikation, Autor, Titel, Veröffentlichungsdaten und Quellarchiv. Die Daten oder Klassifikationssektion beinhaltet Fakten über die Daten, die in dieser Quelle enthalten sind, und werden benutzt, um die Sammlung an Quellen zu analysieren, die der Forscher genutzt hat. Die Sektionen Autor, Titel, Veröffentlichungsdaten und Quellarchiv enthalten freie Textblöcke, die spätere Forscher davon informieren, wie sie die Quelldaten erhalten können, die der ursprüngliche Forscher genutzt hat.
• Eine <SOURCE_CITATION> Struktur wurde unterhalb des zitierten Fakts eingefügt. Es ist normalerweise das Beste, wenn das Quellzitat nur die Information enthält, die spezifisch für das zitierte Fakt sind und dann auf die generelle Beschreibung der Quelle zeigt, wie sie in <SOURCE_RECORD> beschrieben ist. Dies reduziert die Redundanz, bietet einen Weg, die Größe eines Datensatzes zu begrenzen, und ist dichter an einem normalisierten Datenmodell.
• Systeme, die Quellen über AUTH, TITL, PUBL und REPO-Felder beschreiben können und sollten immer diese Information in GEDCOM in dem Quelldatensatz (<SOURCE_RECORD>) übertragen, auf den aus der <SOURCE_CITATION> verwiesen wird. Systeme, die nur freie Quellnotizen erlauben, sollten dazu ermuntern dass diese Informationen über die folgenden Kategorien enthalten:
  • TITL – ein beschreibender Titel der Quelle
  • AUTH – Wer hat das Werk erschaffen
  • PUBL - Wann und wo wurde es erschaffen
  • REPO – wo kann man es erhalten

Wenn möglich sollten die Kennzeichen für diese Kategorien im Text angegeben werden, so dass ein empfangendes System diese wieder parsen, und sie so den empfohlenen Feldern der Quell- oder Zitatstruktur zuordnen kann.

Beispiel aus dem GEDCOM-Standard 5.5.1

Im GEDCOM-Standard ist ein Beispiel ausgeführt, bei dem einige Elemente der SOURCE_CITATION und des SOURCE_RECORD verwendet werden:

• 1 BIRT
• 2 DATE 02 OCT 1822
• 2 PLAC Weston, Madison, Connecticut
• 2 SOUR @6@
• 3 PAGE Sec. 2, p. 45
• 3 EVEN BIRT
• 4 ROLE CHIL

• ...

• 0 @6@ SOUR
• 1 DATA
• 2 EVEN BIRT, DEAT, MARR
• 3 DATE FROM Jan 1820 TO DEC 1825
• 3 PLAC Madison, Connecticut
• 2 AGNC Madison County Court, State of Connecticut
• 1 TITL Madison County Birth, Death, and Marriage Records
• 1 ABBR VITAL RECORDS
• 1 REPO @7@
• 2 CALN 13B-1234.01
• 3 MEDI Microfilm
• 0 @7@ REPO
• 1 NAME Family History Library
• 1 ADDR 35 N West Temple Street
• 2 CONT Salt Lake City, Utah
• 2 CONT UT 84150

Vereinbarungen zu SOUR

Diese Vereinbarungen sind aus der Diskussion in der Gedcom-L Liste abgeleitet worden und durch Abstimmung unter den beteilgten Programmautoren verabschiedet worden.

Vorbemerkung zu den Vereinbarungen

Die Diskussion in der Gedcom-L war stark geprägt von der Tatsache, dass sich die beteiligten Programme sehr stark unterscheiden in der internen Behandlung von Quellen. Neben Lösungen mit einem mehrzeiligen Feld für Quellen-Angaben pro Personen- oder Familien-Datensatz stehen teilweise Lösungen, die eine sehr differenzierte und strukturierte Quellenverwaltung anbieten. Dies macht sich natürlich auch im Umfang der nach GEDCOM exportierten Informationen bemerkbar. Eine Vereinheitlichung der Umgangsweise mit dem GEDCOM-Standard kann dabei keinesfalls dazu führen, dass alle Informationen aus einer umfangreichen Quellenverwaltung in einem anderen Programm mit einfacherer Behandlung der Quellen ankommen.

Vereinbarungen zu SOUR haben daher im wesentlichen den Zweck, dass zwischen Programmen mit gleicher Strukturtiefe zur Quellenverwaltung der Austausch per GEDCOM ohne Informationsverlust funktioniert, und bei einer Übertragung in Programme mit anderer Struktur der Quellenverwaltung zumindest die gemeinsamen Elemente richtig zugeordnet übertragen werden.

Vereinbarungen für den Export zu SOUR

E1 Vorgaben des GEDCOM Standards 5.5.1 für Quellen

Die detaillierten Vorgaben zur Struktur der Beschreibung und des Zitierens von Quellen aus dem Standard müssen eingehalten werden.

Dies gilt sowohl für

• Quellenzitate (SOURCE_CITATION)

als auch für

• Quell-Datensätze (SOURCE_RECORD).

E2 Export mit/ohne Quell-Datensätze

Gemäß Standard ist sowohl der Export unter Verwendung von Quell-Datensätzen als auch derjenige ohne Quell-Datensätze ("eingebettete Quellen") zulässig. Der Standard empfiehlt eindringlich, Quell-Datensätze zu verwenden. Dieser Empfehlung wird auch hier gefolgt, der Export ohne Quell-Datensätze bleibt aber zulässig.

E3 Umfang der exportierten Quell-Struktur

Ein Programm, das intern eine strukturierte Quellenverwaltung hat, muss im Standard-Export diese Struktur in der vom Standard vorgegebenen Art exportieren.

E4 Zuordnung der Quellen-Zitate

Neben der Zuordnung von Quellen-Zitaten ermöglicht der Standard auch die Zuordnung von jeweils beliebig vielen Quellenzitaten zu einzelnen Ereignissen, Namen, Multimedia-Datensätzen, Bemerkungen. Bietet ein Programm intern solche Zuordnungsmöglichkeiten von Quellenzitaten, muss dies auch im GEDCOM-Export abgebildet werden.

Vereinbarungen zum Import von SOUR

I1 Umfang des Imports

Ein Programm muss beim Import diejenigen Strukturinhalte zu Quellen aus einer GEDCOM-Datei richtig zugeordnet importieren, die es intern auch darstellen kann. Dies gilt unabhängig davon, ob die angebotenen GEDCOM-Datei mit oder ohne Quell-Datensätze aufgebaut ist. Dagegen gehen angebotene Inhalte, die das Programm intern nicht strukturiert verarbeiten kann, in der Regel verloren.

I2 Ersatzweise Übernahme von Informationen

Um die Informationsverluste nach I1 zu verringern, ist es zulässig, Informationen aus intern nicht strukturiert zu verarbeitenden Teilen zu Quellen ersatzweise in unter der Quelle angeordneten Bemerkungen einzuspeichern. Der Standard empfiehlt als Mindestumfang bei einer solchen Vorgehensweise, Informationen zu TITL, AUTH, PUBL und REPO zu übernehmen. Dieser Empfehlung schließen sich die hier beteiligten Autoren an. Aus dem Datensatz REPO soll dabei der Inhalt von NAME übernommen werden, also die Beschreibung des Standortes der Quelle.

I3 Zuordnung der Quell-Zitate

Hat ein Programm nicht die Möglichkeit der Zuordnung von Quell-Zitaten zu einzelnen Ereignissen usw, so sollte beim Import das Quell-Zitat dennoch berücksichtigt werden und dem übergeordneten Datensatz (Person oder Familie) zugeordnet werden. Hat das Programm dagegen intern die Möglichkeit der Zuordnung der Quell-Zitate, so muss die Zuordnung aus der GEDCOM-Datei auch übernommen werden.

Behandlung/Darstellung schwieriger Situationen

Musterdatei zur Diskussion der Quellen

In der Gedcom-L wird die Diskussion um die Möglichkeiten des Exportes zu Quellen derzeit anhand eines Beispieles diskutiert. Die dabei entwickelte GEDCOM-Datei ist hier aufgeführt. Sie nutzt einige Möglichkeiten des Standards, aber noch längst nicht alle Strukturen und Kennzeichen.

In der Datei werden anhand eines Musterbeipieles die Quellen zum Todesfall für eine Person beschrieben. D.h. es sind mehrere Quellen für ein Ereignis zitiert. Dabei werden Quellendatensätze eingesetzt mit Querverweisen (Zitaten) im Datensatz der Person. Die Datei nutzt weiter die seit GEDCOM-Standard 5.5.1 gegebene Möglichkeit, zu einer Quelle (hier: Kirchenbuch Hambuch) verschiedene Standorte / Archive (Kennzeichen REPO, im Beispiel: Bistumsarchiv Trier - Original, LDS-Mikrofilme im Zentralarchiv der Mormonen in Utha/USA) anzugeben.

Die Programmautoren testen derzeit, was beim Import der Datei in ihre Programme passiert. Nicht jedes Programm unterstützt eine Quellenverwaltung

• mit Zuordnung von Quellenzitaten zu einzelnen Ereignissen
• mit Zuordnung mehrerer Quellenzitate zu einem Ereignis
• mit Zitaten von Archiv-/Standort-Datensätzen (REPO) in einem Quellen-Datensatz

Programme, die statt der Quellen-Datensätze eingebettete Quellen verwenden, haben deutlich weniger Strukturinformationen. Hier geht es dann um die Diksussion, was aus dem Beispiel übernommen werden kann und wie es übernommen wird.

Es ist geplant, die Datei weiter auszubauen.

Hier ist sie nun, die Beispieldatei (mit fiktiven Daten):

0 HEAD
1 SOUR manual
1 SUBM @SUBM@
1 GEDC
2 VERS 5.5.1
2 FORM LINEAGE-LINKED
1 CHAR UTF-8
0 @SUBM@ SUBM
1 NAME unknown
0 @I1@ INDI
1 NAME Peter /Emmerich/
1 DEAT
2 DATE 6 SEP 1825
2 PLAC Hambuch
2 SOUR @S1@
3 PAGE 125
3 EVEN DEAT
2 SOUR @S2@
3 PAGE S87/1825
3 EVEN DEAT
2 SOUR @S3@
3 PAGE H12/1830
3 EVEN MARR
4 ROLE FATH
3 DATA
4 TEXT Sohn des am 6. September 1825 verstorbenen Schuhmachers Peter Emmerich und se
5 CONC iner Frau Magdalena, geb. Ungers, aus Hambuch
2 SOUR @S4@
3 PAGE 98 Nr. 734
0 @S1@ SOUR
1 TITL Kirchenbuch Hambuch IV
1 ABBR KB Hambuch IV
1 DATA
2 EVEN BIRT, DEAT, MARR
3 DATE FROM 1798 TO 1827
3 PLAC Hambuch, Rheinland-Pfalz
1 PUBL Katholische Kirche St. Johannes, Hambuch
1 REPO @R1@
2 NOTE Kirchenbuch kann im Lesesaal im Original eingesehen werden, einzeln
3 CONC e Digitalfotos erlaubt (Stand 2005). Inzwischen werden nur noch Mik
3 CONC rofilme vorgelegt und das Fotografieren ist verboten.
2 CALN ?
3 MEDI book
1 REPO @R2@
2 CALN 0462735
3 MEDI fiche
0 @S2@ SOUR
1 TITL Zivilstandsregister Kaisersesch
1 ABBR ZR Kaisersesch
1 PUBL Standesamt Kaisersesch
1 REPO @R3@
2 CALN Bestand 656,75 Bd. 1-55
3 MEDI book
2 CALN Afi 2278ff
3 MEDI fiche
2 NOTE zugänglich im LHA Koblenz sind nur die Mikrofilme
0 @S3@ SOUR
1 TITL Zivilstandsregister Cochem
1 ABBR ZR Cochem
1 PUBL Standesamt Cochem
1 REPO @R3@
2 CALN Afi 1745ff
3 MEDI fiche
0 @S4@ SOUR
1 TITL Ortsfamilienbuch Hambuch
1 ABBR OFB Hambuch
1 AUTH Fred Mustermann
1 PUBL Köln 1985
2 CONT Eigenverlag
2 CONT Hauptstr. 1
2 CONT D-50667 Köln
1 NOTE Das OFB Hambuch enthält auch die Familien der Orte
2 CONT Brachtendorf, Eulgem, Gamlen, Zettingen,
2 CONT welche mit zur Pfarrei Hambuch gehören
0 @R1@ REPO
1 NAME Bistumsarchiv Trier
1 ADDR Jesuitenstraße 13
2 CONT 54290 Trier
1 PHON +49 (0)651 96627-0
1 EMAIL bistumsarchiv@@bgv-trier.de
0 @R2@ REPO
1 NAME Family History Library
1 ADDR 35 N West Temple Street
2 CONT Salt Lake City, Utah
2 CONT UT 84150
0 @R3@ REPO
1 NAME Landeshauptarchiv Koblenz
1 ADDR Karmeliterstraße 1-3
2 CONT 56068 Koblenz
1 PHON +49 (0)261 9129-0
1 EMAIL post@@landeshauptarchiv.de
1 WWW www.landeshauptarchiv.de
0 TRLR

Abweichungen vom Standard bei der Verwendung

Unerlaubte parallele Verwendung von Quell-Zitaten mit und ohne Verweis auf Quell-Datensätze

Der GEDCOM Stadard 5.5.1 hat zur Behandlung der Quellenzitate eine eindeutige Präferenz: Er empfiehlt, dafür Quell-Datensätze einzusetzen. Und er schreibt vor, dass Programme, die mit Quell-Datensätzen arbeiten, die ältere Version mit einer <SOURCE_DESCRIPTION> nicht mehr verwenden dürfen. Originalzitat aus dem Standard:

<Zitat> Die Daten in der Quellzitat-Struktur (SOURCE_CITATION) beinhaltet Informationen zu der Quelle im Bezug auf die zitierten Daten. (Siehe GEDCOM Beispiele). Systeme, die keine Quell-Datensätze16 (SOURCE_RECORD) nutzen, müssen die nicht bevorzugte zweite Variante der Quellzitat-Struktur nutzen. Systeme, die Quell-Datensätze der Ebene null nutzen, müssen dann, wenn sie ein Quellzitat entdecken, das keinen Zeiger auf einen Quell-Datensatz enthält selbständig einen neuen Quell-Datensatz anlegen, und die Beschreibung (SOURCE_DESCRIPTION) des Quellzitates in dessen Titel speichern. </Zitat>

In der bisherigen Praxis haben viele Programme diese Vorschrift nicht beachtet. Sie haben parallel Verweise auf Quell-Datensätze

• 1 SOUR @S1@

und Quell-Zitate mit Benutzung der <SOURCE_DESCRIPTION>

• 1 SOUR Heiratseintrag

verwendet.

Zusätzlich gibt es das Problem, dass einige Programme auch leere <SOURCE_DESCRIPTION> bzw. fehlende Zeiger auf Quell-Datensätze exportieren, also

• 1 SOUR

Das ist nach Standard nicht erlaubt, da ein Zeiger mindestens die umrahmenden @ und ein Zeichen dazwischen haben muss, und auch die <SOURCE_DESCRIPTION> mindestens ein Zeichen haben muss ( {1:248} mit Möglichkeit der Verlängerung über CONC / CONT ).

Die Autoren haben diskutiert, wie mit dieser Vorschrift des Standards umgegangen werden soll. Sie haben festgehalten, dass es auch Programme gibt, die für beide Versionen (mit/ohne Quelldatensätze) verschiedene interne Datenfelder / Datenstrukturen angelegt haben und somit beide Versionen intern parallel dem Anwender anbieten. Diese Programme haben ein besonderes Problem, einen GEDCOM-Standard gerechten Export aufzusetzen.

Folgende Vorgehensweise wird derzeit in der Liste diskutiert:
1. Bei einer nichtleeren SOURCE_DESCRIPTION wird dazu ein Quell-Datensatz angelegt, der als TITL und als ABBR den Inhalt der SOURCE_DESCRIPTION bekommt.
2. Im Falle einer leeren SOURCE_DESCRIPTION (oder eines fehlenden Zeigers auf den Quell-Datensatz) wird ein Quell-Datensatz mit dem TITL und der ABBR "(ohne Titel)" angelegt.
3. Optional können in beiden Fällen 1 und 2 eine NOTE im Quell-Datensatz hinzugefügt werden, dass dieser Datensatz bei einem Import einer nicht Standard-gerechten oder mit der alten SOURCE_DESCRIPTION aufgebauten GEDCOM-Datei erzeugt wurde.
4. Keine gemeinsame Vorgehensweise wird bisher gefunden, wenn in einer GEDCOM-Datei gleich mehrfach eine leere oder eine gleichlautende SOURCE_DESCRIPTION angeboten wird. Hier wird entweder zu jeder verschiedenen SOURCE_DESCRIPTION genau ein Datensatz angelegt, den dann alle Stellen zitieren, bei denen diese SOURCE_DESCRIPTION vorkam. Oder es werden für jedes Quell-Zitat getrennte Quell-Datensätze angelegt. Programme, die einen eindeutigen Titel im Quell-Datensatz benötigen, müssen dafür einen Zusatz zur SOURCE_DESCRIPTION ab dem 2. Zitat hinzufügen, z.B. eine laufende Nummer.
5. Wie die Programme solche Daten nach dem Import behandeln, ist Programm interne Sache und wird hier nicht festgelegt.

Zu Punkt 3 besteht die Kritik, dass Programme, die beim Import wieder intern die Datenstruktur mit den SOURCE_DESCRIPTION rekonstruieren wollen, das über eine Abfrage machen würden, ob sich neben dem automatisch erzeugten TITL und ABBR weitere genealogische Informationen im Quell-Datensatz befinden. Dazu können vom Anwender eingegebene Informationen in den Bemerkungen gehören. Um hier dennoch die Rückumwandlung zu schaffen, wird entweder ein Verzicht auf das optionale Anlegen der Bemerkung unter 3. oder aber ein einheitlicher, standardisierter Text dazu diskutiert.