Niklas Lindström: I got a question over e-mail... regarding ISSUE-44
Niklas Lindström: Using "@container": "@set" in framing - Josh Mandel asked me if the consequence is if this didn't have any effect in compaction.
Manu Sporny: I think we said that the only place it matters is in framing.
Markus Lanthaler: I think that's the last issue we're discussing today.
Niklas Lindström: I asked Josh to comment, if he doesn't - I'll put something in that issue. It might be useful to support the list via @list and @set construct in compaction.
Manu Sporny: We've had reviews by Oracle and W3C staff, they have some minor comments but are happy with the documents overall. We need to change the feedback into issues and discuss them - nothing major, mostly minor questions on JSON-LD usage.
Manu Sporny: There are two ways null can be used in JSON-LD... in the @context and in the body of the document. I think we found consensus last time by stating that if 'null' is used in the value position in the body of the document, then a processor must ignore the key-value pair. If null is used in the @context, it has a number of different effects:
Manu Sporny: Clear the active context: "@context": null and "@context:" [null, ...]
Manu Sporny: Clear a term/prefix declaration: "term": null,
Manu Sporny: Clear the datatype associated with a term: "term": {"@id": "http://example.org/term", "@type": null}
Manu Sporny: Clear the language associated with a term: "term": {"@id": "http://example.org/term", "@language": null}
Manu Sporny: Clear the container type associated with a term: "term": {"@id": "http://example.org/term", "@container": null}
Niklas Lindström: I believe that the last 3 mean the same thing is if you define a term w/o a @type/@language/or @container.
Gregg Kellogg: Yes, I think so.
Niklas Lindström: People might want to use @language to do "title_en" and "title_sv"
Niklas Lindström: Should language mean something there? We've never used it in a @term definition before, right?
Gregg Kellogg: Why don't we create an issue for this and discuss it later.
Markus Lanthaler: "@id": null: clear the whole term declaration. What if that it's in the body? (see also #84)
Markus Lanthaler: Perhaps we should also define what happens if something like { "@value": null, "@language": "de" } is in the document.. I assume we just discard the wholetyped/language-tagge d literal.
Markus Lanthaler: The same for lists? Or should "@list": null" result in an empty list? (this is probably related to #79)
Gregg Kellogg: @set is not used in the body, only the @context.
Markus Lanthaler: Maybe we should discuss that as well - another issue.
Gregg Kellogg: my opinion - @id: null causes the object to be ignored - in @context should be equivalent to term null.
Gregg Kellogg: Within the body, if you use @id: null - then the object has no definition.
Manu Sporny: I think @id: null should mean "no id", not "no object" - it should generate a bnode.
Niklas Lindström: If you use @id: null for a term, we have an open question on whether or not that term should be possible to use in ISSUE-84.
Manu Sporny: I think we should discard the whole object for { "@value": null, "@language": "de" }
Markus Lanthaler: yes
Markus Lanthaler: @list: null should discard everything as well.
PROPOSAL: Unless otherwise specified, when 'null' is used in the @context, it removes any definition associated with the key.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: Unless otherwise specified, when 'null' is used in the @context, it removes any definition associated with the key.
Discussion about initial context - what should we have in there?
Markus Lanthaler: Can you override those values in the initial context?
Gregg Kellogg: yes.
Gregg Kellogg: I think the key is to treat this uniformly... I think @type taking and @id.
Markus Lanthaler: Well @id and @type are special cases, we don't need them in the initial context.
Gregg Kellogg: My processor would pay attention to this.
Niklas Lindström: I think that @id has an intricate meaning, @type when it's used as datatype is fine... but @type as it is used as rdf:type could be in the initial context. It is an alias for rdf:type. We may want to raise an issue about @type - I think Josh Mandel asked that now we have @container: @set - if you could define @type to always be of type @container: @set.
Niklas Lindström: Another case - if you don't want rdf:type to have @coerce @id on them, which we have now, you may want to have a plain object w/ a URI for the type... or label for the type. There are certain use cases that warrant this. You might want to define a term for @type. It might be good to clear the default definition by setting "@type": null in initial context.
Markus Lanthaler: That would change JSON-LD completely.
Niklas Lindström: If we don't go in this direction we can't support all of RDF.
Niklas Lindström: That is the initial context definition.
Markus Lanthaler: You wouldn't need to reset @type.
Niklas Lindström: If you don't reset @type, then we don't know what compaction would do.
Manu Sporny: Let's tackle this initial context issue later, we already have an issue for it...
PROPOSAL: If @context is set to 'null', then the active context is cleared or set to the initial context (depending on the resolution to ISSUE-80)
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1
Niklas Lindström: +0.5
Niklas Lindström: +1
RESOLUTION: If @context is set to 'null', then the active context is cleared or set to the initial context (depending on the resolution to ISSUE-80)
PROPOSAL: If 'null' is associated with a key in the body of a JSON-LD document, then the JSON-LD processor MUST act as if the key-value pair was never declared. If @value or @list is set to null in expanded form, then the entire JSON object is ignored.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +1
RESOLUTION: Unless otherwise specified, if 'null' is associated with a key in the body of a JSON-LD document, then the JSON-LD processor MUST act as if the key-value pair was never declared. If @value or @list is set to null in expanded form, then the entire JSON object is ignored.
Topic: ISSUE-79: Define how empty arrays are handled
Gregg Kellogg: Last time I spoke about this, I mis-spoke - empty arrays should be removed from normalization if they are not a @set or @list.
Gregg Kellogg: How do we preserve it if we're a set.
PROPOSAL: If an empty array ([]) used as a value is not subject to @list coercion, then the value MUST be removed from normalized output. The empty array MUST be preserved in compacted and expanded output.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
David I. Lehn: +1
Markus Lanthaler: +1
RESOLUTION: If an empty array ([]) used as a value is not subject to @list coercion, then the value MUST be removed from normalized output. The empty array MUST be preserved in compacted and expanded output.
Discussion around whether we should support the preservation of [] for @set.
Gregg Kellogg: I don't see a compelling reason here - it's incompatible with RDF, we'd have to invent something new to preserve it. If we create something new, then we'd have an issue when we went down to triples.
Markus Lanthaler: Is an empty set different from an empty list? From a developers point of view?
Manu Sporny: I think developers that know RDF will see a difference between empty set and empty list, those that don't - won't.
Gregg Kellogg: I think framing is what they use this stuff for.
Markus Lanthaler: All of this applies to lists as well - why should they be any different.
Niklas Lindström: An empty set of triples is nothing.
Niklas Lindström: s/is/says/ really. :)
Gregg Kellogg: We have a graph model - that is one of the limitations of graphs - they can't represent the absence of information.
Gregg Kellogg: The only way to do this would be to construct some meta-node... a vertex that had meaning outside of RDF.
Niklas Lindström: .. NOT EXISTS { ?s ex:term ?o }
Manu Sporny: Is there an argument here for preserving @set [] in compaction?
Niklas Lindström: I think so
Gregg Kellogg: I'm supportive of that.
Manu Sporny: Would we mess w/ the document structure?
Gregg Kellogg: let's say we have a @container: @set - do we change to array form when compacting
Manu Sporny: So in expansion do we keep @set?
Niklas Lindström: I don't think so... I think @set is removed when expanding.
Gregg Kellogg: The idea would be that general expansion algorithm, when expanding values not in array form, would put them into array form. When compacting, you can always count on the fact that values are in array form.
Gregg Kellogg: In expanded form, all values are in an array. In compacted form, we compact down to whatever is the simplest.
Markus Lanthaler: You lose the empty @set when doing normalization.
PROPOSAL: When normalizing, anything that is not coerced to a @list container type that has an empty array for its value is removed from the normalized output.
Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: When normalizing, anything that is not coerced to a @list container type that has an empty array for its value is removed from the normalized output.
PROPOSAL: When compacting and expanding, anything that is coerced to a @set or a @list container type that has an empty array for its value is preserved in the compacted and expanded output.
Niklas Lindström: +1
Gregg Kellogg: +1
Manu Sporny: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: When compacting and expanding, anything that is coerced to a @set or a @list container type that has an empty array for its value is preserved in the compacted and expanded output.
Niklas Lindström: .. values for syntactic keys: @value, @language, @id, and @type *when used for a datatype*..
PROPOSAL: Unless otherwise specified, when performing the expansion algorithm all values must be contained in a JSON array structure. This does not apply to values for syntactic keys such as @value, @language, @id, and @type when used to specify a datatype.
Niklas Lindström: +1
Manu Sporny: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
David I. Lehn: +1
RESOLUTION: Unless otherwise specified, when performing the expansion algorithm all values must be contained in a JSON array structure. This does not apply to values for syntactic keys such as @value, @language, @id, and @type when used to specify a datatype.
Niklas Lindström: .. should we propose:" When compacting, anything that is coerced to a @set or a @list container type has its values put into an array in the compacted output, even if there is only one value."?
PROPOSAL: When compacting, anything that is coerced to a @set or a @list container type has its values put into an array in the compacted output, even if there is only one value.
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Manu Sporny: +1
David I. Lehn: +1
RESOLUTION: When compacting, anything that is coerced to a @set or a @list container type has its values put into an array in the compacted output, even if there is only one value.
Manu Sporny: I think we may want to move this to W3C...
Manu Sporny: Maybe in a month.
Gregg Kellogg: Lots of spec updates to make, but we should be in good shape.