- From: Jonathan Rees <jar@creativecommons.org>
- Date: Tue, 6 Jan 2009 12:53:24 -0500
- 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 UTC