RE: URIs & Namespaces

Erik,

I wrote the following email and then, when rereading it it finally occurred
to me where you are seeing some problems with the current status quo; actual
examples always help so much.  I'm going to leave my reply but I'm going to
start with this so that you don't answer any of my other comments
prematurely.

Your example that really resonated with me was when you explained that
Google/Yahoo/MSN maps URLs have become the *defacto* URI for location, and
I'll agree that that is bad. And none of those websites are being careful to
ensure their URLs are unique for a location, so you can have thousands of
URL that have identify the same location because of unrelated values for
parameters unrelated to location. Those websites thus are handling their
URLs like identifiers, they are handling them like they are some program
pointer that makes their program display the correct map (which, btw, is the
problem with most website's use of URLs, but I digress...)

So you suggested a "loc:27.987328,86.923828" as an example URI for a
hypothetical "LOC:" scheme.  I think where you tripped me up was in your
desire to define it as a URI where I am predisposed to want to see URLs
instead of URNs because you can't dereference URNs and I think there is huge
value to being able to dereference all identifiers and get defining
information about those identifiers, especially if that information is
machine parsable.

Anyway, I am starting to see value in a URN where the URN becomes a norm for
passing the information via a URL.  So in the case of your example, what if
you simple publish a recommendation that says to store information in
"loc:{lat},{long}" format and then that any site that would process it (i.e.
Maps at Google, Yahoo, MSN, etc.) would strip the "loc:" off and use the
format in it's URLs for dereferencing (at least Google already does),
publish URI Templates that explain how to handle this, and then your LocWeb
group also publish a canonical dereferencing location on the web? 

Moving on to my previously written comments....

Erik Wilde wrote:
> i am not concerned about the length of uris, but i do think 
> that having to register a dns domain and set up a server is 
> not really what you should have to do, when you want to 
> establish a shared vocabulary for place names. 

I'd like to explore the "should have to" part of your statement?  I'm not
sure where you are coming from with that?   

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?
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?

> sure, you *can* piggyback anything on http, and thus claim 
> that http is the only uri scheme that the web should ever 
> use. but do you really think all entries in 
> http://www.iana.org/assignments/uri-schemes.html
> should have been http:{uri-scheme}/{value} and then the web 
> would be better off than it is today?

Do I think the web would have been better off piggybacking HTTP?  For many
things, absolutely I do.  IMO there is value to have a scheme when it
specifies a different protocol but even then in some cases I'd rather have
seen it tunnel over HTTP.  However, debating the road not taken that we
cannot change is not nearly as useful as debating future implementations
that we can effect.

And to show my intellectual honestly, referencing my comments from this
weekend I have an "ideology" regarding URIs and URNs; I think they should be
HTTP URLs far more often than they have been.

> just a diversion: what i do think is that most browsers are 
> simply terrible and allowing to plug-in uri scheme handlers. 
> they are pretty flexible for dynamically adding media type 
> handlers, but noch such mechanism is provided for uri 
> schemes. i think that is actually something that is part of 
> the reason why creating new uri schemes looks like a bad idea.

Actually I think the cause and effect is opposite and the circumstances
fortunate. Having slow growth in schemes is a good thing as opposed to a bad
thing because new schemes require distribution of new code in the browsers
and can lead to a very buggy web experience.  Using tried-and-tested schemes
and protocols makes for a lot more robust web, and it follows my own person
theory of "software entropy"; i.e. the more widely software has been
distributed and the longer it has been in use, the lower it's entropy and
those the greater its value.  IMHO anyway.  '-)

> sure. which is fine as long as you want to drive on these 
> roads. or, put differently: should the web exclusively be 
> about http interactions? 

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?" 

> isn't it nice that i can send mail and place phone calls from 
> my browser? that i could fire up my navigation gadget by 
> pointing to a location? sure, the majority of web traffic is 
> and probably always will be http, but there are other things 
> which are useful, too.

Such as?  There are a small, finite number of interaction types that cover
almost everything that you'd need to do on the web one of which is
request-response, and HTTP handles that brilliantly.  If there is something
that is request-response, why create the complexity of using something else?

OTOH, we are off-topic because we were discussing the HTTP "sceme" with URIs
instead of the HTTP "protocol."  Using the HTTP scheme for location is just
a layering of technology which is one of the world's oldest and best tested
design patterns.

> > 	http://clubs.brkpl.org/golf/tilden 
> > 	http://clubs.brkpl.org/golf/metro 
> > 	loc:brkpl/clubs/golf/tilden 
> > 	loc:brkpl/clubs/golf/metro
> > Have you really gained anything by creating a new scheme?  You've 
> > shortened by 7 characters, but for your local short names 
> of "tilden" and "metro"
> > nothing has changed.
> 
> 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.

That said, I assume my discussion that follows regarding a
"LocationRegistry.org" handles that concern.

That said, can you give me a use case where you would envision these URLs to
be stored, presented, shared, etc?  Currently I can't see why a "LOC:"
scheme would be important, but maybe presenting several use-cases will allow
me to see beyond my current limits on envisioning your concepts.

> now this means you expect all people to basically implement a loc: 
> scheme but simply write it down with a http: syntax. and 
> implement some magic check to recognize when they encounter 
> such a loc-http uri...

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?

> >> for example, the tel: and mailto: schemes make sense (i think), 
> >> because not only do they identify things, they also clearly define 
> >> how to interact with them.
> > They may make sense, but they are not nearly as widely used 
> as HTTP.  
> > What's more, they are not dereferenceable which IMO is 
> being able to 
> > dereference a URI is an incredible benefit.  
> "URN:ISBN:0-395-36341-1" 
> > is interesting, but
> > http://isbn.info/0-395-36341-1 is far more useful (assuming 
> it returns 
> > information for the book designated by ISBN # 0-395-36341-1).
> 

> well, being able to tap a tel: uri on my iphone...

Damn Apple zealot iPhone users... '-P  

j/k :-)

> 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?

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 
> http://telnumbers.org/{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.

> but: if the skype folks wouldn't be as narrow-minded as they 
> are, they would have introduced tel: handlers into all major 
> browsers by now (or at least would have pushed for plugin 
> features and deployed plugins for skype), and the web could 
> be better integrated with the non-http world.

There goes those damn narrow-minded people trying to get a strategic
advantage...  

You know if they had just used the HTTP scheme like
"http://skype.com/myscreenname" we'd all be much better off, don't you
agree?

> ok, tell me how to piggyback these onto http:
> 
> file:
> sip:

There are different protocols and are not applicable to what I'm advocating,
although SIP might be able to be implemented using RESTful HTTP.

> fax:

	http://telRegistry.org/{number}

> news:

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

> https:

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

> tag:

	http://tagRegistry.org/{tag}

> (just kidding, don't do it) 

	Too late!  :)

> i don't want to come across as 
> somebody who wants to have uri schemes for all kinds of 
> things, but i think there are cases where it makes sense.

And there are use-cases where it does make sense, but when I'm presented
with a Atheist I present the case for God and when presented with a Theist I
present the case for no god... 

> so i use a http uri, dereference that, get some html, find a 
> magic name in a meta tag, and then conclude that, in reality, 
> this was a http-loc uri and then i am where i would have been 
> with a loc uri in the first place? and for all of that to 
> work i need to know the magic LocationRegistry.org service? 
> and how does that service know that some domain is a location 
> domain? do i need to register with that magic service when 
> registering my place name dns name? 

Yep, that's one way to do it.  Kinda like how you'll have to do it to
validate that a value of "loc:" that you want is valid.  And if you are not
interested in validity, why do you even care to have a scheme?

> 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 
> http://maps.google.com/maps?ll=27.987328,86.923828&spn=0.09063
> 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 www.w3.org?  What about www.iana.org?  And what about www.ietf.org?


So why not a foundation that owns www.location.org?  (BTW, it is currently
registered by what looks like a squatter so could probably be had for a few
thousand dollars)

Or heck, how about "LocWeb.org?"

Who owns the 10 root DNS servers?  Maybe you can have:

	http://1.LocWeb.org
	http://2.LocWeb.org
	...
	http://10.LocWeb.org

I'm modeling after ideas things that have come before even though we've not
yet assembled the technology in exactly the same way before.  Though why
not?

> so, for the coordinates, what's the http solution? google 
> maps? yahoo maps? microsoft virtual earth? something else? if 
> so, what? i would prefer a neutral way to say "that's a pair 
> of coordinates", and then users can choose.

How about you define a standard that says that any server can use the
"location URL format" assuming they expose the following in Robots.txt:

	LocWeb-BaseURL: http://maps.google.com/locweb

Then your location format 

> for example, the iphone does some pretty dirty hacks and 
> based on some pattern matching re-routes you from its web 
> browser to the builtin mapping app. they can do this because 
> they mostly look for google maps patterns in uris, but it 
> really is a terrible hack.

Agreed, and it violates URI Opacity.  Of course it violates it because there
is no other way to get the functionality without violating URI Opacity which
means the architects of the web have failed to provide solutions for that
need.  I've actually thought about this issues at length (see various
writings on http://blog.welldesignedurls.org) and think that augmenting
Robots.txt and using URI Templates could see us solving many of these
problems (although I'm currently rather unhappy with the direction URI
Templates has recently taken, though I've not had time to debate it.)

> if we had a loc: scheme for wgs84 coordinates, would you prefer that 
> place names should still use http, or should they be folded 
> into the loc scheme?

It we had to have a "LOC:" scheme I'd prefer an analogy in HTTP with a
well-known conversion between the two.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org

Received on Tuesday, 11 December 2007 08:45:16 UTC