- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 26 Nov 2012 20:03:20 -0500
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
Thanks to Markus for scribing last week! The minutes from last week's
call are now available (I have yet to clean up and upload the audio):
http://json-ld.org/minutes/2012-11-20/
Full text of the discussion follows including a link to the audio
transcript:
--------------------
JSON-LD Community Group Telecon Minutes for 2012-11-20
Agenda:
http://lists.w3.org/Archives/Public/public-linked-json/2012Nov/0016.html
Topics:
1. ISSUE-159: Add specifying @language to expanded form
2. ISSUE-170: Clarify sets and lists
3. ISSUE-182: Graph vs DataSet
4. ISSUE-197: Abuse of describedby relation in link header
5. ISSUE-140: Consider objectify/link API method
6. ISSUE-179: Consider moving WebIDL to Appendix or Note
7. ISSUE-188: Numbers and booleans as @type
8. ISSUE-184: Definition of JSON-LD processor in the API spec
9. ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core
Processing
10. ISSUE-171: Value Compaction broken
Resolutions:
1. Close ISSUE-159 by referencing ISSUE-133: no further
actions required.
2. 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.
3. 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.
4. Normatively define the concept of a "JSON-LD document",
including description of the scope of blank nodes, which is the
scope of the document.
5. Add in the RDF-mapping section Richard is writing a
statement that JSON-LD documents serialize datasets (which may
contain only a default graph)
6. Align with RDF WG ISSUE-105 (once there is a final decision
from the RDF WG) regarding graphs, datasets, authoritative
representations, and content negotiation.
7. Retain the ability to specify a JSON-LD context via the
'Link' HTTP header.
8. 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.
9. Defer creation of a .graphify() mechanism until after
JSON-LD 1.0.
10. 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.
11. 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.
12. Define "JSON-LD processor" in a Conformance section in the
JSON-LD API.
Chair:
Manu Sporny
Scribe:
Markus Lanthaler
Present:
Markus Lanthaler, Manu Sporny, Gregg Kellogg, François Daoust,
Niklas Lindström
Audio:
http://json-ld.org/minutes/2012-11-20/audio.ogg
Markus Lanthaler is scribing.
Topic: ISSUE-159: Add specifying @language to expanded form
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/159
Manu Sporny: The proposal is to close this issue by referencing
ISSUE-133
PROPOSAL: Close ISSUE-159 by referencing ISSUE-133 - no further
actions required.
Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
François Daoust: +1
Niklas Lindström: +1
RESOLUTION: Close ISSUE-159 by referencing ISSUE-133: no further
actions required.
Topic: ISSUE-170: Clarify sets and lists
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/170
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.
Topic: ISSUE-182: Graph vs DataSet
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/182
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]
Gregg Kellogg: Related RDF WG issue is
http://www.w3.org/2011/rdf-wg/track/issues/105
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: https://github.com/json-ld/json-ld.org/issues/197
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)
Gregg Kellogg: rel=http://www.w3.org/ns/json-ld#context should
apply to any application/json, or sub-types
Niklas Lindström: I'm proposing that we use the IRI but define
it without using the media type
Discussion about how to define
http://www.w3.org/ns/json-ld#context ...
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: https://github.com/json-ld/json-ld.org/issues/140
Manu Sporny: niklas, I think you want this feature most.. any
objections to defer it
Niklas Lindström: no, I wouldn't object but I wouldn't mind
keeping it open till we really have no other issues open
Manu Sporny: we wouldn't close it - we would move it to the
JSON-LD.next milestone
PROPOSAL: Defer creation of a .graphify() mechanism until after
JSON-LD 1.0.
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1
Niklas Lindström: +0.95
Markus Lanthaler: +1
RESOLUTION: Defer creation of a .graphify() mechanism until after
JSON-LD 1.0.
Topic: ISSUE-179: Consider moving WebIDL to Appendix or Note
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/179
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: https://github.com/json-ld/json-ld.org/issues/188
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: https://github.com/json-ld/json-ld.org/issues/184
PROPOSAL: Define "JSON-LD processor" in a Conformance section in
the JSON-LD API.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
François Daoust: +1
Gregg Kellogg: +1
RESOLUTION: Define "JSON-LD processor" in a Conformance section
in the JSON-LD API.
Topic: ISSUE-178: Consider renaming JSON-LD API to JSON-LD Core Processing
Manu Sporny: https://github.com/json-ld/json-ld.org/issues/178
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.
Topic: ISSUE-171: Value Compaction broken
https://github.com/json-ld/json-ld.org/issues/171
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.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: HTML5 and RDFa 1.1
http://manu.sporny.org/2012/html5-and-rdfa/
Received on Tuesday, 27 November 2012 01:03:59 UTC