Commonspace

Posted: July 26th, 2002 Comments Off on Commonspace

Back to the games stuff soon, page but in the meantime, more about
this
journal has fascinated me to the point of hypnotism. I can’t remember the last time a web page this long held my attention all the way down. (There is also a second page)

It turns out that the author read extracts on This American Life last week:
the stream is here. The reading is about half an hour in, visit web but don’t jump to it.
Listen to the first few minutes, which are just as fascinating, but about something completely different. (And don’t be put off by the presenter’s habit of speaking very fast in a horrible nasal tone)

You probably already knew that Ogg Vorbis has hit 1.0.
What you probably didn’t know is that Vorbis is not the only free audio format to use the Ogg
bitstream spec. Speex is an audio codec aimed at speech compression. It gives impressively-good-quality results at data rates as low as 10kbs. It’s at version 0.5 at the moment, approved but given that it was only 0.1 a couple of months ago, it looks like completion may not be far off. Unfortunately, an obvious stand-out item on
their
to-do list is patent clearance. I’m sure I don’t need to go into a rant about
the implications for free software here, especially given
recent
events. What would be really great is some pro-bono organisation of patent
lawyers who would be able to assist open projects with patent clearance.
Unfortunately, given the amount of work this would probably involve per
project, it’s not something we’re likely to see any time soon.

Oh, and to clear up potential confusion: Ogg is a way of packaging up encoded multimedia data. Vorbis is an audio codec that uses Ogg as its encapsulating data format. There are other codecs that use Ogg, such as Theora (an upcoming video codec from
Xiph.org, who created Ogg and Vorbis) and Tarkin (a more adventurous video codec than Theora, still in planning stages).

I guess a name-collision was inevitable, illness but it would have helped if Apple had made
some admission that their new calendar app, viagra here
iCal, medstore is intruding on the namespace
of the IETF’s iCalendar effort. (And
they’re not even the first to
pick the shortened form) Furthermore, Apple’s
iCal page makes little mention of supporting
the IETF standard, though I’ve heard it on good authority (a.k.a.
my chum Ian, who edits MacUser UK) that
iCalendar is supported. But which bits?
Wes and the gang have been
making guesses.

Okay, unhealthy so it’s not exactly on time, drugs but the
Perl
5.8 press release is now out. Most of the work is
muttley’s, information pills some is
hitherto’s and some is mine.
Many thanks also go out to Jarkko
and Larry for their quotes,
and Kevin at the
Perl Foundation website.
Now,
how do we get it off here and onto all the news sites? The Perl Foundation
is a non-profit and has no newswire account, as far as I can tell.
I’ve mailed
a
bunch
of
sites, and I’ve pinged a load of journo
friends too, and now (on Owen’s
suggestion) I’m blogging it. If you’re a blogger, it’s very possible that you’re using
one
of
the
many
perl-based blogging tools already.
So do us a favour and scream it from the rooftops!

The idea of location-based information services is one that many geeks (including myself) are lusting after. There’s an obvious application for the Semantic Web here, order but also for plenty of existing web sites and services. Here’s a way of thinking about it: Commonspace.
Read on to find out what it is, and and how we can start using it to provide location-based services without waiting for big service networks to get their acts together.

I use location-based services on the web all the time. Every other day I go to Streetmap or Multimap to get a map for a London address. Multimap is particularly interesting because users can annotate the map with names of particular locations. When you look up a street, you get a list of all the notable locations on that street, their addresses, and their marks on the map.

Bloggers, being very communal types, have started taking this further: they’re creating their own community maps (such as
NYCbloggers and London Bloggers) and announcing their locations. (The most advanced of these, which
MattJ pointed us at today, is BlogMapper) This is fun; I’ve often imagined having a live map that I could carry with me that would show me the locations of my friends as Bond-style little-pinging-dots. (“Ooh, Benny’s walking only two streets away! I’ll catch up with him.”) Obviously, there are major privacy implications here.

One industry group that is currently wrestling with live location-based services and their privacy implications is that of the 3G network providers. 3G phones will have GPS built-in from the start. Naturally, the networks are working on all kinds of exciting apps to sell us the technology. Lots of “Find My Nearest…” They’re obvious. But what about data that’s more to do with the users? What if we want to use more diverse data sources?

Let’s step back a moment and think about the world. We have realspace: it’s real world locations, it’s here, it’s three-dimensional, it’s what we walk around in. We also have dataspace, which is information about locations in real space.

A road exists in realspace. But the name of the road exists in dataspace. The only way you can know the name of a road you are on is by looking at a map (which is dataspace) or a road sign (which is data brought into realspace) or by associating with other data. (“I am by Bob’s house, I already know Bob lives on Wembley Road, therefore I am on Wembley Road.”)

When you look at a map for guidance, you are making an interaction between realspace and dataspace. The map is a layer of data that fits very snugly over the real space it describes; that’s why it’s useful as a map. All the points in this dataspace layer have an unambiguous, 1-to-1 association with points in realspace. Of course, that only works if you discard one dimension of realspace from the association, since a road map is 2D and realspace is 3D, but it’s a compromise that we’re usually fine with making.

Now suppose that the reason you’re reading the map for guidance is that you’re trying to find a restaurant that your restaurant guide tells you is really good. This guide may be separate from your map; certainly, the information is separate. It’s another data layer over realspace. It’s not as complete as a map is – it’s only describing locations that happen to be restaurants – but it’s still giving you data about locations. This data is decidedly non-physical: the menu, the prices, the reviewer’s opinion, etc., but it still maps directly to a particular location.

So you’re using two data layers over realspace, cross-referencing them to guide you in your pressing quest for good food. This is what location-based services aim to help with. They’ll take a good chunk of the work for you and cross-reference various data layers so as to help you with what you want to do.

I’ve described two layers of dataspace over realspace, but there’s a potentially limitless number of them. Imagine realspace as the bottom layer of a pile, the really thick one, and floating above it is a massive stack of less-tangible dataspace layers that tower up so far you can’t see the top. This tower of dataspace layers and the realspace they map to is commonspace.

Here’s a proper definition for you: Commonspace is the union of a realspace location and the dataspace that relates to it. (It’s a refined, discrete chunk of the noosphere) The guidance action I’ve described above is a commonspace interaction that slices through those layers.

If you want to see a really cool commonspace application in action, take a look at this fantastic augmented-reality demo from the MIT Media Lab. The window views both realspace and dataspace as one. This time, there is a 1-to-1 mapping from the dataspace to realspace in all three dimensions. The user is creating a shape in dataspace, but using realspace interaction to directly describe both its shape and its location. (Here’s another: The Augurscope is a viewing portal into a virtual space overlaid directly onto realspace.)

Both the projects described above use very rich commonspace layers, in that they involve complex shape data and a very high-resolution mapping to realspace. However, in another sense they’re not particularly rich: they’re only dealing with shape and texture data.

For other kinds of data, let’s look at Vindigo, the useful PDA application. It provides all kinds of location-based services. Okay, you have to explicitly tell it where you are, but once you’ve done that it gives you information ranging from local cinema times to restaurant reviews, as well as pictorial maps. It’s medium-resolution, in that it goes down to street-address level, but there are many layers of dataspace here.

One concept that MattW told me about was “data boots”. Take a dataspace layer such as relative pollution levels across locations. Your data boots have access to this layer. When you move from a low-pollution to high-pollution area, they slow you down, like you’re walking uphill.

Okay, so by now I hope we’ve established what commonspace is. But how can we use it now to create new cool and useful things? (Clue: it involves the Semantic Web)

I’ve already mentioned Blogmapper, which is about linking blog entries to geographical co-ordinates. Another concept that does this on a per-blog level is the already-popular BlogChalking. Blogmapping improves on this not only by linking per-entry, but by using a machine-readable format called
RDFmap. It’s a lot easier for software to parse than Blogchalked ALT tags.

As is explained elsewhere, RDF datastores are a key part of the Semantic Web. All we’re talking about are XML documents; they could be static files on a webserver. But they contain rich, parseable data. In this case, geographical data.

Let’s try an example that someone could code tomorrow: I’m in town and I need an ATM. I happen to be standing outside a building and using their Wi-Fi connection. I run a script that queries the MAC address of this Wi-Fi hub against a known RDF store of all the publically-accessable hubs in town. Assuming it finds a match, it’ll give me my co-ordinates. Now I have my location, the script uses it to create a query on another RDF store, one that contains the locations of all the ATMs in town. The query goes something along the lines of “give me the top five ATM locations within half a mile of my location, sort in ascending order of distance”. It gives me a set of location co-ordinates back, and I can click on them to send the co-ordinates through a roadmap server which returns maps when given co-ordinates, such as the ones mentioned at the start of this piece. Bingo!

The tools needed for this are not only readily-available, but most of them are already standardised. We can do this now. Personally, I’d like to see a bit more flexibility in the RDFmap spec for things like paths, complex shapes and other location-specification methods (such as, say, postcodes, or phone code areas, or whatever, with specified translation methods) but those are just niggles. A bit more important is an RDFmap query standard but I’m sure that’ll come.

The potential is obviously incredible. But a key aspect here, vital to the Semantic Web, is that anyone can contribute. Add to other dataspace layers, or create your own. They’re just web pages. If you’ve got useful data to offer (“Don’t go to that restaurant, it’s terrible!”) you can offer it, with a hard geographical link. Using Semantic Web tools like FOAF that connect people and their data, there’s a good chance that your opinion will be discovered and listened to.

This is interesting to me on a personal level too, as I was involved in a project that was created to be an ultimate location-based information service: h2g2, the
real-life Hitch-Hiker’s Guide To The Galaxy. One example that Douglas often gave to illustrate was this: He’s driving through a town he hasn’t been in before and the Guide, his little handheld device that knows where he is (okay, we had big aims for the future) tells him that there’s a record shop nearby that’s selling that CD he’s been wanting for ages. Now, what kind of system could deliver this? It’s becoming more and more obvious that a big monolithic server that contains all the data is completely the wrong approach. We weren’t thinking completely monolithic – we’d interface with external datasources, just as other popular location-based services have done. But the key is to make it as easy possible to provide that data. This is how the web works. And a unified toolkit to do it all is just around the corner.

---