- From: Robert Sanderson <azaroth42@gmail.com>
- Date: Fri, 11 Jul 2014 16:42:11 -0700
- To: Linked JSON <public-linked-json@w3.org>, "iiif-discuss@googlegroups.com" <iiif-discuss@googlegroups.com>
- Message-ID: <CABevsUFha6rxOFyj4Qwc5HUFATZ68U-Hfym3H=4=4_sLmjom3A@mail.gmail.com>
Dear JSON-LD folk,
(and cc iiif-discuss)
We're trying to provide useful contexts, frames and sample code for working
with the JSON-LD representations of our data in the IIIF community (
http://iiif.io/).
One issue that we're struggling with is how to provide use contexts across
multiple, related specifications.
There are two APIs in IIIF. One describes the structure of a set of images,
and another describes how to interact with the individual images. The
intent is that the two can be implemented separately or together -- the
structure could reference static images, and the image service might be
stand alone without any structure overlaid.
>From the structural description's JSON-LD, we import the context of the
image description only at the block where it's needed.
A completely artificial example is at:
http://iiif.io/api/presentation/2.0/example/test_case.json
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/
We have also been using framing, which runs into the same problem, as it
expands the document in order to frame it.
A real example is:
http://iiif.io/api/presentation/2.0/example/manifest1.json
Many thanks for any thoughts on the matter,
Rob Sanderson
--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305
Received on Friday, 11 July 2014 23:42:41 UTC