W3C home > Mailing lists > Public > uri@w3.org > December 2007

Re: URIs & Namespaces

From: Erik Wilde <dret@berkeley.edu>
Date: Tue, 11 Dec 2007 15:46:04 -0800
Message-ID: <475F213C.9080603@berkeley.edu>
To: uri@w3.org
CC: Mike Schinkel <mikeschinkel@gmail.com>

hello mike.

> I am seeing two distinctly different use cases, one being (b) the wgs84
> coordinates and the other being (c) the user-defined segment.  Since we
> entered the discussion on (c) a lot of my prior comments apply more to (c)
> than to (b).  

sure. and my (a) and (b) goals are more explanations of why i want to do 
(c) the way i want to do it, and how i should o it best.

> 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. 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. since 
wgs84 coordinates are not a name, but a resource, they should not use a 
urn scheme, but a uri scheme.

> I think a URN Namespace fits far better here than a scheme with none of the
> scheme downsides.  It gives you what you need which is a shared syntax for
> wgs84 location information without having the baggage of adding a scheme.

technically, whether some client needs to know "loc:" or "urn:loc:" to 
use its navigation features does not make a difference, but the latter 
would imply that there's some resolution service involved, which is not 
the case.

>> 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). there is always *some* http use case you 
could come up with, often involving doing some searching or data mining 
and then displaying some kind of summary. 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.

> If you meant local as "context-specific" then by the opening quote in this
> email invalidates the use of a scheme.  If you actually meant global then
> you need some way to register them, even if the registration system is
> hierarchical as analogous to DNS otherwise you can easily end up with the
> same URIs that point to different locations.

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

> You are taking my example too literally.  The point is that there is
> additional information that can only be retreived by dereferencing an HTTP
> URL and you have the same needs for locations. You can't embded all
> information about a location into a URI and have it still be useable so
> having a way to dereference that information would be valuable someone would
> want to know about the location.  

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. of course, you can geocode 
  the html page and there is prior work an that area and i think that's 
a good idea, but in a truly location-aware web, location should show up 
in the three core parts of web architecture:

- location uris
- location information in http
- location for content (html, xml, atom)

> BTW, if you used a well-known server approach your GPS device can be
> configured to know that the domains represent location registries and won't
> have to do a lookup, and your iPhone can do the derefernce once and then
> cache the info that it represents a location.

where to i get these domains from? do they all use the same scheme for 
composing their uris? 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? and if i want to use 
them, i must know their "special nature of being http location uris"?

>> 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="http://magictel.org/+1-510-..."> method, but i would 
>> consider the latter being a hack, rather than a good design. 
> We are back to use-case (b), right?  In that case, how about <a
> href="urn:geoloc:12.34567,98.7654">?   And in contexts where it was
> understood it would be possible to strip both "urn" as well as "urn:geoloc"
> in other contexts.

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 ;-)

> But I can assume you want (b) and (c) to be unified, right?  However, they
> are two different use-cases.  What about this instead:
> (b) -> URN Namespace GeoLoc
> (c) -> Any HTTP URL that returns a content-type of "text/geoloc" when conneg
> requests it, or text/html with a <meta> element containing the the GeoLoc
> when conneg does not request "text/geoloc" specifically?  (I'll be damn! I
> just found a good use for conneg here... :)

(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 it might still be 
useful enough if i set up a meeting with a friend. or if somebody looks 
up my location on the facebook-follows-your-every-move service, where i 
don't really want to broadcast my gps coordinates 24h a day.

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

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

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

>>>> fax:
>>> 	http://telRegistry.org/{number}
>> aha. magicfax.org. who's running that again?
> The magixfax.org foundation.  Like IANA.org, etc.

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

>>> 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)
>> because i don't think there should be a central registry for 
>> locations. 
> I guess that's the crux of the disagreement.  I think there should be if you
> are applying names.  If you are using wgs84 coordinates, a URN Namespace can
> accommodate.  As I've explained earlier in this email.

yes, that is the crux. but i enjoy the discussion, really.

> 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. using uris as names 
partitions the namespace sufficiently to make collisions highly 
unlikely, and that's good enough. at least for me.

> I agree the web should become location aware. Thus far it seems you've been
> fixated on a location scheme as being the only viable way to approach it. In
> this email I have explored several different approaches (HTTP URLs, URNs,
> Content-Types, HTTP Headers, HTML <link> & <meta> elements so I'm interested
> to see if you can envision any of them as being viable compared to adding a
> location scheme.

like i said above, i think location should become a first-level concept 
that is represented in uris, http, and content. i am not saying i 
personally will or can make that happen, but i am convinced that it will 
happen, one way or the other. i also think this would be a good time to 
make it happen in a well-defined way, trying to come up with some 
consistency in the design, but this is just me, thinking about possible 


Received on Tuesday, 11 December 2007 23:47:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:11 UTC