GEDCOM/OBJE-Tag

Name und Bedeutung

Tag

OBJE

Formelle Bezeichnung

OBJECT

Deutsche Bezeichnung

Verweis auf Daten

Verwendung

Normalerweise Verweis auf Bild-, Audio-, Video-Daten, z.B. Fotos, Dokumenten-Scans: "Multimedia-Link"

Formale Beschreibung zulässiger Werte

Vorgaben des GEDCOM Standards

Verweise auf meist in Dateien angelegte, zu einem Datensatz gehörende Bild-, Audio- oder Videodaten werden über das Kennzeichen OBJE dargestellt. Wie bei Quellen und Bemerkungen gibt es im GEDCOM-Standard zwei verschiedene Vorgehensweisen zu OBJE:

• eingebettete Darstellung: OBJE ist mit allen untergeordneten Kennzeichen direkt im aufrufenden Datensatz enthalten
• eigener Datensatz: OBJE verweist mit einem Zeiger auf einen Datensatz, in dem die entsprechenden Informationen enthalten sind

Dies wird im GEDCOM-Standard 5.5.1 so dargestellt:

MULTIMEDIA_LINK:=
[
n OBJE @<XREF:OBJE>@ {1:1}
|
n OBJE
+1 FILE <MULTIMEDIA_FILE_REFN> {1:M}
+2 FORM <MULTIMEDIA_FORMAT> {1:1}
+3 MEDI <SOURCE_MEDIA_TYPE> {0:1}
+1 TITL <DESCRIPTIVE_TITLE> {0:1}
]

Dabei ist die Zeile mit +2 FORM bei GEDCOM 5.5.1 neu gegenüber GEDCOM 5.5 eingefügt. MEDI hat entsprechend eine um 1 höhere Ebenennummer erhalten.

Der Multimedia-Datensatz sieht nach GEDCOM-Standard-Vorgabe so aus:

MULTIMEDIA_RECORD:=
n @XREF:OBJE@ OBJE {1:1}
+1 FILE <MULTIMEDIA_FILE_REFN> {1:M}
+2 FORM <MULTIMEDIA_FORMAT> {1:1}
+3 TYPE <SOURCE_MEDIA_TYPE> {0:1}
+2 TITL <DESCRIPTIVE_TITLE> {0:1}
+1 REFN <USER_REFERENCE_NUMBER> {0:M}
+2 TYPE <USER_REFERENCE_TYPE> {0:1}
+1 RIN <AUTOMATED_RECORD_ID> {0:1}
+1 <<NOTE_STRUCTURE>> {0:M}
+1 <<SOURCE_CITATION>> {0:M}
+1 <<CHANGE_DATE>> {0:1}

Wie schon bei SOUR und NOTE sind im eigenen Datensatz für OBJE mehr strukturelle Möglichkeiten zur Darstellung von Detailinformationen gegeben als in der eingebetteten Version. Auffällig ist die Verwendung unterschiedlicher Kennzeichen für den <SOURCE_MEDIA_TYPE> in der eingebetteten Version ( MEDI ) gegenüber der Datensatz-Version ( TYPE ). Das ist wohl dem noch unausgereiften Stand des GEDCOM 5.5.1 geschuldet.

Vereinbarungen zu OBJE

Auf der Basis der Diskussion in der Gedcom-L wurden die folgenden Vereinbarungen entwickelt und durch Abstimmung unter den Autoren verabschiedet. O2 und O3 haben auch aus unterschiedlichen Gründen einige Gegenstimmen erhalten, so dass hier in einer späteren Phase noch versucht werden soll, Verbesserungen einzubauen.

O1 Umfang zu Multimediadateien

Es wird vereinbart, den Export zu Multimediadateien entsprechend der Vorgaben des GEDCOM Standards 5.5.1 durchzuführen. Insbesondere müssen die Änderungen gegenüber dem GEDCOM-Standard 5.5 im Export umgesetzt werden: Einführung des vorgeschriebenen Kennzeichens FORM unter OBJE.FILE, Entfall eingebetteter Binärdateien ( BLOB ). Die Referenzierung mehrerer Multimediadateien ( OBJE.FILE(n) ) in einem Multimediadatensatz ist wie im Standard vorgesehen zulässig, wird jedoch nicht empfohlen: Viele Programme können diese neue Struktur in ihrem Import nicht verarbeiten.

O2 Referenzierung auf Multimediadateien

Auf Multimediadateien wird durch die Angabe von Pfadinformationen und Dateinamen verwiesen ( in OBJE.FILE ). Zu diesen Verweisen wird vereinbart:

Hinter dem Kennzeichen FILE dürfen wahlweise folgende Angaben exportiert werden:

• 1. Der reine Dateiname „Dateiname“
• 2. Der absolute Pfad „absPfad+Dateiname“
• 3. Ein relativer Pfad „relPfad+Dateiname“

Hierzu gelten folgende Festlegungen:

• a) Der Dateiname muss vollständig mit der Dateiendung zusammen ausgegeben werden.
• b) Der absolute Pfad enthält auch die Laufwerkskennung, es darf auch eine komplette URI ausgegeben werden ( siehe [1] )
• c) Der relative Pfad relPfad beginnt immer mit einem Punkt, z.B.: ./Verzeichnisname/
• d) es wird empfohlen, mehr als die im Standard vorgeschriebene Mindestlänge von 30 Zeichen für das Datenfeld OBJE.FILE umzusetzen, um auch längere Dateinamen inkl. der vorgenannten Pfadinformationen aufnehmen zu können.
• e) die Dateiendung muss zusätzlich in einem dem FILE Kennzeichen untergeordneten Kennzeichen FORM exportiert werden.

O3 Ergänzende Informationen zu FILE

Der Inhalt von FILE hängt davon ab, welchen Aktion der Anwender umsetzen will:

• bei einem Transfer innerhalb eines Rechners (ohne Verschieben/Kopieren von Media-Dateien) werden die absoluten Pfadangaben vom empfangenden Programm benötigt. Es wird daher empfohlen, in diesem Fall den absoluten Pfad einzutragen.
• bei einem Transfer auf einen anderen Rechner (mit gleichzeitigem Transfer der Mediadateien) ist dem exportierenden Programm die (zukünftige) Verzeichnisstruktur auf dem empfangenden Rechner in der Regel nicht bekannt. Daher wird empfohlen, unter FILE relative Pfade einzusetzen. Gleichzeitig sollten die Mediadateien gemäß dieser Pfade auf das Transportmedium kopiert werden oder der Anwender entsprechende Kopieranweisungen erhalten.

O5 Zulässige Dateitypen

Es ist erlaubt, beliebige Dateien als Multimediadateien zu referenzieren. Die im GEDCOM-Standard enthaltene Aufzählung von Dateitypen unter MULTIMEDIA_FORMAT wird als nicht abschließende Liste von Beispielen interpretiert.

O6 Ausschnitte aus Bilddateien

Es ist zulässig, Informationen zu Ausschnitten aus referenzierten Bilddateien zu exportieren. Um diese Information zu exportieren, wird die Verwendung der Nutzerdefinierten Kennzeichen _PRIM_CUTOUT und _POSITION vereinbart. Diese Kennzeichen werden dem Kennzeichen FILE untergeordnet:

2 FILE ./Dateiname.Dateityp
3 FORM Dateityp
3 _PRIM_CUTOUT Y
3 _POSITION x1 y1 x2 y2

Mit _PRIM_CUTOUT Y wird angegeben, dass in diesem Fall aus der Datei der unter _POSITION genannte Ausschnitt verwendet werden soll. Die genaue Bedeutung der Zahlenwerte x1,y1,x2,y2 ist derzeit noch in Abstimmung

O7 Priorität bei mehreren Media-Dateien

Sind in einem übergeordneten Datensatz mehrere Media-Objekte referenziert, so wird die Priorität gemäß GEDCOM-Standard durch die Reihenfolge der Aufrufe von OBJE im übergeordneten Datensatz festgelegt: Höchste Priorität hat der erste Aufruf. Sind innerhalb des OBJE-Datensatzes mehrere Dateien mit FILE referenziert, so hat der die zuerst angegebene Datei Priorität.

Es ist zulässig, die Priorität zusätzlich durch ein jeweils untergeordnetes Kennzeichen _PRIM mit dem Inhalt Y zu unterstützen. Dabei wird empfohlen, die durch den Standard festgelegte Priorisierung über die Reihenfolge der Angaben mit einzuhalten, z.B.:

0 @I1@ INDI
...
1 OBJE @O1@
2 _PRIM Y
1 OBJE @O2@

0 @O1@ OBJE
...
1 FILE "datei1"
2 FORM "..."
2 _PRIM Y
1 FILE "datei2"
2 FORM "..."

Behandlung/Darstellung schwieriger Situationen

Änderungen gegenüber GEDCOM 5.5

Im GEDCOM Standard 5.5.1 ist eine deutliche Änderung gegenüber dem Vorgänger 5.5 enthalten: Die Möglichkeit, komplette Multimediadateien mit dem Kennzeichen BLOB direkt in die GEDCOM-Datei einzubetten, wurde in 5.5.1 entfernt. Stattdessen enthalten die OBJE-Datensätze jetzt auch Verweise auf externe Dateien. Die Gedcom-L hat dies sehr intensiv diskutiert und ist zu folgenden Ergebnissen gekommen:

1. In 5.5 ist diese Einbettung nicht ausreichend beschrieben. Da der Verschlüsselungstyp für die Binärdatei nicht mit angegeben wird, wird es für das empfangende Programm schwierig, die Binärdaten zu entschlüsseln.

2. Es ist kein einziges Programm bekannt, welche diese Möglichkeit mit BLOB umgesetzt hat. Alle Genealogieprogramme, die überhaupt Multimedia-Dateien unterstützen, arbeiten mit Dateinamen ( OBJE.FILE ), ggfs inklusive Pfadangaben.

3. Bis auf einen Autor haben sich alle anderen Autoren und Anwender in der Diskussion dafür ausgesprochen, dem Standard 5.5.1 zu folgen und keine Einbettung von Binärdateien in GEDCOM-Dateien zu vereinbaren. Hauptbegründung ist neben der generellen Basis GEDCOM 5.5.1 in diesem Projekt die mangelhafte Kompatibilität einer solchen Vorgehensweise und damit drohender Datenverlust.

Enstprechend diesem Diskussionsstand sind die Entscheidungsvorschläge aufgebaut.

Zu dem neu eingeführten Kennzeichen FORM unter OBJE.FILE siehe unten (bei Dateitypen). Bei der Verwendung der eingebetteten Objektverweise (also ohne eigene OBJE-Datensätze) wurde die in 5.5 noch enthaltene Möglichkeit, Bemerkungen (Kennzeichen NOTE) dem Kennzeichen OBJE unterzuordnen, in 5.5.1 entfernt. Weiterhin wurde in 5.5.1 die Möglichkeit eingeführt, unter einem OBJE mehrere Dateien zu referenzieren. Damit können in einem Objekt z.B. Bild- und Tondateien zusammen referenziert werden und so einander zugeordnet werden.

Pfadangaben

In der Liste wurde kontrovers diskutiert, wie die Anforderung des Standards zur MULTIMEDIA_FILE_REFERENCE ( OBJE.FILE ):

"Eine komplette Referenz auf eine lokale oder entfernte Datei, auf die im GEDCOM-Kontext verwiesen wird."

zu interpretieren ist.

Eine Auslegung ist, dass mit dieser Standard-Vorgabe ausschließlich absolute Pfadangaben zulässig sind. Die andere ist, dass die Pfadangaben eine Identifizierung der Datei ermöglichen muss, was nach einem Datentransfer auf einen anderen Rechner mit dem Absolutpfad des urprünglichen Rechners nicht mehr geht.

Die beiden Positionen konnten in der Diskussion nicht entschieden werden. Dies wird über die Abstimmung zu den Entscheidungsvorschlägen erfolgen, welche der zweiten Interpretation (Identifizierung der Dateien unter Zuhilfenahme von Relativpfaden) folgen.

Abgelehnter Entscheidungsvorschlag

Mit deutlicher Mehrheit wurde der folgende Entscheidungsvorschlag (war als Alternative zum bereits zurückgezogenen O4(alt) eingebrcaht) in der Abstimmung der Programmautoren abgelehnt:

• O4 Vorbelegung im Header
• Optional darf im Header der GEDCOM-Datei ein Alternativpfad vorbelegt werden. Dazu wird ein Kennzeichen _ALTPATH direkt dem 0 HEAD auf Ebene 1 unterstellt.

• Diese Vorbelegung mit _ALTPATH gilt in der gesamten GEDCOM-Datei. Der Alternativpfad kann vom empfangenden Programm bei der Suche nach Mediadateien verwendet werden, die unter dem in OBJE-FILE angegebenen Pfad nicht gefunden werden.

Damit gibt es keine gemeinsame Vereinbarung über eine gleichzeitige Kennzeichnung relativer und absoluter Pfade zu einer OBJE-Datei. Der Dateipfad ist also mit einer der über O2 verabschiedeten Versionen zu beschreiben.

Nicht umgesetzte Version: Zusätzliche Kennzeichnung von Alternativ-Pfaden in OBJE

Der während der Diskussion zwischenzeitlich eingestellte Vorschlag mit Nutzerdefinierten Kennzeichen für Alternativpfade fand in der Liste schon in der Diskussuion keine erkennbare Mehrheit und wurde daher gar nicht erst zu einer Abstimmung geführt:

Vorbemerkungen

Es wurde in der Liste herausgearbeitet, dass je nach Anwendungsfall entweder eine absolute oder ein relative Pfadangabe im importierenden Programm benötigt wird. Der Gedcom-Standard sieht aber nur eine Angabe FILE unter OBJE vor. Aus diesem Grund kommen wir ohne eine Nutzerdefinierte Erweiterung nicht aus, wenn wir dem Anwender beim Export der GEDCOM-Datei die Entscheidung ersparen wollen, ob diese Datei nun auf demselben Rechner wieder eingelesen werden soll oder mit den Mediadateien zu einem anderen Rechner transferiert werden soll. Daher wird vorgeschlagen, die Möglichkeiten des Gedcom-Standards mit Nutzerdefinierten Kennzeichen zu erweitern, um die vorkommenden Varianten in einem gemeinsamen Export einer GEDCOM-Datei abdecken zu können. Der Vorschlag ist so strukturiert, dass der heutige Inhalt von OBJE.FILE wohl in allen Fällen beibehalten werden kann. Dafür werden unter OBJE-FILE entsprechende Alternativen zugelassen. Die Ergänzung zu einer vollständigen Information erfolgt dann optional über die neu einzuführenden Kennzeichen _ABSPATH und/oder _RELPATH.

Die GEDCOM-Datei ist dabei unabhängig davon, ob bei einer Weitergabe der Informationen an einem anderen Rechner die Media-Dateien von einem Genealogie-Programm „automatisch“ kopiert werden oder aber dem Anwender jeweils auf geeignete Weise die Hinweise gegeben werden, was er wohin zu kopieren hat. Wird somit sowohl beim Export als auch beim Import ein Programm eingesetzt, welches die Mediadateien gleich mit kopiert, so braucht der Anwender sich um diese Kopieraktivitäten nicht mehr zu kümmern. Die GEDCOM-Datei sieht aber genau so aus, wenn auf einer der beiden Seiten oder auf beiden Seiten ein Programm eingesetzt wird, welches das Kopieren der Mediadateien dem Anwender überläßt.

Der Vorschlag war in Entscheidungsvorschlägen O2 bis O4 dargestellt.

O3(alt) Ergänzende Informationen zu FILE

Optional darf die Angabe aus n FILE durch eines oder beide der folgenden, dem Kennzeichen FILE direkt untergeordneten Kennzeichen ergänzt werden:

• n+1 _ABSPATH
• n+1 _RELPATH

_ABSPATH darf nicht ausgegeben werden, wenn mit FILE ein absoluter Pfad ausgegeben wurde.

Unter _ABSPATH wird ein absoluter Pfad „absPfad1“ angegeben. Die Mediadatei ist dann zu finden unter absPfad1+Dateiname oder unter absPfad1+relPfad+Dateiname, je nachdem, was unter FILE steht.

Unter _RELPATH wird ein relativer Pfad „relPath1“ ausgegeben. Die Mediadatei ist dann zu finden unter „relPath1+Dateiname“ oder unter „relPath1+relPath+Dateiname“, je nachdem, was unter FILE steht. Ist unter FILE ein absoluter Pfad ausgegeben, so wird daraus nur der Dateiname entnommen. Es wird empfohlen, sowohl den Absolutpfad als auch den Relativpfad zu exportieren, um die GEDCOM-Datei entsprechend universell einsetzbar zu machen. Eine dieser Varianten kann dabei direkt in OBJE.FILE stehen, die andere sollte über das Nutzerdefinierte Kennzeichen ergänzt werden. Programme, die die Media-Dateien nicht selbst in ein Transportmedium kopieren, sollten dem Anwender eine Information geben, in welche Verzeichnisse er die Mediadateien kopieren muss, damit sie passend zu den Relativpfaden in der GEDCOM-Datei untergebracht sind.

O4(alt) Vorbelegung im Header

Optional können die Angaben unter _ABSPATH und/oder _RELPATH auch im Header der GEDCOM-Datei vorbelegt werden. Dazu wird das jeweilige Kennzeichen _ABSPATH bzw. _RELPATH direkt dem 0 HEAD auf Ebene 1 unterstellt.

Diese Vorbelegung von _ABSPATH bzw _RELPATH gilt in der gesamten GEDCOM-Datei dann für jedes FILE unter OBJE, welchem kein abweichendes _ABSPATH bzw- _RELPATH untergeordnet ist.

Da im Inhalt unter einem Kennzeichen erkennbar ist, ob es ein Absolutpfad oder ein Relativpfad ist, wurde weiter vorgeschlagen, statt der beiden Kennzeichen _ABSPATH und _RELPATH nur ein Nutzerdefiniertes Kennzeichen _ALTPATH (alternativer Pfad) zu verwenden.

Beispiele zur Anwendung von O2 bis O4

Beispiel 1

Für das exportierende Programm sind alle Bilder im Verzeichnis

• D:/ExpProgramm/Genealogie1/Bilder/

enthalten. Mit OBJE @O1@ soll nun der Verweis auf das in diesem Verzeichnis liegende Bild

• Bildname.jpg

exportiert werden. Für die Angabe des absoluten Pfades stehen z.B. folgende Möglichkeiten zur Wahl:

0 @O1@ OBJE
1 FILE D:/ExpProgramm/Genealogie1/Bilder/Bildname.jpg

oder

0 @O1@ OBJE
1 FILE Bildname.jpg
2 _ABSPATH D:/ExpProgramm/Genealogie1/Bilder/

oder

0 HEAD
1 _ABSPATH D:/ExpProgramm/Genealogie1/Bilder/
…
0 @O1@ OBJE
1 FILE Bildname.jpg

Für die Angabe des relativen Pfades stehen z.B. folgende Möglichkeiten zur Wahl:

0 @O1@ OBJE
1 FILE ./Bilder/Bildname.jpg

oder

0 @O1@ OBJE
1 FILE Bildname.jpg
2 _RELPATH ./Bilder/

oder

0 HEAD
1 _RELPATH ./Bilder/
…
0 @O1@ OBJE
1 FILE Bildname.jpg

Relativer und absoluter Pfad sollten beide exportiert werden, z.B.

0 @O1@ OBJE
1 FILE D:/ExpProgramm/Genealogie1/Bilder/Bildname.jpg
2 _RELPATH ./Bilder/

oder

0 HEAD
1 _ABSPATH D:/ExpProgramm/Genealogie1/Bilder/
1 _RELPATH ./Bilder/
…
0 @O1@ OBJE
1 FILE Bildname.jpg

Die beteiligten Programme können nun wie folgt mit den Daten umgehen:

• I. Unter dem angegebenen absoluten Pfad ist die Datei beim Import zu finden. Der Link zu dieser Datei wird hergestellt.
• II. Der absolute Pfad existiert nicht. Dann wird der relative Pfad ausgewertet. Je nach den Anweisungen, die die Programme den Anwendern hierfür geben (bei Übernahme GEDCOM-Datei und MediaDateien von einem Transportmedium wie Stick, CD, …), wird folgendes gemacht:
• IIa) Das exportierende Programm hat dem Anwender die Anweisung gegeben (über Bedienungsanleitung oder Meldung auf dem Bildschirm etc…), die Mediadateien inkl. der Unter-Verzeichnisse in ein vom Programm vorgegebenes Verzeichnis zu kopieren; oder das exportierende Programm hat dieses Kopieren selbst erledigt. Aus den Unterverzeichnissen werden die relativen Pfade abgeleitet, die der Media-Datei in der GEDCOM-Datei beigelegt werden. Das importierende Programm sucht die Datei ausgehend von dem Verzeichnis, in dem die GEDCOM-Datei steht. Der Pfad zu diesem Verzeichnis wird dabei um den relativen Pfad ergänzt und der Link zur Datei mit dem so gebildeten Verzeichnis gebildet. Das Programm kann dann den Link so belassen oder die Datei vom Transport-verzeichnis in ein programmintern festgelegtes Verzeichnis umkopieren und dann den Link entsprechend neu setzen.

Auf diesen Wegen kann gearbeitet werden, ohne dass der Empfänger des Transportmediums selber Mediadateien umkopieren muss.

• IIb) Der Export ist wie unter a) erfolgt. Das importierende Programm hat dem Anwender die Anweisung gegeben (über Bedienungsanleitung oder Meldung auf dem Bildschirm etc…), die Mediadateien inkl. der Unter-Verzeichnisse in ein vom Programm vorgegebenes Verzeichnis zu kopieren. Dann sucht das importierende Programm die Media-Datei in dem um den relativen Pfad erweiterten Verzeichnis (ausgehend vom Basis-Verzeichnis des aktuellen Programmlaufes) und stellt den Link her.
• IIc) Das exportierende Programm hat dem Anwender die Anweisung gegeben, alle Media-Dateien in ein vom Programm festgelegtes Verzeichnis direkt zu kopieren (ohne Unterverzeichnisse), und hat den _RELPATH unter Bezug auf das Verzeichnis, in das die GEDCOM-Datei exportiert wird, gebildet. Das importierende Programm verlinkt direkt auf den Dateinamen in dem mit dem relativen Pfad ermittelten Verzeichnis. Achtung: Das geht nur, wenn auf dem Transportmedium alle Media-Dateien verschiedene Namen haben, siehe Beispiel 2!)

Damit ist für alle diese Varianten, mit denen Programme beim Export und Import arbeiten, eine zielgerichtete Arbeit möglich. Variante II. b) wurde in der Liste z.B. für PAF und GenPlus diskutiert. Bei allen Variationen, die beim Export oder beim Import auftreten, wird beim Import entweder der Relativpfad oder der Absolutpfad benötigt. Beides kann der GEDCOM-Datei entnommen werden, wenn der entsprechenden Empfehlung von OF2 gefolgt wurde. Damit sind dann alle Varianten abgedeckt.

Beispiel 2

Das zweite Beispiel soll verdeutlichen, wie mit 2 Mediadateien gleichen Namens, die aber auf dem Ursprungsrechner in verschiedenen Verzeichnissen liegen, umgegangen werden kann.

Für das exportierende Programm sind die Bilder in den Verzeichnissen

• D:/ExpProgramm/Genealogie1/Bilder/

und

• D:/Anwender/MeineBilder/

enthalten. Es soll nun der Verweis auf zwei Bilder exportiert werden, die beide den Dateinamen

• Bildname.jpg

tragen und die jeweils in einem der beiden Verzeichnisse liegen.

Der Export mit absoluten Pfaden ist unproblematisch:

0 @O1@ OBJE
1 FILE D:/ExpProgramm/Genealogie1/Bilder/Bildname.jpg
…
0 @O2@ OBJE
1 FILE D:/Anwender/MeineBilder/Bildname.jpg

Werden die Bilder jedoch auf ein Transportmedium kopiert (Stick, CD, …), so müssen entweder die Bilder umbenannt werden (nicht zu empfehlen) oder aber auf dem Transportmedium auch zwei verschiedenen Verzeichnisse angelegt werden. In diesem Fall könnten also die Unter-Verzeichnisse /Bilder/ und /MeineBilder/ angelegt werden, oder aber auch /Bilder1/ und /Bilder2/. Die konkrete Bezeichnung hängt im Einzelfall davon ab, welche Anweisung das Programm dem Anwender gibt (oder was es selbst anlegt und kopiert). Folgen wir der Möglichkeit /Bilder1/ und /Bilder2/, so kann der Export so erfolgen:

0 @O1@ OBJE
1 FILE ./Bilder1/Bildname.jpg
…
0 @O2@ OBJE
1 FILE ./Bilder2/Bildname.jpg

Selbstverständlich können sowohl Absolutpfade und als auch Relativpfade exportiert werden, z.B. so:

0 HEAD
1 _ABSPATH D:/ExpProgramm/Genealogie1/Bilder/
1 _RELPATH ./Bilder1/
…
0 @O1@ OBJE
1 FILE Bildname.jpg
…
0 @O2@ OBJE
1 FILE ./Bilder2/Bildname.jpg
2 _ABSPATH D:/Anwender/MeineBilder/

Einige Bemerkungen zu den Vorschlägen

Was zunächst vielleicht kompliziert aussieht, ist es eigentlich aber nicht. Wie bei FORM unter PLAC ist zunächst der Vorschlag eingearbeitet, eine Vorbesetzung im Header der Datei unterzubringen, die immer dann gilt, wenn im OBJE-Datensatz nicht etwas anderes vorgegeben wird. Vorteil: Insbesondere bei langen Pfadnamen wird die Datei kürzer, die permanente Wiederholung desselben Pfadnamens kann entfallen.

Im weiteren muss das Programm beim Import in der Lage sein, relative und absolute Pfade zu unterscheiden. Das ist jedoch nicht neu gegenüber dem heutigen Iststand, da auf dem Markt ohnehin Programme mit beiden Varianten vorkommen. Somit verbleibt noch die Aufgabe, ggfs aus einer als Absolutpfad übergebenen Datei den Dateinamen herauszufiltern und diesen mit einem Relativpfad zu verknüpfen. Oder aus einer mit einem Relativpfad übergebenen Datei den Dateinamen herauszufiltern und diesen mit dem Absolutpfad zu verknüpfen.

Insgesamt kann damit jedes Programm den für seinen Export und Import optimalen Weg gehen, und doch kann über einen wie gerade beschrieben gestalteten Importmodul jede Version eingelesen werden.

Insbesondere deckt dieser Vorschlag beide Anwendungsfälle gleichzeitig ab, ohne dass der Anwender schon beim Export der GEDCOM-Datei eine Entscheidung zu treffen hätte: Transfer der Daten innerhalb desselben Rechners und Transfer der Daten über ein Transportmedium auf einen anderen Rechner.

Zur Kompatibilität ist zu bemerken, dass sich gegenüber dem heutigen Stand des Exports nichts ändert, wenn das empfangende Programm die Nutzerdefinierten Kennzeichen _ABSPATH und _RELPATH nicht versteht und sie samt Inhalt verwirft. Der unter FILE exportierte Inhalt kann beibehalten werden und dann eben wie bislang ohne Rückgriff auf die Zusatzinformationen unter den Nutzerdefinierten Kennzeichen verarbeitet werden.

Länge des Feldes Dateireferenz

Im GEDCOM-Standard wird zur Referenzangabe auf eine Multimediadatei folgende Angabe zur Länge gemacht:

MULTIMEDIA_FILE_REFERENCE:= {Size=1:30}

Eine Beschränkung auf 30 Zeichen könnte kritisch werden, wenn neben dem Dateinamen, wie diskutiert, auch Pfadangaben in diesem Feld mit aufgenommen werden. Daher verweist die Diskussion hier darauf, dass die Längenangaben zu Datenfeldern ( hier 30 Zeichen ) Mindestangaben sind. Es dürfen (und sollten hier) auch mehr Zeichen als 30 unterstützt werden, um die Pfad- und Dateinamen vollständig zu übertragen.

Dateitypen

Mit GEDCOM 5.5.1 ist auch das Kennzeichen FORM unter OBJE.FILE als zwingend vorgeschriebenes Kennzeichen eingeführt worden. In der Gedcom-L wurde diskutiert, dass die dazu im GEDCOM Standard enthaltene Auswahl der möglichen Dateitypen (Dateiendungen) nicht als abschließend, sondern nur als Auflistung von Beispielen interpretiert wird:

"MULTIMEDIA_FORMAT:= [ bmp | gif | jpg | ole | pcx | tif | wav ]"

In dieser Auflistung fehlen so wesentliche Dateiendungen wie mp3, pdf und doc. Solche Dateien sollen ebenfalls referenziert werden können.

Medientypen

Es wurde festgestellt, dass der GEDCOM Standard 5.5.1 mit seiner Definition der Medientypen nicht dem MIME-Standard folgt. Der GEDCOM-Standard hat das Kennzeichen MEDIA (welches ab 5.5.1 dem vorgeschriebenen OBJE.FILE.FORM optional unterstellt wird) wie folgt beschrieben: "SOURCE_MEDIA_TYPE:= [ audio | book | card | electronic | fiche | film | magazine | manuscript | map | newspaper | photo | tombstone | video ]"

Während audio und video z.B. im MIME Standard auch aufgeführt sind, gilt das nicht für die meisten anderen im GEDCOM-Standard genannten Medientypen. Dagegen fehlen solche Medientypen aus dem MIME-Standard wie text, image, message im GEDCOM-Standard.

Die Diskussion zu diesem Thema ist nicht abgeschlossen.

Ausschnitte aus Grafikdateien

Von einigen Programmen wurde vorgetragen, dass sie intern die Möglichkeit haben, aus vorhandenen Grafikdateien nur bestimmte Ausschnitte anzuzeigen. Die Information, welche Ausschnitte das jeweils sind, sollen auch nach GEDCOM exportiert werden. Ein Vorschlag dazu ist (in Anlehnung an den Family Tree Builder):

1 OBJE
2 FILE ./Bild.jpg
3 FORM jpg
3 _PRIM_CUTOUT Y
3 _POSITION 879 602 1559 1509
4 MEDI fiche
2 TITL Max Muster

Mit _PRIM_CUTOUT Y wird die Information übertragen, dass an dieser Stelle nur ein Ausschnitt der Datei referenziert wird, mit _POSITION dazu die Festlegung dieses Ausschnittes.

Offen ist noch die genaue Festlegung, was die 4 Zahlen hinter _POSITION beschreiben sollen. Es könnte sein: X-Position, Y-Position (beides von der linken oberen Ecke), Breite, Höhe. Es könnte aber auch sein: X-Position, Y-Position (beides von der linken oberen Ecke), X-Position, Y-Position (beides von der rechten unteren Ecke)

Es wird darauf hingewiesen, dass die Kennzeichen _PRIM_CUTOUT und _POSITION nicht direkt dem Kennzeichen OBJE unterstellt werden dürfen, weil dann nicht klar ist, zu welcher von ggfs mehreren FILE Kennzeichen unter einem OBJE der Ausschnitt gelten soll.

Abweichungen vom Standard bei der Verwendung

Durch die inkompatiblen Änderungen im Standard von 5.5 auf 5.5.1 kommt es je nach verwendetem Standard zu Abweichungen. Dies ist eine besondere Herausforderung an die Importmodule der Genealogieprogramme.

Eine weitere Fehlerquelle ist die unterschiedliche Struktur von eingebetteten OBJE zu den Datensätzen OBJE. Neben dem unterschiedlichen Kennzeichen zum SOURCE_MEDIA_TYPE ( TYPE bzw. MEDI ) ist auch die Ebene des Titels unterschiedlich:

Beim eingebetteten OBJE darf neben mehreren aufgeführten Dateien nur ein TITL stehen, im OBJE Datensatz wird dagegen jeder Datei ein TITL unterstellt. Es gibt Programme, die beim Import von einer Darstellung in die andere wechseln und dabei Fehler machen, indem sie die die erforderlichen Strukturänderungen nicht ausführen. Das führt zu ungültigem GEDCOM-Code.