Skip to content

what's the use of "@container": ["@id", "@set"] #140

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
VladimirAlexiev opened this issue Feb 26, 2019 · 8 comments
Closed

what's the use of "@container": ["@id", "@set"] #140

VladimirAlexiev opened this issue Feb 26, 2019 · 8 comments

Comments

@VladimirAlexiev
Copy link

https://w3c.github.io/json-ld-syntax/#example-82-indexing-data-in-json-ld-by-node-identifiers-with-set-representation
Maybe I'm missing something but what use is "@container": ["@id", "@set"]?
I think that with @id indexing, every @id gets one JSON object.
So @set will turn them all into singleton arrays: what is the use of that?

@ajs6f
Copy link
Member

ajs6f commented Feb 26, 2019

@VladimirAlexiev The idea is to be able to force the shape of the resulting JSON. One of JSON-LD's most important uses is "annotating" vanilla JSON so that it can be understood in a semantic context. In this use case it's not always possible to decide to use an array or a single value-- that decision may have already been made.
Another way to put it: JSON-LD context authors may need to ensure that their JSON results match a certain expected JSON structure (e.g. defined by an API spec) so that clients who only understand JSON (not JSON-LD) have no more trouble than they must parsing the JSON.

@dlongley
Copy link
Contributor

I recommend we have this sort of reasoning added to the feature descriptions in the spec (where possible).

@VladimirAlexiev
Copy link
Author

@ajs6f without such annotation, the jsonld processor will unpack the singleton arrays.

In this case all the arrays are singletons by necessity, so what use it is to have that annotation?

@gkellogg
Copy link
Member

Note that ["@id", "@set"] really only helps the compaction process. When expanding, a processor will treat a single value vs an array of that single value the same way. The need is to make sure that when framing and/or compacting, that the resulting serialization will always use the array form in this case, which makes the programming logic to access such things easier.

@ajs6f
Copy link
Member

ajs6f commented Feb 27, 2019

@VladimirAlexiev Does that help answer the question?

@azaroth42
Copy link
Contributor

@iherman
Copy link
Member

iherman commented Mar 29, 2019

This issue was discussed in a meeting.

  • RESOLVED: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency
View the transcript 4.3. @container [@id, @set]
Rob Sanderson: Link: #140
Rob Sanderson: this issue questions the relevance of @container [@id, @set]
… many people have answered, in the line of “it’s a feature, not a bug”
Proposed resolution: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency (Rob Sanderson)
Rob Sanderson: +1
Gregg Kellogg: +1
Dave Longley: +1
Tim Cole: +1
David Newbury: +1
Gregg Kellogg: it is about consistency and orthogonality, despite the lack of use case
Pierre-Antoine Champin: +1
Ruben Taelman: +1
Adam Soroka: +1
Ivan Herman: +1
Resolution #3: Close #140 as a feature not a bug - no need to use it if you don’t want it, and gives consistency
David I. Lehn: +1

@VladimirAlexiev
Copy link
Author

@aj6f and @gkellogg thanks for the explanations!
In this case, as @dlongley said, it'd be useful to add a similar explanation to the spec.

Wow, the prev comment demonstrates an enviable level of automation on part of the w3c :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants