Properties can not be relative IRIs -- requires better documentation

[pchampin]

It recently came as a surprise to me that, in JSON-LD, you can not use a relative IRI as a property. In this example, the key "./baz" is ignored (although "./bar" is correctly interpreted as a value of @id).

Then I realized that this is probably a feature, not a bug, and I can see the rationale. After digging into the spec, I also realized that it is indeed documented in the Expansion algorithm (it all comes down to document relative defaulting to false in the IRI Expansion function).

However, I think other people might get confused by it, especially because nothing in the JSON-LD syntax document hints at this. On the contrary, section 5.2 states

In JSON-LD, IRIs may be represented as an absolute IRI or a relative IRI.

And Section 8.2 states:

All keys which are not IRIs, compact IRIs, terms valid in the active context, or one of the following keywords MUST be ignored when processed:

Ironically, in many other places of the spec, absolute IRIS and relative IRIs are both explicitly mentioned as allowed (e.g. as values of @id or @context).

The most obvious solution would be to replace "IRIs" by "absolute IRIS", in the sentenced quoted above. I would even argue in favor of a note, drawing the reader's attention to the fact that relatives IRIs as keys are deliberately ignored in JSON-LD.

[gkellogg]

A relative IRI may be used as a key, as long as, when expanded, it resolves to an absolute IRI. Practically speaking, this would require an @vocab be defined in the context, or that a term which is exactly the same as the IRI be defined.

If this is confusing, it may be worth adding a note to the grammar section.

[pchampin]

Terms resolved by @vocab are not treated as relative IRIs (as far as I can tell, they are simply concatenated), so for me it falls under the category of "terms valid in the active context" -- indeed, a @vocab makes basically any term valid.

If it was a relative IRI, my understanding is that the @base would be used to turn it into an absolute IRI; but for keys, this is not the case, @base is not used. So relative IRIs, as I understand them, are systematically ignored.

[gkellogg]

You're correct that @vocab is used, but such IRIs are not systmatically ignored, unless there is no value for @vocab.

Values interpreted as IRIs fall into two categories: those that are document relative, and those that are vocabulary relative. Properties and values of @type, along with terms marked as @type: @vocab are vocabulary relative, meaning that they need to either defined terms, a compact IRI, where the prefix is a term, or a relative IRI resolved using @vocab.

Looking at the Expansion Algorithm, you can see in step 8.2 that key is expanded using the IRI Expansion algorithm, passing active context, key for value, and true for vocab.

The IRI Expansion Algorithm in step 5 does If vocab is true, and active context has a vocabulary mapping, return the result of concatenating the vocabulary mapping with value. Thus a relative IRI is turned into an absolute IRI by concatenating the value to the @value. Granted, this does not use normal relative IRI resolution algorithm as in step 6, but it will result in an absolute IRI.

In your example, if the key was "./baz", and @vocab was "http://example.com/" the result should be "http://example.com/./baz", which is an absolute IRI.

[pchampin]

I see your point, and I could live with that; then your second paragraph above (which is a very clear summary of that point of view) would definitely have to be included somewhere in the spec.

My problem is that several parts of the spec contradict this broader definition of "relative IRI":

Section 1.7

@base: Used to set the base IRI against which relative IRIs are resolved.

→ Should at least be rephrased to "against which some relative IRIs are resolved".

Section 3.2

In JSON-LD all relative IRIs are resolved relative to the base IRI.

→ Clearly not all of them, only document-relative IRIs, not vocab-relative IRIs.

Section 4.2

JSON-LD allows IRIs to be specified in a relative form which is resolved against the document base according section 5.1 Establishing a Base URI of [RFC3986].

→ Again, not necessarily the document base. And it is not correct that all relative IRIs are resolved according to RFC3986: vocab-relative IRIs use a simpler algorithm (simple concatenation).

(ibid)

Setting @base to null will prevent relative IRIs to be expanded to absolute IRIs.

→ Only document-relative IRIs. This won't affect vocab-relative IRIs.

[gkellogg]

@pchampin please see if PR #573 addresses your concern; I found the cleanest thing to do was to re-define the term relative IRI to make it clear it only refers to things which are relative to the document base, along with some of the explanatory notes you suggested.

[gkellogg]

As this issue keeps coming up (see digitalbazaar/jsonld.js#225), perhaps we should consider a syntax to allow proprerties and types to be evaluated relative to the document base, instead of the vocabulary base. For example:

{
  "@context": {"@vocab": "@base"},
  "@id": "#BrewEats",
  "#databaseId": "23987520"
}

might resolve both "#BrewEats" and "#databaseId" against the document location.

[pchampin]

@gkellogg PR #573 makes things much clearer. Thanks.

As for allowing (base-)relative IRIs as @type values and properties, I think that would indeed meet the expectations of many people -- well, it would meet mine, at least ;-)

My intuition regarding @vocab is that it exists to allow "prefix-less" terms to be used. Anything containing a slash or a hash looks like a relative IRI, and should be treated as such, IMHO (i.e. resolved against the base IRI).

Granted, that would break compatibility. Currently:

{ "@context": { "@vocab": "http://example.org/V/", "@base": "http://example.org/B/" },
  "./foo": "bar",
}

interprets ./foo as http://example.org/V/./foo; with my proposal, it would now mean http://example.org/B/foo.

But do many people use @vocab that way? And if they do, do they intend it that way? Especially considering that, from RDF's point of view, http://example.org/V/./foo is not the same as http://example.org/V/foo? I doubt it, so I could live with this.