RFC-G103:  GML Core Tag System and Logic
J. D. McPhail and M. Oner
April 2001

 

Introduction:

Logical Structure of Geotechnical Data

For the development of the GML tags, it is proposed that the representation of geotechnical data possess a structure that follows the categories of geotechnical data. The three main sources of data that contribute information to the geotechnical project are the

(1) Office Category

(2) Field Category

(3) Laboratory Category

By using categories as the basis for the organization of the geotechnical data in a project, an added bonus will be a solution to the responsibility question. It is proposed that each category contain the data that originates at that site.

Figure 1. Tagging the three top level categories of geotechnical data

The aforementioned categories (office, laboratory and field) form the first level of the geotechnical data structure. The second level involves the tasks that are normally performed at each site. These are referred to as "subcategories". Together, these form the following geotechnical data structure:

SITE 1. The typical tasks performed in the office include:

SITE 2. The typical tasks performed in the field include:

SITE 3. Some tasks performed in the laboratory are

 

GML Core:

Tagging the Geotechnical Data

The tags presented below (Figure 2) to describe the logical structure of geotechnical data are named "core tags". These core tags comprise the first three levels of the data tree representing the geotechnical data structure (<GML> is the root node). These core tags should not be changed. The fourth level tags, however, are the ones that will label the specific individual data items. The process of defining new tags is explained subsequently.

 

Figure 2: Three main category tags

Figure 2. The GML Core Tags

This hierarchical style of GML is inherited from XML. There is no limit on the number of "children," levels of subcategories, and "siblings" in GML.

It is proposed here that each GML file transfer be amended with a <Prolog> tag containing information on privacy and authenticity. The suggested children tags of this area are as follows:

<Prolog>
<Project>
<Name>
<Date>
<SecurityLevel>
<Status>
</Project>
<Authorization>
<Signature>
<AuthorizationCode>
<AuthorizedBy>
</Authorization>
<Security>
<SecurityMethod>
<PublicKey>
</Security>
</Prolog>

 

Figure 3: Authenticity tags

Figure 3. Example of the tags used for privacy and authenticity

Core tags were defined above. The set of fourth level tags can be defined by anyone designing a GML based system. The selection of tags depends on factors including the data storage and transmission needs of the organization, as well as the existing methods in place. If one needs to derive a GML document from the data saved in the AGS file format, a set of equivalent tags may be derived as explained in the next section.

How Fourth Level GML Tags Can Be Selected

There are two data label sets that are publicly available. These are the field headings used by AGS, and another by NGES. Both of these groups have defined names for individual geotechnical data items. These names can be used to select tags by modifying the upper case and underscore found in the headings. The advantage to keeping the headings is that there is a unique relationship between the two. This allows you to go back and forth, so they may always be converted. The existence of the program AGS2GML makes these conversions straightforward. However, it should be realized that a unique "file conversion" can not occur, because the AGS file format is a small subset of the GML system being envisioned. Therefore, AGS2GML is able to take an AGS file and write the corresponding tagged file in GML, but not vice versa.

Definition Process of New Tags

The GML design foresees the possibility that any person or company will need to extend and customize the tags. Deleting existing tags will probably never occur, since there is no requirement that one should always use all the available tags. Therefore a simple process of adding new tags to GML is proposed below.

A new tag creator should document the need, the reasoning, and the complete format in an ASCII file and post it on a Web server. This file may be named such as

MyNewTag.TDF

where MyNewTag is what is being defined, and TDF is short for "Tag Definition File."

The new tag may be either a private or a global one. A private tag is one that a person or company needs in their projects, but it may not interest anyone else. For example, if the requirements for your team leader states that they need to be a Professional Engineer (PE), you can list that, indeed, the team leader does have a PE. In addition, he may have his Masterís Degree. You are able to put <PE> and <Masterís Degree> in tags under the project leaderís name. These only concern the company running the engineering project, and not necessarily anyone else.

In the case of private tags, the TDF file can be anything the organization chooses to document. Large organizations may already have their documentation standards. A global tag, on the other hand, is one that the tag creator desires/allows others to use it as well. The new tag should be made public in this case. In addition, the documentation of the new tag should be made available by posting the TDF on a public web server.

For the core GML tag set, the TDF file is posted on the geotechnical website, at the address: GML Core Tags TDF File