Re: Framed output without a `@graph` wrapper

+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.

Gregg, should we create an issue in https://github.com/json-ld/json-ld.org/
?

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/2013
> Jul/0143.html
> [4] https://lists.w3.org/Archives/Public/public-linked-json/2013
> Aug/0001.html
> [5] https://github.com/json-ld/json-ld.org/issues/293
>
>
>


-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049