Allow declaring `@container` on `@type`

[jmandel]

For consistent framing, I sometimes want to force an object's @type into an array. This would mean allowing a context like:

{
  "@type": {
    "@container": "@set"
  }
}

... which currently throws a 'keywords cannot be overridden' error.

[lanthaler]

We discussed that several times but so far we decided to not support that. I see a number of problems with this:

• @type gets an even more special keyword - even more special code would be needed for it
• what if someone decides to set it to "@container": "@list"? There would be no way to use @type in compaction then which would force us to throw an exception.

Is this just be a "nice-to-have" for you or is it preventing some use cases respectively requiring an excessive amount of client code that could otherwise be elminited? As I see it, it just requires one additional if-statement in the client application.

[jmandel]

From my perspective, allowing context to set a @container on @type
helps developers explicitly express their desired "data shape" in the
same way they can for other predicates. It's strictly (for me) about
simplifying client code by eliminating if/then logic. (But I think
that's important.)

To be clear, I'm only advocating that contexts be allowed to assign
@set (not @list). I understand there is a trade-off here between
complexity to implement the API vs. consume it... just wanted to put
in a word here from the consumer's perspective.

On Thu, May 17, 2012 at 1:16 AM, Markus Lanthaler
reply@reply.github.com
wrote:

We discussed that several times but so far we decided to not support that. I see a number of problems with this:
 - @type gets an even more special keyword - even more special code would be needed for it
 - what if someone decides to set it to "@container": "@list"? There would be no way to use @type in compaction then which would force us to throw an exception.

Is this just be a "nice-to-have" for you or is it preventing some use cases respectively requiring an excessive amount of client code that could otherwise be elminited? As I see it, it just requires one additional if-statement in the client application.

---

Reply to this email directly or view it on GitHub:
#122 (comment)

[lanthaler]

Would a flag in the compaction algorithm be fine as well for you or does it absolutely need to go into the context?

[jmandel]

If I could pass a flag in the options to frame() and that flag makes it
through to compact(), my needs would be well served.
On May 17, 2012 9:04 PM, "Markus Lanthaler" <
reply@reply.github.com>
wrote:

Would a flag in the compaction algorithm be fine as well for you or does
it absolutely need to go into the context?

---

Reply to this email directly or view it on GitHub:
#122 (comment)

[gkellogg]

Turtle would allow setting a rdf:type as a list; it doesn't make sense, but the syntax allows it.

+1 to allow @container @set on @type

[lanthaler]

Would it be a viable alternative to allow this just in framing and ignore it in all other algorithms?

[lanthaler]

RESOLVED: Add a flag to the .compact() and frame.() algorithms that turns off optimization of arrays with single items in them to single values in the output.