Speech Acts in HTTP

@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix s: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix log: <http://www.w3.org/2000/10/swap/log#>.
@prefix list: <http://www.w3.org/2000/10/swap/list#>.
@prefix str: <http://www.w3.org/2000/10/swap/string#>.

In order to reason about HTTP requests, we'll take advantage of a standards-track RDF vocabulary for HTTP [HR] .

@prefix ht: <http://www.w3.org/2006/http#>.

For example, an HTTP request such as:

GET /hello.txt HTTP/1.1
Host: www.example.com

gives rise to this logical formula:

_:some_connection ht:requests (_:some_request).

_:some_request ht:methodName "GET";
  ht:absoluteURI "http://www.example.com/hello.txt".

Likewise, a response such as:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Content-Length: 14
Content-Type: text/plain

Hello World!

gives rise to:

_:some_request ht:response _:some_response.
_:some_response ht:methodName "GET"; ht:statusCodeNumber "200".

In section 7.3. GET of the HTTPbis specification, we find:

The GET method means retrieve whatever information (in the form of an entity) is identified by the request-target.

The RDF vocabulary above concerns itself primarily with the message format, so we'll need to introduce a new term to capture this semantic relationship:

@keywords is, of, a.
@prefix : <httpspeech#>.

information a owl:DatatypeProperty;
  # s:domain s:Resource # content-free
  s:comment """whatever information (in the form of an entity)
     is identified by the request-target of
     an HTTP GET request.""";
  s:isDefinedBy <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-08#section-7.3>.

Entity s:label "Entity"; a owl:Class.

messageEntity s:label "message entity";
  s:domain ht:Message;
  s:range Entity;
  s:comment """body bytes (after transfer encoding) interpreted
    as per content headers (e.g. content type) of a message.
    In the case of RDF content, the entity is a formula/graph""".

These terms are related to ABLP logic in that an HTTP 200 response to a GET request is a claim, by that server/connection, that a resource has some associated information:

@prefix c: <speech#>.

@forAll E, RES.

{
  RES log:uri ?I.
  ?CONNECTION ht:requests [ list:member ?Q ].
  ?Q ht:methodName "GET";
    ht:absoluteURI ?I;
    ht:resp ?A.
  ?A ht:statusCodeNumber "200".
  ?A messageEntity E.
}
=> { ?CONNECTION c:says { RES information E } }.

perhaps another layer between hs:messageEntity and information for parsing

Note that the conclusion of this axiom is not a fact about the resource:

{ RES information E }.

but only a claim made by the server. The server might be a buggy proxy.

Only origin servers are authoritative when they make such claims:

{
  ?CONNECTION ht:connectionAuthority ?A.
  RES log:uri ?I.
  (?I "http://([^/]+)/") str:search (?A).
} => { ?CONNECTION c:controls { RES information E } }.

Due to limitations in the reasoner we're using, we need a more constrained axiom:

{
  ?CONNECTION c:says { RES information E }. # needed for fwd chaining

  ?CONNECTION ht:connectionAuthority ?A.
  RES log:uri ?I.
  (?I "http://([^/]+)/") str:search (?A).
} => { ?CONNECTION c:controls_spo ( RES information E )}.