Re: Framed output without a `@graph` wrapper

I created https://github.com/json-ld/json-ld.org/issues/435

My original message perhaps should not have suggested a mechanism for 
control. An alternative to a flag, such as the approach you suggest, 
might be cleaner.

Cheers,
Simeon

On 10/26/16 9:50 AM, Gregg Kellogg wrote:
> On Oct 26, 2016, at 5:35 AM, Robert Sanderson <azaroth42@gmail.com
> <mailto:azaroth42@gmail.com>> wrote:
>
>>
>> +1 from me (as the sender of [3] below).  Having a flag to not
>> unnecessarily generate @graph would be a great improvement.  If
>> there's a fear of backwards incompatibility, the default could be to
>> include @graph.
>
> Yes, it is annoying. iIRC, the thought at the time was that a frame
> could return one or more results, and it would be odd if the results had
> a different shape depending. However, in my experience, when a frame is
> used in this context, the user usually knows to expect just a single result.
>
> Rather than add yet another flag, I would suggest that if the outermost
> frame in a frame document contains @graph, that we ensure that the
> result does as well, otherwise, only use it if necessary to contain
> multiple results.
>
>> Gregg, should we create an issue
>> in https://github.com/json-ld/json-ld.org/ ?
>
> Yes, please create an issue.
>
> Gregg
>
>> Rob
>>
>>
>> On Wed, Oct 26, 2016 at 10:59 AM, Simeon Warner
>> <simeon.warner@gmail.com <mailto:simeon.warner@gmail.com>> wrote:
>>
>>     Hi all,
>>
>>     I think framing is an important aspect of JSON-LD and I agree with
>>     the introductory comment "Developers typically work with trees,
>>     represented as JSON objects. While mapping a graph to a tree can
>>     be done, the layout of the end result must be specified in
>>     advance. A Frame can be used by a developer on a JSON-LD document
>>     to specify a deterministic layout for a graph." [1]. I would add
>>     that not only is a deterministic layout important, this layout
>>     should be as simple as possible (but no simpler ;-) ). We should
>>     expect to cater for JSON-only use of the data extracted from
>>     JSON-LD systems, and for a developer working with JSON:
>>
>>     {
>>       "@context": "http://iiif.io/api/image/2/context.json
>>     <http://iiif.io/api/image/2/context.json>",
>>       "@id": "http://example.org/r1",
>>       "formats": [
>>         "jpg",
>>         "png"
>>       ],
>>       "height": 2000,
>>       "width": 2000
>>     }
>>
>>     is much preferable to:
>>
>>     {
>>       "@context": "http://iiif.io/api/image/2/context.json
>>     <http://iiif.io/api/image/2/context.json>",
>>       "@graph": [
>>         {
>>           "@id": "http://example.org/r1",
>>           "formats": [
>>             "jpg",
>>             "png"
>>           ],
>>           "height": 2000,
>>           "width": 2000
>>         }
>>       ]
>>     }
>>
>>     To access `width` it is much nicer to write `data.width` than
>>     `data["@graph"][0].width`.
>>
>>     I found some discussion of this issue in 2013 [3] and later in
>>     that thread it seems that the pattern "agreed" upon [4] was to
>>     frame and then compact again to remove the `@graph` construct in
>>     cases where one knows that it can be done:
>>
>>     >  compact( frame( flat, frame), context)
>>     >
>>     > produces the desired output :)
>>
>>     (the rest of that thread went on to discuss bnode handling leading
>>     to issue [5]).
>>
>>     I think that there should be a flag/keyword in the frame to
>>     control whether `@graph` is artificially added in the second to
>>     last step of the framing algorithm [2]:
>>
>>     > If compacted results does not have a top-level @graph keyword,
>>     or if its value is not an array, modify compacted results to place
>>     the non @context properties of compacted results into a dictionary
>>     contained within the array value of @graph.
>>
>>     It seems ugly and wasteful to have to run compaction (or some
>>     kludge doing just the needed transformation) in order to remove
>>     the `@graph` construct.
>>
>>     Cheers,
>>     Simeon
>>
>>     [1] http://json-ld.org/spec/latest/json-ld-framing/#introduction
>>     <http://json-ld.org/spec/latest/json-ld-framing/#introduction>
>>     [2]
>>     http://json-ld.org/spec/latest/json-ld-framing/#framing-algorithm
>>     <http://json-ld.org/spec/latest/json-ld-framing/#framing-algorithm>
>>     [3]
>>     https://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0143.html
>>     <https://lists.w3.org/Archives/Public/public-linked-json/2013Jul/0143.html>
>>     [4]
>>     https://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0001.html
>>     <https://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0001.html>
>>     [5] https://github.com/json-ld/json-ld.org/issues/293
>>     <https://github.com/json-ld/json-ld.org/issues/293>
>>
>>
>>
>>
>>
>> --
>> Rob Sanderson
>> Semantic Architect
>> The Getty Trust
>> Los Angeles, CA 90049

Received on Wednesday, 26 October 2016 22:06:57 UTC