Re: Explaining the benefits of http-range14 (was Re: [HTTP-range-14] Hyperthing: Semantic Web URI Validator (303, 301, 302, 307 and hash URIs) )

Norman Gray wrote:
> Nathan, hello.
> On 2011 Oct 20, at 12:54, Nathan wrote:
>> Norman Gray wrote:
>>> Ugh: 'IR' and 'NIR' are ugly obscurantist terms (though reasonable in their original context).  Wouldn't 'Bytes' and 'Thing', respectively, be better (says he, plaintively)?
>> Both are misleading, since NIR is the set of all things, and IR is a 
>> proper subset of NIR, it doesn't make much sense to label it "non 
>> information resource(s)" when it does indeed contain information 
>> resources. From that perspective "IR" and "R" makes somewhat more sense.
> 
> That's true, and clarifying.
> 
> Or, more formally, R is the set of all resources (?equivalent to "things named by a URI").  IR is a subset of that, defined as all the things which return 200 when you dereference them. NIR is then just R \ IR.

Indeed, I just wrote pretty much the same thing, but with a looser 
definition at [1], snipped here:

""
The only potential clarity I have on the issue, and why I've clipped 
above, is that I feel the /only/ property that distinguishes an "IR" 
from anything else in the universe, is that it has a 
[transfer/transport]-protocol as a property of it. In the case of HTTP 
this would be anything that has an HTTP Interface as a property of it.

If we say that anything with this property is a member of set X.

If an interaction with the thing named <p:y>, using protocol 'p:', is 
successful, then <p:y> is a member of X.

An X of course, being what is currently called an "Information Resource".

Taking this approach would then position 303 as a clear opt-out built in 
to HTTP which allows a server to remain indifferent and merely point to 
some other X which may, or may not, give one more information as to what 
<p:y> refers to.
""

[1] http://lists.w3.org/Archives/Public/www-tag/2011Oct/0078.html

That's my understanding of things any way.

> It's NIR that's of interest to this discussion, but there's no way of indicating within HTTP that a resource is in that set [1], only that something is in IR.

Correct, and I guess technically, and logically, HTTP can only ever have 
awareness of things which have an HTTP Interface as a property. So 
arguing for HTTP to cater for non HTTP things, seems a little illogical 
and I guess, impossible.

> Back to your regularly scheduled argumentation...

Aye, as always, carry on!

Best,

Nathan

Received on Friday, 21 October 2011 12:58:34 UTC