Continuing my series on the OGC KML 3 kick-off, lets talk a little bit about Metadata.

To date, metadata in KML has been somewhat confusing, ill-defined, and just kind of “wishy-washy”. This is the effect of several causes. First, KML is ‘lightweight’ and has been used by many mappers that haven’t had an interest in adding richer information to their pretty maps - yet. This is changing, as the concept of mapping, geography, and information is becoming easier to do and the concept more clear, more users are looking for how to include extra information about their geodata.

Another problem is the term Metadata, which has different meanings in different spheres. In GIS, Metadata are the supporting information that describe the data set: when it was created, who did the collecting, how complete is it, what are the license terms, keywords, coverage, and so on. The Federal Geographic Data Committee (FGDC) gives definition. For an example, check out the Baton Rouge GIS Metadata for Lots, 2004, East Baton Rouge Parish, Louisiana.

By contrast, programmers and general users have learned to refer to Metadata that is more generically “data about data”. This typically means just extra information that goes with the data, instead of primarily about the data. Examples include categories, tags, number of lanes for road, building type, and so on. GIS practitioners refer to these as attributes instead of metadata.

Anyways, the result has been that people often just become confused when talking with one another because of a different vocabulary. In the end, everyone just wants to be able to describe their data and add more information to it than just the strict geometry. See what the Dublin Core Metadata Initiative has done for HTML and RSS.

What’s the current situation?

Many developers have started pushing the envelope of what is possible in KML, and more directly, what Google Earth supports natively. Mano Marks at the Google Developer Knowledge Database provided a good document on how to possibly use XML in the Metadata tag.

Chris at FortiusOne has been blogging a lot about the how it is currently possible to use Metadata in KML 2.1 for thematic mapping. Jason Birch has found some really intriguing uses of the Schema tags that Google Earth actually uses for styling balloons.

Getting back to KML 3 and the OGC Technical Committee, one thing that seems difficult about the current KML Schema and Metadata support is that it allows (requires) users to define and use their own tags, or elements. Using Jason Birch’s example, he’s defined a schema for newts:

<Newt>
   <name>Sammy G</name>
   <styleUrl>http://www.jasonbirch.com/files/kml_schema_style.kml#newt_style</styleUrl>
   <Point>
     <coordinates>1.75,1.75,0</coordinates>
   </Point>
   <newt_id>36</newt_id>
   <newt_breed>Common Orange Slitherer</newt_breed>
   <newt_slime_factor>7.2</newt_slime_factor>
   <newt_tail_length>6</newt_tail_length>
 </Newt>

This is really powerful, but what this now requires is that any KML client or library that wishes to support metadata now has to delve into some fairly complex XML creation and parsing. The was created on the fly in the schema definition, which the client will have to parse and then use to parse the rest of the document to extract any information at all. A client couldn’t simply say “I don’t understand Metadata” and still successfully get the geometry out of the KML document.

This is especially important using the concept of modules that allow KML implementations to only include pertinent areas of functionality. If a mobile phone client want to display markers, but isn’t going to use Metadata it shouldn’t be required to implement the complex Schema parsing just to get at the markers.

Don’t remove my schema tags!

I personally have heard this a couple of times, and fear not, we’re not talking about doing away with Metadata or ’schema tags’. Instead, we’re considering just simplifying how they’re used. Primarily, we want to support lightweight addition of additional data without requiring you to use that data to understand the underlying geometry.

To illustrate, check out the example document at the OGC Network. Returning to Jason’s example, we’re going to define the Schema (to provide for more ’strictness’ to make XML-heads happy)

<Schema name="newt_data">
    <SimpleField type="int" name="newt_id"></SimpleField>
    <SimpleField type="string" name="newt_breed"></SimpleField>
    <SimpleField type="decimal" name="newt_slime_factor"></SimpleField>
    <SimpleField type="decimal" name="newt_tail_length"></SimpleField>
</Schema>

And then our actual placemark can use these attributes:

<Placemark class="newt" id="sammyg_newt">
  <name>Sammy G</name>
  <gml:Point>
    <gml:pos>1.75 1.75 0</gml:pos>
  </gml:Point>
  <link type="application/html" href="http://mynewtfarm.com/list#sammyg_newt"/>
  <Metadata class="newt_data">
    <property name="newt_id">36</property>
    <property name="newt_breed">Common Orange Slitherer</property>
    <property name="newt_slime_factor">7.2</property>
    <property name="newt_tail_length">6</property>
  </Metadata>
</Placemark>

What this now allows is for someone to easily add metadata, or attributes, without requiring a client to use it to just show a marker where ‘Sammy’ currently is located. In addition, the metadata could be more complex than just a simple string or numeric value if required.

But I want my real Metadata

While KML is a lightweight geospatial interchange format, it shouldn’t restrict users from referencing more formal data formats as necessary. In fact, it would be straight-forward to publish a simple KML file referencing all of your more complex geodata and then let users choose which data they want to investigate.

Using the , we can easily reference a related document that includes a full GML Metadata description.

<Placemark id="newt_10">
  <atom:link rel="related" type="application/xml+gml" href="http://mygisserver.com/lizards/newt/10"/>
  <Point><pos>43 82</pos></Point>
</Placemark>

(Note: application/xml+gml isn’t a valid MIME type that I’m aware of, I’m just using it as an example of how you can indicate to an application what is at the endpoint)

This way, a developer can include lightweight attributes, or Metadata, but also reference richer Metadata as necessary.

We still have to look at how this affects styling - we want to allow for templating marker descriptions (BalloonStyle) and also possibly apply styling based on values of the Metadata. If you have some suggestions - we’d love to hear them.