Re: Multiple Contexts with expand/compact?

\On Jul 14, 2014, at 10:51 AM, Robert Sanderson <azaroth42@gmail.com> wrote:

> 
> Thanks for the response Gregg!
>> 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/
> Sadly, no; at least not yet. I previously suggested that a frame might include an imbedded context, which would remain, and be used for compaction, in the output document. I think it's something which should be considered when the framing spec is completed, but it will be difficult, as the frame is expanded before processing.
> 
> Yes, it seems like it would need some directive that the @context definition should be maintained or not, so that when compacting it can be re-introduced. But as it's not actually RDF, the intermediate representation would be strange :(
> 
> At least it wasn't that we were missing anything obvious :)
>  
> I don't see how you would do this with anything other than a frame.
> 
> And is there a pattern for the current frames definition that would provide a workaround?  If there was some agreement, given that the frames spec isn't set yet, that seems like it would be useful progress?

I think the way to do this would be to first frame the inner part, with the inner context you want, then frame the outer part, with the outer-most context, and then programmatically update the result of the outer frame with the content of the inner frame. This would get you inner frames using the context you want, but requires some custom code do do this merger.

I don’t think that frames can solve every problem, but they can be a good part of the solution. I’ve been doing this to add reverse keys to the result of frames, as framing doesn’t (yet) support @reverse.

Gregg

> Many thanks,
> 
> Rob
>  
> 
> Gregg
> 
> 
>> 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
> 
> 
> 
> -- 
> Rob Sanderson
> Technology Collaboration Facilitator
> Digital Library Systems and Services
> Stanford, CA 94305