Mon 21 Apr 2008
Tags: fire eagle, location, web, microformats
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?
Mon 03 Dec 2007
Tags: blosxom, blosxom plugins, microformats
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
Email: gavin@openfusion.com.au
URL: http://www.openfusion.net/
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.
Sat 01 Dec 2007
Tags: blosxom, blosxom plugins, microformats
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
or
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 supportuf_geo_meta - geo supportuf_hcalendar_meta - hcalendar supportuf_hcard_meta - hcard supportuf_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.
Wed 12 Sep 2007
Tags: web, web2.0, lifebits, microformats, data blogging
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?
Thu 06 Sep 2007
Tags: web, web2.0, lifebits, microformats, data blogging, inverted web
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?