GeoWorld-Issue Date: October – 2006, Posted On: 10/1/2006
GML Development-GML Profiles and Applications Build the GeoWeb
By Ron Lake, president, Galdos Systems Inc.; e-mail: rlakegaldosinccom.
Geography Markup Language (GML) is gaining momentum, and it's being adopted worldwide in a broad diversity of application domains, ranging from aviation to natural-resource management to transportation security to geographic features to satellite imagery to real-time sensor data streams. But with such a diversity of data types and world views, how can GML cope? The answer lies in GML application schemas and, to a lesser extent, GML profiles. Much like the XML Schema on which GML currently builds, GML isn't a closed language. There are no roads, rivers or other concrete geographic objects in GML. Instead, GML provides a set of core data constructs (e.g., TimePeriod, Polygon, Coverage, etc.) and a mechanism by which users build their own objects particular to applications of interest. Such user-defined vocabularies are called GML application schemas.
Language for Languages
GML, therefore, is a language for building geographic languages. Users define objects of interest via GML core constructs to define object characteristics, many of which may be geometric (e.g., Polygon, Point), topological (e.g., Node, Face), temporal (e.g., TimeInstant), etc. Each geographic language depends on or is a GML application schema. Note that because GML uses XML schemas as its foundation, users are free to employ XML Schema base types (e.g., string, positive integer, etc.) and create their own data types in XML schemas, just as if they had never used GML. This provides GML with simplicity as well as considerable expressiveness, and it makes GML data self describing. GML often has been used to recast an existing XML-based language, so it uses GML styles and core data types. The results are typically close in appearance to the original language, a significant strength when migrating users.
GML has flexibility and expressiveness, but how does this help to communicate information? And aren't there a lot of different flavors of GML? In fact, GML-aware software can read any GML application schema and determine the objects and properties in that schema. Then it can use that information to process any corresponding GML data stream. The meaning of the data object (e.g., "What is a buoy?") isn't expressed in GML, other than in terms of its properties. GML doesn't perform magic. Nonetheless, there will be more use of GML application schemas in the context of the GeoSemantic Web, with GML expressing the typology of a given domain or set of domains.
Looking at any particular application schema, it may use a lot of GML core data types, or it may use only a few. Rarely, if ever, will an application schema use all of the core GML data types. To simplify matters, a GML profile keeps the specific types that an application schema uses and forgets the rest. In some cases, the profile is specific to one application schema, or it may be more general and support a wide range of schemas that use a limited GML subset. Using profiles can reduce the entry costs and make it easier for software developers to provide GML support. This may come at the cost of generality, however, and developers and vendors need to weigh the tradeoffs involved. As an example, the geoRSS GML profile contains only Polygon, Point and LineString, and it doesn't use GML features. A GML profile can be generated automatically in many cases, and a tool for this has been available since GML 3.0. Users can generate an application schema for a domain and then automatically generate a GML profile that supports it.
In more complex cases, the GML profile may involve restrictions on the use of GML data types. Such cases require human intervention and often a lot of work to realize. More GML application schemas will be created in the future, and there will be better and broader support for GML's core data types and structures. The challenge then will move to managing the schemas and objects that they define. More emphasis will be placed on what the objects mean and how they're related to one another. And there will be online, machine-readable geographic object registries-one more step in building the GeoWeb.
Read the article on their website: GeoWorld .