Re: Context processing of object without @context

Gregg Kellogg

On Aug 26, 2013, at 7:56 AM, Dave Longley <> wrote:

> On 08/26/2013 02:11 AM, Gregg Kellogg wrote:
>> Step 3.2.3 of the Context Processing Algorithm still indicates that it's an error if the dereferenced context is not an object containing @context. Looking in the resolution we did on Aug 6 [1], the CG agreed that remote context documents are required to contain @context to be valid. However, our tests (e.g., compact-0001) are defined through a manifest the references IRIs for the input document and context. compact-0001-context.jsonld [2], is in fact, a document containing an empty object. There are numerous other tests that are much like this.
>> Clearly, either people have been running these tests by dereferencing the test files and providing them as immediate values to the algorithms, or have some other mechanism which allows for an empty object. (In my case, I was running these tests in a more permissive mode before, and thus did not stop when this was detected.
>> From the API, if the input document is a DOMString, it's dereferenced before calling the algorithm; this is not the case for a context. We should clarify that the test runner should treat each test parameter as a DOMString (being the absolute IRI that is the property value, after fully expanding the manifest based on it's URL).
> Hmm, this is problematic because there is different behavior (sometimes, eg: @base?) for remote contexts vs. local ones. I don't think that we're always supposed to treat the parameter given to the API document as a remote context (if it is a URL, yes, but otherwise no). So, we wouldn't have any way, other than inlining the contexts in the manifests, to specify that a context is not remote.

I think that's what we'd need to do; moreover, to survive a transformation to RDF, I think an inline context would need to be encoded in a string. Taken as is, a test entry lists input, context, and expect all as IRIs, which become fully expanded, so the context is always specified given a URL. If we make it a value (perhaps with a special datatype), we could then specify an immediate value to be used for the context.

Similarly, we don't have a way to specify an immediate input document to a test (although that's probably not too important). Perhaps something like the following:

  "@context": ["", {"inline_context": {"@id": "context", "@type": "jld:SerializedJSON"}},
  "@id": "",
  "@type": "mf:Manifest",
  "name": "Compaction",
  "description": "JSON-LD compaction tests use object comparison.",
  "baseIri": "",
  "sequence": [{
      "@id": "#t0001",
      "@type": ["jld:PositiveEvaluationTest", "jld:CompactTest"],
      "name": "drop free-floating nodes",
      "purpose": "Unreferenced nodes not containing properties are dropped",
      "input": "compact-0001-in.jsonld",
      "inline_context": "{}",
      "expect": "compact-0001-out.jsonld"

> It would be better, perhaps, to specify that the test suite context given in by context parameter is *not* remote. Rather, if that context references another one via a URL, only then will the context be considered remote. This gives us the ability to provide both types of contexts for testing.
>> The easiest resolution for the test cases would be to change all context documents containing just an empty object to contain an empty context:
>> {
>>   "@context": {}
>> }
>> I recall having this discussion some time ago, and some people passed the context as a value, while others as an IRI. I think it's clear that the test manifest provides an IRI, and we need to be clear that we're invoking the algorithms appropriately.
>> Gregg Kellogg
>> [1]
>> [2]
> -- 
> Dave Longley
> Digital Bazaar, Inc.

Received on Monday, 26 August 2013 15:20:57 UTC