RE: 'Entity'

Hi Noah,

> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
> 
> David Booth writes:
> 
> > 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,
> 
> Hmm, really?  

Yes.  RFC2616 sec 1.3 defines 'entity' as:
http://www.ietf.org/rfc/rfc2616.txt
[[
entity
      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, as
      described in section 7.
]]

> You could be right, but it seems strange to me.  So, 
> consider the following two step example: 
> 
> 1) I do an HTTP PUT to http://example.com/someuri and include 
> in the PUT a 
> Content-Type and an entity body
> 2) I do an HTTP GET to the same URI, and it returns a 
> Content-Type and 
> entity body that are byte for byte the same as what was sent 
> with the PUT.
> 
> Let's further assume, if you like, that we know the fellow who runs 
> example.com, and he assures us that it's the nature of resources like 
> http://example.com/someuri that what you put is always what 
> you get;  they 
> don't have some other internal state that changes, except in 
> response to 
> PUTs, and what you get is always what you put.  Even in this 
> case, your 
> preferred terminology is:  what you sent was an entity, but not a 
> representation, what you received was a representation?  

Not quite.  That should be: what you sent was an rfc2616:Entity, but not *necessarily* an rfc2616:Representation, but what you received definitely was a rfc2616:Representation.   

> It's all 
> terminology and as long as we use it consistently I suppose 
> it's OK, 

I'm just trying to ensure that we are using these RFC2616 terms in the way that 2616 intended them.  

> but 
> it makes more sense to me to highlight the connection and to 
> use the word representation for both.

We're not just using the word "representation", we're talking specifically about rfc2616:Representation -- the notion defined in RFC 2616.  And *that* notion *only* pertains to responses, so it would be misleading at best to use the term in conjunction with a request.

David Booth

> 
> Noah
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> "Booth, David (HP Software - Boston)" <dbooth@hp.com>
> Sent by: public-awwsw-request@w3.org
> 01/06/2009 02:53 PM
>  
>         To:     Jonathan Rees <jar@creativecommons.org>
>         cc:     "public-awwsw@w3.org" <public-awwsw@w3.org>, 
> (bcc: Noah 
> Mendelsohn/Cambridge/IBM)
>         Subject:        RE: 'Entity'
> 
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 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:51:26 UTC