jsonld.js and JSON-LD Playground deliver different compacted results

[nitmws]

I'm setting up a simple transformer from Turtle RDF to JSON-LD using this jsonld.js node module.
The expanded JSON-LD is ok: https://raw.githubusercontent.com/nitmws/rdf-jsonld-transformation-test1/master/testdata/sample069x.json
Then jsonld.compact(doc, context, {skipExpansion : true}, ... is executed

• compact is read from https://raw.githubusercontent.com/nitmws/rdf-jsonld-transformation-test1/master/ODRL22.jsonld
• output: https://github.com/nitmws/rdf-jsonld-transformation-test1/blob/master/testdata/sample069x%3Dcompact.json
  which includes "undefined" properties - this should not be the case.

Using the expanded JSON-LD and the context object with the JSON-LD Playground shows a better result: the "undefined" properties are "uid" properties as it should be the case. (https://json-ld.org/playground/#startTab=tab-compacted&json-ld=https%3A%2F%2Fraw.githubusercontent.com%2Fnitmws%2Frdf-jsonld-transformation-test1%2Fmaster%2Ftestdata%2Fsample069x.json&context=https%3A%2F%2Fraw.githubusercontent.com%2Fnitmws%2Frdf-jsonld-transformation-test1%2Fmaster%2Ftestdata%2Fsample069x%253Dcompact.json)

Simple question: what makes the difference?

[davidlehn]

The playground uses jsonld.js but it's currently using a quite old version. Are you using a recent jsonld.js and seeing the "undefined"s? I think that bug may have been addressed. If not, it would be good to create a minimal test case we could add to the test suite.

[nitmws]

I've installed the latest version of jsonld.js available by npm, package.json shows jsonld": "^0.4.12
Using this version results in the "undefined" properties.
And this project/repository can be used as test case: https://github.com/nitmws/rdf-jsonld-transformation-test1
The testdata are (they come from the work on the ODRL Recommendation of the W3C POE WG):

• sample069x - it includes a triple object not defined by ODRL (odrl:DELETE) for POE test purposes
• sample069x-corr got this corrected (odrl:delete)

... but that should not make a difference for the transformation. Both variants show "undefined" properties instead of a couple of different properties in the ...=compact.json files.

[davidlehn]

The problem is the following constructs in ODRL22.jsonld:

"uid":     {"@type": "@id", "@id": "@id"},
"type":    {"@type": "@id", "@id": "@type"},

uid isn't even being used but those constructs are apparently not handled well with any recent jsonld.js (recent 0.4.x or dev 0.5.x). Are you just trying to setup aliases for @id and @type? The following change will do that:

-    "uid":     {"@type": "@id", "@id": "@id"},
-    "type":    {"@type": "@id", "@id": "@type"},
+    "uid":     "@id",
+    "type":    "@type",

@dlongley @gkellogg: Does the above have defined behavior or should implementations error on it? If it's defined then we should add some test suite tests for it. If not, should this be defined in 1.1 or what should implementations do? Clearly jsonld.js shouldn't be spitting out "undefined" nonsense when this happens. Would be better to just have an error.

[nitmws]

Thanks for this feedback. My role is testing libraries for transforming Turtle into JSON-LD, I'm not a big JSON-LD expert. I'll forward this to the experts in the W3C POE group.

For clarification: why were the uids applied as expected on the Playground - because it uses a "quite old version"?

[davidlehn]

I'm not sure what the expected result is according to the spec for the input. But yes, the older code on the playground site (circa early 2016) and the new code produce different results. The new code should be doing just about anything but putting "undefined" into the output. I imagine we'll figure out what the spec says should be done, add some tests to the main JSON-LD test suite, and fix the code to do the right thing.

[nitmws]

ODRL has a property named uid and it provides the identifier of the object, therefore it should be treated as @id in JSON-LD. That was the goal of the mapping from uid to @id. As I was not on the team creating the @context I don't know why {"@type": "@id", "@id": "@id"} was used - but I'll try to find out.

[davidlehn]

I forgot I dealt with this before! There is a test case but the jsonld.js test suite is skipping that at the moment. Here's the PR with some discussion:
#183

[nitmws]

Makers of the ODRL context assumed that "uid": {"@type": "@id", "@id": "@id"} should work -
as the 5.1 Context section of the JSON-LD 1.0 Recommendation shows in Example 3 a comment on the - above claimed as wrong - "@type" : "@id" of "This means that a string value associated with 'homepage' should be interpreted as an identifier that is an IRI" which does not contradict or exclude their use: the value string of "uid" is the identifier of the node. It looks like the interpretation shown above is: a "uid": "@id" covers implicitly the type of uid as an @id value must be an IRI, an explicit definition is not allowed.
(And they had a similar assumption about "type": {"@type": "@id", "@id": "@type"} )

Interesting to see #183 covering exactly this issue.

[davidlehn]

The playground was updated to jsonld.js 0.5.17. The above should be fixed.