RE: URIs & Namespaces

Erik:

What I'm about to say may sound sarcastic but I'm just being matter-of-fact
so please take it that way.  I'm coming to the conclusion that you came to
this list not so much to get other's opinions on the use of a URI scheme for
location but instead to advocate for the use of a URI scheme for a location.
If the latter really is the case, then just let us know that to be the case.
I was interested in the discussion because I saw it as an exploration to
find the best solution but if you've already made up your mind then it
really is a waste of time to continue to debate it, at least for me.

OTOH, if you have not already made up your mind I apologize for thinking
otherwise and invite you to continue to read on. 

But either way it will be helpful to know your current position on this.

Erik Wilde wrote:
> > So instead of having:
> > 	geoloc:27.987328,86.923828
> > You would have:
> > 	urn:geoloc:27.987328,86.923828
> > I think that gives you essentially all the same benefits, no?
> 
> no. urns by definition have resolvers, which implement a 
> well-defined process of taking a urn, and spitting out some 
> uri. well, sort of. the syntax itself (rfc2141) does not say 
> much about all of that. 

LOL!  In the case of location wgs84, your resolver is your GPS! ;-)
IOW, you don't need a resolver because your resolution is done by
mathematical formulas.

> basically, urns are mostly used if 
> people think about some resolution process where they have a 
> urn, and the resolver turns that into a non-urn uri. 

Can you give me a reference that would authoritate that statement?

> since
> wgs84 coordinates are not a name, but a resource, they should 
> not use a urn scheme, but a uri scheme.

You say they are a resource, I say they are a name, and TBL says making the
distinct is fraught with peril: http://www.w3.org/DesignIssues/NameMyth.html
:-)

> technically, whether some client needs to know "loc:" or 
> "urn:loc:" to use its navigation features does not make a 
> difference, 

Exactly.

> but the latter would imply that there's some 
> resolution service involved, which is not the case.

So as we are in disagreement that a resolution service is required can
anyone else here step in and give their opinions?

> >> 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.
> > Agreed, but it seems to me you are making the assumption 
> that HTTP is 
> > not valid when there are use-cases outside the web. I would 
> argue if 
> > there are use-cases within the web (i.e. to be able to lookup 
> > information about the location via a dereference) then an 
> HTTP URL behaves nicely as a URI.
> 
> that makes it hard to ever use anything than http (which 
> seems to be your line of thought anyway). 

Why?  If the information is embedded into a URL via an recognize syntax, why
can't it do double-duty?

> but what, as somebody wanting to make a 
> phone call, serves me better: my phone just making that call, 
> or my phone-based browser displaying a web page that informs 
> me what number to type in on the phone's keypad? i prefer the former.

Clearly you are not contemplating my example. In my hypothetical use case
your phone would get the necessary info from the webpage transparently to
make the call for you, it your phone would only show a web page to inform
you when the phone you are using wouldn't have understood GeoLoc: anyway.
You keep conveniently ignoring that you are going to have to have a phone
that understands GeoLoc: and you keep ignoring the fact the using an HTTP
approach will support older phones that can browse but not GeoLoc: whereas
only new phone could ever support GeoLoc.

> look at xml namespaces. global names and no registry. not 
> pretty, some people argue, but very useful, i would reply. 
> more on that later.

And IMO, XML namespaces are the poster children for where non-globally
registered namespaces supported by URIs with no resolution requirement have
gone horribly bad.  It was specifically XML Namespaces I was referring to
earlier when I said that namespaces can create such a problem. (Of course,
knowing that you are a published author who has written lots about XML, I
assume that my criticizing XML namespaces to you is like postulating to the
pope that there is no god.  If so, well at least you know where I stand. :)

> sure. that's the difference between making location a 
> web-level concept, where you can have a resource that *is a 
> location*, or making it a second-level concept, where you 
> have a web page that *talks about a location*. these are 
> pretty different things. 

Yes of course. One is a resource and the other is a representation returned
by that resource. I don't see the problem.

> where to i get these domains from? 

Many options.  One is to have it in the spec.  Others are for you to find it
like you've managed to find Google, Yahoo, and MSN maps.

> do they all use the same scheme for composing their uris? 

I'm not advocating a scheme, you are.

> if so, where do they get 
> that from? and if they follow some standard for doing that, 
> aren't they effectively creating location uris, but they just 
> prefix them with http? 

Yes, but with additional semantics for those HTTP resources.

> and if i want to use them, i must know 
> their "special nature of being http location uris"?

Sure. The entire web is built on knowing the 'special nature' of things that
are spelled out in specs.

> like i said above, i don't think urn are a good idea here. 
> but i am glad to see that you example does not say "http:..." here ;-)

You don't budge an inch, do you?  ;-)

> (c) may map to (b), but maybe not. if i say i am "at work", 
> that is a highly relevant space for all people who know me, 
> even though i don't associate any geographic information with 
> it. 

But you "at work" is not globally relevent, and didn't I establish that a
scheme should only be used for something that is gloabally relevent?  Why
have you not addressed that?

> > If you use this approach then the design of the location 
> registry can 
> > be orthogonal to the URN Namespace for GeoLoc.  This would 
> let people 
> > set of their own approaches for things like 
> "BerkeleyPlaces.org" from 
> > my earlier email and keep that part out of any need for 
> > standardization.  After all, your (c) use-case is just a 
> mapping to your (b) use-case, right?
> 
> sometimes. often not, i assume. often, place information is 
> highly contextual and does not need gps coordinates to be useful.

If it is not then it is not universal and has no business as URI or a
scheme.  The entire point of URIs is that they are globally unique and
represent something in global space.  You keep wanting to graft local and/or
private concepts onto a global space but you are not willing to use the
globally registered solution to disambiguate.  Can you not see the logical
falacy of your thinking?

> >> and it would raise the question who is running 
> magictel.org, if some 
> >> browser did not implement the magic tel functionality and would 
> >> actually dereference the uri.
> > But that browser wouldn't expect to find magic tel anyway, so 
> > dereferencing the URL would be okay because the browser otherrwise 
> > wouldn't know what to do with it.
> 
> well, my web page might include a magictel.org uri in a link, 
> what happens if that is clicked with a non-magictel-enhanced 
> browser? for "tel:", firefox just tells you that is has no 
> idea what to do with it. 
> for a http://magictel.org uri, i would see an ad-infested web 
> page 

Who the hell said anything about an "ad-invested" web page?!?!?  By bringing
that up you are discrediting your argument.

> that told me to pick up a phone and dial. i prefer the 
> error message, and if the web page is not horribly 
> ill-designed (using links labeled "click here!"), i would 
> still be able to see that this was a phone number, but my 
> browser simply lacked the features to use it.

What you propose is a dead-end for the user who does not have the tel: or
GeoLoc: equipped handset, and I'm proposing a way for that user to be able
to accomplish their desired task.  Honestly, I can't see why you would argue
that a dead-end is a good thing?!?

And you are making sweeping assumptions about the fact that the web page
must by defintion be horribly ill-designed.  If that is a real concern, we
might as well all shut down the root DNS servers, close the doors at the W3C
and go home now.
 
> > It would also be the benefit of the person finding a tel: 
> URL who has 
> > not idea who telephone that is.  Ignoring the privacy concerns, I 
> > would love to be able to go to http://tel.org/{number} and find out 
> > who the number is registered to. In contexts where there are no 
> > privacy concerns, it would be very useful to have a 
> canonical location to describe the datum.
> 
> that's a secondary concern. 

Secondary concerns are worth considering, especially if you can get both
primary and secondary concerns covered by one solution.

> if you know what a phone number 
> is (because there is a well-defined uri scheme for phone 
> numbers), you might want some directory or lookup service, 
> but you can have that easily if you understand what a tel: 
> uri is and then feed the number to your preferred directory 
> service. http://tel.org/ again looks to me like a single 
> domain getting more centralized power that would be prudent.

Does iana.org have more power than is prudent?  Do the 10 root DNS servers
have too much power?  There are numerous models for making this work (root
servers, preferred providers, etc.) and your attempts to discredit those
solutions by tarnishing them with misdirecting phrases like "horribly
ill-designed web pages" don't change their merit.

> another happy major google adsense customer, i guess. why 
> should anybody get that monopoly? fax: is working just fine.

Who said it would be a monopoly? Oh, you did. :)   But I didn't.  I could be
a non-profit foundation, a collective of ISPs like the DNS root servers, a
network of preferred providers, and/or a publisher-specific provider.  IOW,
it would be a lot like OpenID.

But again, you don't need if for the wgs84 coords as an URN works best
there; the "named" places would work best like providers.

BTW, this infrastructure I speak of would be valuable for a lot more than
just GeoLoc and is something I plan to advocate for far more than GeoLoc.

> > Maybe we do agree... But only if you accept that people 
> won't get to 
> > use a global scheme for those things "that they want to use."  If 
> > people get to define, there is a need for a global registry, either 
> > directly or indirectly.
> 
> no. like i said above, xml namespaces show how you can use 
> locally defined namespaces that are universally identifiable 
> without using a registry. and i think it is a good concept. 

And like I said, XML Namespaces are the type of thing I personally want to
be involved in ensuring never happens to the web again. :)

> using uris as names partitions the namespace sufficiently to 
> make collisions highly unlikely, and that's good enough. at 
> least for me.

But not good enough for me.  Other have an opinion?

> like i said above, i think location should become a 
> first-level concept that is represented in uris, http, and 
> content. 

It can become a 1st level concept with a spec to piggyback HTTP and combine
with a URN namespace for wgs84 coords.  BTW, a spec makes it first-level, no
scheme required.

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

Received on Wednesday, 12 December 2007 01:55:52 UTC