Re: Framed output without a `@graph` wrapper

On Oct 26, 2016, at 5:35 AM, Robert Sanderson <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> 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",
>>   "@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",
>>   "@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
>> [2] http://json-ld.org/spec/latest/json-ld-framing/#framing-algorithm
>> [3] 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
>> [5] https://github.com/json-ld/json-ld.org/issues/293
>> 
>> 
> 
> 
> 
> -- 
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049