Allow class-scoped framing

[azaroth42]

It would be useful to allow individual classes to have their own frames, such that a class which can appear at many points in the structure can be defined only once and then the definition inherited.

For example, a class like Type / Concept / Tag might appear anywhere in a structure associated with any other class. Currently (I believe) you would need to define all possible structures to ensure that the Type was framed consistently.

[gkellogg]

What do you think this might look like? Framing serves as a "program by example", and I'm not sure what such a frame might look like.

[azaroth42]

I can't recall what the issue was, closing :)

[azaroth42]

Ahha, and in coming back to an implementation, I recall the issue. It's related to https://github.com/w3c/json-ld-syntax/issues/19 and https://github.com/w3c/json-ld-api/issues/33.

Framing is a program-by-example or templating system, but it requires the absolute structure to be known from the root node down. We have a "Type" (or Concept, or Tag) that has a structure we'd like to see repeated every time it is referenced, but don't know all of the places in the structure where it might occur.

So we'd like the following to be able to be specified in a frame, without knowing the structure for property, just to make a frame for resources that have a type of Tag:

{
  "tag": {
    "id": "http://example.org/tag1",
    "type": "Tag",
    "label": "example tag"
  },
  "property": {
    "more_properties": {
      "tag": {
        "id": "http://example.org/tag1",
        "type": "Tag",
        "label": "example tag"
      }
    }
  }
}

Rather than the second instance being just the URI.

[azaroth42]

In terms of potential syntax, the best I can come up with is a new keyword (I hear the groans from around the world) that would be a wildcard for properties. It can't be a second graph shape in @graph as the processor wouldn't know which shape was the top, and which was the child template. It can't use @nest as then you wouldn't be able to frame nested (structural, transparent) properties.

e.g. something like:

{
  "@anywhere": { 
    "tag": {
      "type": {"id": "Tag", "@embed": always"}
      "label": {"@embed": "always"}
    }
  },
  "property": { ... }
}

[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 #29 to be discussed for inclusion in a future call
  View the transcript

  Class-scoped framing
  Rob Sanderson: link: https://github.com/w3c/json-ld-framing/issues/29
  Rob Sanderson: The idea here … instead of having framing on only predicates to also have it on classes, whenever you find a resource of type X you use this subframe. But we’d deferred #38 and this seems to be a subtopic of that.
  Gregg Kellogg: Deferred just means we’re not working on this now. Or do you mean defer into another WG?
  Rob Sanderson: Well, defer and we’ll see what happens.
  Ivan Herman: Wait, we’re getting to feature freeze. Whatever is deferred at feature freeze means it goes to another version.
  Gregg Kellogg: I think it meant we weren’t accepting new proposals. It’s still on the docket to work on, but the WG might decide to defer to a later version.
  Ivan Herman: Deferring means that this will not be part of the upcoming version of JSON-LD.
  Gregg Kellogg: Ok, I’m not prepared to say that for this or other things we’ve said “deferred” to.
  Rob Sanderson: I’ve also thought that way, not necessarily closing. If not we’re going to do it we should close.
  … SRI and references to meta data we should continue to discuss it even though they are deferred.
  Ivan Herman: As soon as we are CR we freeze it. For our own time tables we have to have a point where we freeze it for ourselves as well. At that point, if we say “defer” … “if after publishing a new REC, this group or any other group should look at this feature”
  Rob Sanderson: I’m fine with subtly changing the semantics of “defer” when we’re in feature freeze. We should take those things that we’ve marked as defer as “in or out”
  Gregg Kellogg: I think we should decide on the next call specific features we’re going to work on for this version. Otherwise it’s going to be nebulous. It’s premature to say those things that don’t get into this WD are deferred. We need to prioritize issues and set a time by which we will have finalized them.
  Ivan Herman: We are dangerously close to that.
  Rob Sanderson: +1
  Gregg Kellogg: So that’s the topic for the next call.
  Rob Sanderson: How about for now we defer based on #38?
  Ivan Herman: Let’s close the topic for now and then look at all these in general.
  Proposed resolution: defer framing #29 to be discussed for inclusion in a future call (Rob Sanderson)
  Gregg Kellogg: +1
  Ruben Taelman: +1
  Rob Sanderson: +1
  Ivan Herman: +1
  Dave Longley: +1
  David I. Lehn: +1
  Resolution #3: defer framing #29 to be discussed for inclusion in a future call
  

[iherman]

This issue was discussed in a meeting.

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

  3.2. class-scoped framing
  Ivan Herman: link: https://github.com/w3c/json-ld-framing/issues/29
  Rob Sanderson: idea is that framing starts with a tree, but if you don’t know where a class starts in a tree then things get complicated
  … likely would require multiple frames within a frame document
  Benjamin Young: +1
  David Newbury: +1
  Proposed resolution: Defer framing #29 until future WG (Rob Sanderson)
  Ivan Herman: +1
  Dave Longley: +1
  David Newbury: +1
  Ruben Taelman: +1
  Gregg Kellogg: +1
  Rob Sanderson: +1
  Pierre-Antoine Champin: +1
  David I. Lehn: +1
  Tim Cole: +1
  Simon Steyskal: +1
  Resolution #3: Defer framing #29 until future WG
  

[AtesComp]

Since the @graph keyword (and using no @graph keyword) implies that "the absolute structure to be known from the root node down", then maybe using a @subgraph keyword would specifies a matching substructure (and might be used multiple times). Non-matching portions should be included "as is" from the input graph. This looks like a search and replace operation.