Andrew Turner has a great series of blog posts on the future of KML that were the product of meetings at the OGC on the topic a week or so ago. Lots of interesting content in Andrew’s series, but the one most near and dear to us is the discussion on metadata. Chris made it out to the meeting with Andrew to throw our 2 cents into the discussion, and convey Chris’s thoughts on the schema tag and how attributed data can be embedded into it. We should not confuse adding attribute data to KML to adding metadata to KML as Sean Gillies points out in response to Andrew’s post. Both are important but serve two different and distinct functions.

Our use of the schema tag is to allow additional data to be added to KML to describe a location on the map. Natively KML supports the ability to add a description and Z coordinate to a location. So, you can describe a push pin with text, HTML and/or a picture then add a Z coordinate that provides a metric to that push pin. This allows you to do many things and has created a lot of great KML, but there are limits. Namely you can only really add two attributes - a description and a metric. Lots of locations descriptions and data in general is multi dimensional.

Lets take a simple example of one of the first Google “My Maps” mashups of the 2004 US Presidential Election. The election mashup is a nice thematic map of Bush (red states) versus Kerry votes (blue states), and when you click on a state it shows you the percent of votes for each candidate. The data on the percentage of votes for Bush and Kerry is placed in the description field of the KML requiring the user to color code each state to create the thematic map. This is quite a bit of work since your are using a qualitative data field to try and do something quantitative.

This is something we would like to change, by making it a lot easier for anyone to create KML that easily handles quantitative data. The geoweb, to date, has done a great job of opening up mapping by allowing anyone to create a qualitative description (text, HTML, pictures) of a location. This is what KML is currently geared to support, but there are an increasing number of people that would like to expand quantitative data beyond a single Z attribute.

In his post Andrew pointed to our use of the schema tag to enable thematic mapping, and that is accurate, but only the tip of the iceberg of what is possible. Once you have access to multiple data descriptors about a location it enables a range of decision making tools. KML currently reflects the “read - write” functionality of Web 2.0, but in order to evolve to a “read-write-execute” web it will need the ability to support quantitative functions that allows users to be enabled by decision support.

Since things are always clearer with examples and our favorite example is finding bars and single (men/women) let me give it a shot. Currently we would search for bars and get back KML that describes the bar - name, address, user comments, maybe a user rating. The KML and current applications cover this very well - we can “read” and “write” back to the KML - very Web 2.0. What is missing is any analysis of those bars that tell me the best one to go to.

Lets say the application already knows a few things about me - I am a 33 years old, single, male, work in IT, and I am a Taurus. This information and much more could be easily picked up from a social network profile like Facebook or MySpace. If I now did a search on bars and the KML had embedded feature attribute data for the bars and the surrounding contextual data I could be directed to the bars that had the highest correlation with women that are single, in an adjacent age bracket, and work in IT. If I had a good experience at the bar I could post back my comment to the bar further reinforcing that quantitative correlation with user generated validation. Now my KML has enabled a “read-write-execute” application that is both qualitative and quantitative. That I believe is the long term value proposition for KML 3.0.

Popularity: 15% [?]

There have been several interesting blog posts of late on the demographics of Facebook and comparison to the demographics of sites like MySpace and LinkedIn. A few folks have looked at the international growth of Facebook, but I have not to date seen any discussion of the geography of Facebook. We all know it is big, but where is it hottest?

David here at FortiusOne decided to do some investigation and build out a dataset the number of members in the different regional networks on Facebook. When you register on Facebook you can join one regional network for the place you consider home. David tallied up the numbers for all the regional networks and geo-referenced the data set, and the top cities ranked out as such:

1. New York, NY = 273530

2. Chicago, IL = 246759

3. Washington, DC = 210160

4. Boston, MA = 171837

5. Atlanta, GA = 156643

6. Los Angeles, CA = 144718

7. Dallas / Fort Worth, TX = 120602

8. Minneapolis / St. Paul, MN =114404

9. Philadelphia, PA = 112495

10, Detroit, MI = 110704

The fascinating bit of this is how few west coast cities there are on the top ten list - only Los Angeles. The trend is even more striking when mapped out:

The Boston Washington corridor is flaming and Chicago definitely stands out in the midwest. So, why is Facebook not as big on the West Coast? Does the West Coast use other services, are there fewer universities, or are they on to the next new new thing.

Popularity: 32% [?]