- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 16 Jul 2014 12:41:36 +0200
- To: "'Gregg Kellogg'" <gregg@greggkellogg.net>, "'Robert Sanderson'" <azaroth42@gmail.com>
- Cc: "'Linked JSON'" <public-linked-json@w3.org>, <iiif-discuss@googlegroups.com>
On Jul 14, 2014, at 10:51 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> Thanks for the response Gregg!
>
> > > When the document is expanded, the @context in the embedded service
> > > block is processed, and the correct RDF representation is generated.
> > > However, the @context for the block is lost, so when it's later
> > > compacted, the remote fields don't get returned to the nice JSON keys
> > > they started out with.
> > >
> > > Is there a solution for this, other than having a single context with
> > > all of the mappings in it? This doesn't help for external contexts
> > > however, as we expect to make use of the GeoJSON-LD context and
> > > structure. For more about our approach in this regard, see:
> > > http://iiif.io/api/annex/services/
Why doesn't it help? You can reference remote contexts in remote contexts.
So you could, e.g., create a context like this
{
"@context": [
"http://geojson.org/contexts/geojson-base.jsonld",
"http://iiif.io/api/presentation/2/context.json",
"http://iiif.io/api/image/2/context.json"
]
}
at "http://iiif.io/api/2/context.json given that none of the terms defined
in those contexts collide. I actually would find that much better. I'm not a
big fan of changing/adding contexts in the middle of a document as it makes
it very difficult for people to keep track what's the active context in each
subtree.
--
Markus Lanthaler
@markuslanthaler
Received on Wednesday, 16 July 2014 10:42:11 UTC