- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 25 Apr 2013 13:16:41 -0400
- To: Linked JSON <public-linked-json@w3.org>
- CC: RDF WG <public-rdf-wg@w3.org>
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