Agenda

http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0046.html

Topics

Google Summer of Code 2013
JSON-LD API and Futures
Implementation Report Submissions
2nd Last Call for JSON-LD API

Chair

Manu Sporny

Scribe

Gregg Kellogg

Present

Gregg Kellogg, Manu Sporny, Vikash Agrawal, Dave Longley, Niklas Lindström, Markus Lanthaler, Paul Kuykendall, David I. Lehn

Audio Log

audio.ogg

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.

Manu Sporny: https://dl.dropboxusercontent.com/u/5278881/GSoC/Proposal.html

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: https://github.com/slightlyoff/DOMFuture/

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.

Markus Lanthaler: http://json-ld.org/test-suite/idltest/

… 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.

Dave Longley: http://blog.izs.me/page/7

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.

Niklas Lindström: ... http://www.python.org/dev/peps/pep-3156/

… 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]

JSON-LD Community Group Telecon

Minutes for 2013-04-30

Topic: Google Summer of Code 2013

Topic: JSON-LD API and Futures

Topic: Implementation Report Submissions

Topic: 2nd Last Call for JSON-LD API