Indexing without a predicate

[azaroth42]

For consideration by the JSON-LD 1.1 WG...

Assuming a nested set of resources where leaf nodes are frequently repeated, it is difficult to find the definition of the node after compaction. Imagine a classification that is used on the second item in a list, and again on the 26th. It would be nice to have a place to look up the label for the classification, instead of repeating it on both 2 and 26. Similarly, information about repeated people, services, or anything else could benefit from this pattern.

As prior art, and use case for inclusion, JSON API has the notion of "included" -- a slot where you can put resources that are included in others, such that developers can always know where to find them. In my work, this has come up with repeated services in IIIF, and classifications, people and places when describing the cultural heritage objects they relate to.

The identifier map pattern is already in this space, but insufficient as it requires a predicate to map to, and the relationship is to a resource somewhere nested in the data structure, not the top level resource. There would also need to be framing support as an extension to @embed:@never such that the inclusions were not embedded in the object data, but with a pointer to where they should go.

Example data:

{
  "id": "1",
  "type": "eg:Thing-with-Items",
  "eg:items": [
    {
      "id":"2",
      "classification": "enum:c6",
      "service": "enum:s2",
    },
    { "id": "3...26 go here", "type": "eg:X"}, 
    {
      "id": "27",
      "classification": "enum:c6"
    }    
  ],
  "included": {
    "enum:c6": {"type": "eg:Type", "label": "Classification 6"},
    "enum:p1": {"type": "eg:Person", "label": "Person 1"},
    "enum:s2": {"type": "eg:Service", "label": "Login Service"}
  }  
}

Playground example with identifier map: http://tinyurl.com/yd5z87xg

The inclusion term could either be a new keyword like @id (@included or @inclusions) that was then re-aliased in the context (to, e.g. included), or it could be a new keyword value for @container (included: {@container: @included}). I think the former is the (slightly) better design, as it makes it more obviously a field rather than a data structure. It would only be usable in a resource that is not nested within other resources (e.g. the top level JSON object ... which might be in an array or @graph). Framing could then use the same keyword: @embed: @included.

/cc @workergnome @zimeon @jpstroop @tomcrane @danbri

[azaroth42]

Noted on 2018-05-07 call:

• This is the same as itemref in microdata.
• And the same as RDFa property copying: https://www.w3.org/TR/html-rdfa/#property-copying
• @BigBlueHat to find references to other JSON hypermedia APIs that also share the same functionality

Question as to best implementation pattern (keyword, predicate, etc) to be discussed in WG.

[gkellogg]

Closed in favor of https://github.com/w3c/json-ld-syntax/issues/19.