Table of Contents

GEDCOM Usage Recommendations

How do we record godparents, witnesses, midwives ...?

The names of a midwife, godfather, or witness to a marriage are often very important for family research. We need them sometimes to ensure whether we found the desired family in a village with several families of the same name.

Normally we don't need to create individual records for those people in our file. In this case we can simply record them in a Note to the person, the birth, or the marriage. If we use inside the note keywords as 'Godmother: ', Best man: ', or 'Maid of honor' we could even analyze them by program, e.g. translate them later into a standard form.

But there is a problem if we want to put them into Individual records and link them to our ancestors. This might be necessary where they are ancestors as well.

How to record such cases was solved by GEDCOM rather late and unsatisfyingly with the property 'ASSO'. As a consequence many genealogical programs designed proprietary and incompatible solutions. Others misinterpreted the definition of the direction of the relationship. Additionally there was a change from 5.5 to 5.5.1, that is upwards incompatible, though not explicitly mentioned as usual.

:-( Caution: It is rather problematic to exchange files that use 'ASSO'.

Other keywords: groomsman, maid of honor

User-Defined Properties = Non-Standard Tags

GEDCOM allows but does not encourage the use of user-defined GEDCOM tags. These must have a leading underscore so that they will not conflict with future GEDCOM standard tags, e.g. _TODO.

Non-standard tags (application specific as well!) should be used only when structured information cannot be represented using existing context. Using a Note field is a more universal way of transmitting genealogical data that does not fit into the standard GEDCOM structure.
(Excerpt from GEDCOM 5.5.1 Lineage-Linked Form Usage Conventions)

:-( Caution: It is rather problematic to exchange files that contain user-defined properties.

No empty tags allowed

All GEDCOM lines have either a value or a pointer unless the line contains subordinate GEDCOM lines.
In other words the presence of a level number and a tag alone should not be used to assert data. For example, '1 DEAT Y' should be used to imply a death known to have happened but date and place are unknown, not '1 DEAT'.
(Excerpt from GEDCOM 5.5.1 Lineage-Linked Form Usage Conventions)

:-( Caution: Some genealogy programs do not accept GEDCOM files with empty tags.

Conflicting event dates and places

Conflicting event dates and places should be represented by placing them in separate event structures with appropriate source citations rather than by placing them under the same enclosing event.
(Excerpt from GEDCOM 5.5.1 Lineage-Linked Form Usage Conventions)

Equal tags with equal level numbers within the same context

Equal tags with equal level numbers within the same context1) imply that multiple opinions or multiple values of the data exist. The significance of the order in these cases is interpreted as the submitter's preference. The most preferred value being the first with the lesser preferred data listed in subsequent lines by order of decreasing preference. For example, a researcher who discovers conflicting evidence about a person's birth event would list the most credible information first and the least credible or least preferred items last.

:-( However, programs that only handle one instance of a tag may use only the last one from a GEDCOM transmission. This causes the preferred value to be dropped when more than one instance is present.

(Excerpts from GEDCOM 5.5.1 Lineage-Linked Form Usage Conventions)

Common examples are children, spouses, names, occupations, notes, … In GenJ we can change the sequence of such entries with drag and drop in the Edit View in GEDCOM mode, e.g. the presumed sequence of children in the family record.

:!: If we exchange our data with other programs that possibly cannot handle multiple tags of the same level it could be wise to store the remaining information within a Note.

See also

1) here: all directly subordinate properties of an entity or property