Re: HTTP method+status code combos and their (http) meaning.

Jonathan Rees wrote:
> On Mon, Jan 24, 2011 at 11:14 AM, Nathan <nathan@webr3.org> wrote:
>> Roughly, I'm quite sure that even the term "representation of" doesn't hold,
>> and can only hold in very very specific circumstances, namely when the term
>> "resource" is given a fixed meaning of "a file on the file system"
> (don't forget the media type and content language)
>> and the
>> set of HTTP methods and messages is constrained to a subset that allows
>> this, precluding negotiation of all kinds, the POST method, and any kind of
>> "dynamic" anything. I'm also quickly coming to the conclusion that thinking
>> of a response message as anything other than just that, is dangerous and
>> leads to incorrect statements being made, for instance it's impossible to
>> prove that this holds:
>>
>>  <http://example.org/foo.html> media:type "text/html" .
>>
>> because there /may/ be another representation sitting there that you didn't
>> GET (various other reasons including auth by IP, cookie, accept headers,
>> temporal/random negotiation, all kinds of things), and thus, one should only
>> be making statements like this about the message returned, by the server, in
>> response to a certain request.
> 
> Yes, beware what conclusions you draw about a resource from one 200
> response. It will tell you what the resource isn't, but will never
> help you figure out what it is.  E.g. if you get a 'representation' of
> Jabberwocky, you will know that the URI shouldn't be used to refer to
> Moby Dick, but you'll have no idea whether it's suitable as a
> reference to Jabberwocky or any other particular resource that 'has'
> that representation. That's not the same as saying that the URI is no
> good as a reference. You need some kind of consistency in order to
> successfully assert something like dc:title or dc:creator, and any
> time you say something like this you're making a prediction about the
> future, and the future is always uncertain (this is where I always
> mention Popper).  You choices are
> 1. Take a gamble.  Maybe it *looks* like the page is going to stable
> and consistent long enough for your purposes, and the cost of your
> metadata assertion being misinterpreted is small enough to justify the
> risk.
> 2. Obtain inside information.  If you can audit the workings of the
> server(s), and get an SLA or other assurance of stability, go for it.
> 3. Seize control.  As long as you are the URI owner, you can arrange
> for the representations to be as convincing as you want them to be.

Next up, this could be moot, because if you wrap the statements up 
with provenance and temporal indicators (just as http messages do) 
then you can assert what you like, because you're not making a 
statement about the resource identified by the <uri> for all time, and 
in to the future, but only your current opinion based on what you 
currently know.

This is where RDF is great for use with HTTP (which only ever gives 
the current state of a resource) in messages, because resource owners 
can make statements which get transferred in a representation/message 
and are only valid for the time that message was received. But as soon 
as you're a consumer, RDF falls apart and isn't enough, essentially 
you need to take the set of statements, wrap them in a graph literal, 
and attach the provenance from the message exchange to the graph 
literal, such that you're locking the message / statements in time 
with temporal validity (and other important info such as the one 
requesting, hashes/signatures and so on).

That way, if a URI suddenly dereferences to an image of a candy bar 
tomorrow, you can say that you now consider it to be an image of a 
candy bar, without any invalid statements being made.

This process solves /so/ many issues, it even gives you a time machine 
of sorts! (And allows RDF diff and merge etc).

You don't say what a URI names (forever) you describe what you think a 
name refers to at X time, under Y context, just as we do here when I 
say Jonathan, I clearly mean you - but somebody else who just said 
that name in another part of the world, does not mean you, it's simple 
when you describe the context (where/when/why/how the name was used) 
as well.

Best,

Nathan

Received on Monday, 24 January 2011 20:34:33 UTC