about REST

Considering how to answer Dan's question "why not anchor time in HTTP
messages?" has forced me to think again about how to explain what I'm
trying to do. My latest thought is that I'm trying to run with Roy
Fielding's insistence that http: is not HTTP. Roy developed the
protocol-independent REST model in part to guide the preparation of
RFC 2616. He needed an independent theory against which to judge the
correctness of the protocol spec. I'm finding that everything I've
been trying to capture in RDF is isomorphic to REST; I just disagree
with details of Roy's formalism and philosophy. This means first
making a protocol-independent logical theory, then showing how HTTP
maps onto it as just one example. (I give data: as a second "protocol"
that maps to the same kinds of statements. There could be many
others.)

Comparison with REST:
RF - resource modeled as a time-varying membership function: a
representation is a member of {resource at time}
JAR  - resource participates in three-place says(resource,
representation, time) relation.  this is formally equivalent

RF - representation is of a state of the resource
JAR - representation is an utterance attributable to the resource
(something it might "represent" to be the case!); resources don't have
to have state, nor do representations have to be derived from state if
it's there.  formally equivalent, ontologically more liberal

Caching is a central piece of the http:-is-not-HTTP story, and I would
like to generalize it to "permission to serve" - if I want to serve
resource R at URI U, how much latitude do I have in doing so? When is
it OK to yield any given representation? I know there's no generic
answer, but we need a way to talk about how one obtains an answer.

Why futz around like this? I'm still trying to formulate a sensible
theory of httpRange-14 and 200 responses that will enable someone
(e.g. a designer or user of IAO, BIBO, or genont) decide for
themselves when a set of HTTP responses (or 'says' assertions
communicated over any other protocol) is/should be consistent with a
set of RDF assertions, without abusing the intended web architecture.
To get there we need not just a definition of "information resource"
but a theory of when any given resource says a representation and when
it doesn't. I don't think we have a story adequate for IAO yet, but I
think we're a lot closer than a year ago.

So I'm very interested in the resources, and only interested in the
protocol to the extent that I can (or have to) extract from it
protocol-independent statements about the resources. To talk about
change in what the resource says, it is not sufficient to talk about
orderings among messages, because we might not be using the HTTP
protocol at all.

Received on Friday, 26 February 2010 22:03:17 UTC