JSON-LD Community Group Telecon

Minutes for 2013-04-30

  1. Google Summer of Code 2013
  2. JSON-LD API and Futures
  3. Implementation Report Submissions
  4. 2nd Last Call for JSON-LD API
Manu Sporny
Gregg Kellogg
Gregg Kellogg, Manu Sporny, Vikash Agrawal, Dave Longley, Niklas Lindström, Markus Lanthaler, Paul Kuykendall, David I. Lehn
Audio Log
Gregg Kellogg is scribing.
Manu Sporny: Welcome to Vikash, who is one of the potential Google Summer of Code students
Vikash Agrawal: Thank-You :)

Topic: Google Summer of Code 2013

Manu Sporny: Vikash is one of the proposal writers. there are around 40 people interested, but just about 10 proposals so far.
… Deadline is May 3rd.
… There's usually a big rush of comments coming in; trying to stay on top.
… Vikash has one of the stronger proposals, and it speaks well that he's on the call today.
Vikash Agrawal: I've started through the implementation last week. Depending on what's going on, I'll do more updates.
… I'm also looking forward more criticism and ideas on where I can improve.
Manu Sporny: you're probably not getting too much feedback, as it's a pretty good proposal. If we go forward, we might end up changing some small things.
Dave Longley: I watched most of the discussions on IRC, and thought the plan was good.
Vikash Agrawal: I've updated the proposal with drop-box links.
Manu Sporny: it's a pretty solid proposal, and I don't think you need to improve anything right now.
… He's going to update the json-ld.org website, and then create a tool to allow easy creation of input.
… Once he's finished "json-ld creator", he's going to start converting LinkedIn API data to JSON-LD.
… Lastly, writing documentation and tutorials.
Dave Longley: yup
Vikash Agrawal: as I said, my task is to understand the schema now, so that I can save time in GSoC.
… I'll need some help as I start working with schema.org.
Niklas Lindström: ... {"@context": {"@vocab": "http://schema.org/"}}
Niklas Lindström: hopefully, the context won't much much more than that example.
Manu Sporny: It might be worth having a full-blown context, so that it can be mixed.
Manu Sporny: You could either write it as a simple @vocab, or you could specify each vocabulary element in schema.org explicitly in the context.
Markus Lanthaler: You can leverage http://schema.rdfs.org/ should be fairly trivial to generate a context out of that
Markus Lanthaler: there's even a JSON version
Manu Sporny: Just using @vocab might make it hard to mix in other vocabularies, and not have them be confused with schema.org.
Niklas Lindström: I still think the first option is better, in principle. The other one may be a bit to overzealous.
Manu Sporny: vikash, you might look at this as well: https://w3id.org/payswarm/v1
Gregg Kellogg: We do need to consider that there might be IRI range properties that vocab might not capture properly. [scribe assist by Manu Sporny]
… If your goal was to do this, I'd write a script to transform schema.org (or schema.rdfs.org) to JSON-LD.
Manu Sporny: Clearly, this will require some discussion.
Markus Lanthaler: wanted to ask what programming languages he knows. Perhaps he'd be interested in writing a FireFox plugin.
Vikash Agrawal: Python, JS, HTML, CSS.
… I plan to work entirely client-side in JavaScript.
Markus Lanthaler: Would you be interested in implementing a JSON-LD processor.
… It would be interesting to see if it's easy for you to implement in another language.
Manu Sporny: we should think about how to best use GSoC student's time. While implementing another processor would be useful, maybe not as useful as some of these other tools.
… An implementation of an API in a browser is something we can already do via jsonld.js. Doing it again would not be too efficient.
Manu Sporny: We could swap out the LinkedIN project for work on another API implementation in JS.
Markus Lanthaler: it would be pretty valuable to get input from someone not as familiar with the algorithms.
Markus Lanthaler: for the LinkedIn API you should look at https://github.com/antoniogarrote/json-ld-macros
Vikash Agrawal: We could try to make the LinkedIN JSON converter generic, so that we could convert anything to JSON-LD, or specific, which might be easier.
Markus Lanthaler: that should make it quite generic (and declarative)
… I'd start with a specific implementation, and then go on to make it more generic.
… Starting out to make something generic might take too much time.
Markus Lanthaler: there's an example transforming GitHub's API to JSON-LD

Topic: JSON-LD API and Futures

Manu Sporny: dlongley has implemented the API, markus the spec-text.
Dave Longley: I talked on whatwg channel and found this futures implementation.
… I took this and made a dependency of jsonld.js, if you're using the API. It allows you two different ways to use the API, one with futures, one with traditional callbacks.
… The WebIDL harness now passes the tests.
… Everything passes except for one that I don't think it's possible to pass.
… I also re-wired the playground to use futures, and everything works okay.
… Markus was talking about changing this to output an EARL report.
Gregg Kellogg: It struck me that by looking at the IDL framework, it should output EARL. [scribe assist by Manu Sporny]
Gregg Kellogg: having EARL reporting in the test harness would be good for everyone!
Vikash Agrawal: I had a problem with the playground implementation.
Manu Sporny: we can update what you've done later on.
Dave Longley: some of the down-sides are that they still seem to be debating what futures should be done.
… It's unclear when things should be asynchronous, and when not.
… As far as we're concerned, we've written a spec such that those details are abstracted away.
… They're also debating how to handle progress events. If you construct a future, if it can begin before you attach handlers, you might miss something.
… There'a also general debate over how to join futures together and handle other asynchronous events.
… The stuff that does affect us is chaining code together; that's fairly complex, compared to simple callbacks.
… When using futures, it's not clear when to use "then" or "done", and takes generally more cognitive load.
… All that being said, all these problems might go away when ES6 is adopted, as they have a new "yield" keyword, that makes all the extra stuff go away.
… Yield would halt the stack frame; this makes asynchronous programming look like synchronous programming.
… Writing the code looks a lot messier then custom code, however it might not be there for web programming.
… The end result might be elegant, but I'm not sure it's where I'd go.
Manu Sporny: The biggest concern I had is that in the short-term it's going to be more work than the node-style callbacks. The idea is that this would be invoked through a generic mechanism.
Markus Lanthaler: :-)
Gregg Kellogg: I think this stuff is really half-baked. We might want to do callback style now, and then do a NOTE on Future style. [scribe assist by Manu Sporny]
Markus Lanthaler: pkuyken.... it's at WHATWG... it's a living standard :-P
Paul Kuykendall: any indication on when future's supposed to be fully baked? We're getting push back because we're not using a spec, but that's not fully baked.
Dave Longley: it's a living standard and will never be truly "stable".
… My problem is that I don't see the node.js people embracing this.
… But, if browser vendors are going this way, this is the direction we're going to have to take.
… People working on futures should be looking more at how node.js works.
… If promises were first-class citizens and could be optimized, then he'd be "all about" them.
... The general feeling I best is that everyone's going to be pushing for people who write Web APIs to use futures.
… If you're going to be on the web, futures is where things are going. Otherwise, probably not.
Manu Sporny: the API is really just for the browsers, we shouldn't pretend it's for anything else.
… If we break ranks with that, we're not doing ourselves any favors.
Dave Longley: the end goal is tighter integration with JS, and that seem like the way things are going.
… Python is going in a different way, probably not so much in other languages.
Niklas Lindström: I basically agree with dlongley; the API is coming part of an upcoming W3C spec. If it was a node spec, then node-style API would be suitable. Futures is very much the way the W3C specs are going.
… My impression is that Futures should be the way to go.
… In Python, they will likely adopt web API interfaces, such as already done with the DOM API.
Markus Lanthaler: it's pretty stable; I only needed to write a couple of sentences.
… We talked about adding examples, but I don't actually think we should do this, as they would have to change if the living spec changes.

Topic: Implementation Report Submissions

Manu Sporny: People should be submitting implementation reports over the next few weeks. [scribe assist by Manu Sporny]
Gregg Kellogg: Yes, just make sure that you output in the EARL report format we covered last week. [scribe assist by Manu Sporny]
Gregg Kellogg: As soon as we start getting those, I'll push out versions of the consolidated EARL report in HTML, JSON-LD, and TURTLE. I'm trying to update my own version. [scribe assist by Manu Sporny]
Markus Lanthaler: I've hit a minor problem with the test suite. [scribe assist by Manu Sporny]
Markus Lanthaler: I've started implementing a test harness based on PHP-unit. The problem is that if you can't do expansion, you can't expand the hash URIs.
Gregg Kellogg: I propose we keep the hash-based URIs. Those that can submit EARL reports can do some processing (they know how to do it). [scribe assist by Manu Sporny]

Topic: 2nd Last Call for JSON-LD API

Manu Sporny: we'll need a 2nd last call because of the Futures change. We don't need to do one for syntax, so we could move it to CR.
… By moving syntax to CR we can ask for implementations.
… The proposal is to be able to enter CR, and have them both come out of CR at the same time.
Gregg Kellogg: How does someone claim conformance of the syntax. [scribe assist by Manu Sporny]
Manu Sporny: we're a subset of JSON, it's the processor that determines that what you have turns into JSON-LD.
Markus Lanthaler: similar question, do we need to resolve features at risk for CR (maybe not).
… secondly, how to we establish exit criteria.
Manu Sporny: I'm proposing we go to CR and say that the exit criteria is passing the test suite.
… In fact, the JSON-LD API might not go to CR at all.
… I'll send details to the list.
David I. Lehn: [END OF TELECON]