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)?
Gregg Kellogg: no
Niklas Lindström: PROPOSAL 1: +1 (and add explanatory text explaining its effective use), PROPOSAL 2: -1
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.
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: Align with RDF WG ISSUE-105 (once there is a final decision from the RDF WG) regarding graphs, datasets, authoritative representations, and content negotiation.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
François Daoust: +1
Markus Lanthaler: +0 - no opinion (haven't read the issue yet)
RESOLUTION: Align with RDF WG ISSUE-105 (once there is a final decision from the RDF WG) regarding graphs, datasets, authoritative representations, and content negotiation.
Topic: ISSUE-197: Abuse of describedby relation in link header
Manu Sporny: There's disagreement whether the "describedby" link header can be used the way we use it for JSON-LD
Manu Sporny: The first question whether we should remove this feature
PROPOSAL: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header.
François Daoust: +1
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: Retain the ability to specify a JSON-LD context via the 'Link' HTTP header.
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
... but everything you mentioned (conneg) should work
Topic: ISSUE-140: Consider objectify/link API method
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.
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-184: Definition of JSON-LD processor in the API spec
Manu Sporny: Let's see if we can make any progress on this issue...
PROPOSAL: Move Data Model and Grammar to the JSON-LD API spec, and rename it to "JSON-LD
Markus Lanthaler: If we move the grammar as well, the syntax spec isn't a syntax spec anymore
Manu Sporny: I fear there are other normative statements as well, tidoust you checked that
François Daoust: there are normative statements but they are referenced by the grammar section, there's also the link header section which stands on its own
Niklas Lindström: How about "JSON-LD Concepts" or similar?
Gregg Kellogg: we could move the definitions to the API spec and just reference them from the syntax
François Daoust: you couldn't reference a non-norminative document from a norminative one
François Daoust: maybe we should defer decision on this until after all other issues are resolved.
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.