Re: summary so far.

You're generting stuff more quickly than I can process it. I will be
selective and not comment on everything that I could.

On Wed, Mar 2, 2011 at 5:49 AM, Nathan <nathan@webr3.org> 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.

No. Only TimBL's requirement that these be distinct breaks. (Maybe
that's what you mean by "things" but you need to be more specific.)
There is a perfectly consistent view - one consistent with practice as
well - that says that the four URIs ought to be used to name the same
resource, because there's no way for an observer to tell them apart. I
think Pat has said something similar.

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

hm. what they refer to depends on who's doing the referring.
JAR's rule #27: Never treat reference or identification as objective.
They are always according to someone.

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

I use 'falsifies' in a technical sense and this doesn't fit it... see
http://en.wikipedia.org/wiki/Falsifiability

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

Meaning and reference aren't exactly the same,by the way. Reference
would be just one kind of meaning. In RDF and webarch there's an
attempt to equate the two, which is laudable but I sometimes find it a
bit like trying to fit a size 11 foot into size 9 shoe.

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

RB = domain of 'has reading' or 'has representation'

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

right, this is how it has come to be used in httpbis and webarch (they
don't really mean the REST sense necessarily)

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

Give up on specification and first-principles analysis, and take the
only important problem to be how/when to write and read metadata, and
you'll be there.

> ... getting there ...
>
> Cheers,
>
> Nathan
>

Received on Wednesday, 2 March 2011 15:43:05 UTC