json-ld serialisation and URIs/predicate overlapping about jena HOT 5 CLOSED

Hi @fatzh,

Jena uses jsonld-java for reading JSON-LD 1.0 and uses titanium-json-ld to parse JSON-LD 1.1.

Jena uses jsonld-java for writing JSON-LD (so JSON-LD 1.0). Note - your data does not have "@ version" (space added to not name a GH user!)

When I parse the [ "book:_B", "book:_C", "book:_2", "book:_1", "book:_A" ] I get different RDF between JSON-LD 1.0 and 1.1 across json-ld-java and titanium. Same for the JSON-LD playground does the same for JSON-LD 1.0 vs 1.1.

See a users@jena thread:
https://lists.apache.org/thread/zl0c6jgxnc9ckmc5pvhcoy72ypyr41fp

Suggestion - could you add a prefix to the data for book:? The writer tries to use the prefixes to build the context.

It looks like a difference between JSON-LD 1.0 and 1.1.

from jena.

hi @afs ! thanks, indeed it seems ok when parsing with @version: 1.0. I guess at some point jsonld-java will support 1.1, they seem to be on it.

Note - your data does not have "@ version"

the data is what I get back from Jena, I guess I can live with it for now, but good to know.

from jena.

@gkellogg -- Hi Gregg, the 1.0 and 1.1 playgrounds confirm this difference in behaviour for the "book:YYY".

If you have a moment, could you point to which of items in https://www.w3.org/TR/json-ld11/#changes-from-10 is causing this?

Simplified version:

{
  "@id" : "http://example/collection",
  "http://example/p" : [ "book:ZZZ" ],
  "book" : [ "book:YYY" ],
  "@context" : {
    "book" : {
      "@id" : "http://onbetween.ch/3ms/cms#",
      "@type" : "@id"
    }
  }
}

gives 1.0 playground:

<http://example/collection> <http://example/p> "book:ZZZ" .
<http://example/collection> <http://onbetween.ch/3ms/cms#> <http://onbetween.ch/3ms/cms#YYY> .

or 1.1 playground:

<http://example/collection> <http://example/p> "book:ZZZ" .
<http://example/collection> <http://onbetween.ch/3ms/cms#> <book:YYY> .

from jena.

Yes, this was intentional, as terms were used too liberally as prefixes, which caused unintended consequences. The note in the Changes since 1.0 Recommendation of 16 January 2014 says the following:

In JSON-LD 1.1, terms will be used as compact IRI prefixes when compacting only if a simple term definition is used where the value ends with a URI gen-delim character, or if their expanded term definition contains an @Prefix entry with the value true. The 1.0 algorithm has been updated to only consider terms that map to a value that ends with a URI gen-delim character.

The operative step is Step 10 in the Create Term Definition Algorithm

Create a new term definition, definition, initializing prefix flag to false, protected to protected, and reverse property to false.

And step 14.2.5:

If term contains neither a colon (:) nor a slash (/), simple term is true, and if the IRI mapping of definition is either an IRI ending with a gen-delim character, or a blank node identifier, set the prefix flag in definition to true.

The operative bit is that this is not a simple term.

This can be changed by adding "@prefix": true to the term definition (playground link):

{
  "@id" : "http://example/collection",
  "http://example/p" : [ "book:ZZZ" ],
  "book" : [ "book:YYY" ],
  "@context" : {
    "book" : {
      "@id" : "http://onbetween.ch/3ms/cms#",
      "@type" : "@id",
      "@prefix": true
    }
  }
}

from jena.

@gkellogg -- thanks for the details.

from jena.