Re: JSON-LD & nested structure

Obviously but the @metadata must be supported by the JSON-LD before working
on the preprocessor

On Aug 25, 2016 12:42, "Martynas Jusevičius" <martynas@graphity.org> wrote:

> How can pagination be a feature of a format like JSON-LD? It is a
> feature of the protocol (that delivers the format).
>
> On Thu, Aug 25, 2016 at 12:30 PM, Aymeric Brisse
> <aymeric.brisse@gmail.com> wrote:
> > My comments inline:
> >
> > On Thu, Aug 25, 2016 at 1:55 AM, Gregg Kellogg <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 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 or JSON Graph. 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.
> >>
> >> 1/ I could add some levels to describe any list using schema: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/fa39b164da8dd39e2e9c9991d8392e
> fb
> >>>>>>
> >>>>>> 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
> >>>
> >>>
> >>
> >>
> >
>