JSON-LD Telecon Minutes for 2013-04-30

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

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

Full text of the discussion follows including a link to the audio
transcript:

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

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Apr/0046.html
Topics:
   1. Google Summer of Code 2013
   2. JSON-LD API and Futures
   3. Implementation Report Submissions
   4. 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:
   http://json-ld.org/minutes/2013-04-30/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]

-- 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 Tuesday, 30 April 2013 16:32:28 UTC