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 Log
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: 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: 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

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