Re: JSON-LD & nested structure

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

Received on Thursday, 25 August 2016 10:43:02 UTC