JSON-LD Telecon Minutes for 2012-11-20

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:54 UTC