RE: Multiple Contexts with expand/compact?

Sorry for the delay Rob

On Wednesday, July 16, 2014 6:36 PM, Robert Sanderson wrote:
> On Wed, Jul 16, 2014 at 3:41 AM, Markus Lanthaler wrote:
> > On Jul 14, 2014, at 10:51 AM, Robert Sanderson <azaroth42@gmail.com> wrote:
> > > > > 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"
> >     ]
> >   }
> 
> The issue that we have with this approach, which we did explore, is
> that it explicitly ties those versions of the contexts together.  We
> expect that the presentation and image APIs will have their own
> separate version progressions, they're only both 2.0 at the moment
> because we just officially adopted semantic versioning and updated
> from Image 1.1 and Presentation 1.0 at the same time.  There is also
> likely to be REST, authentication/authorization, perhaps video or
> other related APIs.  And importantly, we want to be able to mix and
> match the APIs to use, for example, Image 2.1 with Presentation 1.0.

It's very cheap to define contexts, even dynamically. Similar to JS CDNs you could set up a service which allows users to combine those contexts on the fly:

  http://iiif.io/api/context/presentation1-image1.1.jsonld

That context could then contain all term definitions itself instead of just referencing the requested contexts.


> We've tried to limit the exposure by only including the major version
> number in the URI, but that doesn't allow for cross major version
> usage.

Yep


> Secondly, it doesn't let the community add in their own extension
> services without having it officially blessed in the master context,

What does "officially blessed in the master context" mean? As far as I understand, there's no "master context" (single context that contains everything needed).. at least not till now, right?


> which we see as a major advantage of multiple context nodes.  Also, by
> including potentially many contexts in a list, it slows processing for
> everyone as their code goes to retrieve everything, rather than only
> those contexts that are actually used.
> (Yes, that code /should/ cache all those contexts but ... )

True, but you can build the complete combined context server side instead of forcing clients to retrieve multiple contexts as outlined above.


> > 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.
> 
> Yes, but we can't guarantee that going forwards.  For example geoJSON
> might introduce terms in the future that could collide with ours, and
> other future imports could do the same from the beginning.  We're keen
> to not duplicate existing work, and that includes context definition.

How will you avoid these collisions then? Are you assuming that the contexts used in a specific JSON subtree don't contain colliding terms?


> Hope that helps explain our approach!

It does, yeah. I'm currently on a plane and writing this offline. Could you please file a issue on GitHub [1] so that we don't forget this use case.


Thanks,
Markus


[1] https://github.com/json-ld/json-ld.org/issues


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 21 July 2014 18:50:42 UTC