Re: about REST

There's no reason not to use messages, when you have them.  It's just
that there are plenty of other sources of evidence for says(R,E,t),
and for each of these there will have to be some treatment of time
and/or events. In particular, the server needs to know that the
relationship holds even before it sends a message that contains E -
it's the relationship that justifies sending the message in the first
place. If you're going to invent fictional messages just so that we
can always talk about messages, as you suggested for data:, I think
you're going to lose me. I'd rather we create a neutral kind of entity
similar to "correspondence" and figure out how we want to do temporal
reasoning with it. If you're saying you'd rather avoid time values in
favor of ordered events I respect that, although it may leave me
wondering how you coordinate mirrors and how you understand the
Expires: header.

On Fri, Feb 26, 2010 at 5:57 PM, Dan Connolly <connolly@w3.org> wrote:
> 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.

In the first cases, there might be no messages. In the second case,
there are all times. I'm not too bothered with data:,abc saying "abc"
for all time, since we're using 'says' technically. (Maybe you are
using 'message' technically?)

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

No, which representations are conforming - I need to know in case
someone asks. (E.g. I am a proxy or mirror, or am providing a web site
under contract.)

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

OK

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

'Message' defined technically? When I watch an hourglass run out, is
it sending me 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 23:26:11 UTC