On Fri, Oct 21, 2011 at 8:33 AM, Norman Gray <nor...@astro.gla.ac.uk> wrote: > > Nathan, hello. > > 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.
The important distinction, I think, is not between one kind of resource and another, but between the manner in which a URI comes to be associated with a resource. Terminology is helpful, which is why people have latched onto "NIR", and one possibility is "direct" (for old-fashioned Web URIs) and "indirect" (for semweb / linked data), applied not to resources but to URIs. A direct URI always names an IR (in fact a particular one: the one at that URI), but an indirect one can name either an NIR or an IR (as in the http://www.w3.org/2001/tag/2011/09/referential-use.html, and as deployed at http://dx.doi.org/ ). HR14a says (in effect) all retrieval-enabled hashless URIs are direct, but other rules (like Ian Davis's) might say other things; the terms are useful independent of the architecture. There might be situations in which 'NIR' is a useful category, but I don't know of any. If you say things like "303 implies NIR" (which is not justified by httpRange-14 or anything else), you get into trouble with indirectly named IRs like those at dx.doi.org. One could adopt a new rule that says an indirect URI cannot name an IR, in which case if you knew the IR/NIR classification you could know which kind of URI you had to use and vice versa, but this seems limiting, unnecessary, and incompatible. Jonathan
