Tagging physical spaces with readable messages for humans has many physical and digital manifestations. What about geotagging for machines?
Geo-warchalking was originally a simple idea of people marking postcodes and latitude/longitude pairs around the urban environment in chalk, similar to the Wi-Fi markings based on symbols chalked by traveling hobos, making the invisible visible.
Written symbols in the world are still hard to get in and out of an electronic location system. You don't really want to be typing in numbers to eight decimal places, or triple-tapping postcodes. Human-understandable is not necessarily machine-readable.
So how can we make reading and writing spatial annotations from handheld devices easy and automatic? Until RFID tags become available in spray cans, anyone can sticker the city...with barcodes.
9.3.1. Big in Japan
Especially in Japan, many modern mobile phones read 2-D barcodes, in a standard format, using the on-phone camera. These barcodes include a phone number and a URL or email address. These barcodes have infiltrated the business world. People print them on their paper business cards, and advertisements often have a barcode link.
But we want to store other data. We want latitude and longitude. We want places. We want lots of things: we want to barcode tables, chairs, everything! How can we create all these specifications to describe all these things?
Many of them exist already, in the form of RDF schemas. [Hack #95] outlines some of the basic options for describing spaces, and things that relate to them, in RDF. There are schemas, or ontologies, to describe positioning (geo), places (spacenamespace, locative) and even people and homepages (FOAF). If you want to describe something else, it's not that hard to make and publish your own special-purpose schema.
Geo-warchalkers propose to use the same standard for barcode encoding as used in Japan: QR Code. It's scalable (up to about 4 KB), it's in the public domain, it handles odd characters (such as Japanese scripts), and it copes pretty well with being readable when the barcode is damaged.
9.3.2. Making 2-D Geobarcodes
There's a selection of software for generating QR barcodes online, most of it Windows payware. The free web service at http://nfg.2y.net/system/qrcodegen.php allows you to type into a text area, and then generates a barcode from your input. Figure 9-2 shows a chunk of geospatial RDF (the example from the geo workspace at http://www.w3.org/2003/01/geo/) encoded as a QR code:
Figure 9-2. An RDF geo-annotation rendered as a 2-D barcode.
Now, it might be worth being a bit pragmatic and not including the RDF blurb at the beginning (i.e., just encoding the actual geo packet). This is the most compressed representation of a WGS84 latitude and longitude in RDF, and its barcode is shown in Figure 9-3:
Figure 9-3. A minimal geobarcode
The other thing to add is a human-readable indication of what you're encodingi.e., the namespace: geo, locative, or FOAF. This makes it possible for you to work out what kind of thing you're scanning or looking for.
And just to prove how crazy this can get, Figure 9-4 shows the description section of my FOAF file.
Figure 9-4. A FOAF file encoded with a geobarcode
If you include all my email aliases, it gets to a point where I don't think camera phones can cope.
So, let's annotate the planet! What do we need next?
9.3.3. Why-Not Questions
22.214.171.124 Why not use RFID?
It's too expensive, and not generally available. All you need with barcodes is a printer.
126.96.36.199 Why not just use a pointer or a URI?
This isn't just for connected devices such as camera phones. Your digital camera might use a geobarcode to geoposition your photo. Your GPS could learn more about places and things via barcodes. Encoding the information within the barcode makes the system more open-ended and hackable.
188.8.131.52 Why not use n3 triples?
I thought more software and hardware would understand some form of XML, rather than n3. (I have never seen an n3-reading app outside of RDF testbeds.)
184.108.40.206 Why not zip/gzip the data first?
This is a pretty good point, which should be investigated. I'm worried that this causes more complexity, and things to go wrong. I want to see if doing this makes the barcodes less fault-tolerant.
9.3.4. See Also