JSON-LD Telecon Minutes for 2012-12-04

The minutes from today's telecon are now available. I haven't been able
to clean up and upload the audio yet.

http://json-ld.org/minutes/2012-12-04/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
JSON-LD Community Group Telecon Minutes for 2012-12-04

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Dec/0004.html
Topics:
   1. Algorithm updates
   2. ISSUE-157: JSON-LD mapping to RDF terminology
   3. ISSUE-184: Definition of JSON-LD processor in the API spec
   4. ISSUE-153: Define error handler behavior
   5. ISSUE-182: Graph vs. DataSet
Resolutions:
   1. The JSON-LD API specification will define two products: 1)
      A JSON-LD Implementation, and 2) A JSON-LD Processor, which is
      dependent on a valid JSON-LD Implementation and implements the
      asynchronous API.
   2. Simplify the error handling mechanism by passing an error
      object to the callbacks which only consists of an error code and
      an optional error message containing additional information for
      debugging.
   3. State in the syntax spec that JSON-LD can be used as a RDF
      graph source. A consumer would just use the default graph and
      ignore all named graphs in that case. This would allow a server
      to use, e.g., both Turtle and JSON-LD in content negotiation.
Chair:
   Manu Sporny
Scribe:
   Manu Sporny
Present:
   Manu Sporny, Markus Lanthaler, Niklas Lindström, François Daoust,
   Gregg Kellogg
Audio:
   http://json-ld.org/minutes/2012-12-04/audio.ogg

Manu Sporny is scribing.

Topic: Algorithm updates

Manu Sporny:  The algorithms need to be revised.
Manu Sporny:  Dave Longley and I are going to go through and
   clean up the algorithms near Dec. 15th
Markus Lanthaler:  I'm going to update my JSON-LD processor this
   week, I hope to update the algorithms as well.
Niklas Lindström:  Hopefully, I'm going to have time to get back
   to the RDFa Labs stuff (which is JSON-LD under the hood)
François Daoust: [one thing to clean up: remove statements such
   as "If context is a string, it must have a lexical form of IRI"
   since that's a syntax consideration (and it's defined in the
   syntax spec), not a processing step]
Niklas Lindström:  I copied some of the JSON-LD implementation
   stuff as a result, if I have time I will be able to read through
   it and comment on it. I'd really like to be able to factor out
   the framing stuff.

Topic: ISSUE-157: JSON-LD mapping to RDF terminology

https://github.com/json-ld/json-ld.org/issues/157
Manu Sporny:  Richard was going to write this section, was too
   busy, Markus is going to write this up.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-syntax/#data-model
Markus Lanthaler:  I took an action to take over the RDF
   re-write, I put something in the syntax spec which is
   more-or-less what Richard has in his draft. It has a few
   clarifications and some things he misunderstood.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-syntax/#relationship-to-rdf
Markus Lanthaler:  That should explain the whole data model in
   all of it's detail and make it easy to map it to RDF. The
   relationship to RDF section is quite short at the moment, there
   are not many differences.
Markus Lanthaler:  We need some reviews of those two sections,
   don't know if they're happy with it yet.
Manu Sporny:  We strongly advise against using bnodes for
   properties, right?
Markus Lanthaler:  yes.
François Daoust:  Just one comment - we had removed MAY SHOULD or
   MUST from the data model. There should be constraints on the
   syntax itself, but not the data model.
François Daoust:  It's fine to say that the data model will be an
   IRI... but the grammar section should say SHOULD NOT use a bnode.
Discussion about data model section, relationship to RDF, and
   ensuring that we address all of the issues brought up by the RDF
   WG. The group believes that the changes will address everything
   raised by the RDF WG.

Topic: ISSUE-184: Definition of JSON-LD processor in the API spec

https://github.com/json-ld/json-ld.org/issues/184
Markus Lanthaler:  In general, I introduced a product which is a
   JSON-LD processor, which is the only product that the spec
   defines.
Markus Lanthaler:  I didn't say anything about parsing because a
   processor normally uses a JSON parser for parsing.
Markus Lanthaler:  I didn't say anything about transforming data
   to a dataset or anything else - it just transforms the document.
   I'm not sure if that's enough.
Manu Sporny:  I thought we'd have two classes of product: A
   "JSON-LD processor" and a "JSON-LD API implementation" (or some
   other name). [scribe assist by François Daoust]
Niklas Lindström:  Could you say something like: your JSON-LD
   processor must be compliant with the algorithms, it can also be
   be compliant with the API
Manu Sporny:  I think we should have two products, seems like two
   different things.
Markus Lanthaler:  Why would you want to do one and not the
   other?
Niklas Lindström:  Some programming languages make it difficult
   to implement the asynchronous API.
Manu Sporny:  Some developers would rather have a synchronous
   API, which we're not going to spec out. We also want to leave
   room for people to innovate on the API portion, as we may not
   provide something that is the best API for certain use cases.
François Daoust:  This is a way to defend the API - it's a way to
   keep the API in the spec, having two products. Not having two
   products will create a wall in the RDF working group - only need
   algorithms, don't need the API. Not having the API tied to a
   product diminishes its value in the spec.
Markus Lanthaler:  Could we have two levels of implementation?
   Level 1 and Level 2.
Niklas Lindström:  This is like having a processor supporting XML
   Infoset... and then having a DOM implementation on top of that.

PROPOSAL: The JSON-LD API specification will define two products:
   1) A JSON-LD Processor, and 2) An Implementation of the JSON-LD
   API, which is dependent on a valid JSON-LD Processor
   implementation.

Niklas Lindström: .. 1) A JSON-LD Processor, and 2) A JSON-LD API
   compliant Processor…?
Manu Sporny:  What about 1) A JSON-LD Processor, and 2) A JSON-LD
   Processor and API ?
Markus Lanthaler: maybe, a "JSON-LD Processor conformant to the
   JSON-LD API" or a "JSON-LD Processor implementing the JSON-LD
   API"
Niklas Lindström: 1) A JSON-LD Processor, and 2) A JSON-LD API
   implementation, which is a JSON-LD Processor

PROPOSAL: The JSON-LD API specification will define two products:
   1) A JSON-LD Implementation, and 2) A JSON-LD Processor, which is
   dependent on a valid JSON-LD Implementation.

Markus Lanthaler: +1
Manu Sporny: +1
Gregg Kellogg: +0.5
Niklas Lindström: +1
François Daoust: +1 (equally happy with other terms)

RESOLUTION: The JSON-LD API specification will define two
   products: 1) A JSON-LD Implementation, and 2) A JSON-LD
   Processor, which is dependent on a valid JSON-LD Implementation
   and implements the asynchronous API.

Topic: ISSUE-153: Define error handler behavior

https://github.com/json-ld/json-ld.org/issues/153
Manu Sporny:  Initially I had wanted us to try and figure out a
   way that a developer could signal that they wanted certain
   recoverable errors to be recovered automatically, or they'd
   provide the proper interpretation, or they would signal that
   processing should stop. A number of folks felt that was overkill,
   so the proposal on the table is to simplify the error mechanism
   to just a simple error callback mechanism with an error code and
   a message.

PROPOSAL: Simplify the error handling by passing an error object
   to the callbacks which only consists of an error code and an
   optional error message containing additional information for
   debugging.

Markus Lanthaler: +1
Niklas Lindström: +1
Manu Sporny: +1
François Daoust: +1
Gregg Kellogg: +1

RESOLUTION: Simplify the error handling mechanism by passing an
   error object to the callbacks which only consists of an error
   code and an optional error message containing additional
   information for debugging.

Manu Sporny:  Do we halt on recoverable errors?
Markus Lanthaler:  if it's recoverable, is it an error?
Gregg Kellogg:  Yes, for example - list_of_lists is recoverable,
   but it's also an error.
Gregg Kellogg:  I have a feature in my processor which is a
   'validate' mode.
Niklas Lindström:  Should the processor stop processing the local
   object, but continue on error?
Gregg Kellogg:  I feel like we should process as much as you can,
   so you can find as many errors as you can.
Gregg Kellogg:  A way to say 'stop processing' when you encounter
   an error is useful.
Gregg Kellogg:  We can have a runtime flag to say "stop when you
   hit an error" or "continue if you can, on error"
Manu Sporny:  I have a problem if we're going to start halting on
   errors that should be recoverable. If the XHTML vs. HTML5 debate
   has taught us anything, it's that processors should try to go as
   far as they reasonably can, sometimes changing the output
   drastically in order to not throw an error and "fix" the input to
   be something reasonable.
Markus Lanthaler:  Yes, but if we do that, the algorithms are
   going to get far more complex... we have to cover every error
   case and how to recover from it.
Manu Sporny:  I see your point, but I think that would be better
   than halting.
Gregg Kellogg:  I think we need at least two levels of errors -
   errors and fatal errors. We want to give folks warnings that
   their input is broken in some way and we "fixed" it.
Markus Lanthaler:  At the moment, the algorithms are defined for
   well-formed documents only. It's up to the processors to produce
   warnings if they want to, but they can do that however they want
   to.
Manu Sporny:  I think that we should use this error/issue
   mechanism to report both warnings and errors.
Markus Lanthaler:  Then we risk having this issue drawn out for a
   much longer time - this issue has already taken a long time to
   deal with.
Markus Lanthaler:  The reason this issue has been open for such a
   long time is that it's difficult to define error behavior for
   each of these cases.
Gregg Kellogg:  I think the reason is the complexity of the API
   callback, not having error recovery conditions.
Niklas Lindström: We need something like: "it is an error to use
   @type and @language in the same element. If that happens, a
   processor should ignore [one of them] and issue a warning." I.e.
   that is a usage error but doesn't result in a processor error,
   only a warning? What are the fatal errors?
Niklas Lindström:  I'm wondering where we're going here - the
   second proposal seems like it may or may not prohibit "Processing
   MUST be stopped after an error is triggered".
Gregg Kellogg:  in RDFa, we recently agreed to describe the
   redefinition of a prefix as a warning. This may come up in
   JSON-LD as a warning.
Gregg Kellogg:  malformed IRIs can also be warnings.
Gregg Kellogg:  A processor should be able to classify that as an
   error, but a non-fatal error.
Niklas Lindström:  I'm thinking of the two different situations,
   where you have a JSON-LD processor (one is during development -
   you may have odd data - raise a warning and continue on
   errors)... in production mode, you might want to halt on the
   first warning/error. I wouldn't want to define something in the
   spec where one of these cases is excluded.
Markus Lanthaler:  In development, you want more debug output -
   it's not just about warnings/errors. I don't think we need to
   specify that in the spec.
Markus Lanthaler:  It's dependent on implementations - some might
   want to debug, do warnings and errors.
more discussion on how to get warnings to developers.
Gregg Kellogg:  I think we need 'warnings', 'errors', and 'fatal
   errors'
Niklas Lindström:  You could just deal with this in the error
   callback - throw an error if you want to stop, don't do it if you
   don't.
Gregg Kellogg:  The issue here is we need some way of saying
   'warnings', 'errors', or 'fatal errors'.
Markus Lanthaler:  What would need to be added?
Gregg Kellogg:  We just need a flag on the 'error', stating
   whether it's a 'warning', 'error', or 'fatal error'.
Manu Sporny:  We've burned a lot of call time discussing this.
   Let's go back to the issue tracker and get some concrete
   proposals down, straw-poll those through the issue tracker, and
   revisit this issue when we have something solid we can propose.

Topic: ISSUE-182: Graph vs. DataSet

https://github.com/json-ld/json-ld.org/issues/182
Manu Sporny:  The RDF WG has kicked this issue back to us and
   told us that we need to drive the issue. I think we're all in
   agreement here on what needs to be done. So, let's see if we have
   consensus here, and if we do, we'll tell the RDF WG that this is
   where we have consensus.

PROPOSAL: State in the syntax spec that JSON-LD can be used as a
   RDF graph source. A consumer would just use the default graph and
   ignore all named graphs in that case. This would allow a server
   to use, e.g., both Turtle and JSON-LD in content negotiation.

Manu Sporny: +1
Markus Lanthaler: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Gregg Kellogg:
   https://github.com/json-ld/json-ld.org/issues/182#issuecomment-10973315
François Daoust: +1

RESOLUTION: State in the syntax spec that JSON-LD can be used as
   a RDF graph source. A consumer would just use the default graph
   and ignore all named graphs in that case. This would allow a
   server to use, e.g., both Turtle and JSON-LD in content
   negotiation.

Gregg Kellogg:  This resolution is still a bit problematic. For
   example, in many of the named graphs cases, the default graph
   would only contain provenance information... the actual data
   would be contained in a named graph. This is problematic, so
   maybe servers would have to serve their data in a different way.
Niklas Lindström:  The issue with named graphs is that you use
   them in a different way when you manage your data internally.
   That's how you handle the quoting of the dataset stuff...
Niklas Lindström:  When you ask the system for the JSON-LD
   document for a named graph, you would get the information from
   that back in a default graph.
Gregg Kellogg:  Well, another proposal I put forward was [scribe
   missed]
Manu Sporny:  I think the problem here is that there are many
   ways to use named graphs and we can't suggest something that is
   going to work across the board. What we might do is tell people
   the following: If the top-most JSON Object contains a '@graph'
   keyword, use that as the 'default graph', if it doesn't contain a
   '@graph' keyword, use the top-most JSON Object as the default
   graph. If we do that, then we don't hit the issue that Gregg
   mentions above.

-- 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 Thursday, 6 December 2012 01:28:45 UTC