Re: Indicating Skolem Nodes (was Re: AW: {Disarmed} Re: blank nodes (once again))

On Sat, Mar 26, 2011 at 12:09 AM, Pat Hayes <> wrote:
> On Mar 25, 2011, at 5:27 PM, Jonathan Rees wrote:
>> *** triviality alert ***
>> On Fri, Mar 25, 2011 at 2:23 PM, Pat Hayes <> wrote:
>>> Which leads me to the idea that they ought to always have a hash in them, to avoid this tarpit. So they are URIrefs, not URIs.
>> I hate to say this, Pat, but you're out of date with respect to URI
>> terminology.
> Say it, say it. I know I am woefully behind the times here.
>> You are indeed correct according to RFC 2396 (1998) - the
>> # occurs in the production for the "URI-reference" nonterminal. (There
>> is no "URI" nonterminal but it would make sense to assume a "URI" was
>> either an "absoluteURI" or a "relativeURI", neither of which allows
>> #.) However, its replacement, RFC 3986 (2005), has the following:
>>      URI-reference = URI / relative-ref
>>      URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>> so those absolute but #-containing things we used to call URIrefs have
>> all been promoted to URI status. To which I say, congratulations!
> Then I am confused about http-range-14. My understanding was that the 303 requirement applied to 'bare' URIs which denote non-information resources, but not to (what used to be called) URI references. So for example ex:this must give a 303 if it is to denote, say, a planet; but ex:that#this can denote anything at all without HTTP having to do anything special. Is this distinction no longer meaningful?

The distinction is still meaningful; upgrading the URI spec doesn't
change the resolution. The wording of the resolution is awkward in a
number of ways but its intent is clear, in the context of the
discussion that led up to it. Roy (and those who voted in favor) took
"http: URIs" to mean http: URIs sensu RFC 2396, not http: URIs sensu


Received on Saturday, 26 March 2011 13:48:01 UTC