It’s been a while since we’ve seen each other. Great series and terrific points you’ve raised. These are things I know I’ve been struggling with when mapping data online too.

It seems to me that there should be some sort of machine-readable *and* human-readable spec that would be the middle ground between any data source and existing data types (KML, RSS, CSV, GeoRSS, JSON, etc).

[Any data] -> [new human/machine spec] -> [Existing Formats]

This new spec should be generic enough to handle all kinds of data, from government SQL databases to spreadsheets, and specific enough to allow auto importing to the existing formats.

This new specification can be the one single format that sites like data.gov and city/state govs publish online. A casual user can use it since the fields are structured to be viewable in a spreadsheet. But developers can use it too to convert it into the formats they use for their sites.

I’ve come up with a proof of concept for this at http://www.omgstandard.com which tries to hit at these points. When I receive any data from online web sources or partnerships with local govs, I first convert it into this XOMGL format, which is how it’s stored in the database. Then when the site needs KML, it outputs as KML. When it needs CSV for a user to download, that’s what it can spit out. Same goes for RSS, JSON, HTML, and , all run through the API.

Of course it’s just a start, but it hits on the ideas of separating content into chunks (addresses, city names, latitude, longitude, name, html description [a catch all], date, categories, source metadata, etc) that can be repurposed. It really is just a way to define the granularity of fields, and what fields are required, without merging the data (like KML and RSS do) or splitting the data up (like GIS solutions do) too much.

Are some of these concepts what you are trying to grab and define?