Niklas Lindström: Have we ever discussed if we allow arbitrary data in the term definitions in the context?

Manu Sporny: What we do now is to just ignore it.. We should create an issue for that... created: https://github.com/json-ld/json-ld.org/issues/82

Niklas Lindström: Will aliasing also apply to subsequent contexts?

Niklas Lindström: We should just allow the use of aliased terms in the body and not in the context

Niklas Lindström: … {"@id": …, "@type": … }

Niklas Lindström: If you look at something like this in the document it means somethings different than when it is in the context

Gregg Kellogg: So?

Niklas Lindström: Term def. are already special.. So we could handle it differently

Manu Sporny: I think we should keep the number of special cases for these rules to a minimum, thus, I don't think we should handle this differently.

Manu Sporny: Niklas, could you please create a separate issue for this?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/82

Gregg Kellogg: As per the existing processor rules, they are ignored.

Manu Sporny: They are removed when compacting and normalizing but remain intact when extending

Manu Sporny: Clarification: ... where non-JSON-LD is anything not recognized by a JSON-LD processor)

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +1

David I. Lehn: +1

Markus Lanthaler: Well actually they are also removed in expansion as the whole context is removed.

Markus Lanthaler: What about the decision we made to remove unknown keys from expansion? https://github.com/json-ld/json-ld.org/issues/56

Gregg Kellogg: I don't think we need normalization for compaction or framing.

Manu Sporny: I agree in the case of compaction, I don't think that is possible for framing... we'll have to chat with Dave Longley to figure out why he required normalization for both compaction and framing.

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

Niklas Lindström: +1

David I. Lehn: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/68

Manu Sporny: This is really a discussion about whether we want to have an array-form for @id or if we want to be more specific about how we express graphs that are not fully connected.

Gregg Kellogg: Are we talking about named graphs or bushes?

Manu Sporny: Bushs, but this solution should also work for named graphs... what we're really talking about are hedges... :P

Manu Sporny: If we have a graph that is a bush - we do this: "@graph": [{},{},{}] instead of this: "@id": [{},{},{}]

Manu Sporny: If we want to make that graph a named graph, we do this: { "@id": "_:graph_name", "@graph": [{},{},{}] } ... you can also assign properties to that named graph and support graph literals with that construct.

Manu Sporny: I don't think we should go down the named graphs rathole yet... let's wait for the RDF WG to figure out what they want to do about it.

Gregg Kellogg: This is a good example of why we need "@graph": http://rdfainfo.digitalbazaar.com/test-suite/manifest.json

Niklas Lindström: Our intent at the moment is not to support named graphs but to ensure that the syntax of bushes supports named graphs in the future

Niklas Lindström: using @set instead of @graph has some appeal as discussed in the issue - it requires less theoretical background

Niklas Lindström: … {"dc:creator": {"@set": […]}}

Niklas Lindström: .. a set of objects vs. a quoted graph

Niklas Lindström: "@many"

Niklas Lindström: I don't think a @set is the same thing as a @graph, we shouldn't conflate the two concepts in an attempt to be clever.

Manu Sporny: @set is really an alias for [], right?

Gregg Kellogg: Yes, except for when you use it for @type coercion.

Markus Lanthaler: Why is a @graph in this context different from having a set with an @id applied to it? [scribe assist by Manu Sporny]

Niklas Lindström: Depends on what you mean by "set" [scribe assist by Manu Sporny]

David I. Lehn: does rdf:Bag terminology help here?

Manu Sporny: I don't think it does - at least, not in a way that would be friendly to newcomers.

Markus Lanthaler: If we add an @id to @set, is that a named graph? [scribe assist by Manu Sporny]

Manu Sporny: That's not clear - it's not clear that @id applied to @set is the same as @id applied to @list is the same as @id applied to @graph. [scribe assist by Manu Sporny]

Niklas Lindström: A similar issue arises if we allow e.g. {"@id": …, "@value": ...}

Manu Sporny: Right now container could be one of these - "@container": @set | @list | @graph

Manu Sporny: When and how we use @set is really orthogonal to this issue. I think it's clear that a @set with an @id is not the same thing as a graph with an @id - I don't know what a @set with an @id is... but I am sure that it's not the same thing as a @graph with an @id. There is a separate issue here of whether we should be using @ordered/@unordered vs. @list/@set - but let's discuss that as a separate issue.

Niklas Lindström: +1

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

David I. Lehn: +1

Manu Sporny: Clarification: This does not mean that we have a named graph solution, but we do believe that it is forward-compatible with such a solution.

Manu Sporny: One could do something like this: {"@id": "_:graph0", "@graph": [{},{},{}] }

Gregg Kellogg: Can we do something like this:

Gregg Kellogg: {"foo": {"@graph": {{}}} - basically, a graph literal?

Manu Sporny: In the future, probably. We've just opened a Pandora's box of discussion about this... it affects normalization in a big way. We should be careful to restrict discussion about this for JSON-LD 1.0. We /may/ have a JSON-LD 1.1, but for 1.0, we may only allow @graph at the top-level.