Manu Sporny: Issues for today are 44, 52, 74, 76 - any updates or changes to the agenda?

Niklas Lindström: Issue 76 now references https://github.com/json-ld/json-ld.org/issues/84

Niklas Lindström: Covers support for controlled probing of unlinked objects

Niklas Lindström: In short, this is a way to parse values of things referenced by null terms (terms that are not bound to anything in the context) [scribe assist by Manu Sporny]

Niklas Lindström: This is more to allow terms to be null, but still allow their contents to be parsed. [scribe assist by Manu Sporny]

Manu Sporny: We'll keep this in mind today but might not have time to discuss it (84)

Ted Thibodeau Jr.: https://github.com/json-ld/json-ld.org/issues/44

Manu Sporny: this has been having out the for quite a while

Markus Lanthaler: I think he initially wanted this in framing

Manu Sporny: he found this to be wider than only for framing

Niklas Lindström: I'm not sure if he widened it to more than framing, but I think this is related to general context definitions. [scribe assist by Manu Sporny]

Niklas Lindström: I think it originated in framing, that's where he takes a graph and creates JSON from it - in his case, he applies a frame. In my case, I don't apply a frame, I just apply a context to my graph data. I have this same need. [scribe assist by Manu Sporny]

Niklas Lindström: The need I have is to define a context that ensures that I have a predictable shape for the data. [scribe assist by Manu Sporny]

Niklas Lindström: My primary data view is part of my construct - I have a predefinied view of a resource - I know how many nodes down there is. I have a limited graph. I apply the JSON-LD context to that limited graph. Then I know what the data looks like. [scribe assist by Manu Sporny]

Markus Lanthaler: We could make it possible if we say that a list or a set always has to be an array. [scribe assist by Manu Sporny]

Manu Sporny: ack: lanthaler

Markus Lanthaler: I think that the thing you're using @context for something they're not really used for. [scribe assist by Manu Sporny]

Markus Lanthaler: I think you're translating RDF data to JSON using the @context - that's usually used to transform JSON to RDF. [scribe assist by Manu Sporny]

Niklas Lindström: I don't need frames for this. [scribe assist by Manu Sporny]

Markus Lanthaler: How do you tell your customers what the shape of the data is? [scribe assist by Manu Sporny]

Markus Lanthaler: How do you tell your customers what the structure of the JSON-LD document is? Are they really using JSON-LD or are they just using the JSON part of JSON-LD? [scribe assist by Manu Sporny]

Niklas Lindström: They're just using the JSON I give them. [scribe assist by Manu Sporny]

Markus Lanthaler: So, there is external documentation? [scribe assist by Manu Sporny]

Niklas Lindström: There isn't - the customers just look at the service and use the record - if properties are missing, there is no problem - if they see a list, they know it's a list. If they see one value, they see one value. [scribe assist by Manu Sporny]

Markus Lanthaler: If you don't specify that in JSON-LD, but you generate the JSON-LD in a particular way, then it would be compliant to the spec, right? [scribe assist by Manu Sporny]

Niklas Lindström: Yes. However, it would be nice to just generate this from the JSON-LD processor. [scribe assist by Manu Sporny]

Manu Sporny: You could just use a JSON-LD frame for this, right? [scribe assist by Manu Sporny]

Niklas Lindström: Going from a simple context to JSON-LD frames would require me to write some 20-odd frames.... It would be more complexity for me to handle. We could just use @container: @set and be done with it. [scribe assist by Manu Sporny]

Gregg Kellogg: I do see value in "@container": "@set" in JSON-LD. [scribe assist by Manu Sporny]

Gregg Kellogg: It's not clear where other than in framing @container: @set would be applied

Manu Sporny: if @container: @set is specified in the context, key values in the document that match that term much be given in an array

Gregg Kellogg: It's not clear to me where the proposal is - we could look at expansion/compaction - the only place we could really apply this is framing. My RDF to JSON-LD translator could frame the data with that algorithm - where do we want this? [scribe assist by Manu Sporny]

Niklas Lindström: If you use @container: @set - you should use an array to encapsulate the data. [scribe assist by Manu Sporny]

Niklas Lindström: I see no harm in parsing it anyway... [scribe assist by Manu Sporny]

Markus Lanthaler: Would it be possible to say @container: @set maps to empty frames? [scribe assist by Manu Sporny]

Niklas Lindström: You mean that @container: @set would only be meaningful in frames? [scribe assist by Manu Sporny]

Markus Lanthaler: Yes... [scribe assist by Manu Sporny]

Niklas Lindström: I think that solves it for me. [scribe assist by Manu Sporny]

Manu Sporny: that would mean that any algorithm should through an exception if single values for container-set terms are encountered?

Gregg Kellogg: I agree, we should keep constraints on @container: @set to Framing.

Manu Sporny: the other option would be to add a new API call, e.g. "jsonld.listify()", which would turn every value in a document into a list

Niklas Lindström: Just want to make sure that if you have this - "references": {"@container" :"@set"}

Niklas Lindström: Then this - "references": "iri-1"

Niklas Lindström: Will be turned into this - "references": ["iri-1"]

Manu Sporny: it seems we have consensus on adopting @set in this manner. The other question is if we like this syntax proposed by Markus:

Gregg Kellogg: we have discussed this before, and came to the conclusion that @container was more consistent with the rest of json-ld

Markus Lanthaler: so @type cannot take arrays in contexts?

Manu Sporny: yes, remember that @type means something different

Manu Sporny: @type in the context is used to set the datatype of the property

Ted Thibodeau Jr.: perhaps put them onscreen?

Niklas Lindström: +1

Markus Lanthaler: +1

Manu Sporny: +1

David I. Lehn: +1

Ted Thibodeau Jr.: +1

Gregg Kellogg: +1

Niklas Lindström: +1

Ted Thibodeau Jr.: +1

Manu Sporny: +1

Markus Lanthaler: +1

David I. Lehn: +1

Gregg Kellogg: +1

Ted Thibodeau Jr.: https://github.com/json-ld/json-ld.org/issues/52

Manu Sporny: Dave Longley's suggestion is to disallow lists in lists for the time being (throw exception), and revisit this in the future if needed

Manu Sporny: anyone in need of lists of lists?

Markus Lanthaler: no, I'm fine without it

Gregg Kellogg: we haven't found any good use cases, and it would add a lot of complexity

Markus Lanthaler: +1

Niklas Lindström: +1

Ted Thibodeau Jr.: +1

Gregg Kellogg: +1

Manu Sporny: +1

David I. Lehn: +1

Ted Thibodeau Jr.: https://github.com/json-ld/json-ld.org/issues/74

Gregg Kellogg: the issue is if you have to terms which map to the same IRI, when you expand, you know have one key where there used to be two; when you compact, it is unclear what to do

Markus Lanthaler: the problem can also occur since you can use full IRIs as keys in documents even if there is a term for it in the context

Markus Lanthaler: on compaction, values with different datatypes should be divided between two terms with different coercion

Manu Sporny: we can't do "last key" wins (json keys aren't ordered)

Manu Sporny: we could use the more specific rule

Gregg Kellogg: there is no problem with e.g. xsd types; we already have specific types for values at this time

Manu Sporny: we currently have a non-determinism

David I. Lehn: agenda did say 120 mins :)

Manu Sporny: The intent for how IRI conflicts are resolved when compacting/expanding: any conflicts between terms that use the same IRI will use the most specific solution when compacting (for example, when compacting "foo": "5" and having to pick between a term that specifies "xsd:integer" as the type and one that doesn't, the one that specifies "xsd:integer" is selected)

Manu Sporny: If there is no solution that is more specific than the other, then a lexicographical comparison is made between the terms in the @context and the lexicographically least term and it's associated @type and other information is used to expand the data.

Manu Sporny: When expanding multiple keys that resolve to the same IRI, the expanded value will have all of the values associated with the IRI merged into a single JSON array.

Manu Sporny: (the order of the values in the resulting JSON array is undefined)

Niklas Lindström: +1 on the intent ;)

Gregg Kellogg: +1 on the intent too

Markus Lanthaler: +1

Manu Sporny: +1 on the intent

David I. Lehn: Good call, bye.

Gregg Kellogg: +1 to @container as part of selection