A standard structure is a structure whose type, tag, meaning, superstructure, and cardinality within the superstructure are described in this document. This includes records such as INDI and substructures such as INDI.NAME.
The recommended way to go beyond the set of standard structure types in this specification or to expand their usage is to submit a feature request on the FamilySearch GEDCOM development page so that the ramifications of the proposed addition and its interplay with other proposals may be discussed and the addition may be included in a subsequent version of this specification.
This specification also provides multiple ways for extension authors to go beyond the specification without submitting a feature request, which are described in the remainder of this section.
Extensions can introduce new structure types, new enumeration values, new calendars with their associated months, and new data types. They can also extend existing structures with new permitted substructure types and extend existing enumeration-type payloads with new permitted values. Extensions cannot change existing meanings, cardinalities, or calendars.
A tagged extension structure is a structure whose tag matches production extTag. Tagged extension structures may appear as records or substructures of any other structure. Their meaning is defined by their tag, as is discussed more fully in the section Extension Tags.
Any substructure of a tagged extension structure that uses a tag matching stdTag is an extension-defined substructure. Substructures of an extension-defined substructure that uses a tag matching stdTag are also extension-defined substructures, but this specification deprecates using a stdTag with a definition that does not match any standard type with that tag. The meaning and use of each extension-defined substructure is defined by the tagged extension structure it occurs within, not by its tag alone nor by this specification.
In the following
0 @P1@ _LOC
1 NAME Βυζάντιον
2 DATE FROM 667 BCE TO 324
1 _POP 15149358
2 DATE 31 DEC 2020
0 @I1@ INDI
1 BIRT
2 _LOC @P1@_LOC are tagged extension structures, as is _POP._LOC.NAME and _LOC.NAME.DATE are both extension-defined substructures. Their meaning is defined by the specification defining _LOC, but since no standard definition of NAME permits DATE as a substructure, such use is deprecated._POP.DATE is an extension-defined substructure. Its meaning is defined by the specification defining _POP.DATEs appear to have g7:type-DATE payloads, we can’t know that is the intended data type without consulting the defining specifications of _LOC and _POP, respectively. The first might be a g7:type-DATE#period and the second a g7:type-DATE#exact, for example.If an extension-defined substructure has a tag that is also used by one or more standard structures, its meaning and payload type should match at least one of those standard structure types.
An extension-defined substructure with tag “DATE” should provide a date or date period relevant to its superstructure, as do all DATE-tagged structures in this specification. Extensions should not use “DATE” to tag a structure describing anything else (even something that might reasonably be abbreviated “date”, such as someone an individual dated).
As a special case, a tagged extension structure can be defined to have a standard structure type. These are called relocated standard structures and can only appear with superstructures that are not documented as a superstructure of that structure type in this specification. The extension-defined substructures of a relocated standard structure are the substructure types documented in this specification for that structure type, including usual limitations on cardinality, payloads, substructures, etc.
Suppose _DATE is defined to mean a g7:DATE (using a documented extension tag). Then in the following
0 @I1@ INDI
1 NAME John /Doe/
2 _DATE FROM 6 APR 1917 TO 11 NOV 1918
3 PHRASE During America's involvement in the Great War
1 BIRT
2 PLAC Queens, New York, New York, USA_DATE is a relocated standard structure with type g7:DATE, with the usual payload type and meaning of a g7:DATE.PHRASE is the structure type expected with that tag as a substructure of g7:DATE: namely, g7:PHRASE._DATE can not be used as a substructure of BIRT because BIRT has a documented g7:DATE substructure with tag DATE.BIRT can not be used as a substructure of _DATE or _DATE.PHRASE because neither structure type has a documented substructure with tag BIRT.Because all substructures have meanings defined relative to their superstructures and no records do, standard records cannot be relocated and relocated standard structures cannot be used as records.
The g7:PLAC substructure documents where the event described in its superstructure occurred. If an application wants a record to describe the place itself it should create a new URI for that extension; reusing g7:PLAC for a record with no superstructure is not appropriate.
All other non-standard structures are prohibited. Examples of prohibited structures include, but are not limited to,
stdTag that is not defined in this document;{0:1} appearing more than once;In some cases, an extension may need to allow multiple structures where this document allows only 1. The recommended way to do this is to create an extension tag and URI and serve a page describing how the semantics of the structure have been extended to allow multiple instances.
Suppose I have multiple sources that give different ages of the wife at a wedding; however, this specification allows only 1 MARR.WIFE.AGE. An extension could not include multiple MARR.WIFE nor MARR.WIFE.AGE, but could define a new extension _AGE, give it a URL, and provide the following definition of this extension structure type at that URL:
Alternate age: an age attested by some source, but not accepted by the researcher as the actual age of the individual. If the age is accepted by the researcher, the standard tag
AGEshould be used instead.
This alternate age extension structure could be used as follows:
Enumerated values may be extended with new values that match production extTag. Enumerations may not use standard values from other enumeration sets.
Dates may be extended provided they use a calendar that matches production extTag. Dates with extension calendars may also use extension months and epochs.