RE: 'Entity'

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?  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?  It's all 
terminology and as long as we use it consistently I suppose it's OK, but 
it makes more sense to me to highlight the connection and to use the word 
representation for both.

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

Received on Wednesday, 7 January 2009 15:37:33 UTC