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:
1 SCHMA
2 TAG <tag value> <URI>
For example:
0 HEAD
1 SCHMA
2 TAG _PRIM http://website.com/IDD/Primary
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?