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 Tuesday, 6 January 2009 19:55:14 UTC