Re: JSON-LD & nested structure

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.

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.

I think there is also potential to use 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.

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 <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 <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 <http://digitalbazaar.com/>
> 
>