Each use of the extTag production is called an extension tag, including when used as a tag, calendar, month, epoch, or enumerated value. Each extTag is either a documented extension tag or an undocumented extension tag. It is recommended that documented extension tags be used instead of undocumented extension tags wherever possible.
A documented extension tag is a tag that is mapped to a URI using the schema structure. The schema structure is a substructure of the header with tag SCHMA. It should appear within the document before any extension tags. The schema’s substructures are tag definitions.
A tag definition is a structure with tag TAG. Its payload is an extension tag, a space, and a URI and defines that extension tag to be an abbreviation for that URI within the current document.
The following header
0 HEAD
1 SCHMA
2 TAG _SKYPEID http://xmlns.com/foaf/0.1/skypeID
2 TAG _MEMBER http://xmlns.com/foaf/0.1/memberdefines the following tags
| Tag | Means |
|---|---|
_SKYPEID | http://xmlns.com/foaf/0.1/skypeID |
_MEMBER | http://xmlns.com/foaf/0.1/member |
Note that at the time of writing, the FOAF URIs used in this example are not URLs.
The meaning of a documented extension tag is identified by its URI, not its tag. As such each documented extension tag needs its own URI: it is its URI, not its tag, that defines its meaning. Documented extension tags can be changed freely by modifying the schema, though it is recommended that documented extension tags not be changed. However, a tag change may be necessary if a product picks the same tags for URIs that another product uses for different URIs. A given schema should map only one tag to each URI.
The following 2 document fragments are semantically equivalent and a system importing one may export it as the other without change of meaning.
It is recommended that the URIs used for documented extension tags be URLs that can be used to access documentation for the meaning of the tag.
The W3C has an interest group note that discusses several ways of achieving this URI/URL mapping, including how a single webpage can describe multiple tags using either HTTP redirects (which requires some server setup) or what they call “Hash URIs” (which require no setup).
That interest group note also explains why it might be desirable to have a separate URIs for a concept and the document describing that concept. Because of the structure of the schema, that separation is less important for FamilySearch GEDCOM 7 than it is for the semantic web, but it remains good advice where feasible.
The schema structure may contain the same tag more than once with different URIs. Reusing tags in this way must not be done unless the concepts identified by those URIs cannot appear in the same place in a dataset, and should not be done unless the URIs identify closely related concepts.
Consider three extensions:
https://example.com/LocationRecord, a record that describes a location.https://example.com/LocationPointer, a substructure of most events that points to a https://example.com/LocationRecord.https://example.com/inLocoParentis, a substructure of some events indicating a non-parent entity that filled the legal role of a parent for that event.Given this, we have the following:
https://example.com/LocationPointer and https://example.com/inLocoParentis must not be given the same tag because they can appear in the same place in a dataset.https://example.com/LocationRecord and https://example.com/inLocoParentis may be given the same tag, but should not be given the same tag because they identify unrelated concepts.https://example.com/LocationRecord and https://example.com/LocationStructure may be given the same tag.One way to satisfy these constraints and recommendations is with the following schema:
An extension tag that is not given a URI in the schema structure is called an undocumented extension tag. The meaning of an undocumented extension tag is identified by its superstructure type and its tag.