W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: Uniform access to descriptions

From: Dan Brickley <danbri@danbri.org>
Date: Wed, 09 Apr 2008 08:58:31 +0100
Message-ID: <47FC7727.8050205@danbri.org>
To: Pat Hayes <phayes@ihmc.us>
Cc: wangxiao@musc.edu, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Phil Archer <parcher@icra.org>


Hi Pat,

Pat Hayes wrote:
> At 7:52 PM +0100 4/8/08, Xiaoshu Wang wrote:
>> Pat Hayes wrote:
>>> At 5:54 PM +0100 4/8/08, Xiaoshu Wang wrote:
>>>> Stuart,
>>>>> Wrt to that resolution... a 303 response means *nothing*... if you 
>>>>> happen to follow the redirection and find something useful about 
>>>>> the thing you originally inquired of, that you trust and are 
>>>>> prepared to stick in your reasoning engine, then you win - if not, 
>>>>> of itself, the redirection has told you nothing/means nothing.
>>>>>
>>>>> 200 tells you that the response convey as representation of the 
>>>>> (state of?) referenced thing.
>>>>>  
>>>> If this is what TAG accepts, i..e, 200=*representation of* as 
>>>> oppose to "resource of".  I have no problem and would be happy with 
>>>> it.  My perception is that TAG is recommending either explicitly or 
>>>> implicitly the latter viewpoint.
>>>
>>> Gentlemen, please both of you speak very slowly and carefully at 
>>> this point, as a precise understanding here is critical.
>>>
>>> Stuart, did you mean that the response conveys/ a/ representation/ 
>>> in the webarch sense/ of the referenced thing? It would be helpful 
>>> if every time the word 'represent' and its cognates are used in this 
>>> very special sense, such usage were explicitly flagged, as it can 
>>> very quickly lead to incomprehension when understood more broadly 
>>> (as it is almost everywhere else in the English-speaking world.)
>>>
>>> (Xiaoshu: from which it follows that in this case, the referenced 
>>> thing in question must be something that/ has/ a 
>>> webarch-representation; so, in this case, it/ cannot/ be some other 
>>> kind of thing that cannot, by virtue of its very nature, have such a 
>>> (webarch-)representation; so, to refer to such things - such, as we 
>>> now might say,/ non-information resource things/ - requires 
>>> something other than a 200 response. Thus goes the http-range-14 
>>> logic, as I understand it. Note that in order to follow this, all we 
>>> need to know is that there are things which (a) cannot have a 
>>> representation in the webarch sense but (b) that we might wish to 
>>> refer to with a URI. 
(aside: perhaps 'http(s) URI' was meant here, rather than just 'URI'?)
>>> Their exact nature need not be specified, but I believe that the 
>>> language of 'information resource' boils down to  an attempt to 
>>> characterize this category of [/things that cannot be 
>>> webarch-represented by a byte stream/]. And, centrally important, 
>>> not having a representation in the webarch sense does/ not/ mean not 
>>> having any kind of representation, being unrepresentable, or not 
>>> being describable. The webarch sense of 'representation' is very 
>>> specialized and narrow.)
>> Pat, as I have detailed argued here 
>> http://dfdf.inesc-id.pt/tr/web-arch.  There can have only one 
>> consistent interpretation, that is: there is no so-called 
>> "information resource". 
>
> The key issue is not what is an information resource, but what isn't. 
> So, in your document you ask, what makes the claim "A person is not an 
> information resource" true? And it seems to me that this at least has 
> a clear answer: because a person is/ not/ something whose essential 
> characteristics can be conveyed in a message.
I don't know what 'essential characteristics' are. Really. What are the 
(erm...) characteristics of the 'essential characteristics' of some 
[named type of] thing? Who gets to decide?

Are you saying that this is actually clear, or 'clear within the world 
of the http-range-14 resolution'?

cheers,

Dan

--
http://danbri.org/
Received on Wednesday, 9 April 2008 07:59:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:55 GMT