W3C home > Mailing lists > Public > public-awwsw@w3.org > January 2009

'Entity'

From: Jonathan Rees <jar@creativecommons.org>
Date: Tue, 6 Jan 2009 12:53:24 -0500
Message-Id: <6BF350ED-FCDF-4701-9D4D-3112ABCEA525@creativecommons.org>
To: David Booth <dbooth@hp.com>
Cc: public-awwsw@w3.org

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 17:54:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 6 January 2009 17:54:03 GMT