Re: Can "http://danbri.org" and "http://danbri.org/" URIs represent different things?

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

> On Jul 2, 2009, at 10:48 AM, <john.1.kemp@nokia.com> <john.1.kemp@nokia.com 
> > 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  
resource,
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  
possibility.)"

But clearly if the protocol is that when asking for information about <http://example.com 
 > you must ask for information about <http://example.com/> , 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  
<http://example.com> never occurs in the system.

Tim

(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