W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2014

Re: Context Questions

From: Gregg Kellogg <gregg@greggkellogg.net>
Date: Mon, 3 Feb 2014 13:22:42 -0800
Cc: Linked JSON <public-linked-json@w3.org>
Message-Id: <17168C8F-1942-4E6D-8BC1-718C7AE70607@greggkellogg.net>
To: Markus Lanthaler <markus.lanthaler@gmx.net>


Gregg Kellogg
Sent from my iPhone

> On Feb 3, 2014, at 12:56 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
> 
>> On Monday, February 03, 2014 9:36 PM, Robert Sanderson wrote:
>> Dear all,
>> 
>> Apologies if I'm missing something in the spec but ...
>> 
>> 1.  Can a context document contain a list of further context
>> documents? For example, to inherit a context from an external
>> specification into a content document, one could define a context
>> document (example.org/context.json) with the representation:
>> 
>> {
>>  "@context" : [
>>    "http://www.w3.org/2013/json-ld-context/rdfa11",
>>    "http://www.openannotation.org/spec/core/context.json",
>>    {
>>      "local" : "http://example.org/",
>>      "property" : {"@id" : "local:property"}
>>    }
>>  ]
>> }
>> 
>> I don't see anything that this violates?  So we can chain contexts all
>> the way down?
> 
> Yes, that works
> 
> 
>> Processors will correctly barf on circular references,
>> where context A includes context B, which includes context A?
> 
> Yep.
> 
> 
>> 2.  If a document contains an @context definition AND the response has
>> a context link header, which takes precedence? In other words, is the
>> link header "seen" before the document's context, or vice versa?  Or
>> is @context in the document ignored when the response is
>> application/json ... and if so, is this a consistent rule?  Thus, any
>> document that looks like JSON-LD but has the regular JSON media type
>> MUST NOT be processed as JSON-LD?  If so, that's kinda harsh,
>> especially in this early period where application/ld+json isn't widely
>> known.  (eg section 6.8)
> 
> Link headers are ignored for application/ld+json responses and (at least
> theoretically) @context should be ignored in all other documents. In
> practice, however, I assume most implementations will use embedded
> @context's. The processor starts with the one in the link header and then
> adds the ones in the document.

Once processing starts for a document, it MUST include processing embedded &context definitions, even if it was passed using application/json originally. But, why wouldn't you just use application/ld+json if you're serving a JSON- LD document?

>> And merging the two questions, if the local context referred to in a
>> link header references other context documents, then we should expect
>> those definitions to be processed?
> 
> Sorry, I don't think I understand this question.

I thin I do: context documents are parsed according to the spec, which includes accessing further remote contexts. It doesn't matter if the context comes from a link header, direct API parameter, or as part of a JSON-LD doc.

> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
Received on Monday, 3 February 2014 21:23:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:41 UTC