About the Author:  To change this standard text, you have to enter some information about your self in the Dashboard -> Users -> Your Profile box. Read more from this author

In my last post I started making a case for maintaining a simple way of publishing simple feature data in KML and talked up the KML Schema tag quite a bit.

The key requirements I had for any such endeavor going forward were:

• Simplicity
• Everything you need to get the basic feature data out should be in one file
• Simplicity
• We shouldn’t discount the benefits of being able to embed styling logic into a geographic data interchange format
• Simplicity

In this post, I intend to put forth a suggestion that I think represents a good combination of the points outlined above, and still allows for KML publishers and consumers to go about their business as usual, should they not have any need for more complex feature data into their documents. Additionally, I think the sort of approach I’m about to suggest could have wide ranging applications across multiple other formats as well, which is an added side benefit.

Read past the jump for the full writeup, but my proposal centers largely around the use of microformats.

I’m pretty new to microformats myself, but have been keeping an eye on them for a while. In short (and I trust any of the more informed members of the microformat community out there to correct me if I’m getting this wrong), microformats provide a way to embed structured data in standard formats, primarily through the extension of the HTML schema. Or, to use an excellent phrase from the official “About microformats” page — “Designed for humans first and machines second…,” which I quite like. I encourage anyone who hasn’t already to go check out the content on their site, there’s quite a bit of it, and I found it to be very informative and well written.

There is actually already a geo microformat, which is primarily for the representation of spatial coordinate data (as far as I can tell), and ties in nicely with the relatively widely used hCard microformat.

As I’m talking specifically about the representation of feature data in KML here, the coordinate data part is pretty much taken care of in this context, but would still be extremely useful in other contexts, or if you wanted to copy the description of a KML feature into a non-KML document, although such examples are probably outside the scope of this post.

So why microformats? Well, myself and some of the talented engineers here at FortiusOne have been thinking about this problem for a while. Specifically, how to allow the vast community of KML publishers out there already to add more to their data, without having to completely change the way they operate, and so that the existing tools that consume KML (Google Earth, I think I remember hearing about a little thing called GeoCommons that might do something with it as well) would still work without any modification, but would require only slight modification (hopefully) in order to support the richer format.

This sort of approach could also still work with data that requires more complex structure, as you can still embed it at a different level of the document to provide additional information or context to your features, but could still leverage the simpler representation as well so that your data could be consumed by the widest variety of clients possible.

So, enough chit-chat, let me dive into some examples. Again, I hope that anyone more in the know than myself can jump in and correct me on any of the finer (or perhaps not so fine) points in here that I might be off on. I would very much like to solicit some feedback from the community on this and publish it as a new microformat specification, but I want to make sure I’m doing things correctly according to best practices/style/etc., as well as making sure that there’s at least a relatively good chance that somebody will use it if given the opportunity, otherwise this is all for naught.

A quick, simple example

As a hypothetical example, let’s say I had a list of people’s locations who expected the Spanish Inquisition (this is obviously hypothetical since nobody expects the spanish inquisition) that I wanted to publish in KML.

I might start off with something like this:

Now, if I wanted to use the KML Schema format to do so, it might be something like:

Which is all fine and good, works right now, and if you had a collection of such features, you could upload them to GeoCommons right now and share maps with everyone based around the sorts of locations where people were expecting the spanish inquisition.

As I mentioned before, I love the schema tag. It makes things easy, you can parse everything in a single file, and it’s there and working right now.

However, there are some problems with the above KML fragment. Namely, if you’re intent on using it as a presentation medium and all of the text in your description tag is important for that purpose, even though it might not all be attributes that make up the feature, you’re duplicating data in your document, which is generally undesirable.

So, let’s try this with a microformat approach:

And now I have my feature data embedded straight into my HTML with only some minor modifications and no duplication of data. There are some additional design patterns that could be followed as well to take care of potentially more complex examples. Let’s say, for instance, that the value for “NumInqusitors” is the integer “3”, but I want the text to have it written out as “three.” In that case, if I’m understanding microformat and semantic HTML etiquette somewhat correctly, part of that previous example could be rewritten as:

<span class=“integer-value” title=“NumInquisitors”><abbr title=“3”>three</abbr></span>

Actually, the nested span/abbr there might not be the correct way of doing it, but it should be close.

And if you wanted to do some even crazier stuff, such as provide additional data/structure/etc. above and beyond simple name/value pairs for features, you should be able to use some combination of existing KML, or your own data packed into something like the Metadata tag, linked into the microformat pieces via id references and using the microformat include-pattern or something similar.

Really, you’re getting a whole lot of flexibility and power to expand the use of your data without giving up much at all, and not cutting off too many other paths.

Certainly, the examples above are not fully complete and probably not 100% correct within the context of microformat best practices, but I think this sort of approach definitely has a place in the future of geodata markup and conforms very well with the patterns already in use by the larger community.

One of the potential issues with the specific examples I gave above that I would expect somebody out there to call me out on is that the way I’ve written it, you won’t know for sure which attributes are present in the features until you parse all of them, or at least run some sort of XPath query over the document to figure it out. I probably don’t have as much of a problem with this as others might, but I can certainly see some very valid arguments against doing things this way. To solve that problem, a hybrid Schema/microformat approach might be called for, such that at the top level of the document I can define my schema using the Schema tag, and use that definition to more easily gain some knowledge about the feature structure I can expect later in the document. The problem I have with that is that if people get used to doing things that way, it becomes a little bit harder to extract microformat KML descriptions and place them elsewhere, even though it would still work if you didn’t require the schema to be predefined.

I would very much like to entertain some discussion and argument over all of this with interested members of the community in the hopes that we can either decide that this is just an awful idea and not waste any time with it, or, I hope, nail it down a little more and get to the point of being able to use it as quickly as possible. So please leave comments or otherwise respond if you have any thoughts or input into the matter, we’d love to hear them.

Technorati Tags: geocommons, kml, microformats, google

Popularity: 8% [?]