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: #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.