Different parsing of the same absolute IRI with or without base IRI

[Tpt]

Not sure if it is already tracked elsewhere.

Let's consider the following Turtle file (note the dot segment):

<http://example.com/foo/./bar> <http://example.com/bar> 1 .

If no base IRI is set then Turtle does not normalize IRIs leading to the NTriple:

<http://example.com/foo/./bar> <http://example.com/bar> 1 .

Whowever, if a base IRI is set, then http://example.com/foo/./bar can be considered as a relative IRI reference (it matches the given grammer) and must be resolved against it using RFC 3986 relative URI transformation that removes dot segments, leading to the http://example.com/foo/bar IRI and the following NTriple:

<http://example.com/foo/bar> <http://example.com/bar> 1 .

[gkellogg]

According to RFC3986 4.1 URI Reference:

A URI-reference is either a URI or a relative reference. If the
URI-reference's prefix does not match the syntax of a scheme followed
by its colon separator, then the URI-reference is a relative
reference.

http://example.com/foo/./bar does match a scheme followed by its colon separator, so is not a relative reference.

RFC3987 2.2 ABNF for IRI References and IRIs and RDF Concepts IRI Grammar describe an IRI-reference as IRI-reference = IRI / irelative-ref but relative-ref does not permit an relative reference starting with a scheme and colon.

irelative-part = "//" iauthority ipath-abempty
               / ipath-absolute
               / ipath-noscheme
               / ipath-empty

I don't really see the ambiguity.

[pchampin]

@gkellogg I was about to make the exact same answer, but then I checked RFC3986 and the resolution algorithm :-/

      -- The URI reference is parsed into the five URI components
      --
      (R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);

      # (...) skipping irrelevant stuff

     if defined(R.scheme) then
         T.scheme    = R.scheme;
         T.authority = R.authority;
         T.path      = remove_dot_segments(R.path);    <-- THERE BE DRAGONS
         T.query     = R.query;
      else
         # ...

So even if the URI reference is nor relative (it has a scheme), its path part is supposed to be processed :-/

[gkellogg]

Yes, the resolution algorithm does work on "a URI reference that might be relative to a given base URI", so it does not restrict itself to irelative-ref.

In 2.4 IRIs we talk about resolving Relative IRI references using the base IRI. Also, the IRIREF Term Constructor uses the base IRI only for Relative IRI references. Even though RFC3986/7 describes using the resolution algorithm on anything that might be a relative IRI, Turtle only invokes this for relative IRI references.

[Tpt]

Thank you for your feedback.

It seems to me that here the key is the definition of "relative IRI reference". If I am not mistaken is not defined in RFC3886/7 and in the RDF concept note that introduces it we do not define it formally. Hence it is imho unclear if it only matches only the productions of irelative-ref or all productions of IRI-reference = IRI / irelative-ref. I assumed the second but if I understand properly, @gkellogg you assume the first (please correct me if I am wrong).

The way forward here is maybe to properly define "relative IRI reference" as the set of relative IRIs produced by irelative-ref inside of RDF concepts.

We would still keep the behavior that //example.com/foo/./bar is resolved into http://example.com/foo/bar against http://example.com base (following relative IRI resolution algorithm) but http://example.com/foo/./bar will be kept unchanged.

[gkellogg]

Hence it is imho unclear if it only matches only the productions of irelative-ref or all productions of IRI-reference = IRI / irelative-ref. I assumed the second but if I understand properly, @gkellogg you assume the first (please correct me if I am wrong).

Yes, I think the definition of relative IRI reference in RDF Concepts should be updated to bind it to the relative-ref production. Turtle should also have a note or non-normative sentence that clarifies that IRI Expansion is only performed for IRIREFs that are relative IRI references, and not full IRIs.

[afs]

The Turtle document says:

IRIs may be written as resolved IRIs, Relative IRI references, or prefixed names.

and both "resolved IRIs" and "Relative IRI references" will cause . and .. to be sorted out.

The IRIREF entry could be updated to mention resolved IRIs.

So even if the URI reference is not relative (it has a scheme), its path part is supposed to be processed :-/

I have always been under the impression that this the case.

[Tpt]

IRIs may be written as resolved IRIs, Relative IRI references, or prefixed names.

If I understand this sentence correctly it means that IRIs that cannot be the output of the resolution algorithm are not valid in Turtle and so the IRIs valid in Turtle are not all the possible productions of the IRI non terminal of RFC3987 grammar but a subset of them (for example http://example.com/foo/./bar is not valid in Turtle). Hence, some IRIs that are valid according to RDF concepts can't be serialized in Turtle. This sounds a bit sad to me.

[afs]

RDF Concepts already says:

An IRI in the RDF abstract syntax MUST be resolved per [RFC3986]

In fact, any IRI can be serialized, but reading it will resolve it. Outside of RDF, this happens as well e.g. browsers.

[gkellogg]

When I parse <http://example.com/foo/./bar> <http://example.com/bar> "1"^^<http://www.w3.org/2001/XMLSchema#integer> . as Turtle using http://example.org/ as the base IRI, I get the same thing back. This is because my code checks to see if it is a resolved or relative IRI and only does IRI resolution for relative IRIs. I believe this is correct, and I think there are tests for this.

[Tpt]

IRIs may be written as resolved IRIs, Relative IRI references, or prefixed names.

In fact, any IRI can be serialized, but reading it will resolve it.

Aren't the two statements in contradiction? Some IRIs can't be the output of the resolution algorithm (eg. http://example.com/foo/./bar) so can't be written as "resolved IRI" if I understand this term properly.

Also, it seems like a big foot-gun to me that one can write a Turtle file without any relative IRIs and get back after parsing it an RDF graph that is not isomorphic to the written one.

My implementation does the same thing as @gkellogg's one and only do IRI resolution for relative IRIs.

[afs]

Are there tests? I didn't see any resolution tests in rdf/rdf11 to cover this case.

IRI-resolution-01.ttl has a related comment

## Two answers:
## RDF 3986 section 5.2.2
## Strict resolving: <http:g>
## Non-strict resolving: <http://a/bb/ccc/g>

## <urn:ex:s042> <urn:ex:p> <http:g>.

because RDF 3986 allows two modes.

[afs]

Some material from RFC 3986 (it's scattered across the RFC):

https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.2.3

The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1) and are removed as part of
the reference resolution process (Section 5.2). However, some
deployed implementations incorrectly assume that reference resolution
is not necessary when the reference is already a URI and thus fail to
remove dot-segments when they occur in non-relative paths. URI
normalizers should remove dot-segments by applying the
remove_dot_segments algorithm to the path, as described in
Section 5.2.4.

relative references only occur when there is no scheme.
But the grammar shares "path" from both "hier-part" and "relative-part" and those two rules have the same definition .

https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.3

All URI references are parsed by generic syntax parsers when used.
However, because hierarchical processing has no effect on an absolute
URI used in a reference unless it contains one or more dot-segments
(complete path segments of "." or "..", as described in Section 3.3),

and https://datatracker.ietf.org/doc/html/rfc3986#section-3.3 "Path"

The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names.

Another relevant part of RFC 3986 is:
https://datatracker.ietf.org/doc/html/rfc3986#section-6.1

In testing for equivalence, applications should not directly compare
relative references; the references should be converted to their
respective target URIs before comparison.

so any meaning is the same.

At some point, the URI has to be sorted out, whether that is parser or use time, is left open ("murky") probably because RFC 3986 is carefully written given URI history from 2396.
(There is no "relative URI" - that was in 2396, but isn't in 3986. "relative reference" is closest.)

Section 5 is "Reference Resolution"

A URI reference must be transformed to its target URI before it can be normalized.

Section 5.2 "Relative Resolution" might on the surface allow not resolving but it says:

This section describes an algorithm for converting a URI reference
that might be relative to a given base URI into the parsed components
of the reference's target.

That "might" is somewhat significant.