Geo-Web

Feature type dictionaries have been with us for quite some time, either within proprietary products, or in open standards such as the Digest FACC. Such feature dictionaries identify concepts or terms of interest within a particular domain of discourse, but do not assign or bind specific properties to these feature types or abstract concepts. Concrete feature types are then constructed from these feature types (a 1:many relationship) in one or more feature catalogues.

This idea is very similar to the model employed by RDFS (Resource Description Framework Schema Language) in which Classes are defined by assertion (the rdfs:Class statement in XML), assertions which do not bind properties to the class definition as would be the case in many object oriented models. Properties in RDF are defined by assigning their domain and range, the domain being the class on which the Property is defined, the range being the class on which the Property takes it values. Property definitions can live in completely different namespaces than the Class definitions - thus different people and organizations can see a single concept as having different concrete realizations (feature types in a feature catalogue).

Since GML was originally written in RDF/S (GML v1.0 profile 1.3), and since many of the GML constructs are copied from RDF/S it should not be too surprising that GML can also represent this separation of Class definitions and Properties, and feature dictionaries and feature catalogues. Since GML is currently written in XML Schema (and not in RDF/S) we can also expect that there are some small things lacking in the GML description.

To create a feature type dictionary in GML, one just creates a set of element declarations, all of which are abstract (abstract="true"), which have no properties and which derive from gml:AbstractFeatureType. Note that such elements automatically have properties including name, description, ID etc that one would find in a feature dictionary.

Property dictionaries can be created in exactly the same manner although these dictionaries MUST import the associated feature type schema for the classes on which the properties are defined (domain). Note that GML has no standard way of saying that the domain of a property is a particular class (feature type). The range part if ok, but the domain would require the use of an additional element (e.g. in AppInfo) to clearly designate the property's domain. Otherwise such properties could apply to ANY feature type in the associated feature type dictionary.

To create a feature catalogue we create a GML application schema in the usual fashion, with each bound feature type's content model (A concrete feature type with bound properties) deriving from the appropriate abstract feature type declaration in the feature type dictionary schema. In such a schema you will see all the properties by ref - i.e. relement ref = "something in the Property Dictionary").

So modulo the non-explicit designation for domains this captures the feature dictionary and feature catalogue structure pretty well.

Note that the "abstract" feature type dictionaries are often hierarchical in nature and this hierarchy can also be captured directly in the feature type dictionary schema using XML Schema inheritance in the usual fashion.

This leads to another interesting connection - namely that such a feature type hierarchy can also be viewed as a classification scheme in the sense of ebRIM. Feature dictionaries thus map to ebRIM classification schemes. Concrete feature types with bound properties can then be seen as being classified by their parent feature type (classification leaf) in the ebRIM scheme.

Like they say - "everything is connected"