Allow class-scoped framing about json-ld-framing HOT 8 OPEN

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.

from json-ld-framing.

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

from json-ld-framing.

Ahha, and in coming back to an implementation, I recall the issue. It's related to w3c/json-ld-syntax#19 and w3c/json-ld-api#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.

from json-ld-framing.

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": { ... }
}

from json-ld-framing.

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}

from json-ld-framing.

This issue was discussed in a meeting.

• RESOLVED: defer framing #29 to be discussed for inclusion in a future call

from json-ld-framing.

This issue was discussed in a meeting.

• RESOLVED: Defer framing #29 until future WG

from json-ld-framing.

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.

from json-ld-framing.