I’m about to start writing some code to demo the concept of
href="http://ThereAndThen.org">ThereThen addressing. A guiding
thought has been to Keep Things Simple, which is why I don’t have
localized notions such as Post Codes (UK) or Zip Codes (US) floating
around in the TT notation. Whatever goes into a TT address must be
universally understood. Components of a URL which follow the TT
sections (Location and Time, always those two, and always in that
order) may certainly be as site-specific in their naming conventions
as they are now. Examples:
http://example.com/
37.749991,-122.45,80F/2003-02-4T13:15:20Z/SF-MOMA.html
http://example.com/
37.749991,-122.45,80F/2003-02-4T13:15:20Z/Store/Books/Dali.html
Which brings me to the notion of altitude. Longitude and
Latitude are universal. As near as I can tell, Altitude
is subject to local-interpretation. I’m happy with Feet.
Some folks from the UK that I have met recently are going
to be happier with meters. I looked for guidance at the RDFIG Geo vocab workspace, and didn’t see
anything nailing down how Altitude should be specified.
My inclination, up till now, could be summed up in two quick examples:
80F for 80 Feet, and 15M for 15 Meters.
Somehow, the notation doesn’t sit well with me. Are there
parts of the world where ‘F’ and ‘M’ aren’t going to be
instantly recognizable as Feet and Meters? Will it lead
to confusion? I wouldn’t want a ThereThen address slamming
into the surface of Mars just because someone got
confused between measurement systems!
One approach would be to put a stake in the ground and say “Altitude
is always Meters”. This would give worldwide consistency
in handling ThereThen addresses. Any application that needs
measurements in Feet can do the trivial conversions to and from
Meters. I like this, because it makes addresses that much
more portable. TT addresses are meant to be processed by programs,
as opposed to interpreted by users, so I am not worried about
my fellow Americans getting confused by seeing meters in the
Location component.
Another approach is to drop Altitude entirely. This changes
my first example to:
http://example.com/
37.749991,-122.45/2003-02-4T13:15:20Z/SF-MOMA.html
It’s certainly a little simpler, but it conveys less information.
Altitude can be important in Urban and Country contexts. There are
Urban contexts where one may want to call attention to the fact they
are posting from the 50th floor of a tall building, or a subway
platform. Bridging from City to Country, someone flying in a plane
may take a certain joy from tagging a blog posting from 10,600
meters up. In the Country, it may make sense for someone to point out
that they are at the top of Glacier Point in Yosemite, as opposed to
the Valley, 900-odd meters directly below.
href="http://www.burri.to/~joshua/">Joshua Schachter points out a
tiny GPS device
for $99 USD, which is one more piece of the “Location from
the Real World maps into the Internet” puzzle.
My conclusion from all of this is that Altitude is certainly
important to enough groups of people to keep it in the ThereThen
addressing scheme. A tangent question to this is “what’s the
default, when no Altitude is specified?” How about 0? (Sea Level)
My other conclusion (this is why I write stuff, it helps me think the
problem through…) is that sticking with Meters should work pretty
well. The conversion to Feet is trivial for local apps that need it,
and it helps ensure that everything in a ThereThen address is universally
understood.
I’d be keen to hear what others think. If you are thinking
within a RDF-centric world, be assured that I intend to work
out how TT addresses can be used in that context. My present
obsession (which is too strong of a word, really…) is that
I needed to focus on what components of ThereThen mean. I have
it down to a universally accepted latitude and longitude, altitude
in meters, and an ISO standard for time. That seems pretty good,
and should remove a lot of obstacles for people in building
some value on top of it.
