RE: non-http uris

Sandro Hawke writes:

> There's a third option here, which is to use something like tag URIs

As I understand tag URIs, they let you mint URI that is unique, but unlike 
http-scheme URIs, they don't tie the relationship between identifier and 
resource to a protocol, do they?  I had inferred, perhaps incorrectly, 
that Erik did not just want to assign an identifier to each geographic 
location, but also to enable a browser (for example), to do something 
special when dereferencing such identifiers.  From your reference [1] on 
tag identifiers:

"This specification only tells people how to mint unique identifiers. 
Policies concerning the use of these identifiers should be set for each 
situation or protocol in which they are used. "

I don't think that works for this case.  I don't think one wants the 
resolution of the identifer to depend on "the situation or protocol in 
which they are used."   From Tim's Design Notes on the Web [2]:  "It 
doesn't matter to whom or where you specify that URI, it will have the 
same meaning.  ....  So, this means that there is no scope within which a 
URI must be placed for it to hold. All you need say is that something is 
"on the Web" and that is enough. Anyone can follow that hypertext link, 
anyone can look up that URI. "  How does that square with the suggestion 
that proper use of a tag URI depends on the situation or protocol in which 
they are used??

Let's say that some particular user agent would want to show you a map or 
a satellite photo of the referenced location when a 
tag:dret@berkeley.edu,2008:geocode:xxxx,yyyy link is dereferenced.  Do you 
anticipate that would work?  Is the idea that agents will eventually 
recognize the tag:dret@berkeley.edu,2008:geocode: prefix?  I understand 
that there are issues with the http choice as well.  The TAG's httpRange 
decision seems to imply that for 
http//dret@berkeley.edu/geocode/?lat=xxxx+long=yyyy you would need to 
return a 303 redirect, as opposed to giving the map directly, but you do 
have a standard means of bootstrapping from widely deployed user agents, 
and you have the same option, I think, for agents to eventually recognize 
the http//dret@berkeley.edu/geocode/ base URI as special.

Noah

[2] http://www.w3.org/DesignIssues/Axioms.html#unique


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Sandro Hawke" <sandro@w3.org>
01/07/2008 05:16 PM
 
        To:     noah_mendelsohn@us.ibm.com
        cc:     "Mike Schinkel" <mikeschinkel@gmail.com>, "'Erik Wilde'" 
<dret@berkeley.edu>, uri@w3.org
        Subject:        RE: non-http uris



> The problem with Erik putting out an experimental geocode schema, in my 
> opinion, is that he may not be the only one with that idea.  Maybe now, 
or 
> a in a few years someone will come up with a better one.  Perhaps Erik 
> will only allow for 2 dimensional coding and someone will decide that 
> height is important.  Perhaps he'll get the resolution "wrong".  Well, 
if 
> he'd just made up a namespace or an HTTP URI, anyone else could just 
make 
> another one.  Once he's started getting people to deploy URIs of the 
form 
> "geocode:xxxx,yyyy" then for all time that must be the only use of that 
> scheme.  Otherwise, when you come upon a link, you won't know whether 
it's 
> an "old" one based on his conventions, or a new one.
> 
> > Do you have a current opinion on what would be best, or do you 
> > just think it
> > needs a lot more exploration?
> 
> Well, if at all possible, I'd try to use http-scheme URIs.  Insofar as 
> there's a deep belief that a separate scheme is needed, I would try to 
go 
> through a very careful process of requirements gathering, community 
> discussion, debate, etc. leading up to an IETF RFC or W3C 
Recommendation. 
> What I'm very reluctant about is to see a scheme go out for 
experiemental 
> use until such careful design and debate has happened. There are many 
> aspects of Web architecture with which it is easy to deploy experimental 

> implementations.  Unless I'm missing something, the tradeoffs in 
> experimenting with new schemes are much trickier.

There's a third option here, which is to use something like tag URIs
[1].  Personally, I do recommend using http: URIs, but I also have
sympathy for that "deep belief" that HTTP is not appropriate for
something like this.

But that doesn't mean you need to go through the whole IETF consensus
process to get a new top-level URI scheme.  You can just use tag URIs,
like:
    tag:dret@berkeley.edu,2008:geocode:xxxx,yyyy
or
    tag:geocode.example.org,2008:geocode:xxxx,yyyy

It's a bit longer, but it lets you just go ahead on your own and worry
about convincing the rest of the world later.

Back to HTTP: If you just used http, then the URL could actually work in
people's browsers.  For instance,
    http://geocode.example.org/xxxx,yyyy
could return some very useful/interesting information.

      -- Sandro

[1] http://www.taguri.org/

Received on Monday, 7 January 2008 23:23:54 UTC