This is part of A Model of Authority in the Web.

Speech Acts in HTTP

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

@prefix ht: <>.

For example, an HTTP request such as:

GET /hello.txt HTTP/1.1

gives rise to this logical formula:

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

_:some_request ht:methodName "GET";
  ht:absoluteURI "".

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


ht:statusCodeNumber ... what a mouthful; kinda redundant. A code is a number, no? TODO: send a comment on the draft.

Also, the draft gives an alternate formulation:

_a:response ht:sc <>

TODO: check that #statusCode200 has a functional property related to a string or number 200; otherwise it's not logically necessary that { <#statusCode200> owl:differentFrom <#statusCode404> }.

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


A recent AWWSW report used corresponds_to, going the other direction. I going that direction awkward as RDF pretty-printers tend to group properties by subject, and the more natural subject seems, to me, to be the resource, not the entity.

Also, in ordinary prose, "corresponds to" is symmetric, and this relationship is not.

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


Wrinkle: time

@@treat TTL/expiry: this morning's WSJ.

and re time and this paper vs. the BAN logic that I did a larch transcription of:

The logic does not consider the problems associated with timestamps and lifetimes, either. Therefore, we do not explain how principals come to believe that messages are recent and are not replays. In these respects the logic is more abstract than the logic of authentication proposed in [4]. The logic of authentication has as its goal describing and debugging fairly low-level authentication protocols; in contrast, the logic discussed here is intended as an aid in developing and applying a general design.


[HR](1, 2) HTTP Vocabulary in RDF 1.0 Koch, Velasco, eds. W3C Working Draft 29 October 2009