HTTP-in-RDF Equivalence

Hi,

I have a question regarding the semantic equivalence (or not) of
alternate representations of the same data.

Although the spec at http://www.w3.org/TR/HTTP-in-RDF/#MessageHeader
stipulates that "field values should be decomposed to the highest
possible extent." it is not clear if the following representations
should be considered semantically equivalent (or not):

Literal:

<http:MessageHeader>
  <http:fieldName rdf:resource="http://www.w3.org/2006/http-header#accept"/>
  <http:fieldValue>application/xhtml+xml; q=1.0, text/html;
q=0.9</http:fieldValue>
</http:MessageHeader>

Decomposed:

<http:MessageHeader>
  <http:fieldName rdf:resource="http://www.w3.org/2006/http-header#accept"/>
  <http:fieldValue rdf:parseType="Collection">
    <http:HeaderElement>
      <http:elementName>application/xhtml+xml</http:elementName>
      <http:param>
        <http:Param>
          <http:paramName>q</http:paramName>
          <http:paramValue>1.0</http:paramValue>
        </http:Param>
      </http:param>
    </http:HeaderElement>
    <http:HeaderElement>
      <http:elementName>text/html</http:elementName>
      <http:param>
        <http:Param>
          <http:paramName>q</http:paramName>
          <http:paramValue>0.9</http:paramValue>
        </http:Param>
      </http:param>
    </http:HeaderElement>
  </http:fieldValue>
</http:MessageHeader>

The reason that I ask is that I can see the vast majority of
implementations using the literal representation, regardless of the
stipulation to decompose, because of the significant increase in
complexity of representation without a clear benefit.

Indeed I found it not a little ironic that immediately after making
the stipulation, the very next example (2.7) demonstrates a literal
where there should be a decomposed representation (a fact that the
commentary acknowledges by saying "the use of a Literal is discouraged
because the field value contains a parameter").

Perhaps the specification can lay out the practical reasons why
decomposition is preferable to literal representation?

In the same vein, are the following representations to be considered
semantically equivalent or not?

<http:fieldName rdf:resource="http://www.w3.org/2006/http-header#content-type"/>

and

<http:fieldName>content-type</http:fieldName>

Again, I can easily many real-world implementations prefering the
latter (not least as it cuts out a huge if or switch statement).

I guess that at the heart of my questions about equivalence is the
following question: "did you have to make it so darn complicated?"

Many developers already regard RDF with suspicion due to the perceived
complexity and I fear that they will have their fears confirmed by
this spec.

Could the spec not be simplified so that the following representation is valid?

<rdf:RDF
  xmlns:http="http://www.w3.org/2006/http#"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <http:Request>
    <http:method>GET</http:method>
    <http:abs_path>/robots.txt</http:abs_path>
    <http:version>HTTP/1.1</http:version>
    <http:header rdf:parseType="Collection">
      <http:MessageHeader>
        <http:fieldName>Connection</http:fieldName>
        <http:fieldValue>Keep-Alive</http:fieldValue>
      </http:MessageHeader>
      <http:MessageHeader>
        <http:fieldName>Host</http:fieldName>
        <http:fieldValue>example.com</http:fieldValue>
      </http:MessageHeader>
      <http:MessageHeader>
        <http:fieldName>Host</http:fieldName>
        <http:fieldValue>Googlebot/1.0</http:fieldValue>
      </http:MessageHeader>
    </http:header>
  </http:Request>
  <http:Response rdf:ID="resp0">
    <http:version>HTTP/1.1</http:version>
    <http:responseCode rdf:resource="http://www.w3.org/2006/http#200"/>
    <http:header rdf:parseType="Collection">
      <http:MessageHeader>
        <http:fieldName>Date</http:fieldName>
        <http:fieldValue>Sat, 24 Mar 2007 14:17:00 GMT</http:fieldValue>
      </http:MessageHeader>
      <http:MessageHeader>
        <http:fieldName>ETag</http:fieldName>
        <http:fieldValue>abc123</http:fieldValue>
      </http:MessageHeader>
    </http:header>
    <http:body><![CDATA[User-agent: *
Disallow:]]></http:body>
  </http:Response>
</rdf:RDF>

If the publisher wanted to decompose a header value for some reason,
the <http:MessageHeader> could also contain a
<http:fieldDecomposition> collection with all the parts you have laid
out in addition to the literal representation.

I also included a <http:method> in my example as that seems far more
usable to me than the current <http:GetRequest> (what are the WebDAV
people going to use?). If <http:GetRequest> is appropriate, why not
<http:200Response> (or <http:RequestGet> and <http:Response200>) ? At
least that would have the virtue of consistency. The benefit of
method-specific subclasses is never set out in the spec.

Regards,
Alan Dean
http://thoughtpad.net/who/alan.dean/

Received on Monday, 26 March 2007 10:49:58 UTC