Provide an option for all terms to get a default "@container"

[michaelcpuckett]

I would like to have all my relational data come back as arrays of IDs.

Right now I have to add the following to @context for each term:

      "foo": {
        "@container": "@set",
        "@type": "@id"
      },

I propose a processor option (similar to embed) that would allow a default container.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion {: #resolution13 .resolution}
• ACTION: Rob Sanderson to put comment in to #31 requesting more info
  View the transcript

  Provide an option for all terms to get a default "@container"
  Rob Sanderson: ref: https://github.com/w3c/json-ld-framing/issues/31
  Gregg Kellogg: I had discussed putting in a default container set unless set otherwise.
  … which is less disruptive than the graph id
  … not a framing issue, but a compaction issue
  Rob Sanderson: just a convenience mechanism
  … is the value of this higher enough to warrant a new default?
  Gregg Kellogg: can’t be done in framing, must be in compaction.
  … is it valuable enough?
  Ivan Herman: this is what schema would do. They are very systematic in mapping this.
  … this will make schema.org will get there automatically
  Gregg Kellogg: currently, list and set are incompatible, though we’ve discussed this.
  David Newbury: .. one used to be ordered, and one unordered…but we’ve overridden that already.
  Rob Sanderson: for this issue, if you were to set a default container at @language
  Gregg Kellogg: that would be scary. Everything would be a language map.
  … and you’d have to define that.
  Rob Sanderson: if you snuck this away…
  Rob Sanderson: how would you undo this if it was @set?
  Gregg Kellogg: … empty array? @container: null?
  Rob Sanderson: in my opinion, the value is outweighed by the danger
  David Newbury: I don’t think that we need better ergonomics for creating contexts…
  Rob Sanderson: so we propose that this is valuable, but can they provide more use cases other than it being a bit redundant?
  Proposed resolution: push back to original commenter, asking for more use cases. Saving context authors some keystrokes is not a high priority (Rob Sanderson)
  David Newbury: +1
  Jeff Mixter: +1
  Rob Sanderson: +1
  Gregg Kellogg: +1
  Ivan Herman: +1
  Rob Sanderson: …
  Proposed resolution: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion (Rob Sanderson)
  David Newbury: +1
  Rob Sanderson: +1
  Ivan Herman: +1
  Jeff Mixter: +1
  David I. Lehn: +1
  Action #2: Rob Sanderson to put comment in to #31 requesting more info
  Gregg Kellogg: +1
  Harold Solbrig: +1
  Resolution #13: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion {: #resolution13 .resolution}
  

[michaelcpuckett]

Thanks @iherman for reviewing this.

For my specific case, I want to model my data based on schema.org. I want to keep a generic, reusable frame and have the schema.org @vocab do the heavy lifting of mapping the relationships. Unfortunately I must define every schema.org term I might use in the @context. If these could all be set to a default, I would not need to have complete knowledge of the vocabulary I'm using.

jsonld.frame(json, {
  "@context": {
    "@vocab": "http://schema.org/",
    "agent": {
      "@container": "@set",
      "@type": "@id"
    },
    "participant": {
      "@container": "@set",
      "@type": "@id"
    },
    "recipient": {
      "@container": "@set",
      "@type": "@id"
    },
    "author": {
      "@container": "@set",
      "@type": "@id"
    },
    ...
  },
})

If there is a simpler way to achieve this, please let me know.

[azaroth42]

Thanks @michaelcpuckett ! There isn't an easier way to do it I'm afraid, as the situation where every term in a vocabulary should always be @container: @set is vanishingly small. It would mean that every relationship was aways one to many or many to many, and never one to one or one to many. (It's also a syntax issue for compaction via setting a context, rather than a framing issue per se, but that's not a big deal)

My understanding of the intent of @vocab is to provide a default mapping from JSON to RDF, rather than a default mapping from RDF into a particular JSON structure. We have heard from several parties that the schema.org approach of just throwing @vocab in there and letting the application sort it out is often insufficient, and it seems like you're in the same boat.