W3C home > Mailing lists > Public > public-rdf-comments@w3.org > August 2015

Re: RDF's relative IRI resolution is ambiguous

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Thu, 27 Aug 2015 15:38:03 -0700
Cc: Richard Cyganiak <richard@cyganiak.de>, RDF Comments <public-rdf-comments@w3.org>
Message-Id: <087F5C3F-355F-46F6-831C-B74C6ADF4266@greggkellogg.net>
To: Ruben Verborgh <ruben.verborgh@ugent.be>
> On Aug 27, 2015, at 3:01 PM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
>> That depends on if <> is interpreted as a relative URI. 
> 
> Upon closely reading RFC3986, an empty URI is a relative URI:
> relative-part = "//" authority path-abempty
>                    / path-absolute
>                    / path-noscheme
>                    / path-empty
> And Section 5.2.2 defines the behavior as:
>            if (R.path == "") then
>               T.path = Base.path;
> So <> necessarily equals the base IRI, without normalization.

5.2.1 says the following:

> Normalization of the base URI, as described in Sections 6.2.2 and 6.2.3, is optional.

So, it would seem that we need to be explicit about expected behavior. The Ruby Addressable library takes the position that the base URI is not normalized in this case, as you suggest. Iím actually surprised to see that my own implementation does the same thing, so the behavior of my own Turtle implementation now seems odd.

Special casing <> in Turtle would be unfortunate, as it is now, all of the RDF.rb parser implementations should be consistent in doing base.join(iri); this has implications for JSON-LD, RDF/XML, SPARQL, Turtle, TriG, Ö Itís important that we be consistent.

IMO, the best interpretation is that, when resolving relative IRIs, all IRIs are resolved relative the the document, or declared, base; no special-case for the empty relative IRI. In fact, as the declared base URI within the document, may itself be relative, it must be resolved against the document location to establish the base URI to use for resolving subsequent relative URIs.

A test suite should repurpose the same tests across different formats, IMO, to make sure we remain consistent; or such tests should be added to each of the relevant test suites.

Gregg

> I'm in the process of building an extensive list of test cases.
> Will share when ready.
> 
> Ruben
Received on Thursday, 27 August 2015 22:38:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:49 UTC