RE: 'Entity'

More below . . .

> From: Jonathan Rees [mailto:jar@creativecommons.org] 
> 
> On Jan 7, 2009, at 11:37 AM, Booth, David (HP Software - 
> Boston) wrote:
> > http://www.ietf.org/rfc/rfc2616.txt sec 1.3
> > [[
> > representation
> >      An entity included with a response that is subject to content
> >      negotiation, as described in section 12. There may 
> >      exist multiple
> >      representations associated with a particular response status.
> > ]]
> > However, even with your reading, the definition of 'content  
> > negotiation' makes clear that any response can use content  
> > negotiation:
> > http://www.ietf.org/rfc/rfc2616.txt sec 1.3
> > [[
> > content negotiation
> >      The mechanism for selecting the appropriate representation when
> >      servicing a request, as described in section 12. The
> >      representation of entities in any response can be negotiated
> >      (including error responses).
> > ]]
> 
> OK, you are right.
> 
> But the following question is still not answered to my satisfaction:
> 
> - Are there any responses that are *not* subject to content  
> negotiation? That is, is an entity in a response always a  
> representation?
> 
> The definition of CN only says that the representation *can be*  
> negotiated, not that it always is (which is what the definition of  
> "representation" requires). Why would the definition of  
> "representation" say "a response that is subject to CN" unless there  
> were responses that were NOT subject to CN?

To emphasize that the relationship between rfc2616:Representation and rfc2616:Resource is many to one (because of content negotiation) even for an rfc2616:Resource that is static.

There is no observable difference between a server that does not perform content negotiation and a server that performs content negotiation but always produces the same response, so I don't see any utility in trying to distinguish rfc2616:Resources that produce response using content negotiation from those that do not.

> 
> Related to this is the question of whether there are any responses  
> that are not transferred. That is, are 'response' and 
> 'representation'  
> syntactic notions, as we have taken 'entity' to be, or are 
> they roles  
> in a process (the process where a server forms a response and sends  
> it, and the response is received by client)? In the case of 
> 'response'  
> at least I believe the English word is overloaded in RFC 
> 2616, and we  
> may need distinct terms for the two cases.

Surely an rfc2616:Response is a kind of english:response, which to my mind is universally understood as being in response to some stimulus.  It would seem awfully contrived to me to read the notion of rfc2616:Response as *not* necessarily being in reply to a request.

What this means to me is that the existence of an rfc2616:Response implies the existence of a corresponding rfc2616:Request.  If a server tries to send a "response" that is *not* a reply to a request, then it is not following the RFC 2616 protocol.

> 
> I hadn't expected that there were things that were 
> representations in  
> the RFC 2616 sense but not in the AWWW sense, but that appears to be  
> the case (content-negotiated 404 responses that are not  
> awww:representations of anything, for example). Neither class (or  
> role) is a subclass (subrole?) of the other.

RFC 2616 does seem to use the term 'respresentation' both for successful GETs and for errors, whereas awww:Representation seems to exclude error cases, so in that sense rfc2616:Representation may have members that are not awww:Representations.  This is unfortunate, but it does still seem plausible to me that rfc2616:Representations for *successful* GETs correspond to awww:Representations in the case of HTTP.  (The notion of awww:Representation presumably encompases more than just HTTP.)

> 
> The idea that "representation" is not a class but rather something  
> else such as a role (whatever that is) or property has been raised  
> here many times. That concern is yet another reason why I am 
> reluctant  
> to define a rfc2616:Representation class, and prefer to rely on  
> properties such as "comes from" or "part of" (entity is part-of  
> response) or "negotiates content" or "represents" instead. In each  
> case we would simply derive "representation" (or whatever 
> other class)  
> as the class of things that participate in the property, 
> which can be  
> done easily using a someValuesFrom restriction.

To my mind, in terms of capturing this stuff in RDF, the fact that RFC 2616's notion of "representation" is a role just means that if a member of that class exists then there must have been a request that prompted it: an rfc2616:Representation cannot exist without a corresponding rfc2616:Request.

> 
> I think that we have already agreed that RF 2616 was not designed to  
> be an ontology and that we are likely to get tangled up if we 
> take its  
> noun phrases to be classes and verbs to be properties.

Yes, I think that is part of the problem we are running into.

> 
> A tactic I have found helpful in understanding what axioms 
> and classes  
> are needed is to consider the model theory. If a model exists 
> in which  
> e.g. every representation is an entity and vice versa, then 
> it is not  
> very helpful to have both classes. In order to eliminate such models  
> you need to have sufficient axioms to force the classes apart. In  
> order to have sufficient axioms, you need to figure them out 
> and write  
> them down. That's what I mean when I say some term is  
> "inconsequential" - the term may be interpreted differently 
> from other  
> terms in some models, but if no evidence of the distinction is  
> *entailed* (true in every model) then there's not much reason to  
> introduce the term. Well, maybe as a placeholder, to make a 
> note that  
> there is something we don't know or refuse to take a stand on, but  
> then we need to be pretty explicit about what we're doing.

A specific case in point would help me understand what you mean.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

Received on Wednesday, 7 January 2009 19:42:46 UTC