17 May 2007 - GML and Database Interoperability

I would like to pick up on the issue of what GML can or cannot add to the interoperability between databases.

First I would note that the whole discussion (Savage et al) wrt GML 1.0 and GML 2.0 is a red herring, since both depend on schema descriptions. The only difference is that GML 2. opted to use XML Schema rather than creating a schema language ourselves (see the example quoted by Savage), and is thus led to a clear separation of schemas and instances. Nonetheless both GML 1. and 2.0 (and 3.0) make more or less the same contribution (good or bad) to the issue of database interoperability.

Let's begin by noting that GML on its own does NOTHING about the fact that I used street when you used road, or that your road has an integer numLanes property while mine has a positive integer numberOfLanes property. Solving this problem automatically is extremely difficult and I would judge well beyond any near term technology. GML provides a middle ground. It allows you to express the schema you do have. It does that using XML Schema and a core set of GML primitives. It allows me to express my schema using the same constructs. Note that when use the same core constructs (geometry, time, topology, coordinate systems) than the interoperability gap is narrowed - but it is not erased. Your schema with numLanes still comes out as numLanes, and my numberOfLanes still comes out as numberOfLanes - we probably would not want it otherwise, since that reflects our view of things. What this does allow us to do however is to SEE the other guys schema and to define the mapping from one to the other. That IS a doable proposition and IS possible and is being done.

GML also makes possible another viewpoint - and that is we can agree on a common schema for a community - just as everyone who uses GML is agreeing on a common structure for the exchanged XML and a common encoding for certain primitives like Point or Polygon. It is too much in my opinion to expect universal agreement on such a schema - if it is hard for a community to do this - how can we expect the whole web to agree? On the other hand it is a doable thing within a restricted community - like all people concerned with ship navigation - or all people concerned with tagging news stories - or all people concerned with commercial aviation. They CAN agree on what a NavAid is and they can agree on how to model it. GML then gives them a way to represent that agreement and to send it to others - and to validate that the data they are exchanging complies with the agreement. Not complete interoperability by any means - but a POSITIVE step forward.

Now I will be the first one to admit that modeling in XML Schema is not everyone's cup of tea. For this reason GML does not require it - nor even encourage it. Tools exist (e.g. ShapeChange) that can create GML application schemas automatically from UML. Other tools can do the same from relational databases and relational databases that incorporate spatial models like Oracle or ArcSDE on Oracle. What GML provides is a reasonably readable expression of the schema and one that can be used to check (to some degree) that integrity of data that complies with it.

So in Summary:

1. GML cannot solve automagically the database interoperability problem.

2. GML can represent reasonably complex data models in GML application schemas that incorporate spatial data, and related constructs for topology, time etc.

3. GML can enable you to validate instances of data against the schema.

4. GML enables the schema to be moved from one place to another - be exposed and thus to support early binding models for data analysis, data visualization and data transformation - including mapping the GML schema to different data stores.

5. GML can enable a community to create, publish and share a schema that is the common vocabulary of the community.

Comments

No comments yet.