- From: Olivier Grisel <olivier.grisel@ensta.org>
- Date: Thu, 6 Oct 2011 12:23:00 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: "David I. Lehn" <dil@lehn.org>, Gregg Kellogg <gregg@kellogg-assoc.com>, Linked JSON <public-linked-json@w3.org>
2011/10/6 Markus Lanthaler <markus.lanthaler@gmx.net>:
>> I'm guessing the processing algorithm will be to process array
>> @contexts in order and you merge each new context (local or remote) on
>> top of the current context state. If so, that seems fine to me.
>
> I would say local contexts should always overwrite remote contexts
> regardless of the order. So first merge all remote contexts in order and
> then merge all local contests in order on top of that.
Why so? As the array is ordered, better state that the context is
processed by strictly following the order disregarding the fact they
are remote or not. If you want to make sure that local context info to
be processed last just put it at the end of the array. This is both
simpler to understand and more expressive:
For instance that would allow JSON-LD producer to define local context
info with reasonable defaults values to be overriden by a dynamically
generated remote JSON-LD document.
We just have to state explicity how to handle reference loops, for
instance for 2 documents doc1.json and doc2.json:
http://example.org/doc1.json
{
"@context": [
{
"somename": "http://example.org/ns1/somename"
},
"http://example.org/doc2.json",
],
...
}
http://example.org/doc2.json
{
"@context": [
{
"somename": "http://example.org/ns2/somename"
},
"http://example.org/doc1.json",
],
...
}
I assume the consumer will have to break those loops as soon as
detected while consuming, hence if it starts by parsing doc1.json the
resulting mapping for somename will be
"http://example.org/ns2/somename"
--
Olivier
http://twitter.com/ogrisel - http://github.com/ogrisel
Received on Thursday, 6 October 2011 10:23:57 UTC