Re: JSON-LD & nested structure

Hello guys,

Another week, another question :)

I was thinking about how a JSON-LD API could properly manage pagination and
was wondering if you had some thoughts about it. I am not talking about the
top level pagination (a POST /search or a GET /collection) that can be
easily supported by either adding an extra top-root attribute "data" or API
headers, but the pagination at any level, like relay does with graphQL
<https://facebook.github.io/relay/docs/graphql-connections.html>.

1/ I could add some levels to describe any list using schema:ItemList
<https://schema.org/ItemList>, but I really don't like to mix both the
substance (the ontology) and the form (the API attributes). To be valid,
that would require to modify all the range object/datatype properties
described in an ontology from X (the current value) to X union
schema:ItemList which would be a mistake IMHO.

2/ I could add a node "@metadata" as a sibling of "@graph" and "@context".
That node "@metadata" would be ignored by the JSON-LD processor but not by
the API user and it would contain some pagination information (like
cursors, total_count, etc.) added by the API. When paginating an embedded
relation, I could replace the array values of that relation by a whole new
{ "@graph", "@metadata" } structure. Exactly like a merge of multiple
JSON-LD documents. The JSON-LD processor would treat it as a blank node but
the developper will be able to extract that part to process it like a new
graph document.

See for example
http://json-ld.org/playground/#/gist/12993b833f99d8ee97e2df0e1a678036 in
the JSON-LD input text area. I have added the @metadata at the top level
and used the system described for the relation pmcore:relB.

Any advice/feedback?

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/
> 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
> > 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
>>
>
>