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
