Re: Can "" and "" URIs represent different things?

On 2009-07 -02, at 19:31, Pat Hayes wrote:

> On Jul 2, 2009, at 10:48 AM, <> < 
> > wrote:
> ...
>> My reading of the MUST in RFC 2616:
>> "If the abs_path is not present in the URL, it MUST be given as "/"  
>> when
>> used as a Request-URI for a resource"
>> is that "no path" is considered to be the equivalent of a path of  
>> "/".
>> My reading would thus be that the URIs denote the /same/ thing.
> What you cite refers to "when it is used as a Request-URI". That is  
> precisely why it does not necessarily refer to denotation. It is  
> centrally important in all these discussions to keep the two things  
> clearly separate. URIs can be used to request (access to) a network  
> resource, and they can be used as names, to denote a resource.

I would prefer you to say, "URIs are used as names, to denote a  
and the can be used to request information about the resource".

When you ask and get a 303, then you are getting information back  
about the thing denoted, but you are not getting back the content of  
any named document.

> The two functions are distinct, and need not coincide.

They are not unrelated.

> Some URIs can denote without being able to be usable to request  
> anything; others may work as requests but not denote what it is that  
> they request (according to http-range-14, a 303 redirect sets up  
> this possibility.)

or rather,
"Sometimes a request for information will be unsuccessful; sometimes  
they will not return that the resource is a document with a given  
content (according to http-range-14, a 303 redirect sets up this  

But clearly if the protocol is that when asking for information about < 
 > you must ask for information about <> , this is  
only useful if the two URI strings are used to denote the same thing.

It is reasonable to canonicalise URIs in an RDF system so that in fact  
<> never occurs in the system.


(Is a URI without the slash actually a valid production anyway -- not  
in a position to check just now?)

> That wording of RFC 26167 that you cite may not have been intended  
> this way, but in fact it gives a perfect justification for a  
> decision that the "/"-less URI might denote something other than  
> what the "/"-normalized URI requests, as danbri originally proposed
> Pat Hayes

Received on Monday, 6 July 2009 03:10:17 UTC