W3C home > Mailing lists > Public > public-wai-ert@w3.org > February 2009

Proposed Responses to AWWSW comments on HTTP-in-RDF

From: Johannes Koch <johannes.koch@fit.fraunhofer.de>
Date: Wed, 04 Feb 2009 15:53:53 +0100
Message-ID: <4989AC01.6040000@fit.fraunhofer.de>
To: ERT WG <public-wai-ert@w3.org>

Hi group,

here are some

Proposed Responses to AWWSW comments on HTTP-in-RDF 

> 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 

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.

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 

> 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.

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 

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:57 UTC