RE: URIs & Namespaces wrote:
> What's wrong with using a base URI and relative URIs?  For example:
> Base URI for the namespace: 
> Name for Berkeley: 
> <snip>
> You have then what is effectively a namespace, but well 
> grounded in the http URI scheme.  Because the DNS name is 
> (hypothetically) assigned to you, you are in a position to 
> delegate assignment responsibilities for the individual URIs. 


Al Gilman wrote:
> A specification SHOULD reuse an existing URI scheme (rather 
> than create a new one) when it provides the desired 
> properties of identifiers and their relation to resources.


Al Gilman wrote:
> This is where microformats are at the moment: most people 
> process the info from the short name.  Few need the backup.  
> But the full drill is still to publish the backup to avoid 
> future problems as people start to use the design pattern more.

I don't follow what you mean by "the backup?"

Erik Wilde wrote:
> that somehow only works for pretty heavyweight place 
> namespaces, where somebody (such as me) would bother 
> registering a dns name and set up the appropriate server. 

I would argue "not really."  If you want them to have meaning to more than
one person, then a shared reference point is rather important.  So for a
group like "Berkeley" you can have "" and your URL

Of course for those that don't want to have to create their own domain they
can piggyback on someone else's domain, i.e. (from
d_Organizations/): (By Any Means Necessary) (An Associate Club of the Northern
California Golf Association) (organization for Boalt law
students) (For current and soon-to-be
pilots) (Berkeley Postdoc Association) (Berkeley Artists in
Resonance) (eXperimental Computing Facility) (Asian Baptist Student Koinonia) (The speech and debate
team) (Cal Berkeley Democrats) (Environmental
sustainability with existing campus programs) (Solar Vehicle Team) (Residential Christian
community) (True Blue Madonna Club) (Berkeley Ballroom Dancers) (Renter's Legal Assistance) (InterVarsity Christian Fellowship) (Berkeley's Animation Club) (UC Berkeley Men's Octet)

Using these you can then let those clubs "register" with the "place
authority" at and then the "registrant" gets to define
their own "places" within their own "namespace" (i.e.
"" is the namespace for the "Golf" club.)  So
here are the URLs for Tilden Park and for Metropolitan Golf Links:
( (See
Within members of the golf club it could easily become know that "tilden" is
shorthand for Tilden Park in Berkeley and "metro" is shorthand for
"Metropolitan Golf Links" in Oakland.  People can refer to "tilden" and
"metro" when within context and and when not within context.   What's
more, the URLs could bring up a bare minimum of information that defines the
term, and IMO that would be good.

Now you might think that "" is too long; fine then; look
for something short that is available, i.e. 

Erik Wilde wrote:
> me, that looks like piggybacking something onto http that 
> should not be there. 

I'll counter that piggybacking is exactly what you want, and that I believe
schemas are designed to be piggybacked on, whenever reasonably possible and
reasonably appropriate.  And HTTP is brilliant for piggybacking.   Take a
look at HTTP URLs:


The {stuff} is an opaque string; it can easily embed your own location
identifier scheme, and browsers can deal with it assuming it followed the
HTTP request/response protocol spec.

When you piggyback you get all the previously paved roads (i.e. all the
in-place infrastructure) without any of the cost of paving.  By analogy it
is why we are more apt to be putting pure Ethanol in near future cars than
liquid hydrogen; the filling station infrastructure is pretty much already
there.  If instead of using HTTP you create a "LOC:" scheme you have to then
proliferate software updates to every computer before it can know anything
about your location scheme; if you use the http schema you get all
computer's knowledge of the transport (after all, that is what it is
hypertext TRANSPORT protocol.)  And you get it all for free; then you need
to do have software at the endpoints where it is processed know how to
inspect the payload within the HTTP URL.

Erik Wilde wrote:
> i do have read the tag finding about 
> avoiding new uri schemes and trying to fit things into http, 
> but i think that if new forms of interaction are involved, 
> then new uri schemes still might be appropriate.

Let's look at my examples above using a hypothetical "LOC:" scheme: 


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.

But for argument let's say there really is a great reason to create a "LOC:"
scheme.  Okay then start with HTTP and tell everyone to use the format of
"http://{sub-ns}.{ns}.{tld}/{cat}/{name}" for HTTP but transform it to
"{ns}/{sub-ns}/{cat}/{name}" when storing it in a database or referring to
it elsewhere.  Once use of these location identifiers becomes ubiqutious you
can then introduce a "LOC:" scheme and translation software that transforms
from HTTP: URL to LOC: URI.  But then I doubt you ever would take this last
step because you'd be loosing all the benefits HTTP provides.  At best I
would expect that you'd introduce LOC: as shorthand where it is known how to
convert from an LOC: URI to an HTTP: URL. JMTCW anyway.

Erik Wilde wrote:
> 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 is far more useful (assuming it returns
information for the book designated by ISBN # 0-395-36341-1). 

Erik Wilde wrote:
> the same is true for ftp: 

FTP is a different case.  FTP is both a different protocol *and* was
ubiquituous before HTTP.  If HTTP came first I'd argue a better FTP would
have been a tunnel over HTTP.  Since you are only proposing a location
identifier and not a location protocol (that I am aware of) I don't see a
reason to create a new scheme for it.

Erik Wilde wrote:
> and, i guess, most other uri schemes that are viewed 
> to be well-justified.

I'm pretty sure I'll have the same opinion of any other URI schemes; feel
free to try me.

Erik Wilde wrote:
> by having a uri scheme for locations, one would know the 
> possible interactions with these resources, such as stating 
> "this is where i am right now" or "find me a route how to get 
> there". that might not work well for all locations, but at 
> least it should.

This can work using HTTP URLs and a domain.  Of course if you need to be
able to determine that it *is* a location, you can set up a webservice at (or similar) that can validate if a domain is a
registered namespace or not, i.e. ah HTTP 200 means it is valid, and HTTP
404 means it is not:

And/or the HTML document returned by dereferencing could include a <meta> element, something

	<meta name="location-namespace" content="Namespace for UC Berkeley

Erik Wilde wrote:
> or to put it differently: how in the current web architecture 
> can i make a statement about my location, and a user can then 
> decide which mapping service to use to find that location? 
> http: in that case forces me to send people to google maps or 
> yahoo maps or some other specific service, whereas all i want 
> to do is to identify my current location, so that others can 
> use that information.

I don't see how HTTP forces anything.  If the world gets behind
"" it would be no different then them getting behind a
"LOC:" scheme.  Actually I believe the chances of them getting behind an
HTTP-based solution would be greater because it is built on top of existing
schemes and protocols, and because would provide them a
place to dereference.

Erik Wilde wrote:
> or let me ask something different: there is an internet draft 
> for a uri scheme for wgs84 coordinates. is that something 
> that should be done or should it be folded into some http 
> prefix? i believe that location is an important enough 
> concept to be represented on the web, so i think there should 
> be the concept of location as a web concept. 

Though I can't speak for W3C or ITEF, I personally would like to see wgs84
piggyback HTTP.  OTOH, I don't have a problem with a dual system (i.e. both
a scheme and an HTTP version of the scheme) ASSUMING we do get an HTTP
version with a mapping to the other scheme or URN.

Erik Wilde wrote:
> now, if location is a web concept (which is open to 
> discussion), should non-gps locations be expressed in that 
> conceptual space, or should they be mapped to http prefixes? 

I don't' follow that...

Erik Wilde wrote:
> i ... generally agree with al gilman that any uri 
> scheme requiring escaped uris within uris is rather ugly. 


-Mike Schinkel

Received on Tuesday, 11 December 2007 05:42:59 UTC