geo/photo raw materials from a walk around Bristol

I’ve just been for a walk around town, taking a few photos on the way, with the camera’s clock sync’d to that of my new GPS. I’ve not yet figured out the best tool to use (other than write my own) for hooking up the photo and location metadata. It’s easy enough to get the data off of the device using GPSBabel; for now I’ve saved tracks and waypoints in GPX format. GPSBabel offers a wealth of other options, none of which I’ve explored yet.

The first thing I had to hand that consumed GPX was Google Earth on my WinXP laptop; it plotted the tracks happily enough:

2004-07-24 walk around town, plotted via google earth

I’m sure there are other, more open-data and hackable systems out there that I can feed this data to, but for a quick test, Google Earth (formerly ‘Keyhole’) is quite fun.

For Windows users, there are WorldWind scripts that convert GPX into World Wind Layers, available as an online service. I’ve just tried that; it produced me XML document that references a PNG image. I need to read the instructions again a bit more carefully, but nice to see that there’s more to the world than Google. There are also some notes on the OpenStreetMap site on MakingGpxTracks.

The next thing I should try is getting the location and photo metadata integrated, and then I can play around with associating images on maps. There is also a growing geo-tagger community using Flickr (by creating odd ‘tags’ that embed lat/long data). For example see various of jip’s photos, and the geobloggers website (which seems to use HTTP REFERER to plot geotagged flickr images with Google maps).

Update: as I suspected, the Locative guys have already done the work :)

After CPAN-installing the Perl dependencies Image::EXIF and RDF::Simple::Serialiser, Time::Piece, LWP::UserAgent, XML::Simple, Data::Compare and Geo::Track::Log, it looks like is just what I’m after (thanks!). 0 ../../mydata/2005-07-24-Tracks.gpx 2004-07-24-BristolWalk/*jpg

The resulting RDF looks about right, from a quick look.

Here’s a quick query of the data using the online Redland SPARQL service. The query I ran was as follows (basically echoing back the core data structure emitted by the perl script above):

PREFIX foaf: <>
PREFIX geo: <>
PREFIX locative: <>

SELECT DISTINCT ?image, ?lat, ?long, ?email 
  ?x rdf:type locative:Packet .
  ?x locative:media ?image .
  ?x geo:lat ?lat .
  ?x geo:long ?long .
  ?image foaf:maker ?who .
  ?who foaf:mbox ?email . 

See the Locative wiki for more uses of the data, including some nice SVG hacks. Or the OpenStreetMap view of the area (seems to be bitmap imagery there but no streets etc yet).

Four notions of “wishlist” for FOAF

After the recent SWAD-Europe meeting on ImageDescription techniques, I made some scribbled notes in a bar on different notions of “wishlist” that might make sense to use with FOAF.

At the ImageDescription meeting we talked a lot about the difficulty of scoping such technical activities, since problem spaces overlap in ways that create opportunities and frustration in equal measure. The idea of having a “wishlist” association with a person’s homepage or FOAF profile(s) illustrates just this. A related idea is that of a foaf:tipjar, ie. a relationship between a person and a document (or part of a document) which explains how to pay or otherwise reward that person. The idea of public wishlists is associated with the practice of companies such as Amazon, who allow people to expose lists of things they’d like bought for them (eg. as Birthday presents). Danny Ayers has done some work on transforming Amazon wishlists into a FOAF/RDF format. This can also be seen as one half of the concept of bartering explored by Ian Davis, and in earlier FOAFShop scribbles. It is far from clear how all this stuff fits together in a way that best suits incrementally fancy deployment.

Anyway, here are four notions of Wishlist as discussed in Spain.

Sense 1: Wishlists as true descriptions

This notion of a wishlist can be characterised as a relationship between a Person (or Agent) and a description of the world. The idea is that the “wish” is for the description to be true. Any RDF description of the world can be used. For example, I might wish for a job at Microsoft (ie. for the foaf:Person whose foaf:homepage is to have a foaf:workplaceHomepage of Or I might wish to get to know someone (expressible with foaf:knows), or for anything else that RDF can describe. A variation on this design is to express that I wish some RDF-expressible state of affairs not to be a true description of the world.

Sense 2: to own particular things

This is a common sense of wishlist. A wishlist in this sense is just a list of things, associated with a Person or Agent that wishes to own them.

Sense 3: an information-oriented expression of interest

Somewhat different, this one. Idea is that we might want to express informational wishes, for example we might want to leave “questions” in the Web, and have services answer them, notifying us of the answers (via email, RSS/Atom, etc.). This kind of wishlist could be implemented through users publishing queries (expressed in terms of RDF/XML descriptions) alongside their FOAF files.

Sense 4: Wanting to own things that match some particular template description.

This is a hybrid of 2 and 3, and can be seen as a common generalisation of 2. In practice, the notion of wishlist as a “list of items one wants to own” is likely to be implemented through a description of the things on that list. The implicit assumption is that for each thing on the list, there is at most one desired object that matches the description (eg. some particular book with ISBN and title). However in practice there are often multiple objects that meet a description, and it is actually quite difficult to constrain item descriptions so that there is only one possible match.

Instead of saying that one wants to own the car whose numberplate is ABC-FOAF-1 you could say “I’d like to own a wn:Car that is RED and whose foaf:maker has a foaf:homepage of and which is the foaf:primaryTopic of some specified page.


Senses 2 and 4 could be re-characterised using sense 1, using notions such as foaf:owns (which doesn’t exist at the time of writing). In other words, ownership-oriented wishlist mechanisms can be seen as being based expressions of a desire that “it should be true that … owns …”, for some particular person and entity.

The big question is… what to do next? what would it make sense to add to, or use with, FOAF?