Re: URIs & Namespaces

hello mike.

Mike Schinkel wrote:
> Isn't it equivalent to say that I think I shouldn't have to register a
> domain in order to be able to "own" a given URL space in HTTP?  Clearly
> that's not realistic.  So let's assume you do get a "LOC:" scheme.  Wouldn't
> you have to register a namepace to disambiguate among other's namespaces?

no, exactly that was the starting point of that thread. i want a loc 
scheme (actually, i call it geoloc) that

(a) identifies locations
(b) does so by using wgs84 corrdinates
(c) can also do so by using place names from some vocabulary that has to 
be identified in the uri as well.

point (c) was the one i was asking on this mailing list to get some 
advice about how to do it.

> OTOH, if you argument is that people should be able to create local groups
> of place identifiers that are not global in scope, why do you need a URI
> anyway?  After all, the "U" in universal implies that it is global, and if
> you don't need global why do you need a URI?

because even though i might not understand other groups' place names, i 
can still match them and maybe even map them, and i do know that they 
are referring to places.

> Not exclusively, but it work extremely well in so many use-cases.  I'd not
> ask the question "Should the web exclusively be about http interactions?"
> and instead ask "When should the web not be about http interactions?" 

agreed. so when i want to place a phone call, it's not http. when i want 
to drive my car somewhere, it's not http. the web is great, but there 
are many things in life which are not really part of the web.

>> something has changed: in the latter case i know i talk about 
>> locations, which i don't know in the former case. that's an 
>> important change.
> What context are you concerned about?  Local, or global?  With a global
> context I'll agree, but I thought you were mostly concerned with local
> places.

local place name vocabularies in the global context of a uri scheme for 
locations, so that i can match and map locations.

> Sure, why not?  Currently I look at a URL but I can't tell if it is
> text/plain, text/html, or application/json unless I dereference it.  Why is
> it a problem to have to do the same for location?

these are different things. for a http uri, you assume it's a 
http-accessible resource you might get in various representations. for a 
location, the resource is not a http-accessible resource, it is a 
location that can be accessed by driving there, living there, meeting 
with friend there, or having your autopilot-steered helicopter let you 
fly there. so the mime type world does not apply so well to the location 
concept, because we are not talking about http-accessible resources.

>> well, being able to tap a tel: uri on my iphone...
>> and just place a call is something i find useful. and while the same 
> Again, it depends on the context. On your iPhone, why do they even require
> you to enter "tel:", why not just the number?

i don't enter tel:, i simply tap a <a href="tel:+1-510-..."> link on a 
web page and the phone knows that's a phone number. again, it could work 
with the magic <a href=""> method, but i 
would consider the latter being a hack, rather than a good design. and 
it would raise the question who is running, if some browser 
did not implement the magic tel functionality and would actually 
dereference the uri.

> The point is that encoding can be easily translated from a canonical HTTP
> representation to a scheme-specific representation to a context-specific
> representation and back.  Not have an HTTP representation means that...
>> thing could be achieved be using a magic http prefix 
>>{number}, this never happened, and 
>> would not reduce the complexity of implementations (it would 
>> have the advantage of being able to display something to a 
>> user with a non-phone browser, though).
> ...we don't get the benefit you just mentioned, for example.

well, it would mainly be's benefit which would definitely 
show you a lot of helpful ads why informing you about the fact that you 
actually need a phone to call a phone number...

> You know if they had just used the HTTP scheme like
> "" we'd all be much better off, don't you
> agree?

so how does that let me place a phone call from within my browser?

>> fax:

aha. who's running that again?

>> news:
> 	REST interface (GET/POST/PUT/DELETE) to
> http://{newserver}/{group}/{message}

so you say you don't need news because you require every news server to 
support http? that's kind of a circular argument. it works ok, though, 
because both protocols are internet-based.

>> https:
> 	http://{domain}/{path}:443

give that one a try with the https server of your choice. when i want 
https, i want secure communications, not clear-text communications over 
a port that's supposed to carry secure communications.

>> tag:

who's running the domain? i think the whole idea of tags was more or 
less that they can be assigned randomly.

>> well, for the gps scenario you might see google maps as this 
>> service, so instead of using loc:27.987328,86.923828 most 
>> people use 
>> 7,0.148659&t=k&hl=en. 
>> but who is the one having this precious domain? if we had 
>> magic domains for tel and fax, who would own those? and have 
>> the right to route people to some service?
> Who owns  What about  And what about
> So why not a foundation that owns  (BTW, it is currently
> registered by what looks like a squatter so could probably be had for a few
> thousand dollars)

because i don't think there should be a central registry for locations. 
there should be the two well-defined concepts of wgs84 coordinates and 
country names (iso is running a registry for the country list), and 
apart from that, people can use what they want to use.

i am still unconvinced that locations are a good candidate for casting 
them into some http convention. but as i said, this is ongoing work and 
will take quite some time and i am really looking forward to discussions 
whether the web as an information should become location-aware or not. i 
strongly vote for the former, but currently there is surprisingly little 
activity in that direction, that's for sure.

if you want to join the discussion and have some time in april:



Received on Tuesday, 11 December 2007 19:14:02 UTC