Re: Resources and representations (was RE: Subgroup to handle semantics of HTTP etc?)

Williams, Stuart (HP Labs, Bristol) wrote:
> Hello Xiaoshu,
>
>   
>> -----Original Message-----
>> From: Xiaoshu Wang [mailto:wangxiao@musc.edu] 
>> Sent: 23 October 2007 16:06
>> To: Williams, Stuart (HP Labs, Bristol)
>> Subject: Re: Subgroup to handle semantics of HTTP etc?
>>     
>
> <snip/>
>
>   
>>> Well... I observe that you persist in wanting to speak of 
>>> representations as resources.
>>>   
>>>       
>> Well, I am a bit confused.  In the eye of semantic web, isn't 
>> everything in the world an rdf:Resource?  Isn't 
>> representation part of this world too? 
>>     
>
> Well, you don't get them as resources for free. You can certainly speak
> of them, maybe using b-nodes.
>
> I know that you get that (information) resource access is different from
> the representation returned.
>
> That the representation can be referred to:
>
> _:b a webarch:Representation;
>     webarch:validFrom	"20071023Z17:39:00"^^xsd:dateTime ;
>     webarch:hasMimeType ... ;  
>     webarch:representationOf http://example.com/aResource .
>
> would seem to qualify it as a resource.
>
> However, I guess what I'm objecting to is that you seem to me to slip
> into speaking of the representation that you obtained from a given
> resource as being that resource.
>   
Yes, that is the point that I was trying to make.  The bit-stream 
manipulated by my browser is not the thing identified by the URI, it is 
a representation of it.  At most, it is a copy of it but this is hardly 
to know just from the representation alone.
>>> Well is suppose that you can conceive of an inverse... and depending
>>>       
>
>   
>>> on whether you regard a representation as a particular message (in 
>>> which case it arises because of an access attempt using a URI) or as
>>>       
> a 
>   
>>> type for all messages that carry the specific sequence of 
>>> bits/bytes... may or may not be functional, respectively.
>>>   
>>>       
>> We don't differ here.
>>     
>>>> httpRange-14 trying to force the issue.  
>>>>     
>>>>         
>>> No... at the most, the TAG's httpRange-14 resolution:
>>>
>>> a) seeks to avoid ambiguity of reference between a thing and a 
>>> description/depiction of a thing.
>>>   
>>>       
>> That is where the problem is.  A URI denotes a thing but 
>> *never* the description of that thing.  The *representation* 
>> returned by the server is a description of that thing.
>>     
>
> The way I have come to square this is that there resources which are
> descriptive in nature eg. some RDF description of a thing (or things),
> or some HTML description of a thing (or things). That description (or
> depiction) is a separate resource from the thing described and deserving
> of its own URI. You can GET representations of a descriptions (or a
> depicition) but those are *not* representations of the
> described/depicted thing.
>   
Then there are two kinds of things now.  One is *description*, the 
other, let's call it, *subject*.  You have one URI, you choose one to 
denote either the *description* or the *subject*.  You cannot denote 
both, right? 
> Now a question arises (and we have been there, along this path - search
> for Partick Sticklers dog or Dan's car) as to whether a representation
> of description can also serve as a representation of the described
> thing. The TAG's httpRange-14 resolution does advise *not* to do that in
> the case of things such as people, places, celestial bodies, physical
> artifacts... use either '#' based client side indirection or 303
> protocol indirection to a resource that describes (possibly amongst
> other things) the thing of interest.
>   
The httpRange-14 is asked on a wrong assumption that a URI can denote 
both a subject and its description. But, it cannot. 
 
>> When people think that 
>> "http://www.ihmc.us/users/phayes/PatHayes" should NOT denote 
>> Pat Hayes because they have confused the returned
>> *representation* as the *resource* denoted by that URI.
>>     
>
> No... its because they have confused the descriptive document(resource)
> that the representation is a representation of with the stated referent
> - or at least find the state of affairs inconsistent.
>   
Why they get confused the "http://www.ihmc.us/users/phayes/PatHayes" as 
descriptive document? Who said that? Pat certainly does not.  is it 
because its *representation* is parsed in an HTML browser instead of a 
hologram? What I was trying to say in the past few days are, you cannot 
infer the nature of *a resource* from the nature of *its 
representation*.  You must read the message and see what it says.
>>> b) leave the range of what can be referenced by an http: URI sans 
>>> fragment, unconstrained.
>>>   
>>>       
>> This becomes non-issue if we straighten out (a), yes?
>>     
>
> Well... it becomes a non-issue for those that regard a representation of
> a depiction of a thing as an adequate representation of that thing (for
> whom a representation of a depiction of a dog is an adequate
> representation of that dog). But there are several around for whom that
> is *not* the case.
>
> Careful assignment of URIs can be arranged so that on can speak
> separately about say, a dog, and its depiction (for example they likely
> have different dc:creators).
>   
The word *adequate* just goes back to the *essential characteristics*, I 
hope we all drop this once for all. We cannot tell objectively which 
case is adequate and which are not.  Let's drop them and treat every 
resource in the same way.
> There remains the question/issue for some as to whether web based
> interaction with the resource actually involve interaction with the
> resource (search for Pat's missives on distant galaxies as resources -
> clearly one would be waiting lengthy periods of time for reponses to
> GETs and what on earth would one expect to become of a PUT or a POST).
> Both the 303 and the '#' approach acknowledge the absurdity that would
> otherwise arise (except in the case of carefully crafted scenarios aimed
> at scoring points) if people and places and distant galaxies were 'on
> the web' in the sense being concieved as networked informatio objects.
> They are not 'on the web' in a networked communicative sense - but they
> can be referred to from the web.
>
>
>   
>>> c) provide a sufficient mechanism for those that care about the 
>>> difference to determine that an information resource has been 
>>> referenced.
>>>
>>> [btw: b) comes at the cost of c)]
>>>   
>>>       
>> (c) is 303? If (a) is clarified, is 303 becomes unnecessary.
>>     
>
> c) is 303 or '#'.
>   
If we have a unified view, this is no longer issue. URI is URI slash or 
#.  All behave the same.
>   
>>> None of this tells you what any given resource is - what a give 
>>> reference actually denotes.
>>>   
>>>       
>> Doesn't httpRange-14 implies this.  If 200, it is an 
>> information resource?  This is what starts off this thread.  
>> Tim, requested by Jonahan and Alan, asked if any triple can 
>> be derived from HTTP response. 
>>     
>
> Well, no... 303 doesn't tell you what particular individual the resource
> is. It doesn't tell you that it's the current weather forecast in
> Bristol, or a house in a surrounding village, or a person, or a dog
> or... well anything at all really. At best its says you *may* find
> something usefully descriptive over there (an then again you might not -
> after all this is the web... and inconsistency is a fact of life).
>   
A representation is by nature descriptive, right?  Why do I need a 
*representation* of a *descriptive thing* to describe a thing at the 
first place?
> <snip/>
>
>   
>>>> Why cannot. Assuming your past few email is posted to my website, 
>>>> wouldn't it possibly change the state of my mind?
>>>>     
>>>>         
>>> But... can you convey your "state of mind" before and after our 
>>> exchange in a message? :-)
>>>   
>>>       
>> But isn't this just a matter of implementation detail?
>>     
>
> I don't know... is the current state of you mind expressible in a
> message?
>   
Of course not all of it but part of it, can't you tell?

Regards,

Xiaoshu

Received on Tuesday, 23 October 2007 18:55:43 UTC