Re: about REST

On Fri, 2010-02-26 at 17:02 -0500, Jonathan Rees wrote:
> 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.

All this makes sense, but if you meant to _answer_ the question
of why not use messages for time, I don't see it.

I didn't say HTTP messages. I said messages in general.

I suppose it's a little contorted to think of which
messages have data:,abc saying "abc", but no more contorted than
thinking about what times data:,abc says "abc"; in
both cases, it's: all of them.


>  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

Nothing distinguishes the sort/kind time from message, so far.

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

In this case, I think it makes *more* sense to talk about messages
than time; i.e. which messages are/would be licensed/conforming?

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

or perhaps just: some ways to falsify the claim that it says
a representation.

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

If you're talking about observing change, then you're talking
about communication, right? i.e. messages.


-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Friday, 26 February 2010 22:57:26 UTC