Re: JSON-LD & nested structure

My comments inline:


*On Thu, Aug 25, 2016 at 1:55 AM, Gregg Kellogg <gregg@greggkellogg.net
<gregg@greggkellogg.net>> wrote:*
>
> *The Hydra CG is working on issues such as pagination [1], which is more
> than just a JSON-LD issue. As with other things in Hydra, this remains a
> work in progress.*
>

1/ It seems to focus only on paginating top-items, which is only a small
part of the problem like I said in my previous mail.
2/ Moreover the idea on the whole page is to basically add an extra
top-level "Collection", which is mixing Form and Substance.


> *Also, the Linked Data Platform has a paging spec [2], but this relies on
> using HTTP headers to communicate paging (and other) metadata. It is, of
> course, consistent with the principles of the Linked Data Platform, which
> does support JSON-LD in addition to Turtle.*
>

1/ max-triple-count and max-kbyte-count are quite technical and focus more
on the data layer than the information layer.
2/ max-member-count only works for top-level items.

*I think there is also potential to use schema.org <http://schema.org>
> ItemLists in combination with the Role class to create in indirect
> relationship similar to Hydra Collections, but there hasn’t been sufficient
> interest to pick this up.*
>
> *Paging remains on open item in the JSON-LD API Best Practices document
> [3], which I’ll get back to sometime.*
>

Right. I really believe in the shifting of RESTful APIs to more flexible
APIs using technos like GraphQL
<https://medium.com/chute-engineering/graphql-in-the-age-of-rest-apis-b10f2bf09bba#.ol48s6b54>
or JSON Graph <http://netflix.github.io/falcor/documentation/jsongraph.html>.
JSON-LD is one of the best format of serialization for that but some
features are clearly missing like pagination that really needs to be filled
to challenge those technos.

Since JSON-LD is mandatory for me to express semantically the concepts, I
guess I would add my "@metadata" field with the merging solution until
then. Please let me know if I can help in any way with some
specifications/inputs as a developer "in the field".

Cheers!


> Gregg Kellogg
> gregg@greggkellogg.net
>
> [1] https://www.w3.org/community/hydra/wiki/Pagination
> [2] http://www.w3.org/TR/ldp-paging/
> [3] http://json-ld.org/spec/latest/json-ld-api-best-practices/
>
> On Aug 24, 2016, at 9:28 AM, Aymeric Brisse <aymeric.brisse@gmail.com>
> wrote:
>
> 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/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
>>>
>>
>>
>
>