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

Re: JSON-LD & nested structure

From: Aymeric Brisse <aymeric.brisse@gmail.com>
Date: Thu, 8 Sep 2016 11:24:47 +0200
Message-ID: <CANURzhj2JNBVGUDy8LAk-Mopf698DRfyczxq4ZiXaRv+uvGUwQ@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: Gregg Kellogg <gregg@greggkellogg.net>, JSON-LD CG <public-linked-json@w3.org>
Any piece of advice / comment on that topic?

On Thu, Sep 1, 2016 at 3:25 PM, Aymeric Brisse <aymeric.brisse@gmail.com>
wrote:

> Hello,
>
> I was wonderning what is the best way to frame a JSON-LD graph using
> multiple @id? I know @id must be an IRI and does not accept arrays of IRIs
> but sometimes we want to "hook" a list of IRIs that have nothing in common
> in kind of relations (@type or whatsoever).
>
> Currently I can only think of 2 hackish-scenarii to frame a list of IRIs
> "ids", but neither of them is elegant:
>
> 1/ for each IRI in ids, frame the graph. Then merge the mutiple @graph
> results into a single one
> 2/ for each IRI in ids, add a statement in the original graph like "<
> http://dummy> ns:hooks <IRI>" . Frame the graph with { @id: "http://dummy"
> } and extract @graph[0]["ns_hooks"] in the @graph result.
>
> Any other solution?
>
> On Thu, Aug 18, 2016 at 3:23 PM, Aymeric Brisse <aymeric.brisse@gmail.com>
> wrote:
>
>> Indeed I was using the official spec (http://json-ld.org/spec/lates
>> t/json-ld-framing/) and didn't find how to use it, hence my email.
>>
>> Thanks Dave for the link it works well on the JSON-LD playground (btw the
>> autocompletion in the JSON-LD Frame input does not display the @embed
>> attribute).
>>
>> Again guys thanks for your replies and happy to see that JSON-LD rocks by
>> fitting all the needs we have! :)
>>
>> On Wed, Aug 17, 2016 at 11:04 PM, Dave Longley <
>> dlongley@digitalbazaar.com> wrote:
>>
>>> On 08/17/2016 04:43 PM, Gregg Kellogg wrote:
>>>
>>>>
>>>> Gregg Kellogg
>>>> gregg@greggkellogg.net
>>>>
>>>> On Aug 17, 2016, at 12:50 PM, Dave Longley <dlongley@digitalbazaar.com>
>>>>> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> I believe I support all of the embedding options that Dave’s does.
>>>>
>>>> BTW, on my short-term list is to try to update the Framing spec based
>>>> on this common behavior.
>>>>
>>>
>>> That would be awesome and much appreciated, Gregg. I can review and
>>> tweak changes at some point.
>>>
>>>
>>>
>>> --
>>> Dave Longley
>>> CTO
>>> Digital Bazaar, Inc.
>>> http://digitalbazaar.com
>>>
>>
>>
>
Received on Thursday, 8 September 2016 09:25:50 UTC

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