Several frames in the same frame document?

[iherman]

Looking at 2.3.1 I tested the core library example of the document on playground with the following frame

{
  "@context": {
    "@vocab": "http://example.org/"
  },
  "@graph" : [
      {
        "@type": "Library",
        "contains": {
            "@type": "Book",
            "@embed": "@never"
        }
      },
      {
        "@type": "Book",
        "contains": {
            "@type": "Chapter",
            "@embed": "@last"
        }
      }
  ]
}

And I got the reply that a frame document must have only one frame object.

O.k., playground is playing per spec, but I was a bit surprised: why can't I have a frame like the one above? In the result, the 'library' would just list the books by ID, and the rest of the graph would include each book separately, including the relevant chapters. Isn't that a viable use case?

[azaroth42]

Or ... can @graph be used in a frame document to dictate the presence of @graph in the resulting JSON-LD document?

[iherman]

Well, the example frame defines either a set of objects in a bush or a graph as part of the (messy) JSON-LD specification. So yes, by using other means we may get a graph.

I realize that this would mean a non-trivial extension of the current framing algorithm, though.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Work on a proposal for solving framing#29 along the lines of embedded contexts / scoped contexts, but for embedded sub-frames {: #resolution3 .resolution}
  View the transcript

  5. Class-scoped Framing (issue frame29)
  Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/29
  Rob Sanderson: framing is like programming by example;
  … you need to know the exact structure from the root down.
  … For some properties (like “link” or “tag”),
  Rob Sanderson: https://github.com/w3c/json-ld-framing/issues/29#issuecomment-463295607
  Rob Sanderson: you would need to be able to say “anywhere this property appears, it should conform with this structure”
  … but this is not currently possible.
  Ivan Herman: isn’t it related to the issue I raised recently, while reading the framing document (issue 38)?
  … We can not currently have a “bush-shaped” frame, with several patterns,
  … the first matching one being used.
  … Wouldn’t it solve your issue as well?
  Gregg Kellogg: I think it is possible to have a bush.
  Ivan Herman: not for the pattern itself.
  Dave Longley: this is pretty close: http://tinyurl.com/y356yzo8
  Dave Longley: to what Ivan wants – in JSON-LD 1.0 framing
  Gregg Kellogg: I think your particular example could still be solved.
  … I’m not sure this completely addresses what Rob wants.
  … This is more like a “macro” feature.
  … It is somehow similar to scoped contexts… Something like a scoped frame.
  Rob Sanderson: +1 to similarity (but not identity) to scoped contexts
  Dave Longley: I think that what Ivan wants is similar.
  … And I do think that there is a gap in the current framing document.
  … It makes sense for us to create like a ‘type frame’.
  Gregg Kellogg: If we do it for types, we should probably do it for properties, too
  Dave Longley: something like @anywhere makes sense to me as well … defining “subframes” at the top of the frame that get applied when certain types or properties are encountered
  Rob Sanderson: @frame :D
  Gregg Kellogg: we might define something parallel to contexts, that could appear anywhere contexts can appear,
  Proposed resolution: Work on a proposal for solving framing#29 along the lines of embedded contexts / scoped contexts, but for embedded sub-frames (Rob Sanderson)
  Rob Sanderson: +1
  Dave Longley: +1
  Gregg Kellogg: +1
  Simon Steyskal: +1
  Pierre-Antoine Champin: +1
  Ivan Herman: +1
  David I. Lehn: +1
  David Newbury: +1
  Benjamin Young: +1
  Resolution #3: Work on a proposal for solving framing#29 along the lines of embedded contexts / scoped contexts, but for embedded sub-frames {: #resolution3 .resolution}
  Gregg Kellogg: We should look to ShEx and SHACL for similar patterns we might leverage
  

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer Framing #38 until a future version
  View the transcript

  pushing to WD for @protected; other open issues before feature freeze
  Rob Sanderson: link: https://github.com/orgs/w3c/projects/4
  Ivan Herman: the only new feature is
  Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/19
  Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/19
  Rob Sanderson: link” https://github.com/w3c/json-ld-framing/issues/29
  Adam Soroka: [people work to find tickets]
  Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/38
  Ivan Herman: I think I said that if it gets too complicated, we can forget it
  Rob Sanderson: link: https://github.com/w3c/json-ld-syntax/issues/103
  Ivan Herman: #38 was discussed and resolved: what happened there?
  Benjamin Young: the resolution sonuds editorial
  Gregg Kellogg: these can be open issues in a WD
  … . feels like too much work
  Rob Sanderson: we can say that no more open issue will come
  Ivan Herman: we would need a nontrivial extension
  … and I am find with closing
  Ivan Herman: I will close it after a resolution, just to be correct
  Rob Sanderson: propose won’t-fix
  Proposed resolution: Defer Framing #38 until a future version (Rob Sanderson)
  Rob Sanderson: +1
  Ivan Herman: +1
  Ivan Herman: wasn’t there some label for deferring to a future version>?
  Adam Soroka: +1
  Ruben Taelman: +1
  Benjamin Young: +1
  Jeff Mixter: +1
  Pierre-Antoine Champin: +1
  Dave Longley: +1
  David I. Lehn: +1
  Gregg Kellogg: +1
  David Newbury: +1
  Resolution #4: Defer Framing #38 until a future version
  Tim Cole: +1
  Ivan Herman: +1
  Adam Soroka: [discussion of potential issues to discuss]
  Gregg Kellogg: i’d like to defer the issues mentioned in that discussions
  Rob Sanderson: bigbluehat: agreed
  Benjamin Young: do we need to list all these issues?
  Rob Sanderson: don’t think we need to
  Pierre-Antoine Champin: I was thinking about property-based indexing
  … if the WD is meant to reassure VCWG and WoTWG then shouldn’t that feature be included in it?
  Adam Soroka: ivan_ yes, but isn’t it already in?
  Gregg Kellogg: is it an open PR?
  Pierre-Antoine Champin: yes, but you suggested a significant syntax change
  Gregg Kellogg: hopefully we can discuss and decide those on the issue itself, or we will need to discuss it next week
  Gregg Kellogg: can we reocrd the specific remaining issues and PRs that merit our attention this week?
  Benjamin Young: https://github.com/w3c/json-ld-syntax/pull/145
  Gregg Kellogg: what pchampin described as needing discussion
  Gregg Kellogg: I see that I approved it
  Pierre-Antoine Champin: I think you implemented it!
  Gregg Kellogg: let’s keep discussion on that PR
  Ivan Herman: there should be a clear list of issues and PRs that are still pending
  

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Defer framing #38 until future WG
  View the transcript

  3.1. several frames in the same document
  Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/38
  Rob Sanderson: are we still agreeing that we don’t do this particular issue in the scope of the current wg?
  Gregg Kellogg: SPARQL 1.2 CG discusses framing in the context of construct queries
  … I’m fine with deferring
  Proposed resolution: Defer framing #38 until future WG (Rob Sanderson)
  Ivan Herman: +1
  Rob Sanderson: +1
  Dave Longley: +1
  Tim Cole: +1
  Benjamin Young: +1
  Gregg Kellogg: +1
  Simon Steyskal: +1
  Ruben Taelman: +1
  David Newbury: +1
  Pierre-Antoine Champin: +1
  Resolution #2: Defer framing #38 until future WG
  

[shkumar4]

I've a similar issue as mentioned here, where I need to define multiple types at root level with their own structure. Is there any update on this issue (last update is from June, 2019). In case, this is still under deferment, please let me know of any workaround for defining unreleted types at root level?