The Long Tail of Location

Brady Forrest asked in a recent post what kinds of applications people would most like to see working with Yahoo's new location-broking service Fire Eagle (currently in private beta).

It's clear that most of the shiny new web 2.0 sites and apps might be able to benefit from such personal location info:

  • photo sites that can do automagic geotagging

  • calendar apps that adapt to our current timezone

  • search engines that can take proximity into account when weighting results

  • social networks that can show us people in town when we're somewhere new

  • maps and mashups that start where you are, rather than with some static default


And such sites and apps will no doubt be early adopters of fire eagle and whatever other location brokers might bubble up in the next little while.

Two things struck me with this list though. First, that's a lot of sites and apps right there, and unless the friction of authorising new apps to have access to my location data is very low, the pain of micromanaging access is going to get old fast. Is there some kind of 'public' client level access in fire eagle that isn't going to require individual app approval?

Second, I can't help thinking that this still leaves most of the web out in the cold. Think about all the non-ajax sites that you interact with doing relatively simple stuff that could still benefit from access to your public location data:

  • the shipping address forms you fill out at every e-commerce site you buy from

  • store locators and hours pages that ask for a postcode to help you (every time!)

  • timetables that could start with nearby stations or routes or lines if they knew where you were

  • intelligent defaults or entry points for sites doing everything from movie listings to real estate to classifieds

This is the long tail of location: the 80% of the web that won't be using ajax or comet or OAuth or web service APIs anytime soon. I'd really like my location data to be useful on this end of the web as well, and it's just not going to happen if it requires sites to register api keys and use OAuth and make web service api calls. The bar is just too high for lots of casual web developers, and an awful lot of the web is still custom php or asp scripts written by relative newbies (or maybe that's just here in Australia!). If it's not almost trivially easy, it won't be used.

So I'm interested in how we do location at this end of the web. What do we need on top of fire eagle or similar services to make our location data ubiquitous and immediately useful to relatively non-sophisticated websites? How do we deal with the long tail?

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?