Re: Multiple Contexts with expand/compact?

Hi Markus, all,

On Mon, Jul 21, 2014 at 11:49 AM, Markus Lanthaler <markus.lanthaler@gmx.net
> wrote:

> Sorry for the delay Rob
>

No problem :)


> > The issue that we have with this approach, which we did explore, is
> > that it explicitly ties those versions of the contexts together.
>
 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.
>

That's true, and we didn't consider that as an option.  The concern that I
(personally) have is one of caching and the ability to recognize the
contexts without dereferencing and inspecting them every time.

For example, a client should probably determine whether the JSON document
that it's reading is actually an instance of the expected API.  The easiest
way to do that at the moment is via the @context link.  If it sees the
expected URI, then it's good to go.
Otherwise, if it uses the RDF model rather than the raw JSON serialization,
it would need to download the dynamic context and apply it before
processing.  For a web application, likely it would just reject the JSON
document as the RDF level is probably out of its scope.

So I guess it's whether the context URI is something that's seen as static
and thus no need to apply it unless it's unrecognized, or if it's seen as a
dynamic and necessary part of the infrastructure.  We've been going with
the first, but the above seems to take the latter approach.

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

Sorry, that was confusing.  The use case we have in mind is when a
community of practice adopts the API but has its own requirements on top of
the baseline information.  For example, online slide deck software might
want to use the Images and Canvases, but have more control over the
transitions between them.  We would want to enable them to define their own
mix-in context that lets them specify the transitions, but still have the
data gracefully degrade for a regular player that doesn't understand them.

For that, the context would need to include their mix-in context... which
we don't necessarily know about or have access to.


> > 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.
> > Yes, but we can't guarantee that going forwards.  For example geoJSON
> > might introduce terms in the future that could collide with ours,
> How will you avoid these collisions then? Are you assuming that the
> contexts used in a specific JSON subtree don't contain colliding terms?
>

By only using one context at once in sub-trees. If the GeoJSON context is
imported for a sub-tree, it's in effect for that sub-tree only, right? And
once it climbs back out of it, the GeoJSON context no longer applies.  This
gives us infinite flexibility for the community based extensions, as above,
without having to worry about collisions.

At, currently, the expense of not being able to re-compact documents once
expanded.



>  Could you please file a issue on GitHub [1] so that we don't forget this
> use case.
>

Will do :)

Thanks Markus!

Rob