RE: 'Entity'

More below . . . 

> From: Jonathan Rees [mailto:jar@creativecommons.org] 
> 
> 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"),  

Again, I think you're misreading the intent of the RFC2616 definition of "representation", which is:
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).
]]

> 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.

I don't think we can avoid it, since it is in important term in rfc2616 and in AWWW.  However, we definitely should be careful to qualify the term when we use it, such as rfc2616:Representation.

> 
> > 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.

I'm not claiming that it is the absolute smallest subclass.  I do not think it is usually useful to define the domain that way.  But it is useful to define the domain to be the smallest *conveniently* defined subclass, and that's what rfc2616:Representation is.  It is true that 2616 does not use the word "representation" in its description of GET in sec 9.3
http://www.ietf.org/rfc/rfc2616.txt
but it *does* refer to "the entity in the response", and since we know from the definition of rfc2616:Representation that (a) it is an entity and (b) it is in the response, and we know that all responses are subject to content negotiation, then it seems quite clear to me that the "entity in the response" is in fact an rfc2616:Representation.  What on earth would an rfc2616:Representation be if it were not this?

> 
> Are the entities in 404 responses subject to CN? I don't 
> know. 

Yes, defintely.  See the above quoted definition of 'content negotiation'.

> 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.

Correct.

> 
> 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.

Whoa!  I'm not proposing any class dbooth:Representation.  I am talking about rfc2616:Representation.

> 
> 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.).

Class rfc2616;Representation is important because it is a notion defined and used in RFC2616 *and* AWWW has a notion of 'representation'.  It would clearly be helpful if we could eventually relate the AWWW notion of 'representation' to the 2616 notion, as an underpinning.

David Booth


> 
> -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
> >>
> >>
> 
> 



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 16:39:00 UTC