Re: Uniform access to descriptions

Pat Hayes wrote:
> At 2:26 PM +0100 4/11/08, Xiaoshu Wang wrote:
>> wrote:
>>> Xiaoshu Wang writes:
>>>> HTTP protocol is a transportation protocol.
>>>> Hence, the semantics of HTTP should be ALL about delivering message 
>>>> and its parsing and it should have nothing to do with judging its 
>>>> content.   
>>> Hmm.  I would have said that HTTP is an application-level protocol. 
>>> Otherwise, why distinguish PUT from POST or DELETE?  What they 
>>> transport isn't much different, except that with delete there is 
>>> seldom need for much information beyond the identifier of the 
>>> resource.  If it were just a transportation protocol, then all we 
>>> would need is well typed messages, and we could encode operations in 
>>> those messages if we wished to.  I'm not sure I'd use your phrase 
>>> "judging its content", but HTTP operations are applied to Web 
>>> resources, and the status codes properly reflect information about 
>>> that interaction.  The fact that certain operations cannot be 
>>> successfully performed on certain classes of resources, and that the 
>>> status codes therefore (if properly used) allow one at times to 
>>> infer information about the nature of the resources, all seem fine 
>>> to me.  If we were talking about TCP, I would for the most part 
>>> agree with you.
>> I think this is the essential issue of all argument is.
> I agree.
>>  As Stuart warned me not to loop the concepts again and again.  Let's 
>> reformulate the argument into a multiple choice question.
>> Question 1: Is there a difference between Representation and Resource?
> Um... it depends what you mean. They are different/ concepts/ 
> (categories, classes, properties), to be sure, since there are may 
> resources that aren't representations (and IMO - though others may 
> differ - there are also representations which aren't resources). But 
> they need not be exclusive: something can be both a representation and 
> a resource. In fact, it is exactly these cases which seem to give us 
> the most trouble in this exchange. For example, a home page is a 
> resource but it might also be reasonably called a representation of 
> the person it describes. (I'm assuming here that 'representation' is 
> being used in a broad sense, not as awww:representation.)
The definition of /representation/ is very precise and clear.  It is 
whatever the stuff (within the web, it is a byte-stream) that eventually 
reaches to the client.  I think you perhaps have though it as 
something-else? Is this the case, because otherwise I cannot follow your 

>> (1a): Yes.  Representation -> Resource; (here let's name "->" as 
>> identify).
> If we are using 'identify' in the TAG sense, then its usually URI's 
> that are at the blunt end of the arrow, not representations. But 
> perhaps you are using the word in a different sense, something more 
> like 'represents' (?) In which case, I agree, a representation 
> represents a resource.
>> (1b): No.  Representation = Resource.
> Well, a representation of resource A can itself/ be/ a resource, 
> though maybe it can't be A itself. (Can we have a self-representing 
> representation? There's no formal reason why not, eg an RDF plain 
> literal could be described this way. On the other hand, some 
> semiologists - notably Umberto Eco - insist that this is impossible. 
> Interesting, if arcane, debate.)
>> Question 2: Can one resource has multiple Representation?
> Yes.
>> (2a) Yes.  So Representation -> Resource but Representation != Resource.
> See above.
>> (2b) No.  (Then explain or drop Conneg)
>> Question 3: What does a URI denote?
> A thing. Or, if you prefer the older terminology, a resource.
>> (3a): Resource.
>> (3b): Representation
>> (3c): Both.
> I'd have to say both, since the categories aren't exclusive.
>> Question 4: Is an HTTP-URI =  HTTP+URI?
> I have no idea what this means.
>> (4a): No.  (Hence, HTTP-URI = Resource, HTTP+URI = Representation.)
>> (4b): Yes.
>> My answer is all (a), which is consistent and without any ambiguity.  
>> If someone propose any model other than (a), then find a model to 
>> make them all consistent.  It is their burden to model it 
>> consistently, not mime.
> Well, here's my, er, model.
> URIs are names, which/ denote/ things.
> URIs also/ indicate/ resources, usually via http: that is, the URI 
> when 'bound to' the Web with a GET starts up a process which returns 
> something via a byte stream. The thing which does the returning is 
> called a 'resource' and the thing returned is called the 
> awww:'representation' of that resource.
> There are also representations (of various kinds, but not 
> awww:representations) which represent (describe, picture, ...) the 
> thing(s) they are representations/ of/. One kind of representation is 
> a formal description (typically an RDF graph) which uses URIs as names 
> to refer to whatever they denote. Some resources are representations 
> in this sense (not in the awww sense.)
> All of the following are things which can be named by URIs: resources, 
> descriptions, RDF graphs.
> The content of http-range-14 can be summarized: when a URI/ indicates/ 
> a resource, then it should be also understood to also/ denote/ that 
> resource. The importance of the 200 code is then simply to indicate 
> that it was indeed the first supplied URI in the http transaction that 
> did the indicating of whatever produces the final result (and not, for 
> example, some other URI it redirected to.)
> Make sense?
> Pat
>> All other questions, such as what is the meaning of "description" 
>> should be answered based on the answers of the above four questions.  
>> I think they summarize different attitudes toward the architecture of 
>> the web.
>> Xiaoshu
>> Let's settle this first and then with some terminology.
>> Xiaoshu
> -- 
> ---------------------------------------------------------------------
> 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

Received on Friday, 11 April 2008 23:58:37 UTC