- From: Jonathan Rees <jar@creativecommons.org>
- Date: Fri, 21 Oct 2011 09:46:20 -0400
- To: Norman Gray <norman@astro.gla.ac.uk>
- Cc: "nathan@webr3.org" <nathan@webr3.org>, Dave Reynolds <dave.e.reynolds@gmail.com>, Leigh Dodds <leigh.dodds@talis.com>, "public-lod@w3.org" <public-lod@w3.org>
On Fri, Oct 21, 2011 at 8:33 AM, Norman Gray <norman@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
Received on Friday, 21 October 2011 13:47:00 UTC