Re: Semantic Web Statement Contexts (was: Can there be a URI for the concepts "I", "you",...)

On 30 Dec 2006, at 16:39, John Black wrote:
> I'm not against current web architecture. If my prior comments  
> seemed to imply that then let this here now retract that implied  
> negativity.

Apologies, seems like I got you a bit wrong then.

(big snip)
> As I understand it, using a name to refer to a thing is not the  
> same as using a key to retrieve representations from a server.  
> Names are interpreted. URI's are used in an HTTP network to access  
> information. These are not the same. And the difference matters.

Yes, I agree up until here.

> When the same name reference might be interpreted differently  
> depending on the context of its use, it is ambiguous.

I say in this case it's not ambiguous, it's broken. If moving a URI  
into another context changes its referent, then the URI is useless  
because it cannot be used reliably to identify anything.

URIs are meant to be context independent. That's a huge feature. An  
approach that requires an additional piece of information beside the  
URI to account for the URI's referent is broken. Such an approach  
might have some benefits, but it loses one of the key properties of  
URIs, the fact that a URI *stands on its own*, globally.

> This is different, for example, from the situation where a server  
> has suffered an internal error that prevents it from returning the   
> representation requested. A "500 Internal Server Error" message is  
> not one of several possible interpretations of what the URI refers  
> to. So it does not disambiguate a name reference.
> Instead, it reports the result of an operation. And that operation  
> is fundamentally different from interpreting the reference of a  
> name. Likewise with all the other HTTP operation return codes. None  
> of them are alternative interpretations of what the URI refers to.

You ignore one important thing. While reference (naming) and access  
are two different functions of a URI, they are related in a well- 
defined way.

There are exactly three different possibilities how naming and access  
can be related for a URI.

1. Pure names. They name something, but don't access anything.  
Examples include HTTP URIs that return 404, tag: URIs, URN namespaces  
without a resolution mechanism.

2. URLs. They name what they access. Examples include all traditional  
web page URLs, and all HTTP URIs that return 200.

3. The third kind, which doesn't have a real name yet. (Max Völkel  
has proposed URR, for Uniform Resource Reference). These URIs name  
one thing, but access another thing, and that other thing should be  
useful in establishing what the URR names. Examples include all HTTP  
URIs that return 303 (the "other thing" is the redirection target),  
hash URIs (the "other thing" is the part before the hash), and URN  
namespaces with a resolution mechanism (the "other thing" is what the  
URN resolves to).

Your (and Pat's) position seems to be that the relation between  
naming and access is arbitrary. I have trouble understanding why you  
would want to take that position. You lose the ability to use the Web  
as a "lookup mechanism" that can help to establish what is named by a  
URI. Again, I think that this is one of the key benefits of the  
SemWeb architecture, and I don't understand why you would want to  
give it up.

> In the classic example of what led to the httpRange-14 solution,  
> http://kashori.com/JohnBlack could, and probably has been used in  
> RDF to refer to me, the person, and also, to my home web page. As a  
> name, then, it is ambiguous, as it might reasonably be interpreted  
> to refer to either one.

Again, this is only the case if you assume that the relation between  
naming and access is arbitrary. It is not.

In a post-httpRange-14 world, the return code limits what the URI can  
possibly name. Thus, if a 200 OK is returned, the URI cannot name a  
person. Thus, the ambiguity is resolved.

> I have never heard it suggested, however, that http://kashori.com/ 
> JohnBlack was ambiguous because it could be interpreted to refer  
> either to the web page, on the one hand, or to a "500 Internal  
> Server Error" message on the other hand. Nor are any of the other  
> HTTP operation result code messages possible interpretations of  
> what that URI refers to when used as a name.

This has never been suggested because HTTP clients obey status codes.

200 means the URI names the returned thing.
500 means you cannot assume that the URI names the returned thing.

This has always been the case. Post-httpRange-14, we have another rule:

303 means the URI does not name the returned thing, and the URI's  
referent is described in the redirection target.

It's quite a simple architecture actually, with a pretty clear method  
of establishing reference. It works. I don't understand why you  
insist on claiming that it doesn't.

Richard


>
>>> I came up with the following suggestions that I
>>> hope further illustrate Pat's point about this being a category
>>> mistake.
>>>
>>> 1. For distinguishing URI that refer to things that do not actually
>>> exist, dead presidents, extinct species, and unicorns, for example,
>>> first return a "404 Not Found" code, then if the client requests the
>>> same URI within 0.5 seconds, return a document describing the
>>> non-existent thing.
>>>
>>> 2. For URI that refer to things that are bad for you, such as
>>> cigarettes and high fat foods, return a "403 Forbidden" code and
>>> then if they repeat the request, a document about that thing.
>> The examples are entertaining (May I suggest the addition of a  
>> "207  Sarcasm" status code to HTTP?), but are different from the   
>> httpRange-14 case in an important way: They do not deal with a   
>> distinction that is relevant to the problem at hand -- the  
>> transfer  of representations of resources over a network.
>> The "303 for non-information resources" practice deals with a   
>> question that *is* somewhat relevant to the problem: Can all the   
>> essential characteristics of this resource be encoded in a  
>> message  that we can send over the network?
>> Your suggested "404 for unicorns" practice deals with a question  
>> that  is *not* relevant to the problem. For the problem of  
>> transferring  resource representations over a network, unicorns  
>> are no different  from horses.
>> (Is the distinction between information resources and non- 
>> information  resources *important* for the problem of  
>> transferring  representations? That's another question altogether,  
>> and I'm not  convinced either way. I'm just saying that the 303  
>> distinction is in  the problem domain, while your suggested  
>> distinctions are not, and  therefore I feel they don't back up  
>> Pat's point.)
>> And anyway it should be 410 for dead presidents, not 404. Please  
>> be  precise in your jokes.
>> ;-)
>> Richard
>>> 1. http://www.w3.org/TR/rdf-mt/
>>> 2. http://www.ibiblio.org/hhalpin/irw2006/
>>> 3. http://www.ibiblio.org/hhalpin/irw2006/presentations/  
>>> HayesSlides.pdf
>>>
>>>
>>> John Black
>>> www.kashori.com
>>>
>>>
>>>>
>>>>    -- Sandro
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>
>

Received on Monday, 1 January 2007 16:09:50 UTC