Re: summary so far.

yay, definitely getting there! follow up at the bottom to keep it in 
context:

Nathan wrote:
> 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.

for all URI <u> in class RB, <u> is bound to a set SR of representations 
{Ri,i=1...n}, to a Thing.
for all URI <u> in class RB, there exists a set SA of agents 
{Ai,i=1...n} for which <u> is a name for SR or T.

hashes [
   for some <u> in class RB there exists a class of sub-URIs of the form 
<u#f>.
   for all <u#f> in <u>, <u#f> is bound to SR.
   if there exists 1...n <u#f> in <u>, then <u> refers to SR and T == SR.
   for all a in SA, <u> refers to SR and T == SR.
] (
  - easy
  - doesn't cover the cases where you can't use <u#f>
  - it's still true that:
     for some a in SA, <u> refers to T
     for some a in SA, <u> refers to SR
     for some <u> in class RB, T != SR.
     for some <u> in class RB, T == SR.
)

slashes [
   for some a in SA, <u> refers to T
   for some a in SA, <u> refers to SR
   for some <u> in class RB, T != SR.
   for some <u> in class RB, T == SR.
   if T == SR then for all a in SA, <u> refers to SR and T == SR.
   if T != SR and no a in SA uses <u> for SR, then <u> refers to T.
   if T != SR and some a in SA uses <u> for SR, then T == SR && T != SR.
] (
  - the problem
)

if any of the following conditions is true, then there no problem:

   if T == SR
   for all a in SA, <u> refers to T
   for all a in SA, <u> refers to SR

the only "fix" is to make ( for all <u> in RB, T == SR ) universally 
true (<u> == IR), or make it universally false ( can't use <u> as a 
name). there's no way to enforce either.

There is one vital question here though, if T != SR, is there anything 
one could even say about SR, the only things that could be said, would 
be those that would be true for all R in SR, which isn't much if 
anything - can we identify what these things are?

Cheers,

Nathan

Received on Wednesday, 2 March 2011 12:54:59 UTC