Metadata: The Eternally Red Herring

KML's shiny <Metadata> tag is the toast of the town, but I think the GIS crowd drank a little too much ESRI Kool-Aid this decade to realize the implications. Paul Ramsey writes:

Where will this all end? I think it will end with the Google Team picking one or a few <Metadata> encodings to expose in their user interfaces (Earth and Maps). At that point all content will converge rapidly on that encoding, and the flexibility of <Metadata> will be rapidly ignored.

The very word "metadata" reeks of sadness. It speaks of librarians locked in dark rooms trying to figure out what data means, long after those who created it are onto the next burning crisis. It smells like scores of sad committee meanings hashing out arcane XML details that no one will ever write a consistent reader or writer for.

It is amazing to me that anyone would want to use the word for anything anymore. But Google did, and people took them at their word. But what Google really meant — in traditional GIS speak — is attribute storage. As they point out in their FAQ article:

Without the <Metadata> tag, KML authors had to either send two files, one with metadata and one with KML, or place their data in the <description> tag

Sound familiar? It's a SHP and DBF file. But now you can marry attribute data to your geometries in one file. And because it can be arbitrary XML, it can be a lot more interesting than boring rows of attributes.

Perhaps only a few big encodings (like a boring row of attributes) will be supported out of the box by Google Earth, but you'll find every XML spec under the sun suddenly glued inside KML documents, and the great sleeping beast of a thousand enterprise applications will suddenly awake from its slumber and devour GIS applications everywhere. Whether you put KML inside a more traditional XML document, or XML inside your KML, it comes to the same thing. It's a smarter, more modern shape file. It's not the usual GIS "metadata" malarkey — it's the real data.