On 10/21/11 8:57 AM, Nathan wrote:
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!
Nice explanation. You've just explained:1. why http scheme based names/handles for data objects are powerful but unintuitive 2. why data object names, addresses, and representation must always be distinct.
The distinct between a URI (generic name/handle) and a URL (locator/address) remains the root cause of confusion. We have two *things* that are superficially identical (due to syntax) but conceptually different. The core concept is always the key to negating superficial distraction associated syntax :-)
Link:1. http://tools.ietf.org/html/rfc3305 -- an interesting read re. URIs and URLs.
Best, Nathan
-- Regards, Kingsley Idehen President& CEO OpenLink Software Web: http://www.openlinksw.com Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca: kidehen
smime.p7s
Description: S/MIME Cryptographic Signature
