TOPIC:

I realize that webtrees v2.1 is a much anticipated version of webtrees that will support extending and augmenting webtrees to include additional tags that will aid in supporting our needs for tracking and exposing additional data-points. But a new and important (in my opinion) addition to the GEDCOM Standard in v7.0 is the inclusion of a HEAD.SCHMA.TAG structure that provides for a URI link to a definition of a particular extended tag. For example tags like _PRIM would have a link in the HEAD record to a page that defines what the tag means and how it is used.

This, for me, is a much needed addition to "The Standard", providing receiving program with a place to look up undocumented tags for their meaning and use as they "could" relate to the receiving program's fields/concepts. It however falls short of what I truly wanted which was a "extended tag clearing house" that documents and manages all extensions so that various sending programs reuse and standardize on extensions rather than redefining and or reusing tags that other programs use in their transmissions.

Reference for this discussion is in section 1.5.1 starting on page 15 of the Release Candidate documentation.

The reason I bring this up here and tie it to a future release (v2.1) of webtrees is that to:
1) Help webtrees developers to place all current extensions used by other software manufacturers into the webtrees internal "known extensions" list (used when importing a GEDCOM).
2) Possibly create a Data Dictionary on the webtrees web sight or develop an Integrated Data Dictionary (IDD) within the GEDCOM structure created for all webtrees installations.

As a former developer of a CODASYL database engine (DBMS) which included as part of the DBMS an IDD that defined all elements of the database I find this concept interesting and important.

To further explain the GEDCOM inclusion of a "Documented Extension" the following HEAD tags were added:

For example:

In the past webtrees would generate a few of its own extensions (_ASSO) or use other program's extensions. This practice will most likely continue, but my understanding of webtrees v2.1 is that the tree administrator can create their own extensions and that the admin would then be responsible for documenting on their website (with a page regarding the extension definition) any extensions they generate. webtrees would need to do the same for any self generated extensions as well.

The point of this entry is to see if, in antisipation of v7.0 we need to begin creating Data Dictionary page for webtrees, encourage tree admins to use this webtrees Data Dictionary page, document any incoming GEDCOM extension tags that will be understandable by v2.1 for our own use?

I think that it is a good idea to have documentation for each custom GEDCOM tag that is used in my tree. Doing this with the new tag SCHMA in GEDCOM 7.0 is a good approach. Some time ago I already started to document all the custom tags which are supported by webtrees but don't finish it, because Greg signaled that webtrees 2.1 will bring new possibilities and because I heard rumors about the eventually coming possibilities in GEDCOM 7.0. As soon as there are some examples of how the documentation using SCHMA can be done, I will try it again.

This HEAD:SCHMA structure does not allow us to have a tag with different meanings in different contexts.

For example, these are different types of data with the same tag:

INDI:NAME and REPO:NAME
HEAD:SOUR and INDI:SOUR
INDI:ADOP and INDI:ADOP:FAMC:ADOP
etc.

Yes! Better than nothing, but not sufficient. The approach of the GEDCOM-L with _SCHEMA was much better and would allow the description of different types of data with the same tag (see Addendum page 37).

Tags like you indicated are considered an "stdTag" and are defined within the GEDCOM v7.0 document. These tags are not considered "Extension" tags and are not prohibited. If you wanted to use the "NAME" tag (ADOP, SOUR) you would be required to define them as extTag if they change the meaning from the stdTag, which forces you to enter them as _NAME (_ADOP, _SOUR) in the GEDCOM and then create a HEAD:SCHMA:TAG structure for them.

If, for example, I wanted to output a "Place Location" as a record in a GEDCOM I would either place an "_" before each tag that has the same name as ones documented in GEDCOM v7.0 and changes the meaning (or structure) or provide new tag names.


For example the following is defined in the GEDCOM-L documentation:
0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M}
2 DATE <DATE_VALUE> {0:1}
2 ABBR <ABBREVIATION_OF_NAME> {0:M}
3 TYPE <TYPE_OF_ABBREVIATION> {0:1}
2 LANG <LANGUAGE_ID> {0:1}

Would be wrong. This structure does use tags that are defined to be the same as those that are in the GEDCOM document but may also change the definition of the tag and therefore the tag become an extTag.

The above would become:
0 @<XREF:_LOC>@ _LOC
1 NAME <PLACE_NAME> {1:M}
2 DATE <DATE_VALUE> {0:1}
2 _ABBR <ABBREVIATION_OF_NAME> {0:M}
3 _TYPE <TYPE_OF_ABBREVIATION> {0:1}
2 LANG <LANGUAGE_ID> {0:1}

My take on this is that:

1. NAME This tag usage does not change the basic definition of the tag in the v7.0 document

   NAME
   The name of the superstructure’s subject, represented as a simple string.
   The NAME tag is also used in a context-defined way for one other structure:
   INDI.NAME
   A PERSONAL_NAME_STRUCTURE (p.48) with parts, translations, sources, and so forth.

   and therefore would not be considered an extTag.
2. DATE Most likely would be defined and used as documented in the v7.0 of the Standard.
3. ABBR Since the ABBR tag in the v7.0 document is defined without any substructure and this usage has a substructure, ABBR becomes an extTag (_ABBR) and therefore would need to be defined for its use.
4. TYPE This tag may not need the "_" preceding it It is sometimes used as an enumerated value in the v7.0 document and at other times it is "free form". I kind of wish the v7.0 document had changed the usage of the tag to be either enumerated or "free form" but not both.
5. LANG As long as it follows the guidance as defined by IETF BCP 47, this can be used as a stdTag.