Topic: ISSUE-170: Clarify sets and lists

PROPOSAL 1: Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form.

PROPOSAL 2: Remove the @set keyword, as we have a compactArrays flag that allows the developer to specify that they always want property values to be placed into arrays.

that's me, unknown there. just listening

Markus Lanthaler: PROPOSAL 1: +1, PROPOSAL 2: -1

discussion about whether we talk about @set in context here or in document

Manu Sporny: Are we agreeing that we don't want to remove it from the body either Gregg?

Gregg Kellogg: I have no strong opinion

Niklas Lindström: would it make the algorithms more complex if we remove it (from the body)?

PROPOSAL: Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form. For the avoidance of doubt, @set is allowed in the body of a JSON-LD document and the spec should explain it's use within the @context and the body of the document.

Manu Sporny: +1

Gregg Kellogg: +1

Niklas Lindström: +1

François Daoust: +1

Markus Lanthaler: +1

RESOLUTION: Clarify why the @set keyword exists in the JSON-LD Syntax specification. Namely, it exists if developers want to selectively ensure that a term's values will always be compacted to an array in compacted form. For the avoidance of doubt, @set is allowed in the body of a JSON-LD document and the spec should explain it's use within the @context and the body of the document.

Topic: ISSUE-182: Graph vs DataSet

Niklas Lindström: In general I'm a bit worried putting Dataset so prominently in the spec

Gregg Kellogg: the motivation for named graphs was provenance.. not really as a dump format

... I also can see other formats such as RDFa supporting named graphs in the future

Niklas Lindström: In general I just need to see were the RDF WG is going with this

... so far it was at the wrong level of abstraction IMO

Manu Sporny: We can't say a JSON-LD document represents a graph because that's just not true, so this is the only viable option.

PROPOSAL: Normatively define the concept of a JSON-LD Dataset. In the context of a Dataset, a JSON-LD document including only a default graph serializes a Dataset with only a default graph. A JSON-LD document describing a default graph and/or one or more named graphs serializes a Dataset with default and named graphs.

Manu Sporny: +1

Gregg Kellogg: +1

François Daoust: +1

Niklas Lindström: +0

Markus Lanthaler: +1

RESOLUTION: Normatively define the concept of a JSON-LD Dataset. In the context of a Dataset, a JSON-LD document including only a default graph serializes a Dataset with only a default graph. A JSON-LD document describing a default graph and/or one or more named graphs serializes a Dataset with default and named graphs.

PROPOSAL: Normatively define the concept of a "JSON-LD document", including description of the scope of blank nodes, which is the scope of the document.

Markus Lanthaler: +1

Niklas Lindström: +1

Manu Sporny: +1

Gregg Kellogg: +1

François Daoust: +1

RESOLUTION: Normatively define the concept of a "JSON-LD document", including description of the scope of blank nodes, which is the scope of the document.

PROPOSAL: Add in the RDF-mapping section Richard is writing a statement that JSON-LD documents serialize datasets (which may contain only a default graph)

François Daoust: +1

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +0

Markus Lanthaler: +1

RESOLUTION: Add in the RDF-mapping section Richard is writing a statement that JSON-LD documents serialize datasets (which may contain only a default graph)

Manu Sporny: The RDF WG will have to discuss this - "encourage RDF concepts to consider that a dataset syntax (such as TriG, N-Quads or JSON-LD) may be used wherever a pure graph syntax is used, using only the default graph. Environments performing content negotiation for a graph may accept a dataset serialization, either using only the default graph, the name equivalent to the URI the document is retrieved from, or the union of all graphs within the dataset, or reject documents serializing more than just a default dataset (pick one)." [scribe assist by Manu Sporny]

PROPOSAL: The rel=http;//www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

Gregg Kellogg: +1

Manu Sporny: +1

François Daoust: +1

Niklas Lindström: +0.5 (it shouldn't be tied to media-type)

Markus Lanthaler: +0.5 if we can make that IRI to dereference to a JSON-LD context describing the feature

Gregg Kellogg: I we want to register "context" as a rel type with IANA, it should be general-purpose

Niklas Lindström: I'm a bit sad that this is so specific to JSON-LD and that neither transform, nor profile nor anything else seems to be usable

Manu Sporny: It might be too early to register something like this.. we might do this in JSON-LD 2.0 if other systems have a similar feature (e.g. RDFa)

RESOLUTION: The rel=http://www.w3.org/ns/json-ld#context relationship replaces the 'describedby' relationship as the mechanism that is used to instruct the JSON-LD processor on which context it should use to interpret the document.

Markus Lanthaler: What's the process to set up such a namespace document?

Manu Sporny: We should talk to Ivan and Sandro.. we did that for RDFa ... we might need to be in last call

Topic: ISSUE-179: Consider moving WebIDL to Appendix or Note

Manu Sporny: It looks like the proposal with the least -1's is to not do anything

Gregg Kellogg: it depends whether we rename the API spec or not

Gregg Kellogg: I think the question is whether it is normative or non-normative

Manu Sporny: François made a good point by asking which specs have a non-normative API... not many, if any.

Gregg Kellogg: if we make the API normative there should be a test suite for it

François Daoust: I think the question is whether to keep the API or not

... having a non-normative API in a REC track document seems very weird

... an alternative would be to define two types of products (algorithms/API)

Gregg Kellogg: you voted -1 to move it to a normative appendix

François Daoust: yes, that looks like a trick to just hide it but not changing anything

... I would be fine with switching sections though

Markus Lanthaler: I wouldn't mind but I'm not sure if this is enough for the RDF WG

Manu Sporny: it might be.. especially considering to change the API spec's name

François Daoust: another possibility would be to publish the API as an informative note

... to not lose it completely

PROPOSAL: Place the Algorithms section in the JSON-LD API document before the API section. Make the API section normative, but clarify that implementers MAY provide their own API that is compliant with the Algorithms.

Gregg Kellogg: +1

Manu Sporny: +1

Niklas Lindström: +1

Markus Lanthaler: +0.8

François Daoust: +1 (note that's more or less the "two classes of product" solution I was suggestion, meaning we may need to introduce that in the doc)

RESOLUTION: Place the Algorithms section in the JSON-LD API document before the API section. Make the API section normative, but clarify that implementers MAY provide their own API that is compliant with the Algorithms.

Topic: ISSUE-188: Numbers and booleans as @type

Manu Sporny: Richard seemed to have the most supported proposal on this...

PROPOSAL: State in the definition of each applicable algorithm that the input is a (well-formed) JSON-LD document. State in the conformance section of theAPI/Algorithms/Proce ssing document that the spec does not constrain the behaviour of JSON-LD processors for JSON documents that are not (well-formed) JSON-LD documents.

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

François Daoust: +1

Niklas Lindström: +1

RESOLUTION: State in the definition of each applicable algorithm that the input is a (well-formed) JSON-LD document. State in the conformance section of theAPI/Algorithms/Proce ssing document that the spec does not constrain the behaviour of JSON-LD processors for JSON documents that are not (well-formed) JSON-LD documents.

Topic: ISSUE-171: Value Compaction broken

Manu Sporny: We need to update all of the algorithms to take things like language maps and property generators into account. The value compaction algorithm assumes too much about the input and needs to be updated to take things like type coercion, language maps, and property generators into account. Not much else we can do on this issue right now.