Base URL is not always absolute in Context Processing

[kasei]

(Related to #265, #356)

Context Processing step 5.2.1:

Initialize context to the result of resolving context against base URL.

This base URL comes directly as the argument to this algorithm. However, in at least one case, the value of base URL is not an absolute IRI.

The expand() defintion in JsonLdProcessor Interface step 5 says:

If the expandContext option in options is set, update the active context using the Context Processing algorithm, passing the expandContext as local context and expandContext as base URL.

In test t0077, the value of "expandContext" is simply "0077-context.jsonld", which will cause Context Processing to attempt to resolve a relative IRI against another relative IRI. I don't think that's what is intended here.

[gkellogg]

See #370 (comment), but in this case "expandContext" should have "@type": "@id", which means that "0077-context.jsonld" would be resolved relative to the manifest location, so would be https://w3c.github.io/json-ld-api/tests/0077-context.jsonld.

The convention had been to resolve the expandContext against the input file location, but I don't see any discussion of this. This would be https://w3c.github.io/json-ld-api/tests/expand/0077-context.jsonld, which is the intent.

The manifest context should be updated to set @type: @id on expandContext and the value changed to "expand/0077-context.jsonld", which would generate a valid absolute IRI when processing.

[gkellogg]

Pending fix in #377.

[kasei]

@gkellogg I think it's a very bad idea to require correct JSON-LD expansion of the test manifest in order to correctly run the tests. Changes in #377 are nice to have, but I don't think requiring that sort of processing should be necessary.

[gkellogg]

Manifests are RDF documents, you can parse them to RDF and use them that way, as you might with Turtle or SPARQL. I typically turn them into JSON-LD for convenience.

Everywhere else a property is an IRI it is typically given as a relative value, this is really no different. Why would expandContext be treated any differently than input or result?

[kasei]

Manifests are RDF documents

Am I right in saying that the current manifests are only available in JSON-LD and HTML? If so, I don't think it's reasonable to assert that they're to be treated as RDF documents, as that means that anyone wanting to run the JSON-LD tests must already have access to a fully conforming JSON-LD implementation of the expansion and toRdf algorithms. If you make the manifests available in another (simpler) RDF format my objection here would be reduced, but I can't understand requiring a fully confirming JSON-LD implementation to support testing a JSON-LD implementation.

[gkellogg]

Turtle manifests are in Turtle (as are N-Triples). Whether parsed as RDF, expanded, or used as is (that is the advanatage of JSON-LD, after all) it’s important to be consistent. The expandContext as a string is interpreted as a URL.

But, I’m really not clear on what point you’re going for and what change would satisfy you.

[gkellogg]

Updated in #377.

[kasei]

Turtle manifests are in Turtle (as are N-Triples).

With all due respect, JSON-LD is substantially more complicated than Turtle and N-Triples, and neither of those manifests is more complicated than listing an input file, and an expected output file.

The expandContext as a string is interpreted as a URL.
But, I’m really not clear on what point you’re going for and what change would satisfy you.

I think at the very least, the manifest documentation needs to call this out as a field that needs to be treated as a URI (and so resolved before the test is run).

[gkellogg]

I added wording in the README and manifest HTML documents about this. It can also be inferred by looking at the context definition in tests/context.jsonld.