Super Simple Public Location Broadcasting

I've been thinking about Yahoo's new fire eagle location-broking service over the last few days. I think it is a really exciting service - potentially a game changer - and has the potential to move publishing and using location data from a niche product to something really mainstream. Really good stuff.

But as I posted here, I also think fire eagle (at least as it's currently formulated) is probably only usable by a relatively small section of the web - roughly the relatively sophisticated "web 2.0" sites who are comfortable with web services and api keys and protocols like OAuth.

For the rest of the web - the long web 1.0 tail - the technical bar is simply too high for fire eagle as it stands to be useful and usable.

In addition, fire eagle as it currently stands is unicast, acting as a mediator between you some particular app acting as a producer or a consumer of your location data. But, at least on the consumer side, I want some kind of broadcast service, not just a per-app unicast one. I want to be able to say "here's my current location for consumption by anyone", and allow that to be effectively broadcast to anyone I'm interacting with.

Clearly my granularity/privacy settings might be different for my public location, and I might want to be able to blacklist certain sites or parties if they prove to be abusers of my data, but for lots of uses a broadcast public location is exactly what I want.

How might this work in the web context? Say I'm interacting with an e-commerce site, and if they some broad idea of my location (say, postcode, state, country) they could default shipping addresses for me, and show me shipping costs earlier in the transaction (subject to change, of course, if I want to ship somewhere else). How can I communicate my public location data to this site?

So here's a crazy super-simple proposal: use Microformat HTTP Request Headers.

HTTP Request Headers are the only way the browser can pass information to a website (unless you consider cookies a separate mechanism, and they aren't really useful here because they're domain specific). The HTTP spec even carries over the "From" header from email, to allow browsers to communicate who the user is to the website, so there's some kind of precedent for using HTTP headers for user info.

Microformats are useful here because they're really simple, and they provide useful standardised vocabularies around addresses (adr) and geocoding (geo).

So how about (for example) we define a couple of custom HTTP request headers for public location data, and use some kind of microformat-inspired serialisation (like e.g. key-value pairs) for the location data? For instance:

X-Adr-Current: locality=Sydney; region=NSW; postal-code=2000; country-name=Australia
X-Geo-Current: latitude=33.717718; longitude=151.117158

For websites, the usage is then about as trivial as possible: check for the existence of the HTTP header, do some very simple parsing, and use the data to personalise the user experience in whatever ways are appropriate for the site.

On the browser side we'd need some kind of simple fire eagle client that would pull location updates from fire eagle and then publish them via these HTTP headers. A firefox plugin would probably be a good proof of concept.

I think this is simple, interesting and useful, though it obviously requires websites to make use of it before it's of much value in the real world.

So is this crazy, or interesting?

Blosxom hcard plugin

Building on my initial set of blosxom microformat plugins, the hcard plugin provides a global hcard variable for inclusion in your blosxom templates.

To use it, you simply define the set of hcard data to use in an 'hcard.yml' file in your blosxom data directory, and then include $hcard::hcard somewhere in your blosxom flavours/template. An example hcard.yml for me might be:

Name: Gavin Carr
Organisation: Open Fusion
Role: Chief Geek
Suburb: Wahroonga
State: NSW
Postcode: 2076
Country: Australia
Latitude: -33.717718
Longitude: 151.117158
HCard-Class: nodisplay
HCard-Style: div-span

I'm using hcard here, so if you have microformat support in your browser (e.g. via the Operator plugin, if using firefox) you should be able to see my hcard on this page.

As usual, available in the blosxom sourceforge CVS repository.

Blosxom Microformat Plugins

I've been messing around recently with some ideas on adding some initial microformats support to blosxom.

Microformats are fragments of html marked up with some standardised html class names, providing a minimalist method of adding simple structured data to html pages, primarily for machine parsing (try out the firefox Operator plugin to see microformats in action). Some examples of currently defined microformats are contact details (hcard), events (hcalendar), links or bookmarks (xfolk), geolocation (geo), etc. See the main microformats website for more.

With blosxom, one simple approach is to allow microformat attributes to be defined within story metadata, and either autoappend the microformat to the story itself, or simply define the microformat in a variable for explicit inclusion in the story. So for example, if you wanted to geocode a particular story, you could just add:

Latitude: -33.717770
Longitude: 151.115886


meta-latitude: -33.717770
meta-longitude: 151.115886

to your story headers (depending on which metadata plugin you're using).

This is the initial approach I've taken, allowing you to attach microformats to stories with a minimum of fuss. So far, the following blosxom microformat plugins are available:

  • uf_adr_meta - adr support
  • uf_geo_meta - geo support
  • uf_hcalendar_meta - hcalendar support
  • uf_hcard_meta - hcard support
  • uf_xfolk_meta - xfolk support

Note that these are beta quality, and may well contain bugs. Feedback especially welcome from microformat gurus. There's also a lot of other ways we might like to handle or integrate microformats - this is just a useful first step.

All plugins are available in blosxom sourceforge CVS repository.

Data Blogging Scenarios 1 - Reviews

Following on from my earlier data blogging post, and along the lines of Jon Udell's lifebits scenarios, here's the first in a series of posts exploring some ideas about how data blogging might be interesting in today's Web 2.0 world.

Easy one first: Reviews.

When I write a review on my blog of a book I've read or a movie I've seen, it should be trivial to syndicate this as a review to multiple relevant websites. My book reviews might go to Amazon (who else does good user book review aggregation out there?), movies reviews to IMDB, Yahoo Movies, Netflix, etc.

I'm already writing prose, so I should just be able to mark it up as a microformats microformats:"hReview", add some tags to control syndication, and have that content available via one or more RSS or Atom feeds.

I should then just be able to go to my Amazon account, give it the url for the feed I want it to monitor for reviews, and - voila! - instant user-driven content syndication.

This is a win-win isn't it? Amazon gets to use my review on its website, but I get to retain a lot more control in the process:

  • I can author content using my choice of tools instead of filling out a textarea on the Amazon website

  • I can easily syndicate content to multiple sites, and/or syndicate content selectively as well

  • I can make updates and corrections according to my policies, rather than Amazon's (Amazon would of course still be able to decide what to do with such updates)

  • I should be able to revoke access to my content to specific websites if they do stupid stuff

  • I and my readers get the benefit of retaining and aggregating my content on my blog, and all your standard blogging magic (comments, trackbacks, tagclouds, etc.) still apply

It would probably also be nice if Amazon included a link back to the review on my blog which would drive additional traffic my way, and allow interested Amazon users to follow any further conversations (comments and trackbacks etc.) that have happened there.

So are there any sites out there already doing this?

Data Blogging for Fun and Profit

I've been spending some time thinking about a couple of intriguing posts by Jon Udell, in which he discusses a hypothetical "lifebits" service which would host his currently scattered "digital assets" and syndicate them out to various services.

Jon's partly interested in the storage and persistence guarantees such a service could offer, but I find myself most intrigued by the way in which he inverts the current web model, applying the publish-and-subscribe pull-model of the blogging world to traditional upload/push environments like Flickr or MySpace, email, and even health records.

The basic idea is that instead of creating your data in some online app, or uploading your data to some Web 2.0 service, you instead create it in your own space - blog it, if you like - and then syndicate it to the service you want to share it with. You retain control and authority over your content, you get to syndicate it to multiple services instead of having it tied to just one, and you still get the nice aggregation and wikipedia:"folksonomy" effects from the social networks you're part of.

I think it's a fascinating idea.

One way to think of this is as a kind of "data blogging", where we blog not ideas for consumption by human readers, but structured data of various kinds for consumption by upstream applications and services. Data blogs act as drivers of applications and transactions, rather than of conversations.

The syndication piece is presumably pretty well covered via RSS and Atom. We really just need to define some standard data formats between the producers - that's us, remember! - and the consumers - which are the applications and services - and we've got most of the necessary components ready to go.

Some of the specialised XML vocabularies out there are presumably useful on the data formats side. But perhaps the most interesting possibility is the new swag of microformats currently being put to use in adding structured data to web pages. If we can blog people and organisations, events, bookmarks, map points, tags, and social networks, we've got halfway decent coverage of a lot of the Web 2.0 landscape.

Anyone else interested in inverting the web?