- From: Aymeric Brisse <aymeric.brisse@gmail.com>
- Date: Thu, 8 Sep 2016 18:27:09 +0200
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, JSON-LD CG <public-linked-json@w3.org>
- Message-ID: <CANURzhjJZ3sezPvDyyz-vjzFaA0ehyY3BWjG8i+8ryLeO4SFjQ@mail.gmail.com>
Thanks Dave for the feedback.
On Thu, Sep 8, 2016 at 4:33 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:
> 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 16:28:01 UTC