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.

[kidehen]

@Gregg,

My comments on this matter moved from digitalbazaar/jsonld.js#225 (comment) to here.

Fundamentally, this issue is a design bug in JSON-LD with regards to constructing RDF sentences/statements that adhere to Linked Data principles. There is nothing in RDF that disallows the use of relative HTTP URIs for denoting the predicates of RDF sentences/statements.

[pchampin]

@kidehen I don't see it as "a fundamental design bug": RDF (the abstract syntax) only allows absolute IRIs. Some concrete syntaxs, of course, allow relative IRIs in some places and resolve them during parsing. On the other hand, N-Triples (for one) does not allow any relative IRI.

That being said, I'm in favor of allowing relative IRIs as predicates or @type values in JSON-LD, but I would rather invoke the principle of least surprise than the Linked Data principles ;-)

[kidehen]

@pchampin,

"IRIs in the RDF abstract syntax must be absolute, and may contain a fragment identifier." specifically refers to the abstract syntax. Thus, as I've stated, we have a bug in JSON-LD with regards to its positioning as a concrete syntax (notation) for crafting RDF sentences in line with Linked Data principles.

A JSON-LD processor MUST (rather than SHOULD) generate absolute IRIs from document addresses when it encounters relative IRIs in content. Anything less is a vector for:

[1] Confusion
[2] Impeding the very underpinnings of Linked Data deployment using RDF sentences/statements.

[kidehen]

@pchampin ,

I can live with principle of least surprise with Linked Data deployed via JSON-LD as an example of where this surprise currently manifests :)

Folks have to be able to scribble equivalent of the following using JSON-LD, in line with what's possible via this RDF-Turtle example:

<#this> <#relatedTo> <#that> .

The http://example.com pattern used all over the place is a confusion vector that ultimately creates the impression that domain ownership is mandatory for Linked Data deployment .

[melvincarvalho]

Relative URIs are kind of a hard core use of RDF, at least, from my limited perspective.

However this is one area where turtle shines. Others being that you can parse it without needing async functions. And with upgrade paths to things like TriG and N3.

I've always been curious as to the standing of relative URIs in JSON-LD. At various times or other I've heard that they can be used or cant be used. As JSON-LD is quite a long spec, a short summary (or gist) on when and where they can be used in JSON-LD, might be appreciated, by more than just me! :)

[gkellogg]

In 1.0, a decision was made on relative URLs, separating document-relative from vocabulary-relative URLs. (some research on resurrecting the decision process is probably in order). Basically, keys and values of @type are evaluated relative to any @vocab definition in the context (unless specifically defined as terms in the context, or compact IRIs), and values of @id are interpreted relative to the document location (which may also be compact IRIs). This is not unlike the way that properties are resolved in RDFa and Microdata.

Another big distinction of JSON-LD compared with Turtle, RDFa and Microdata, is that a context can be a remote document, and does not need to be specified inline. If specified inline, then always resolving relative IRIs to the document is clear, but if it comes form a remote location, the question becomes what is the document location that is used to resolve these things.

Another criteria for JSON-LD is that things that aren't mapped in from the context are dropped, which is useful to allow for specifically ignoring things in JSON documents while extracting those things that are mapped. As a result, if there is no @vocab object keys that are not otherwise mapped in the context get dropped, as do their values.

The main distinction is that Turtle allows a prefix to be defined relative to the document, as Kingsley has shown, while JSON-LD doesn't have such a mechanism.

That said, the landscape JSON-LD 1.1 is facing is way beyond that of the 1.0 phase where we were struggling for adoption, and some things might be revisited, when they don't create interoperability issues. Specifically allowing the @vocab to be specified as @base might be a way to deal with this, and updating the vocabulary-relative IRI handling to use RFC3986 resolution rules, rather than simple string append.

[gkellogg]

More to do on this.

[kidehen]

@gkellogg,

Okay, I should be much clearer about the fact that my quest is for the use of "relative HTTP URIs" to identify the predicates of RDF statements when using JSON-LD notation :)

Resolving this is very important. I would like to always provide RDF-Turtle and JSON-LD examples when producing Semantic Web of Linked Data utility demos etc..

[kidehen]

@gkellogg,

Do we have any timeframe for implementing the parsing algorithm outlined at https://tools.ietf.org/html/rfc3986#page-30?

Right now, the issue of relative URIs for denoting RDF sentence predicates remains in limbo.

This is a serious problem.

Kingsley

[gkellogg]

@kidehen It's up for discussion on today's CG call. Perhaps a PR with changes ready by the end of the week, depending.

[gkellogg]

Do we have any timeframe for implementing the parsing algorithm outlined at https://tools.ietf.org/html/rfc3986#page-30?

Note that the document-relative IRIs are resolved using this algorithm, your issue is with vocabulary-relative IRIs. In general, changing the algorithm may introduce backwards compatibility issues. However, we're exploring the "@vocab": "@base" use case, which would allow relative IRIs to be resolved against the document base (per your examples). In that case RFC3986 resolution probably makes sense.

[gkellogg]

Discussed on call today. RESOLVED to adopt @vocab: @base gramar, and use RFC3986 resolution in this case.

[niklasl]

Mightn't this problem be resolved by simply allowing @vocab to be resolved against @base (instead of requiring it to be a full IRI)? From the examples given, I find that satisfactory, simpler, and most importantly we won't have to tamper with the value space of keys in surprising ways...

[kidehen]

@gkellogg,

Re "your issue is with vocabulary-relative IRIs" comment, it is clearer to me for this issue to be described as being about the ability to identifying the predicate of an RDF sentence/statement using a relative URI.

I doubt most RDF users and/or developers instinctively realize the existence of this problem -- without it being revealed using my preferred description :)

Anyway, I anxiously await the bug fix.

Kingsley

[kidehen]

Hi Gregg,

Example given:

{
  "@context": {
    "@base": "http://example/document",
    "@vocab": ""
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "#Restaurant",
  "#name": "Brew Eats"
  …
}

The “@vocab”: “” has the effect of using the current document base (either location, or set via @base) to create property IRIs. This would expand to the following:

[{
  "@id": "http://example.org/places#BrewEats",
  "@type": ["http://example/document#Restaurant"],
  "http://example/document#name": [{"@value": "Brew Eats"}]
}]

Is there any reason why this example has to include http://example.com? I would expect that eliminating the need for example.com (inline) is a testsuite and usage combo for the feature (proper HTTP URI resolution) introduced by this bug fix :)

Can't this example work without an @base directive?

[gkellogg]

The example can, indeed, without a @base declaration, although we’d need to add text to indicate what the assumed document location was to get the expanded results.

[gkellogg]

Kingsley, note that the example was changed in the PR to remove @base and describe in prose the document location. Please let us know if you're good with pulling #603 and closing this issue.

[kidehen]

@gkellogg ,

Okay for closure.
Thanks!

[kidehen]

@gkellogg ,

Please write out an example of this fix so that I can add it verbatim to my test at:
http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/Nanotations/base-test-3.txt

I assume none of the examples in my doc are correct (since they fail my QA), hence my request.

/cc @TallTed

[gkellogg]

Kingsley, there is an section that covers this. If you set @vocab to "", it will cause properties to be expanded relative to the document base.

It doesn't seem that the development playground is taking this right now, and we may need some more test coverage.

Personal issues will prevent me from looking at this in more detail for a while, but I think the spec text is clear. The example should include "@version": 1.1 to enable this.

[kidehen]

@Gregg,

None of the following work:

{
  "@context": {
    "@base": "http://example/document",
    "@vocab": ""
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "#Restaurant",
  "#name": "Brew Eats"
  …
}

or

{
  "@context": {
    "@vocab": ""
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "#Restaurant",
  "#name": "Brew Eats"
}

Please paste something that should work, Ideally something I can test with your online parsers etc..

/cc @TallTed

[azaroth42]

As @gkellogg mentioned, it also needs the @version: 1.1 within the context to require the processing mode. That said, I'm not certain whether the deployed -dev playground is up to date with this particular pattern.

[TallTed]

@gkellogg /cc @kidehen @iherman

I've just submitted a PR to add the "@version": 1.1 declaration to the example JSON-LD snippet, as this is necessary for the "@vocab": "" to have the desired effect. I think the following should deliver what we're looking for, once parsers are updated to handle JSON-LD 1.1 --

In its own document

{
  "@context": {
    "@version": 1.1,
    "@vocab": ""
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "#Restaurant",
  "#name": "Brew Eats"
  …
}

As a paste to the the dev playground parser

{
  "@context": {
    "@version": 1.1,
    "@base": "http://example.com/document"
    "@vocab": ""
  },
  "@id": "http://example.org/places#BrewEats",
  "@type": "#Restaurant",
  "#name": "Brew Eats"
  …
}

[gkellogg]

Mine should work, but can’t investigate right now. There is a Travis validation framework, but it does not yet check results.

[kidehen]

On 5/3/18 6:00 PM, Ted Thibodeau Jr wrote: @gkellogg <https://github.com/gkellogg> /cc @kidehen <https://github.com/kidehen> @iherman <https://github.com/iherman> I've just submitted a PR to add the ***@***.***": 1.1| declaration to the example JSON-LD snippet, as this is necessary for the ***@***.***": ""| to have the desired effect. I think the following should deliver what we're looking for, once parsers are updated to handle JSON-LD 1.1 -- In its own document { ***@***.***": { ***@***.***": 1.1, ***@***.***": "" }, ***@***.***": "http://example.org/places#BrewEats", ***@***.***": "#Restaurant", "#name": "Brew Eats" … } As a paste to the the dev playground parser <https://json-ld.org/playground-dev/> { ***@***.***": { ***@***.***": 1.1, ***@***.***": "http://example.com/document" ***@***.***": "" }, ***@***.***": "http://example.org/places#BrewEats", ***@***.***": "#Restaurant", "#name": "Brew Eats" … } — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#488 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABeGcZ_WKqz6RBc_4z0RRMRcQl3-qPBKks5tu330gaJpZM4NXrFE>.

I am still getting an error using  the example above. Is there an updated parser anywhere the implements this fix? The example should be: { "@context": { "@Version": 1.1, "@vocab": "" }, "@id": "http://example.org/places#BrewEats", "@type": "#Restaurant", "#name": "Brew Eats" … } i.e., @base removed. And the condition leading to the following error message shouldn't arise: jsonld.SyntaxError: Invalid JSON-LD syntax; the value of "@vocab" in a @context must be an absolute IRI. This entire effort is about supporting relative HTTP URIs, as per URI spec.

…

-- Regards, Kingsley Idehen Founder & CEO OpenLink Software (Home Page: http://www.openlinksw.com) Weblogs (Blogs): Legacy Blog: http://www.openlinksw.com/blog/~kidehen/ Blogspot Blog: http://kidehen.blogspot.com Medium Blog: https://medium.com/@kidehen Profile Pages: Pinterest: https://www.pinterest.com/kidehen/ Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen Twitter: https://twitter.com/kidehen Google+: https://plus.google.com/+KingsleyIdehen/about LinkedIn: http://www.linkedin.com/in/kidehen Web Identities (WebID): Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i : http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this

[kidehen]

@gkellogg,

I am kinda lost right now. Is there a place where one can test closure of this matter? I couldn't get anything going using your distiller either.

/cc @TallTed

[davidlehn]

@kidehen: jsonld.js (and therefore the playground) and pyld don't handle this newer test case yet.

@gkellogg: The compact #t0095 test was added with an empty vocab test. Should that have 1.1 @version and appropriate manifest options? Or is this supposed to work in 1.0 too?

[gkellogg]

It shoule either @version in context or processingMode in maniferst

[kidehen]

@gkellogg,

I can now confirm based on (my own test setup using our OSDS Browser Extension) that this matter is now resolved.
Examples that now work:

{
  "@context":
  {
     "schema": "http://schema.org/",
    "@base": ""  
  },
    "@id": "#BrewEats",
    "@type": "schema:Restaurant",
   "#name": "Brew Eats",
    "#databaseId": "23987520"
}

OR

{
  "@context":
  {
     "schema": "http://schema.org/"

  },
    "@id": "#BrewEats",
    "@type": "schema:Restaurant",
    "#name": "Brew Eats",
    "#databaseId": "23987520"
}