Re: [IIIF-Discuss] Re: Multiple Contexts with expand/compact?

Hi Chris,

The advantage is extensibility.  In order to have stable versions of the
main APIs, we can't add in additional services to the main contexts and API
descriptions.  However, technically nothing prevents anyone from adding in
extra information as it's all RDF underneath.  By requiring that the
extensions only come at certain points (eg, as the object of a "service" /
sioc:has_service) and must have their own context, then they're easy to
ignore if the context isn't understood, they're easy to include in the
specification in the future, and means that we don't need to register or
otherwise enforce which external contexts are used.

Also, compactness is a pretty big win.  We don't need to have a single
context that references every other context that someone has proposed as
being potentially useful.  Thus we don't need to worry about collisions
between the contexts, and processing time of reading through all of those
contexts.

Does that help?

Rob

On Wed, Jul 16, 2014 at 4:31 PM, Chris Chapman <chris@pentandra.com> wrote:

> Hi Rob,
>
> Maybe I'm being dense here, but what's the benefit of referencing the
> external context only at the block where it's needed rather than in the
> main context definition?
>
> Chris Chapman
> Pentandra
>
>
> ------------------------------
>
> *From: *"Robert Sanderson" <azaroth42@gmail.com>
> *To: *"Markus Lanthaler" <markus.lanthaler@gmx.net>
> *Cc: *"Gregg Kellogg" <gregg@greggkellogg.net>, "Linked JSON" <
> public-linked-json@w3.org>, iiif-discuss@googlegroups.com
> *Sent: *Wednesday, July 16, 2014 10:36:09 AM
> *Subject: *[IIIF-Discuss] 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
>
> --
> -- You received this message because you are subscribed to the
> IIIF-Discuss Google group. To post to this group, send email to
> iiif-discuss@googlegroups.com. To unsubscribe from this group, send email
> to iiif-discuss+unsubscribe@googlegroups.com. For more options, visit
> this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "IIIF Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to iiif-discuss+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
>


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