From GenWiki

Jump to: navigation, search


This page is an English extract of the German page GEDCOM/OBJE-Tag [1], for full details see the German page.

Name and Meaning






Normally reference to image, audio, video data, e.g. photos, document scans: "Multimedia-Link"

Formal Description of Permissible Values

Base: GEDCOM Standard Draft 5.5.1

References to image, audio or video data belonging to a record and stored in files are referenced by the tag OBJE. As with sources and notes the GEDCOM standard offeres two different approaches for OBJE:

  • embedded representation: OBJE and the related subordinate tags are part of the calling record
  • own record: OBJE refers by a pointer to a record in which the information is stored

This is specified in GEDCOM 5.5.1 standard as follows:

n OBJE @<XREF:OBJE>@ {1:1}

Note: GEDCOM 5.5 uses +1 FORM and +2 MEDI instead.

The multimedia record is specified in GEDCOM 5.5.1 as follows:

n @XREF:OBJE@ OBJE {1:1}
+1 <<CHANGE_DATE>> {0:1}

Note the different tags for the <SOURCE_MEDIA_TYPE> in the embedded version ( MEDI ) compared to the record version ( TYPE ). This is probably due to the immature state of the GEDCOM 5.5.1.

Agreements for OBJE

The agreements for OBJE are derived from the discussion on the Gedcom-L. They were decided by a vote of the program authors of the list.

O1 Extent to Multimedia Files

It is agreed to export the multimedia files according to the specifications of the GEDCOM standards 5.5.1. In particular, the changes from the GEDCOM 5.5 standard must be implemented in the export:

implementation of the tag FORM as sub-tag of OBJE.FILE, elimination of embedded binary files ( BLOB ).

Referencing several multimedia files ( OBJE.FILE ) in a multimedia data set as provided by the standard is permitted but not recommended: Many programs can not process this new structure during import.

O2 References to Multimedia Files

A reference to multimedia files will be done by specifying the path and file name information ( in OBJE.FILE ). For these references it is agreed:

After the tag FILE following information may optionally be exported:

  • 1. Just the plain filename „Filename“
  • 2. The absolute path „absPath+Fileiname“
  • 3. A relative path „relPath+Filename“

For this purpose, the following definitions apply:

  • a) The file name must be fully listed together with the file extension.
  • b) The absolute path includes also the drive letter, it may also be issued a full URI ( see [2] ).
  • c) The relative path relPath always starts with a dot, e.g.: ./directory_name/
  • d) It is recommended to implement more than the minimum length of 30 characters as defined by the standard for the data field OBJE.FILE to accommodate even longer file names incl. the above path information.
  • e) The file extension must also be exported by the tag FORM, subordinated of the tag FILE.

O3 Supplementary Information to FILE

The contents of FILE depends on what action the user wants to implement:

  • For a transfer within a computer ( without moving/copying of media files ) the absolute path information is required by the receiving program. It is recommended to enter the absolute path in this case.
  • For a transfer to another computer ( with simultaneous transfer of media files ) the exporting program doesn't know the ( future ) directory structure of the receiving computer. Therefore, it is recommended to use relative paths for FILE. At the same time the media files should be copied in accordance with these paths to the transport medium and/or to provide copy rules to the user.

O5 Permitted File Types

It is allowed to reference any files as a multimedia files. The list of file types under MULTIMEDIA_FORMAT, included in the GEDCOM standard, is interpreted as a not finalized list of examples.

O6 Sections of Image Files

It is acceptable to export information to sections of the referenced image files. To export this information, the use of user-defined tags _PRIM_CUTOUT and _POSITION is agreed. These codes are subordinate to the tag FILE:

2 FILE ./filename.filetype
3 FORM filetype
3 _POSITION x1 y1 x2 y2

By _PRIM_CUTOUT Y it is stated to used, from the file referred the cutout defined by _POSITION. The exact meaning of the numerical values x1, y1, x2, y2 is currently still in consultation.

O7 Priority for Multiple Media Files

If in a parent record several media objects are referenced, according to the GEDCOM standard the priority is determined by the sequence of OBJE tags in the parent record: Highest priority has the first call. Are whitin an OBJE record multiple files referenced by FILE, the file specified first has priority.

It is allowed to support the priority by an additional tag _PRIM with Y as content. It is recommended to follow the prioritizing according the standard, for example:

0 @I1@ INDI
1 OBJE @O1@
1 OBJE @O2@

0 @O1@ OBJE
1 FILE "file1"
2 FORM "..."
1 FILE "file2"
2 FORM "..."
Personal tools
In other languages