- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Thu, 8 Sep 2016 10:33:28 -0400
- To: Aymeric Brisse <aymeric.brisse@gmail.com>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, JSON-LD CG <public-linked-json@w3.org>
On 09/08/2016 05:24 AM, Aymeric Brisse wrote: > Any piece of advice / comment on that topic? Sorry for the slow response! Busy times over here. :) > > On Thu, Sep 1, 2016 at 3:25 PM, Aymeric Brisse <aymeric.brisse@gmail.com > <mailto: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? Unfortunately, we don't yet have a feature for specifying multiple @ids. That's an interesting use case we should consider. That unfortunately means you're left with making multiple calls and doing the merging yourself (or taking another approach like you described). > > On Thu, Aug 18, 2016 at 3:23 PM, Aymeric Brisse > <aymeric.brisse@gmail.com <mailto:aymeric.brisse@gmail.com>> wrote: > > Indeed I was using the official spec > (http://json-ld.org/spec/latest/json-ld-framing/ > <http://json-ld.org/spec/latest/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 <mailto:dlongley@digitalbazaar.com>> > wrote: > > On 08/17/2016 04:43 PM, Gregg Kellogg wrote: > > > Gregg Kellogg > gregg@greggkellogg.net <mailto:gregg@greggkellogg.net> > > On Aug 17, 2016, at 12:50 PM, Dave Longley > <dlongley@digitalbazaar.com > <mailto: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 > <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 > <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 > > > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Thursday, 8 September 2016 14:34:21 UTC