Re: Multiple Contexts with expand/compact?

Hi Markus,

On Wed, Jul 16, 2014 at 3:41 AM, Markus Lanthaler <markus.lanthaler@gmx.net>
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.

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.

Secondly, it doesn't let the community add in their own extension services
without having it officially blessed in the master context, 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 ... )


> 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.

Hope that helps explain our approach!

Rob

-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305