Re: [Uri-review] Re: early draft of a "geo:" URI scheme.

[Alexander Mayrhofer <axelm-ietf at nona.net>]

Hi,

Frank, thanks for taking the time to review this. comments inline.

Frank Ellermann wrote:
>> we have been working on a first draft of a "geo:" URI to identify
>> geographic locations
> 
> Hi, I don't quite get the idea of this scheme, what's the resource ?

The URI scheme identifies a geographic location - so the resource is a place
on (above/below) earth.

> Or in other words, what's wrong with "URIs" like string:foo or
> number:4, where I could "query" the string length with a "string
> length service", or the smallest divisor of the number, etc. ? 

Ok, i get your point. Your point is "data that is just simple data does not
deserve a URI scheme?" - well, the geo URI has semantics behind. It's not
just two or three numbers, those numbers have a special meaning as they
identify an actual physical location.

Consider calculating the spatial distance between two geo: URIs. That would
not work with, let's say - a "data:"; URI, because the semantics are not
defined (Note to myself: add "distance calculation" to the draft?)

However, i read that we should work more on the semantics of the scheme,
because it does not seem to be clear in the first place. Point taken :)

> I like ideas in the direction of <http://geourl.org>, various map
> services, or DC locations.  It would be nice to have a "common" way
> to express geo locations in Web documents.  But I'm not convinced
> that an URI scheme is the way to go.

Well, URIs have quite a few advantages - they can be used in a myriad of
protocols, they have a well known scheme, and they have a well known unified
definition - their specification.

There are a bunch of formats / schemes available for expressing geographic
information in various protocols/data formats (vCard GEO property, geo.*
META tags, geo microformat, DHCP LCI, DNS LOC, etc.) Some of them do not
even specify what kind of reference system they use, which altitude datum is
to be used, etc.. All of them are tied to a specific protocol/data format.
Some of them are human readable.

A URI goes _beyond_ the use in a web page.

A URI could be used in a lot of protocols, would provide a common view on
what reference system is to be used, and could be "transformed" between
different applications easily.

It would also allow the user to decide what to do with the information,
based on the context (applications would have to make clear the semantics of
a context, of course..). Other URI schemes have different meanings in
different contexts too, like "http:" can address a web page, identify an XML
namespace, or provide an identity by itself (openid...).

Also, geographic information is becoming more and more important, and
considering that more and more internet services make use of location
information, i think a common scheme to identify and address locations in
internet protocols would make sense.

I am well aware that the intended "keep it simple" approach does not work
for certain very specific applications, but i tend to use the 80/20 rule here...

> Apart from that fundamental issue I found no problems in your I-D.

again, thanks for reviewing. I'm happy to discuss those issues in Prague, if
you're there, too.

Alex

_______________________________________________
Uri-review mailing list
Uri-review at ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review