Proposed Responses to AWWSW comments on HTTP-in-RDF

Hi group,

here are some


Proposed Responses to AWWSW comments on HTTP-in-RDF 
(<http://esw.w3.org/topic/AwwswHttpVocabularyInRdfComments>)

> Headers

In fact we thought about this before, but decided not to do it.

1. Some of the headers used in HTTP are defined in HTTP/1.1 (RFC 2616), 
while quite a lot of them are not. So we created a seperate model with 
the header names (http://www.w3.org/2008/http-headers) which is intended 
to be in line with the IANA headers registry. The http:headerName 
property uses resource objects from this model.

2. We had a comment asking to provide a literal approach resulting in 
the http:fieldName property.
(JK: It's unclear to me whether there is still a real use case for 
http:headerName.)

3. We wanted to provide a more structured approach for deconstructing 
header values, using http:headerElements, http:elementName, 
http:elementValue, http:params, http:paramName, http:paramValue 
properties, and http:HeaderElement and http:Param classes.

Question:
If there was an httph:contentType property, which other headers do you 
think we should provide a property for?


> Body alternatives

Yes, we think of it as multiple interpretations of the entity. So 
strictly the only object resource for http:body would be a 
cnt:Base64Content resource. Connections to other interpretations 
(cnt:TextContent, cnt:XMLContent resources) could be created using a 
different vocabulary.


> Term Usage

We use the word "representations" in the generic English sense.


> MessageHeader

We removed all the OWL restrictions from the schema.


> Date

Recommending the use of a date property was a comment on an earlier 
draft. These dates are not part of HTTP. And so we think there should 
not be a specific date property in the HTTP-in-RDF vocabulary. ThatÄs 
why we proposed the use of dc:date here.


> MethodName versus Method

Same as http:headerName and http:fieldName.

(JK: It's unclear to me whether there is still a real use case for 
http:method.)


> HeaderElement

It's not related to markup elements. in fact it mirrors the way header 
values are decomposed in Apache HttpComponents Core. A next draft should 
be more explanatory about decomposing header values and the use of 
http:HeaderElement and http:Param.


> Domains and ranges

We try to provide a donain and range for as many properties as we think 
possible. However, domains and ranges can sometimes restrict the reuse 
of properties within other vocabularies.

Question:
If the intended use of e.g. the http:headers property is an RDF 
collection (closed!, not an open RDF container like Bag or Seq) with 
http:MessageHeader resources, what would the range of this property be?


> StatusCodeGroup

(JK: I think the introduction of StatusCodeGroup was triggered by a 
comment on a previous draft. The subclassing of http:Response seems 
reasonable.)


> Links

(JK: I should take more care on that.)


> OWL problems

We removed nearly all OWL from the schema.

The 'asterisk' with http:requestURI is in fact awkward.
(JK: We should talk about this.)

About the use of RDF collections: We use collections because the 
sequence of requests/headers is relevant. Having an http:Connection 
resource with multiple http:request properties would not model a 
sequence of requests, would it?

-- 
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, 4 February 2009 14:54:44 UTC