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

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