JSON-LD Telecon Minutes for 2013-04-23

Thanks to Niklas for scribing! The minutes from this week's telecon are
now available.

http://json-ld.org/minutes/2013-04-23/

Full text of the discussion follows including a link to the audio
transcript (audio not uploaded yet, will do so later):

--------------------
JSON-LD Community Group Telecon Minutes for 2013-04-23

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0023.html
Topics:
   1. JSON-LD API and Futures
   2. Term re-definition behavior
   3. Test Suite Design
Resolutions:
   1. Address ISSUE-125 by adopting a Futures-based approach for
      the JSON-LD API.
   2. When re-defining a term 'A', any previous definition for
      term 'A' is removed before the right hand side for the new
      re-definition is evaluated.
Chair:
   Manu Sporny
Scribe:
   Niklas Lindström
Present:
   Manu Sporny, Dave Longley, Niklas Lindström, Markus Lanthaler,
   Gregg Kellogg, Paul Kuykendall
Audio:
   http://json-ld.org/minutes/2013-04-23/audio.ogg

Manu Sporny:  Anything else we need to discuss today? [scribe
   assist by Manu Sporny]
Dave Longley:  We need to discuss terms and term redefinition.
   [scribe assist by Manu Sporny]
Niklas Lindström is scribing.

Topic: JSON-LD API and Futures

Manu Sporny:  this came out of a discussion re. node-callback
   style vs. future (and web spec) callback style
   …: it seems possible to ref. a spec outside of the w3c (whatwg
   futures)
   … most browser vendors intend to use that Future API
   ... so using nodejs callback style would deviate from this
   … dave and Markus have worked on impl. and spec changes to see
   what switching to Futures entails
Markus Lanthaler:

http://www.markus-lanthaler.com/tmp-futures/json-ld-api/#the-application-programming-interface
Markus Lanthaler:  not that many changes that had to be made
   … dropped the callback signatures and changed the void return
   type to Future
   … the algorithm didn't change at all
   … only how the methods are linked to the algorithms
   … now you create a future and return it, and then the caller
   resolves or handles error
   …I didn't include much details on Futures, instead decouple
   that from here and allow the referenced spec to describe the
   details
Manu Sporny:  although anne wanted us to mention some details,
   but that is now be expressed in this futures-adaptation
Gregg Kellogg:  an example could illustrate how this is used
Dave Longley:  a danger with that would be that an example would
   be invalid if the Futures API changes
Markus Lanthaler:  the good thing is that that isn't normative
   though
Manu Sporny:  that would be a nice tradeoff; and we can to some
   extent change examples even after REC
Manu Sporny:  and we don't have to to the overloading anymore?
Markus Lanthaler:  true
   …. error callback also returns a Future; overall no
   fundamental changes
Dave Longley:  what does the load context cb resolve to? the
   return value used to include final url and data
Markus Lanthaler:  now either string error or dictionary with url
   + context
Dave Longley: http://promises-aplus.github.io/promises-spec/
Dave Longley:  futures, based on Promises/A+
   … I've looked at something implementing this in JS
   … the API is similar to Futures, but not identical
   … I went ahead and implemented Futures. Some changes is that
   previously we could just call the callback, now we have to pass
   an object [niklasl: did I get that correctly?]
   … [dave describes details on the implementation, regarding
   input and return values]
   ... I did complete an implementation of Promises/A+; I need to
   wrap that to make it compliant to the Futures spec. However, it
   may be that that spec changes to become closer to Promises/A+
Dave Longley:  I found it more difficult to use Futures than the
   node.js continuation-style, but that may be a part of the
   learning curve. It seems like the Futures spec may be changing
   and it may be changing closer to the Promises API. [scribe assist
   by Manu Sporny]
   … it's unclear right now. Noone uses this incarnation of
   Futures yet, apart from us...
Markus Lanthaler:  create/fulfil and reject are missing from
   Promies/A+, need to be added for Futures
Manu Sporny:  is this the right direction? It seems clear that we
   can add this, and that the Futures spec can evolve independently
Dave Longley:  from what I can tell, I'd expect that more people
   with experience will look at the Futures API and demand changes.
   But it will probably become what ends up in web browsers.
   … I don't think people will give up and go with the node
   callback style. It will end up different from now, but people are
   used to having a framework for this.
Gregg Kellogg:  it seems like a very elegant way of doing things.
   I'm nervous about using this at this early stage, but it seems
   like the right direction.
   … we seem to be able to handle spec changes of that , unless
   radical. The test suite must be adapted, but the spec text is ok.
Paul Kuykendall:  adding these changes this late in the game,
   using a spec in such an early stage, is somewhat worrying
Manu Sporny:  if we choose to take a path that goes away from the
   web platform (the browser vendor's POV), it may very well cause
   problems (with uptake..)
   … since this API is targeted to JS impl.s in the browser, this
   is important
Paul Kuykendall:  decoupling this would be good to get further
   along with the specs
   … it would be good to not bind the algorithms to the API
Manu Sporny:  that's done now
Gregg Kellogg:  but they are bound – they're in the same spec
Gregg Kellogg:  if we fail to get to LC due to API instability,
   the algorithms fail along with that
Manu Sporny:  we could split the API out, we need to go to
   another LC; if we move to futures, same thing
   … we don't seem to want to take the no-change route
Markus Lanthaler:  also, the current callback style isn't like
   the callback-style done in browsers
Dave Longley:  we also need two independent implementations
Manu Sporny:  it could be fairly easy: use the core js impl. . of
   the algorithms but implement your own Futures on top
Markus Lanthaler:  most important to have impls implement the
   features/algorithms
Gregg Kellogg:  it doesn't seem to be required that futures are
   implemented async.
Niklas Lindström:  Regarding any other options - is it possible
   to have some parts of the API by demanding that the data passed
   in has previously resolved any fetching of any entities? [scribe
   assist by Manu Sporny]
Niklas Lindström:  This would be a two-pass approach, where every
   external reference would be resolved. [scribe assist by Manu
   Sporny]
Manu Sporny:  I think we tried to think about that approach, it
   would be a lot of cognitive load on the developers. [scribe
   assist by Manu Sporny]
Niklas Lindström:  It would be nice to have a mathematically pure
   transformation that is synchronous... it's sort of beside the
   point at this stage. [scribe assist by Manu Sporny]
   … [it would still have to be async to do the initial loading
   of external resources]

PROPOSAL: Address ISSUE-125 by adopting a Futures-based approach
   for the JSON-LD API.

Manu Sporny: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Dave Longley: +1
Paul Kuykendall: +1

RESOLUTION: Address ISSUE-125 by adopting a Futures-based
   approach for the JSON-LD API.

Manu Sporny:  This decision requires that the JSON-LD Algorithms
   and API spec must go through a second Last Call.
Manu Sporny: ISSUE-124 is resolved as a result of this resolution
   - http://www.w3.org/2011/rdf-wg/track/issues/124
Manu Sporny:  thus the optionals parameter can be the last, and
   optional
   … I all respond to the interested parties
Markus Lanthaler:  do we want to include an example or more
   prose?
Manu Sporny:  both would help
Paul Kuykendall:  will both specs go through LC or only
   algorithms and API?
Manu Sporny:  I believe only this; we can continue with Syntax to
   CR
   …. but the test suite uses the algorithms+API; so the Syntax
   would wait for that
   … after LC we could probably go to PR, once we have
   implementations reports etc.
Paul Kuykendall:  just checking the state of things when we base
   our future on something which is a draft...
Manu Sporny:  we do this to increase the chances of browser
   vendors of adopting this API
Markus Lanthaler:

https://github.com/json-ld/json-ld.org/commit/4751e057970d3ca3161cb43c37cd6f7f5c0ef57d
Markus Lanthaler:

https://github.com/json-ld/json-ld.org/commit/657c90f3fc4050fce006fa11a2a420e7e4efe049

Topic: Term re-definition behavior

Dave Longley:  to recap: this issue is about what the behavior is
   if you in a new context use a term in the RHS which is already
   defined. Should it remove the old term def before interpreting of
   the RHS
   … recursion would fail with recursion if the term is
   completely new...
Gregg Kellogg: [{"term": "a"}, {"@vocab": "b"; "term": "term"}]
Manu Sporny:  the last time, a bunch of us seemed to agree that
   the definition should be reset before the interpretation is done
Markus Lanthaler:  it's not a partial redefinition if you just
   use a term for expansion
   … if you delete a term as soon as it is defined you introduce
   an asymmetry
Gregg Kellogg:  re. the above example, this illuminates the
   choice
Dave Longley:  the cognitive load is reduced if we reset the term
   as soon as it is defined
Markus Lanthaler:  do we need to change anything in the
   algorithms?
Dave Longley:  just fix a bug and put some clarification in text
   in the algorithm

PROPOSAL: When re-defining a term 'A', any previous definition
   for term 'A' is removed before the right hand side for the new
   re-definition is evaluated.

Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
Dave Longley: +1
Paul Kuykendall: +1

RESOLUTION: When re-defining a term 'A', any previous definition
   for term 'A' is removed before the right hand side for the new
   re-definition is evaluated.

Dave Longley:  the only change in the algorithm is if you
   redefine a term which looks like a curie (which was brought up
   initially)

Topic: Test Suite Design

Manu Sporny:  basically we're keeping the test suite the same
   … for the api, we're going to have developers point to the
   test harness they use for the api
   … we have the approach for both the main syntax-focused suite
   and the API test suite
Gregg Kellogg:  EARL reports for the different manifests is
   enough to produce the report (in turtle or json-ld)
Gregg Kellogg:  the driving manifest will determine the absolute
   IRIs for the tests
Markus Lanthaler:  but locally hosted manifests will then resolve
   to different IRIs
Gregg Kellogg:  perhaps a base would be enough
   … the turtle test suite manifest has this problem currently
Markus, Gregg, and Dave Longley will submit implementation
   reports for a total of 5 implementations.
   … digital bazaar will have implementations in js, php and
   python
   ... [gregg on negative tests, datatypes, syntax tests]
Manu Sporny:  next stage is getting some reports done
   ... it would be good to get EARL reports from implementors
   … the format will be like the turtle reports
Gregg Kellogg:

https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/rdf.rb-earl.ttl
Gregg Kellogg:  this is the earl report for the turtle tests; the
   form will be the same
Dave Longley:  are we going to generate these reports in json-ld?
Gregg Kellogg:
   https://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/reports/index.html
Gregg Kellogg:  the report I use takes test manifests and
   individual reports; processes as RDF, runs sparql to extract
   results; and generates a json-ld file from that
Manu Sporny:  can each implementation produce JSON-LD?
Gregg Kellogg:  yes; it can take any RDF format, including
   JSON-LD
Manu Sporny:  better to send a report, or publish it?
Gregg Kellogg:  best to submit them through rdf-comments mailing
   list
   ... need to identify the specific processor used

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Thursday, 25 April 2013 17:17:04 UTC