[If you want to skip most of this post, at least jump to the "Take Away Point"]

You know those funky tags like “cell:cellid=197216005″, “geo:tool=GMiF” and even “camel:size=medium” you see around the place? Well yeah, we’ve been watching them very closely too, and by “we’ve” I mean a few of us here in the office that care very much about these things, Aaron probably more than most of us.

They are now ‘recognized’ and rather more formalized. Aaron’s post to the API list says it far better than I could …

Machine Tags
(http://www.flickr.com/groups/api/discuss/72157594497877875/)

… This development is probably far more important than it initially sounds. I’ll try to avoid choking while I find myself using the following marketing speak (and please pretend that I’m using the Deep Film Trailer voice for this).

First there was Tags! They came and revolutionized the internet and created Folksonomies, now, today is the day that Tags evolved, ladies and gentlemen, I present the 5th generation of Tags: Machine Tags!!!!

So how are Machine Tags different?

Well, now when you enter a tag such as “flickr:user=revdancatt” the backend takes that tag, splits it into its three components and stores them into its own special database. Yes, that’s how important we think they are, enough to give them special treatment. Via the API you could not only find “flickr:user=revdancatt”, but also wildcards, I can find all photos tagged with a “flickr:user=”, or any namespace that happens to have “*:user=revdancatt” or even anything that points to “*.*=revdancatt” and other various combinations.

They are called “Machine Tags” because we expect them to generally be added by automated systems and later sucked up and processed by machines.

Example: I have my psychotic photo taking Spime out in the wild. Its taking photos, emailing them to flickr, geotagging them and also recording the heading, wind speed, temperature, atmospheric conditions, lighting levels and whatever the heck else it fancies, because you never know when you need this stuff. It then sends them up to Flickr as “windpseed:mph=32″, “temperature:fahrenheit=77″. Its stuffing this information into tags, but via the API it can use it as a lightweight datastore.

Another application could do searches for “temperature:fahrenheit=” and get every photo that has decided to record the temperature for whatever reason, even if it was for a recipe photo.

Talking of recipes, I could take photos of raw ingredients, such as a carrot and say things like “ingredient:units=g”, “ingredient:calories=54″, “ingredient:fiber=8.2″. Then I could take a photo of a cooked dish, that contained those ingredients “ingredient:55516475869=160″ which says I used 160 units of the ingredient found in photo_id 55516475869. A meal could contain dishes and so on.

Its be very convoluted for a person to enter that information. But totally possible for a 3rd party website to pull all the photos that have an “ingredient:units=” value (better if it also picks a type or two), then allow you to create a Dish from those (in a drag-drop ajax-y fashion), adjusting the amounts and allowing you to upload a photo of the final dish. The photo and all the data would be written back to flickr with the correct Machine Tags. Dishes could have other classification types layered over the top, allowing people to find Dishes to put together into a Meal.

By stepping back through the values held in the tags it’d be possible to calculate the total calorific value of the meal, without having to store that anyplace, adjusting the amount of an Ingredient in a Dish would alter the final value.

Anyway, the above example may not be that exciting, but does illustrate how 3rd party developers have more power to do stuff. We won’t see it straight away, but it will start to happen.

But this is just “Simple steps, first”. We don’t do ranges, so you can’t currently do “colour:red=128″ and then search for all photos that have a red value between 64 and 192, yet. You can’t get distinct lists of values, so asking for a “give me a distinct list of ‘dish:type=’” won’t bring back “snack, main, pudding, drink, cocktail”. Which is why I say you could use it as a “Light” datastore.

Its sort of, but Not Quite RDF forced into tags. (NQRDF)

The other caveat is, at the moment, only newly entered Machine Tags (i.e. from this post on) are picked up this way by the API. We’ll probably offer a ‘backfill’ service at some point, or quick script could be written to re-enter the tags on a per-user basis by someone else if they really wanted to.

However, the take away point for me here … [disclaimer: I work for Flickr] … is that a massive site (Flickr) with over 3 gahbahzillion photos and goodness knows how many tags to go along with that. Have modified their databases, tweaked code and written APIs to allow and encourage developers to use Machine Tags. Which to me, marks a recognition and evolution in Tags and how they can be used.