Different behavior when parsing a JSON-LD containing an embedded context vs. a referenced context

[rorlic]

Version

4.10.0

What happened?

I'm using the Jena CLI tools to test parsing a json-ld file containing a referenced context ("@context": "https://...") and noticed that the @base is not applied to the identifiers (@id). When copying the context into the json-ld file ("@context": {...}) this works just fine as expected.

Example files can be found here: referenced context and embedded context. The referenced context can be found here.

Relevant output and stacktrace

$ riot example.context-by-url.jsonld 
<file:///Users/rankoo/dev/json-ld-test/context-test/document-id> <http://www.w3.org/2000/01/rdf-schema#label> "Just a simple document" .

$ riot example.context-embedded.jsonld 
<http://example.com/document-id> <http://www.w3.org/2000/01/rdf-schema#label> "Just a simple document" .

Are you interested in making a pull request?

None

[rorlic]

FYI: according to the JSON-LD Context Processing Algorithms at Context Processing Algorithm:

If context is a string, it represents a reference to a remote context. We dereference the remote context and replace context with the value of the @context entry of the top-level object in the retrieved JSON-LD document.

So, I would expect the same behavior in both cases.

[rorlic]

Should I report this to titanium instead?

[afs]

Hi there - sometimes it takes a while to get to issues.

I tried example.context-by-url.jsonld at https://json-ld.org/playground/ and it raised an error on fetching the context but I don't think that is the problem. Something must have happened because an rdfs:label property is produced.

It could be the way Jena calls Titanium (version 1.3.3)

https://github.com/apache/jena/blob/a2e5f53aa752f6c52d15b37b6a942a24a25f5058/jena-arq/src/main/java/org/apache/jena/riot/lang/LangJSONLD11.java#L107-L113

though then I'd expect it to happen in both examples.

So it looks to me like a Titanium issue (caveat that I'm not a heavy JSON-LD user).

[rorlic]

Hi, thank you for looking into this.

The reason it does not work for you in a browser is indeed CORS. If you use chrome you can fix this by installing a chrome extension which allows you to control CORS.

However, it does work in the JSON-LD playground (which uses a javascript library called jsonld.js). The result for both examples in triples is:

<http://example.com/document-id> <http://www.w3.org/2000/01/rdf-schema#label> "Just a simple document" .

Interesting enough, I see the same incorrect behaviour if I try it using EasyRDF Converter (which uses its own PHP implementation for JSON-LD parsing). Browsing through their unit tests I do not see a test using a remote context, so they most likely also suffer from a similar problem.

So, how do you suggest we proceed given that it is most likely a Titanium issue?

[afs]

So, how do you suggest we proceed given that it is most likely a Titanium issue?

Raise an issue on the Titanium repository. Ideally, with copies of the test files so the report is self-contained (copies means they are preserved long term).

I found two closed issues in the general area that might be related, although they are not looking like they are exactly the same:

https://github.com/filip26/titanium-json-ld/issues/63 https://github.com/filip26/titanium-json-ld/issues/67

[afs]

@rorlic Did this get raised as an issue on titanium-jsonld?

jena is has recently been upgraded to titanium-jsonld version 1.4.0 but the outputs haven't changed.

[afs]

Raise an issue on the Titanium repository.

Closing because this is an issue for the dependency.