- 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