Re: summary so far.

Jonathan Rees wrote:
>> So, <u> does not refer to an HTTP/REST resource, that is, even if you could
>> see the entire set of representations ever given to every person, you still
>> often cannot deduce to what the URI refers, what it names.
> 
> umm. doesn't compute. Oh, I see, you're saying the mapping from URI to
> IR isn't functional. Agree completely - someone has got to (or has the
> privilege to) decide which of those IRs the URI is to refer to, even
> assuming that they're using the URI to name an IR at that URI. THis is
> why my 'is bound to' relation is not functional.

interesting thing here.. next paragraph

>> Here is some evidence to back up this claim:
>>  http://lists.w3.org/Archives/Public/public-awwsw/2011Mar/0006.html
>>
>> In the case pointed to above, you must see how the URIs are /used/
>> (consistently over time) to establish what they refer to; and not what the
>> information resource reflects (consistently over time).
> 
> Yes, meaning of a URI is how it's used by agents

now this is interesting, and I'm unsure exactly how to say it, but if we 
work from HTTP Resource upwards to URI, such that we consider an HTTP 
Resource as being a distinct object for which all URIs used to refer to 
it are bound to that HTTP Resource (the URIs are a property of the HTTP 
Resource), then we come to the wrong conclusions, and things break.

In the quoted example above, it would mean that all four URIs are bound 
to the "HTTP Resource", they all refer to the "same thing", which is 
clearly inconsistent and just wrong in every way.

Even though there is only one "HTTP Resource", there are four distinct 
"Resources".

Each of the four URIs could be bound to one, or four, or two billion 
different "HTTP Resources" and you wouldn't know.

Which means that.. they're unquantifiable.

Every single bit of information which could possibly be used to 
determine exactly how many HTTP Resources there are, is therefore 
hidden, and has to be, otherwise the whole thing falls apart. This is a 
product of the uniform interface and the compound identifier with it's 
late binding of the various differently scoped names of which a URI 
comprises.

Jonathan: Kudos, you said this a while back and I didn't fully grasp 
what you meant, but you were right, you cannot prove in any way that 
there is more than one HTTP/REST resource (technically by looking 
through the uniform interface).

This falsifies all kinds of things, and I have to draw some conclusions.

"meaning of a URI is how it's used by agents" - check, yes.

(I'll have to iteratively explain the next bit)

each URI is optionally bound to a set of representations over time, each 
representation is anonymous (only existentially quantified) by default 
(*) and late bound to the URI as a product of the dereferencing process, 
thus if one representation has been bound to a specific URI then that 
URI belongs to the class of things for which representations have been 
bound. I'll that class of things RB for now (has a [R]epresentation 
[B]ound).

* given two identical representations, you cannot tell what they are 
representations of, if they are representations of the same thing, or 
two different things.

Okay, I used representation above to mean content+meta, nothing more, 
nothing less, and doesn't mean that it's a "representation" of anything. 
I've purposefully not used the term information resource, because at 
this moment in time I can't bring myself to say any more than there are 
URIs, some URIs have had content+meta's bound to them, and thus we could 
make a proper subclass which is the class of all URIs for which a 
content+meta has been bound.

Jonathan, have I caught up with you yet?

... getting there ...

Cheers,

Nathan

Received on Wednesday, 2 March 2011 10:50:58 UTC