The words relative IRIs and resolve should NOT be used with Prefix Names / CURIEs

[gcarothers]

[09:38] Gavin, note that the suggestion to use the empty prefix in lieu of base wasn't to say that it is the same as Turtle, but that it is an alternative.
[09:38] For some reason, many had strong objections to introducing @base.
[09:41] That's fine, the words that don't work are Instead, authors may use a prefix definition to resolve relative IRIs:
[09:41] Prefix doesn't work by RESOLVING relative IRIs
[09:41] Prefixes have nothing to do with relative IRIs nor with resolving
[09:41] Prefixes are simple concat
[09:45] Yes, the empty prefix wasn't intended to resolve relative IRIs, but as a way of using CURIE syntax in a way that some might use as an alternative to @base.
[09:45] I don't much care for it, but if there is no @base, CURIE is the only real alternative.
[09:55] Yeah, I just don't think the words relative IRIs and resolve should be used with Prefix Names / CURIEs

[gkellogg]

Expand may be a better term than resolve. In wondering if a prefix can be defined as a relative IRI, so that expanding a compact IRI could result in a relative IRI? We don't every seem to say that a term must expand to an absolute IRI, just an IRI.

[gcarothers]

On Sun, Aug 19, 2012 at 1:23 PM, Gregg Kellogg notifications@github.comwrote:

Expand may be a better term than resolve. In wondering if a prefix
can be defined as a relative IRI, so that expanding a compact IRI could
result in a relative IRI? We don't every seem to say that a term must
expand to an absolute IRI, just an IRI.

No, CURIEs/Prefix names are expanded via simple concatenation. Resolve and
relative imply using the URI/IRI/URL rules which would result in
very different IRIs. Also it must in fact be an absolute IRI as
a relative IRI used in a prefix definition must be first
resolved relative to the current base URI.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/141#issuecomment-7856463.

[gcarothers]

That is to say, EXPAND is fine. The rest isn't.

[gkellogg]

Well, what if I have the following?

{ "@context": { "foo": "foo/bar#" }, "http://example.com/prop": {"@id": "foo:baz"}}

If that document is located at http://example.org/doc, I could see the following happening:

1. foo:baz expands to foo/bar#baz.
2. this is resolved as a relative IRI against http://example.org/doc to yield http://example.org/foo/bar#baz.

This involves both expansion and resolution. I believe this may be a reasonable interpretation, but not necessarily one we want to support. Either way, we need to add something to describe required behavior.

I can't recall, does Turtle require that the value of a @Prefix be an absolute IRI? If not, how do you handle this?

[gcarothers]

The value IRI side of prefix bindings in Turtle is resolved at the time of binding. Anything else leads to insanity. ;) Basically reverse your step 1 and 2.

{ "@context": { "foo": "foo/bar#" }, "http://example.com/prop": {"@id": "foo:baz"}}

1. resolve foo/bar# to http://example.org/foo/bar# and bind to foo:
2. expand foo:baz to http://example.org/foo/bar#baz

[gkellogg]

Looking at my implementation, I see that when I process the context, I do use the document base to expand relative IRIs, so my implementation does work as you say. However, the algorithm is actually not specified that way. The algorithm requires that terms expand to absolute IRIs within the context, without regard to a document base. As I understand exception processing, if after looping a sufficient number of times, the term does not expand to an absolute IRI, it does not create a term mapping.

So, it seems that, as written, this can't really happen, but the processing the corner case still needs to be made more explicit.

So, the result is that my example document wouldn't end up expanding to any output, as "foo" would never map to an IRI in the first place.

Evaluating the context using the document base is something we should consider, though, as it can be useful, IMO.

(another thing is allowing a context specified as an IRI to be document relative; something I've done in the past, which is particularly useful before a site is published, or during development).

[msporny]

@gcarothers Does this solution work for you? Do you feel that the document was reworded to address your concerns?

[gcarothers]

Yes, I find this solution acceptable (I might include xml:base not just base from Turtle depending on the background from XML and HTML)