A couple months ago Tom Taylor and Tom Armitage launched a web-based game based around geotagged Flickr photos called noticin.gs.

Noticings is a game about learning to look at the world around you.

Cities are wonderful places, and everybody finds different things in them. Some of us like to take pictures of interesting, unusual, or beautiful things we see, but many of us are moving so fast through the urban landscape we don’t take in the things around us.

Noticings is a game you play by going a bit slower, and having a look around you. It doesn’t require you change your behaviour significantly, or interrupt your routine: you just take photographs of things that you think are interesting, or things you see. You’ll get points for just noticing things, and you might get bonuses for interesting coincidences.

Maybe it’s just me (I don’t think so) but this is precisely the sort of thing we always hoped people would build on top of the Flickr API.

You “play” noticin.gs by uploading geotagged photos to Flickr and tagging them noticings. At the end of each day the noticin.gs robots query the Flickr API for new photos and assign points to each photo. Points are awarded for being the first noticing in a neighbourhood, because a player noticed something every day at lunchtime and so on; the scorings change and adapt with the game itself.

Tom Taylor and I started talking about adding the “machine tags extras love” (remember, that is actually now a technical term on the Flickr engineering team) a while back. One idea was use the photo’s (noticin.gs) score as the key back in to their world but that seemed like an odd fit. Knowing the score for a photo doesn’t tell us how those points were awarded which is, really, the interesting part and what would we link to?

I’ll come back to the what-do-we-link-to part again later.

As it happens, every single noticing has its own web page and a unique ID that, conveniently, is the same as the photo that was noticed so we settled on noticings:id=PHOTO_ID as the tag that will be “expanded”. If it’s present we’ll ask the noticin.gs servers for the list of reasons that photo was awarded points and display the one with the highest score linking back to the noticin.gs page for that ID.

You can either add the special machine tag yourself or ask noticin.gs to do it for you automatically. To enable automagic machine tagging you’ll need to log in to noticin.gs and change the default settings. If you’re worried about creating yet another account for an yet another online service, don’t be: noticin.gs uses the Flickr Auth API itself to manage user accounts so “logging in” is as simple as authorizing noticin.gs to access your Flickr account (the way you would any other Flickr API application).

This is what it looks like once you’ve logged in:

Paul Mison has a lovely post about noticin.gs where he describes the game as “the biggest change to the way I post photos” to Flickr. That kind of thing makes all the bad days worth it.

Don’t forget: You can subscribe to an RSS feed of all the new photos machine tagged with noticings:id= and since the photos should all be geotagged already you can also create a network link for new photos and hop around from noticing to noticing in Google Earth.

Which is as good a segue as any to show a picture of a space ship. A “space ship.” I like this picture because it reminds me of machine tags.

Which is as good a segue as any to talk about trains. But not just trains. Machine tags for trains. Actually, train stations.

We have a lot of pictures of train and subway stations. A casual search for the words subway OR metro alone yields 1.5 million results. If you add the word train to the list you get 5.7 million. That’s just searching for stuff in English.

Unfortunately, few transit systems have websites with pages dedicated to each station in their network (we’ll cut them some slack as they’re busy, you know, running the trains). A few do but none of them seem to have much in the way of a public API, even something as simple as a getInfo method.

So, a couple weekends ago I created Fake Subway APIs, which is a plain-vanilla XML-over-HTTP API service for returning information about train and subway stations. It doesn’t do much right now except return the name and URI for a station given its short code.

I did this because I wanted to make sure that the code we run to determine the “meaning” of a given machine tag always expects to be asking someone else for the answer. Even if a fake subway API is little more than a canned list of IDs and names it seemed important to go through the motions of treating machine tag extras as something external to Flickr.

My hope is that Fake Subways APIs will become irrelevant sooner rather than later, as individual services start building this stuff themselves. For now, though, it works and it means we can enable the “machine tags extras love” for four transit systems: BART in the San Francisco Bay Area, the metro (STM) in Montréal; Transport for London (aka the “Tube”) in, well, London; the National Rail Service in the UK.

The syntax is the same for all of them:

service name + ":station=" + station code

Like this:

• For BART : bart:station=16th

  A complete list of BART station codes is available over here.

• For the STM (aka the “metro”) : stm:station=m48

  A complete list of STM station codes is available over here.

• For TFL (aka the “Tube”) : tfl:station=LON-N

  TFL machine tags are a bit of a bear compared to the others. Specifically, you need to indicate both the station code and the line code. This is a consequence of the way the TFL website is set up. A complete list of TFL station codes is available over here.

• For the UK National Rail System : ukrail:station=HMN

  A complete list of National Rail station codes is available over here.

We chose those four because they were the ones which I knew to have a webpage for each station that could be linked to (or in the case of London Underground could be teased out because, let’s be honest, it’s the Tube) at the end of a machine tag.

Since all of this has started, hooks for the MBTA in Boston and the TTC in Toronto have been added to Fake Subway APIs so it seems reasonable to expect that we’ll add support for them here too.

Check it out, a train:

If your subway system isn’t listed please don’t take it personally. I work on this in the mornings over coffee and weekends when I’m sick and should be resting. The entire project is open source and I’d welcome contributions. Munich, for example…

One glaring omission is the New York City subway system, sometimes known as the Metropolitain Transportation Authority (MTA), because they don’t have proper webpages for the stations they operate. Fake Subway APIs provides a (fake) MTA API and even has fake/place-holder subway pages for each of the stations but where’s the fun in that?

One of the goals with the machine tags project has been to deliberately link outwards to the various sites, and services, rather than funnel everything through a single channel. A “small bridges” approach instead of an all roads lead to [INSERT BIG SITE HERE] model, so to speak.

(Speaking of tubes…)

We’ve certainly had discussions around the idea of using Wikipedia as a sort of universal content resolution system, for things or people otherwise “missing” from the Interwebs. Tim Bray wrote a really good piece about this called “On Linking” a couple years ago. It’s not that we don’t love Wikipedia or support what they’re doing and they almost certainly have the most comprehensive list of trains stations anywhere on the Internet.

It’s just that we’d like to actively encourage as many people as possible to participate in what Tom Coates’ called the “Web of Data“, in a presentation in 2006, making their data available to to both humans and machines but also maintaining authorship of all that crunchy goodness. Tom’s slides are a bit opaque on their own and to date the best telling of the presentation has been Simon Willison and company’s collaborative note-taking, which I’ve liberally excerpted here:

Every new service that you create can potentially build on top of every other existing service.

Every service and piece of data that’s added to the web makes every other service potentially more powerful.

So the same things that keep the hippies happy keep the evil capitalists happy. They all have to play in the same ecosystem. If not, you end up in a backwater, disconnected from the cool stuff that’s happening. strength in sharing and participating.

So far, it’s an idea that worked pretty well for us if all the amazing stuff people have built on to top of the API is any measure.

If you look closely you’ll notice that I’ve had to link to an (Internet Archive) archived version of Simon’s site from 2006 since the notes are nowhere else to be found. There is still, obviously, lots of work left to be done no matter which road you prefer.

Also: While we’re talking about Wikipedia, Josh Clark’s Wikipedia Machine Tag Generator, which he built during the Yahoo! BBC Hack Day event in 2007, is just plain awesome.

So, where are we going with all of this? It’s a bit too soon to tell but one of the things I like about all of the recent machine tag work is that they start to expose geographies outside of the traditional grid of latitudes and longitudes. If that sounds a bit wooly and hand-wavey that’s because it is.

In concrete terms, one thing that’s pretty exciting is the ability to infer location for all those photos that aren’t geotagged yet but do have Upcoming, or foursquare, or OpenStreetMap machine tags or, yes, even train stations. All those services have their own APIs and aside from just pulling back coordinates you can use them to fill in simple, but important, details like whether a photo was taken indoors or outdoors.

And if we’re lucky they’ll start to show us the donut holes and the “place fields” (props to Matt Jones’ delicious links for that one) that we walk through every day but don’t recognize or don’t have names for yet.