- 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