Re: 'Entity'

On Jan 6, 2009, at 2:53 PM, Booth, David (HP Software - Boston) wrote:

> Hi Jonathan,
>
> Actually what I was trying to bring out was the difference between  
> rfc2616:Representation and rfc2616:Entity, which is direction: an  
> rfc2616:Representation is only in a *response*, while an  
> rfc2616:Entity may either be in a request or in a response, so  
> rfc2616:Representation is a subclass of rfc2616:Entity.  I am fine  
> with your interpretation of rfc2616:Entity below, but I think it is  
> useful to distinguish between these classes because they are used  
> differently.

Oh good. I will clarify this in the vocabulary file then.

> Off hand I do not know whether class rfc2616:Entity has the same  
> members as class rfc2616:Representation.   Perhaps it does, but I  
> think I would want to see appropriate evidence before assuming that  
> it does.

I have read through RFC 2616 and I couldn't determine whether all  
entities in 200 responses were representations (i.e. "subject to CN"),  
or only if some of them were. I would like to think that if the RFC  
had meant for "representation" to mean any entity delivered in a 200  
then it would have said as much, but as far as I'm concerned we're  
totally in the dark on this question. I also wanted to stay entirely  
away from the word "representation" since it has caused so much  
suffering.

> In our discussion of the "comes from" property
> http://esw.w3.org/topic/AwwswVocabulary
> I was trying to point out that the domain of "comes from" is  
> currently defined as rfc2616:Entity in the wiki, but I think it  
> would be more precise to change it to rfc2616:Representation,  
> because rfc2616:Representations are the only kind of  
> rfc2616:Entities to which the "comes from" relation applies: the  
> "comes from" relation can only apply to an rfc2616:Entity e if e is  
> also an rfc2616:Representation.

Well, if you have any property P with rdfs:domain D and rdfs:range R,  
there may be elements of D or R that are not P-related to elements of  
R or D. You can always define D' = the subclass of D for which there x  
in D' implies the existence of y in R such that x P y, and similarly  
for R'. So here I think you are saying that rfc2616:Representation is  
the smallest subclass of rfc2616:Entity that is an rdfs:domain of  
comes-from. That's OK, although I don't think this is what RFC 2616  
actually says, so I would apply a different label to this class.

Are the entities in 404 responses subject to CN? I don't know. If so,  
then such entities might not "come from" according to my definition,  
since I want to restrict "comes from" to the situation where someone  
has done a GET and the response is a 200. So perhaps your  
rfc2616:Representation is a superclass of smallest-domain-of-comes- 
from, as the former would include 404 entities and the latter might not.

In general we have:
rfc2616:Entity = entity-headers + entity-body  (noncontingent)
dbooth:Representation = subclass of rfc2616:Entity consisting of those  
entities that come-from some web resource (or: are transferred in a  
response?).  An Entity starts out life by not being a Representation,  
but as soon as it is transferred in a response (or 200 response) then  
it becomes one.

We could also have another subclass of Entity, those that have occured  
in PUT requests (smallest domain of "goes to").

You say that these subclasses of Entity are important. I have no real  
objection but I would like to know why. I would think that any time  
you would be tempted to say that an entity belongs to the smaller  
class, you would be just as happy to say what it is that defines that  
smaller class (that the Entity comes from some Web resource, that it's  
subject to CN, etc.), or to allow membership in the smaller class to  
be inferred from the fact that it is involved in some relation (which  
has particular domain or range, etc.).

-Jonathan

> 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.
>
>
>> -----Original Message-----
>> From: Jonathan Rees [mailto:jar@creativecommons.org]
>> Sent: Tuesday, January 06, 2009 12:53 PM
>> To: Booth, David (HP Software - Boston)
>> Cc: public-awwsw@w3.org
>> Subject: 'Entity'
>>
>> One confusion we were having today had to do with whether RFC 2616
>> "entities" are purely syntactic, vs. historically contingent.
>> http://esw.w3.org/topic/AwwswVocabulary
>>  says:
>>
>> Entity: Definition: The information transferred as the payload of a
>> request or response. An entity consists of metainformation in
>> the form
>> of entity-header fields and content in the form of an entity-body.
>>
>> Just to be clear, I did not take the first sentence as
>> constraining -
>> that every entity had to be a payload of some request or response in
>> order to be an entity. Rather, I took the second sentence as
>> defining
>> - something can be an entity even if it is never transferred.
>> It never
>> occurred to me that the term 'entity' should be restricted to only
>> those syntactic things that were actually transferred. I read the
>> first sentence as "The information transferred as the payload of a
>> request or response *is an entity*" not "An entity is
>> [defined to be]
>> the information transferred as the payload of a request or response."
>>
>> Your interpretation, I think, was that something never transferred
>> could not be an entity. E.g. if I am a web server and compose
>> an HTTP
>> response, and then put the response onto my network
>> controller, but it
>> doesn't get transferred to any receiver (maybe because my network
>> cable isn't plugged in), then the entity-body and
>> entity-header fields
>> do *not* constitute an entity, because no transfer occurred. I admit
>> that this is a plausible reading.
>>
>> We could have two separate classes if both notions are
>> needed. However
>> the only one I care about is the noncontingent one, since the
>> historical contingency is both untestable and inconsequential.
>>
>> I can create a new class for noncontingent things, but it would be
>> simpler if we all agreed to read the RFC 2616 definition as I
>> read it
>> - in particular we wouldn't have to agonize over labels. If you want
>> to keep rfc2616:Entity as requiring that the information actually be
>> transferred via HTTP, then I guess we'll need two classes with two
>> names/labels (or sets of labels). (Later, any unused class could be
>> removed from the ontology.)
>>
>> Alternatively I can clarify that what's meant is the class of
>> noncontingent things, but remove the implication that the definition
>> is taken directly from RFC 2616.
>>
>> What is your pleasure?
>>
>> Jonathan
>>
>>

Received on Tuesday, 6 January 2009 20:56:34 UTC