Bill Kearney

What're you near?

I've been mulling over what would be a good way to indicate useful positioning data. There are any number of ways we all think about a location for something. Most of the time we don't use just one style of identifier.

To cut to the chase, using latitude/longtitude cooridinates is not what most people consider as a useful way to describe a location. I'd tell someone I'm going downtown, not a coordinate pair.

Even if I happen to know the coordinate pair, other folks won't and would look at me like I was a nut if I tried to make them. (not that they don't give me that look anyway...)

What I'm after here is a way for people to indicate, in their Foaf documents, that they're near something. This way, when sifting through a LOT of data I can simple as for the near elements. Once I've got those it's a simple matter to detect what location URI are being used and what positioner is being used.

As in:

<foaf:Person rdf:nodeID="wkearney99">
	<foaf:name>Bill Kearney</foaf:name>
	<foaf:based_near rdf:nodeID="nn" rdf:type="http://ideaspace.net/postal/us#20817"/>
	<foaf:based_near rdf:nodeID="aa" rdf:type="http://www.daml.org/2001/10/html/airport-ont/iata#DCA"/>
	<foaf:based_near rdf:nodeID="rr" rdf:type="http://www.daml.org/2001/10/html/airport-ont/icao#KDCA"/>
	<foaf:based_near rdf:nodeID="bb" rdf:type=
	"http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing?latitude=38.99882&longitude=-77.12685"/>
</foaf:Person>

This would allow anyone knowing how to do 'based_near' searches on the Airport vocabulary to find me. Likewise if they knew how to do searches based on my made up postal vocabulary they could use that. The advantage here is in order to find me they need only search for the 'near' element and then know what vocabularies are useful. It gets more involved when things requiring parameters come into play but not so much as to be impossible to handle.

What's a cool possiblity here is doing lookups on the foaf:based_near element and then doing string matching on the leading prefixes you know about. If all you know about are postal codes then you're just going to look for foaf:based_near elements starting with "http://ideaspace.net/postal/us#" as a way to refine your results. Likewise for handling airports or GPS coordinates.

Where this start to get very interesting comes from using RDF to better describe the nature of the nearness. Later in the document I could use an rdf:Description to say 'how near' I am to one of them.

<rdf:Description rdf:nodeID="aa">
	<oc:distance>10</oc:distance>
</rdf:Description>

<rdf:Description rdf:about="http://www.daml.org/2001/10/html/airport-ont/icao#KDCA">
	<dc:title>Ronald Reagan National Airport</dc:title>
</rdf:Description>

Here I'm saying, using the OpenCyc vocabulary for distance, that I'm 10 miles from it. I'm not entirely up to speed on the complete accuracy of making the statement in this manner, but you get the idea. Note the title is describing the airport itself. I can't use that to describe the "#aa" fragment as that's my nearness relationship, not the airport itself.

If I wanted to be clever I suppose I could put something like a dc:description on the distance relationship to say something like how horrible a drive it is during rush hour. That exercise left to the readers...

So if something went querying for me, then sub-queried for what I'm based near, and then went querying for any extra descriptions about the results found, they'd be able to know I'm 10 miles from it. If they asked further they'd find the title for it is 'Ronald Reagan National Airport'.

This is that layering effect that's so hard to describe to people. You could turn around and apply that same sort of markup onto anything else you wanted.

Yes, this form of markup will require what some would consider extra processing to handle. But by making use of simple statments like this it's highly likely that the processing time would end up being much more predictable as the amount of data grows. Instead of having to pick apart a rats nest of compound XML fragments it'll become possible to use a lot of little statements added up in layers.

Update: thanks go out to Morten (twice now) for pointing up my mistakes in the orignal example and helping to refine it. The full document now validates, here's it's graph.