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

[Tim Berners-Lee]

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

> On Jul 2, 2009, at 10:48 AM, <john.1.kemp@...> <john.1.kemp@...
> > 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
>

[Xiaoshu Wang]

David Booth wrote:

> On Thu, 2009-07-02 at 15:50 -0500, Pat Hayes wrote:
>  
>> On Jul 2, 2009, at 3:42 PM, Alan Ruttenberg wrote:
>>
>>    
>>> On Tue, Jun 30, 2009 at 8:54 PM, Dan Brickley<danbri@...>  
>>> wrote:
>>>      
>>>> Hello TAG,
>>>>
>>>> Talking with some SW folk about OpenID, and whether my "me-the-
>>>> person" URI
>>>> could be practically usable as my OpenID, I came up with this  
>>>> corner-case:
>>>>
>>>> Could http://danbri.org be a URI for "me the person", and http://danbri.org/
>>>> be a document about me (and also serve as my OpenID)?
>>>>
>>>> As I understand HTTP, any client must request something, so the  
>>>> former isn't
>>>> directly de-referencable. The client has to decide to ask for / from
>>>> danbri.org instead. But they're still different URIs, aren't they?
>>>>
>>>> Is...
>>>>
>>>> <Person  xmlns:foaf="http://xmlns.com/foaf/0.1"/
>>>>         rdf:about="http://danbri.org">
>>>>  <openid>
>>>>    <Document rdf:about="http://danbri.org/"/>
>>>>  </openid>
>>>> </Person>
>>>>
>>>> ...at all feasible? I guess it depends on how exactly we think  
>>>> about the
>>>> "add a / to the end" step...
>>>>        
>>>      
>>>> From an RDF point of view the URI strings are different means that
>>>>        
>>> they can denote different things.
>>>
>>> I guess the question I have about this is: Why be so "clever"?
>>>      
>> I think I can answer that. Because people are. In fact, people use the  
>> same name for a person and the person's website and the person's name,  
>> etc., often without even noticing that they are doing it, and  
>> certainly without falling into instant incoherence or having their  
>> brains catch fire. But our inference engines can't handle this kind of  
>> ambiguity, at present. So it would be handy if a notational convention  
>> could be adopted that allowed the dumb machinery to keep its prissy  
>> distinctions distinct, while allowing human readers to be sloppy  
>> without even noticing that they are being sloppy. This idea is an  
>> elegant step in that direction, if it can be made to work.
>>    
>
> I agree that a *clear* notational convention would be helpful.   But I
> do *not* think that using subtly different URIs to distinguish between
> Dan and his web page is a wise design choice.   It is just inviting
> confusion and error.  The likely result is that *both* URIs would be
> used for both purposes, without the intended distinction.  I think it
> would be better to "ambiguously" use the same URI for both than to use
> two URIs that differ so subtly that even the HTTP protocol cannot
> distinguish them.
>  

What is "subtle" and "clear"? "x" differs from "x/" by one character. So
does "x" to "xy"?

With regard to Dan's proposal: the issue should be about if it will
damage the current practice of using "/" or existing protocol.  If not,
then by all means use the convention.  On the other hand, also by all
means to make people be aware of your intension what the "subtle"
syntactic different "clearly" means.

Xiaoshu