Re: JSON-LD Best Practice: Context Caching

> On Apr 25, 2016, at 5:17 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> Hi folks,
> 
> We've been getting requests to write up some best practices for JSON-LD.
> Here's a proposal for one:
> 
> TL;DR: Don’t ever put a system that uses JSON-LD into production without
> thinking about your JSON-LD context caching strategy. If you want to use
> JSON-LD, your strategy should probably either be: Cache common contexts
> and do JSON-LD processing or don’t do JSON-LD processing, but enforce an
> input format via something like JSON Schema on your clients so they’re
> still submitting valid JSON-LD.
> 
> http://manu.sporny.org/2016/json-ld-context-caching/

Great post.

Moreover, where possible, use HTTP cache-control headers (Last-Modified, ETag) in combination with conditional HTTP requests or other client-side cache strategy, and use prefer a locally cached version. The Structured Data Linter takes this approach so that it does not maintain a fixed version (e.g.) the schema.org JSON-LD context, but retrieves it from schema.org unless it has it cached. As long as the application remains loaded, it will not need to re-fetch the context from schema.org.

Moreover, don’t re-compact a retrieved JSON-LD file unless you really need to use a different context than was used to originally compact the file. Severance’s numbers assume always needing to re-compact the file, which is usually not the case, unless a client is mix-and matching data from multiple sources with different contexts.

For best results, a service should provide JSON-LD compacted and framed with a reasonable context designed for developers to use as JSON. JSON-LD algorithms should only be necessary for transforming to other formats, re-frame, or when attempting to work with data from multiple sources where assumptions about contexts can’t be made.

JSON-LD was designed to be “just JSON” so that publishers and developers could continue to use it the way they have always processed JSON. The point of JSON-LD is that it can have meaning independent of published API specs (by treating keys and values as URIs that describe what they represent). This grounds the data to a sound data model and allows for arbitrary extensibility, but this is not required for many many use cases.

Gregg

> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Web Payments: The Architect, the Sage, and the Moral Voice
> https://manu.sporny.org/2015/payments-collaboration/
> 
>

Received on Tuesday, 26 April 2016 00:39:45 UTC