Re: 'Entity'

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?

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.

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.

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.

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.

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.

Jonathan

Received on Wednesday, 7 January 2009 17:42:53 UTC