RE: URIs & Namespaces

Erik, Sean:

I found this which I'll reference before I comment on your emails:

FROM: http://infomesh.net/2001/09/urischemes

"Why Not Create A New URI Scheme?
"There is a huge problem in people creating new URI schemes... URI schemes
are one of the most valuable resources that the Web has to offer, and are
intended only to address information spaces that are globally useful.
Creating new URI schemes to address spaces which are not useful to the Web
in general, which aren't registered, or which break some axioms of Web
architecture are the most harmful sorts of new URI schemes."

I think that makes a key point, being URI schemes are intended only to
address information spaces that are globally useful.  More on that below.

Also this, which references the former: 
http://esw.w3.org/topic/UriSchemes

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

The fog is slowly clearing for me on this set of use-cases.  

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

I can now see the rationale for for a scheme associated with wgs84 primarily
because by definition it can be known to be unique.  However, I actually
think what you want there is not a scheme but instead a URN Namespace:

	http://en.wikipedia.org/wiki/Uniform_Resource_Name  

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?

Sean Reilly wrote:
> What about the case when you want to use the URI on GPS 
> device that lacks a TCP/IP connection?
> 
> Say your GPS device has a built-in address book with an entry like the
> following:
>   name: Sean Reilly
>   home-loc: loc:55.959123,-3.191657
>   home-addr: 48 London St, ...
>
> An http: URL in a situation like that would be useless.  Many 
> cars and handheld devices have GPS built-in but not a full 
> internet connection.  If there were a standalone loc: URI 
> scheme then the identified resources could be accessed on all 
> appropriate devices including a traditional browser.

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.

In addition, info from that URN could be used in HTTP URL in a defacto
standard way such that the mapping sites can access them.

Back to (c), can also do so by using place names from some vocabulary.  That
use case by its very nature needs to either be local and context specific,
hence not a candidate for a *Universal* Resource Identifier, or needs some
registration method to ensure its uniqueness.  HTTP and DNS can already
handle that brilliantly.

Erik Wilde wrote:
> 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.

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

I used the term "local" to mean "context-specific" yet I think you are using
is colloquially, right?  IOW, if I restate what you said as simply "place
name vocabularies in the global context of a uri scheme for locations, so
that i can match and map locations" wouldn't it still have the same meaning
you required?

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.

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

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.  

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.

As an aside, and this is another part of my ideology, I don't assume an
http-accessible resource will provide various representations.  Personally I
think content negotiation is mostly a pox on the web, and I (would like to)
assume that each URL will provide a unique representation and that I use
unique URLs for different represenations, i.e. HTML, XML, JSON, etc.

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

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

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?  

> 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, it would mainly be magictel.org'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...

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.

> > 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?
> 
> so how does that let me place a phone call from within my browser?

That URL could return an HTTP header or HTML <meta> or <link> element that
contains information about how to place the call. Benefit there would be
that the HTML page could contain information about the software that the
user would need to download to initiate the phone call.  With <a
href="skype:999-999-9999">Call Me</a> the only people who that works for are
the people who happen to have Skype software already installed.

> >> fax:
> > 	http://telRegistry.org/{number}
> 
> aha. magicfax.org. who's running that again?

The magixfax.org foundation.  Like IANA.org, etc.

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

Sigh.  You can absolutely build a server and a client using REST-based
services that could provide the same features and benefits of a news server
without having to use the NNTP protocol or NEWS: scheme.  But you asked how
I would handle that AS IS those protocols and schemes were not legacy (or at
least that is how I answered.)  Given that they are legacy, just it is
circular but that wasn't the context of my answer.

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

That's just because the browsers were implemented to support HTTPS.  If they
had been implemented to support port 443 then it would work fine.  Remember,
you are asking how HTTP could have been used instead of these, so you can't
hold me to legacy concerns.

Actually there are a significant debate over the problems that using HTTPS
as a scheme created although I can't seem to dig them up via Google at the
moment.

> 
> >> tag:
> > 	http://tagRegistry.org/{tag}
> 
> who's running the domain? i think the whole idea of tags was 
> more or less that they can be assigned randomly.

The magictag.org foundation.

Yes, that was the idea, but I think it was a bad idea.  I also don't see
them in widespread use, probably because it wasn't a great idea.

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

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

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.

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

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.

> if you want to join the discussion and have some time in april:
> 
> http://dret.typepad.com/dretblog/2007/12/locweb-2008-cal.html

I'll discuss offlist.

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

Received on Tuesday, 11 December 2007 22:54:00 UTC