Response to comment on HTTP-in-RDF

Hi Jonathan,

thanks for reviewing the document(s) and commenting.

I'm refering to your comment "HTTP Vocabulary in RDF 1.0 - 'Entity' 
class request" 
(<http://lists.w3.org/Archives/Public/public-earl10-comments/2009Dec/0004.html>).

> I would like to suggest that the vocabulary include some treatment of
> HTTP entities. This would be useful in validating cache and proxy
> correctness, for example in accounting for the 'etag' header.

Would this be impossible with our current approach?

> It would
> also be useful to the TAG in some of its ontology work, and I believe
> in many other applications.

Our current approach tries to reflect the grammar structure of an HTTP 
message. The concept of Entity is somehow higher-level and not part of 
this grammar. So we did not yet consider to reflect it in our vocabulary.

> You could, for example, have an Entity class. Each Entity would have a
> subset of the information carried in some Message; there would have to
> be a property that related an Entity to a Message, similar to 'part
> of'.
> 
> The MessageHeaders of an Entity would only include entity-headers, not
> request-headers.
> 
> For minimum disruption to what you have so far Entity could be made a
> subclass of Message, which I think would be OK (i.e. an Entity is a
> Message that has no headers that are not entity-headers).

In section 4.1 (<http://www.w3.org/TR/HTTP-in-RDF/#graphs>) we require a 
Message resource to be related to one HTTP version. I think, an Entity 
resource should not have this requirement. So "Entity subClassOf 
Message" does not look very nice.

> A more
> principled approach would be to have a common superclass of Message
> and Entity, but I don't know what you'd call that class.

A Message is related to
* an Entity
* MessageHeader(s) that are no entity headers

An Entity is related to
* the payload
* MessageHeader(s) that are entity headers

That's better.

However, a creator tool must then have knowledge about which headers are 
to be considered entity headers and which not. It cannot just create the 
triples from the structure of an HTTP message as it could do with our 
current approach.

HTTP 1.1 Section 7.1 
(<http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.1>) lists 
10 entity headers, leaving room for more (extension-header). Neither RFC 
4229 (HTTP Header Field Registrations) nor the IANA registry for message 
header field names give any indication about which registered headers 
are entity headers.

> Probably many
> other designs are possible, such as having no common superclass and a
> disjoint suite of properties for the two.

What about the following approach? Make EntityHeader a subclass of 
MessageHeader. So a tool that claims some knowledge about which headers 
are entity headers can use EntityHeader for entity headers and 
MessageHeader for the rest. And you will have at least a minimal notion 
of an entity by putting together the payload (body property's object 
resource) and resource of type EntityHeader. A tool without this 
distinguishing knowledge could still just use MessageHeader.

-- 
Johannes Koch
Fraunhofer Institute for Applied Information Technology FIT
Web Compliance Center
Schloss Birlinghoven, D-53757 Sankt Augustin, Germany
Phone: +49-2241-142628    Fax: +49-2241-142065

Received on Wednesday, 3 March 2010 15:24:07 UTC