W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2016

Re: JSON-LD & nested structure

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Wed, 17 Aug 2016 15:50:00 -0400
To: Aymeric Brisse <aymeric.brisse@gmail.com>, Gregg Kellogg <gregg@greggkellogg.net>
Cc: JSON-LD CG <public-linked-json@w3.org>
Message-ID: <9bc39500-5e01-de15-446a-97cc00dd672f@digitalbazaar.com>
On 08/17/2016 12:28 PM, Aymeric Brisse wrote:
> Hello Gregg & Dave,
>
> I am currently dealing with another problem. Let's say 2 resources
> are linked together by more than 1 predicate.
>
> As a JSON API developer that wants to return a tree and not a graph
> I expect that the following LD framed graph...
>
> [snip]
>
> ... to duplicate some parts of it if needed
>
> That way the developper don't have to deal with an identitymap
> pattern just to parse the JSON, meaning that he can access directly
> to the hash object["pmcore:relB"]["rdfs:label"]["@value"]
>
> How can it be achieved in an automatic manner?

The JavaScript, Python, and PHP framing implementations support several
framing "embed" options:

@always - always embed (nest) nodes except when a circular reference is
encountered, even if it duplicates data

@last - (the default) only embed the last occurrence of a particular
node so that the data is not modified via duplication

@never - never embed nodes, always use simple references

Some more discussion is here:

https://github.com/json-ld/json-ld.org/issues/377

The default embed option can be changed at the API level by passing in
a flag to the `frame` call. The embed option can also be set at a
more granular level within the frame itself. I've done this on the
playground using your example data and the "@always" option, to produce
what I believe is the desired output:

http://json-ld.org/playground/#/gist/fa39b164da8dd39e2e9c9991d8392efb

I don't know if the Ruby implementation supports these features yet.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com
Received on Wednesday, 17 August 2016 19:50:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:48 UTC