Re: Uniform access to descriptions

>>>If I don't know what is an IR, how do I judge what it isn't?  This 
>>>is essentially what Tim responded to my question.  He said: well 
>>>!IR <> non-IR.  Then, what is the intersection of IR and non-IR. 
>>>This is not an answer, this is to avoid answer and then it is 
>>>useless, don't you think so?
>>
>>No. The world is full of cases of concepts which have clear 
>>examples and non-examples but which are very hard to specify near 
>>their edges, so very hard to give exact definitions for. Colors are 
>>the often-cited canonical example. There are reds which everyone 
>>will agree are red and blues which everyone will agree are 
>>non-reds, but near the red/orange boundary nobody will agree, even 
>>with themselves from day to day. Natural concepts often resist 
>>precise definitions. That doesn't stop them being extremely useful, 
>>however.
>Pat, I see the problem now.  We agree on that there is no clear 
>distinction for IR.  So, let's don't argue in that direction.
>
>My question is very clear and precise.  Do you agree to invoke such 
>logic in the web.
>
>If HTTP(x)=200, x=IR
>If HTTP(x)=303, x=?
>
>Here is the multiple choice
>(1): Yes.   (1a) The distinction between 200-303 is important. 
>(Then, it is you who is trying to make a clear distinction, not me.)
>   (1b) The relationship between 303 and 200 is not important. 
>Hence, 200 and 303 becomes irrelevant and therefore httpRange-14.
>
>(2).  No.  then, any discussion between 200 and 303 is moot and 
>therefore httpRange-14.
>
>Tell me your position.  My position is very clear - that is (2). 
>Otherwise, I don't know if you are defending for or against my 
>position.

OK, I will have to go for 1a, then. I wish I didn't have to, and I 
don't like it, but I see no other feasible choice at present. If 
someone comes up with one I'll be delighted to hear it. If the 
Semantic Web were smart enough to handle URI ambiguity the way that 
human language handles lexical ambiguity, there would be no problem; 
but right now it isn't, and it probably won't be for some time to 
come. So we have to do something simpler and cruder.

But I think you have focused on the wrong end of the transaction. The 
issue is not so much that the code sends a message to the user of the 
URI, but rather that the thing that responds to the URI GET must do 
something. It must somehow distinguish between the case where it, or 
maybe what it sends back, is what the URI denotes, and other cases. 
And in those other cases, there have to be two URIs involved somehow, 
because the the responding thing is indeed a resource which can be 
given a URI, and that URI has to be different from the URI we are 
talking about here, which denotes something else. If I sit down and 
try to pretend to be this poor responding thing, I'm at a loss to see 
what I can do when I get sent the first URI, other than send it 
somewhere else.

As for the distinction being clear: I don't accept that we have to 
get it nailed down exactly, with a perfect definition, before using 
it. The exemplar cases are clear enough for it to be useful.

Pat

-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections