Relative IRI Reference should bind to the irelative-ref production

[gkellogg]

From w3c/rdf-turtle#89 (comment), the definition for relative IRI reference should clarify that this is for IRI references matching the irelative-ref production in the IRI Grammar.

[afs]

It could do but the doc also says

An IRI reference refers to either a resolved IRI or relative IRI reference

so resolving happens in all cases.

[gkellogg]

My intention was to narrow the definition of a "relative IRI reference", which is certainly a kind of "IRI reference".

We can say that an IRI reference is either a "resolved IRI" or "relative IRI reference" while still narrowing the definition of "relative IRI reference" to be those that conform to the irelative-ref production.

My read of the Turtle IRIREF production is that only relative IRI references use the resolution algorithm, which I believe is correct, if relative IRI references are not resolved IRIs.

[afs]

My read of the Turtle IRIREF production is that only relative IRI references use the resolution algorithm, which I believe is correct, if relative IRI references are not resolved IRIs.

The IRREF section is at odds with earlier text in Turtle and with RDF Concepts where it says "Resolved IRIs".

Actually, it is broader than that: the IRIREF rule allows illegal IRI output:

The characters between < and > are taken, with the numeric escape sequences unescaped, to form the IRI.

It is just characters between < and >. They may not be a legal IRI.
What about <]][[[> or <:colonSegment> or <http://example/path#frag#frag>?
(aside from what "to form" could be read as; it could be read as "some process", not fixed as take characters as given).

Legal IRIs comes by being in the RDF abstract syntax.

We can say that an IRI reference is either a "resolved IRI" or "relative IRI reference"

In Turtle 6.3 "6.3 IRI References"? The turtle doc says "IRI References" but then talks about "Relative IRI References" and links to non-normative text in RDF Concepts.

I can't see any way using "resolved" can mean something other than "5. Reference Resolution" has been applied.

(The trouble is resolved is more than base URI, as we are finding out, but I would expect many people to see it only in that context.)

FWIW: "the basic algorithm in section 5.2." - there isn't a "basic algorithm" in section 5.2 - probably means not the later section on normalization.

[gkellogg]

The IRREF section is at odds with earlier text in Turtle and with RDF Concepts where it says "Resolved IRIs".

I don't see that. In RDF Concepts "resolved IRIs" are mentioned informatively in two places:

• IRI equality: Two IRIs are the same if and only if they consist of the same sequence of Unicode code points, as in Simple String Comparison in section 5.3.1 of [RFC3987]. (This is done in the abstract syntax, so the IRIs are resolved IRIs with no escaping or encoding.) Further normalization MUST NOT be performed before this comparison.
• An IRI reference refers to either a resolved IRI or relative IRI reference, as described by the IRI-reference production in E. IRI Grammar. The abstract syntax uses only fully resolved IRIs.

In Turtle:

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

In Turtle 6.3 "6.3 IRI References"? The turtle doc says "IRI References" but then talks about "Relative IRI References" and links to non-normative text in RDF Concepts.

IIRC, we only informatively talk about IRI references in concepts (other than 6.3), and define terms because they come from RFC3986/7. 6.3 IRI References says how Relative IRI references are resolved.

I can't see any way using "resolved" can mean something other than "5. Reference Resolution" has been applied.

Looks like a big hole somewhere, more than one Turtle parser does not resolve all IRIs using Reference Resolution. And, of course, N-Triples does not do any form of IRI resolution, so if Turtle were to always resolve references, then <http://example.com/foo/./bar> <http://example.com/bar> 1 . would parse to a different triple in Turtle then it does in N-Triples, and there would be no way (short of using escapes) to write IRIs with dot-segments in Turtle and have them survive after insertion into a graph.

How do you suggest we resolve this? (sic)

[gkellogg]

should be resolved before CR

[w3cbot]

This was discussed during the #rdf-star meeting on 07 August 2025.

[w3cbot]

This was discussed during the #rdf-star meeting on 07 August 2025.

[TallTed]

In the title of this, issue, please s/the irelative-ref/the relative-ref/

(spotted by @sdasoracle)

Reading more deeply, not actually an error, though confusing.

[w3cbot]

This was discussed during the #rdf-star meeting on 04 September 2025.

View the transcript

Issue 169 Relative IRI Reference should bind to the irelative-ref production (by gkellogg) [ms:CR] [spec:editorial]

ora: what about w3c/rdf-concepts#169

---