Or, more precisely, everybody loves <Metadata>.
Hardly is KML into the OGC standards process and already folks are getting ready to standardize what goes into the anonymous <Metadata> block.
Ron Lake thinks that ... wait for it ... wait for it ... GML would be an "ideal" encoding to use in <Metadata>.
Chris Goad at Platial thinks that we should be doing content attribution (who made this, who owns this) in <Metadata>.
Even Google is getting into the game. The explanations of how to integrate your application schema for <Metadata> extensions into the KML schema are a nice reminder of the sort of eye-glazing details that have made life so hard for GML. Doing things right is hard.
It is particularly delicious that the very thing that makes adding information to <Metadata> fiddly is the preparation of schemas: you need metadata about the metadata you are adding to <Metadata>.
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.
Monday, April 23, 2007
Subscribe to:
Post Comments (Atom)
3 comments:
I don't.
I prefer the (probably now deprecated) Schema tag.
http://earth.google.com/kml/kml_tags_21.html#schema
Self contained, uncomplicated. Limited to adding attributes to a PlaceMark, but that's all the metadata most casual users want to maintain anyway.
Jason
Amen to that. Why on earth would you want something more complex? Maybe my view is a little limited, but I can't imagine that you'd really need anything more, at least to describe features, 99% of the time. Granted, you can give more 'meaning,' if you will, through gigantic, detailed, and complex application-specific schemas, but meaning is useless unless it's easy to consume and derive new knowledge from.
Why are we reinventing metadata yet again? We already have FGDC and ISO metadata, which don't mesh or overlap completely, and now we are adding another metadata paradigm, which again does not overlap the previous ones.
Record-level metadata is fine, keep it as an attribute as Jason Birch has it, anything else should either completely subsume and replace, or point to FGDC or ISO infrastructure.
Post a Comment