Compact IRI generation in JSON-LD 1.1

There is a discussion going on in the Pull Request dealing with how IRIs are compacted in JSON-LD 1.1 [1]. Basically this PR deals with two related issues:

1) Compacting relative IRIs used as values of @id.
2) Determining appropriate terms to use for creating Compact IRIs when compacting.

In the first case, the behavior in JSON-1 1.0 is to always attempt to compact IRIs relative to the original document location. This has caused problems when compacted documents are re-published elsewhere, so a compactToRelative options has been added in 1.1, defaulting to true, to continue to allow this behavior. The argument for leaving it as true is for backwards compatibility, but it could also be argued that this was broken behavior in 1.0, and the default should be false.

When compacting and IRI that might be used for a @type value or for a property, if a term definition does not exist but a term exists that is a prefix, a processor will construct a compact IRI made up by using that prefix term, followed by the minimal suffix separated by a colon (‘:’). This behavior leads to unexpected results in 1.0 processors. A fix that could be applied independent of the processing mode would be to restrict the set of terms that can be used to form compact IRIs to just simple term definitions (those that do not have an object value), or to simple terms that end in a colon (‘:’), for which no intermediate colon needs to be added; this would be more of an errata-level change that would affect expected behavior of 1.0 processors.

To make things even more explicit, @dlongley suggests that, when in 1.1 processing more (e.g., “@version”: 1.1 is added to the context), only simple terms ending in a colon will be considered.

As not everyone on this list follows the details of issues and pull requests on GitHub, I wanted to open these issues up for comment on this list. Please either reply here, or on the pull request.

Gregg Kellogg
gregg@greggkellogg.net

[1] https://github.com/json-ld/json-ld.org/pull/511

Received on Tuesday, 4 July 2017 18:27:38 UTC