JSON-LD Telecon Minutes for 2012-08-07

Thanks to François for scribing! The minutes from today's call are now
available here:

http://json-ld.org/minutes/2012-08-07/

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

--------------------
JSON-LD Community Group Telecon Minutes for 2012-08-07

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2012Aug/0005.html
Topics:
   1. New github event notification system
   2. ISSUE-149: Create a pre-processing step option for the API
   3. ISSUE-146: Support array position to property binding
   4. ISSUE-147: Add synchronous methods to the API
   5. ISSUE-80: Remove initial context from API spec
Resolutions:
   1. Do not support a pre-processing step option in the JSON-LD
      API to transform incoming JSON.
   2. Do not support a declarative mechanism that is capable of
      mapping array position to an RDF property.
   3. The JSON-LD API method signatures across all languages are
      exactly the same. If a developer wants synchronous behavior, they
      MUST NOT add the callback parameter. Add an issue marker to the
      JSON-LD API spec stating that this functionality is at risk.
Chair:
   Manu Sporny
Scribe:
   François Daoust
Present:
   Manu Sporny, Gregg Kellogg, François Daoust, David I. Lehn,
   Niklas Lindström, Markus Lanthaler, Dave Longley
Audio:
   http://json-ld.org/minutes/2012-08-07/audio.ogg

Manu Sporny:  Any changes to the agenda? [scribe assist by Manu
   Sporny]
Gregg Kellogg:  Perhaps looking at the new github event
   notification system? Mirror the activity over to rdf-comments.
   [scribe assist by Manu Sporny]
François Daoust is scribing.

Topic: New github event notification system

Manu Sporny:  Stephane sent an email about this new mechanism on
   Github.
   … I looked at it yesterday.
   … It could work. We could register a user, one email address
   per project, maybe, I think, though.
   … Two ways to go: through the W3C system, or through a
   reflector to rdf-comments.
   … Either way would work fine. Any opinion?
Gregg Kellogg:  I suggest to bring it up on the RDF call
   tomorrow.
   … Other people might want to use that on top of JSON-LD.
David I. Lehn: github folks might add features you need if they
   don't have them now
Manu Sporny:  sounds good.
   … The other concern I have is about spamming the list with
   tiny changes.
   … 3 filtering options I think, commits to the repo are just
   sent but they may not be related to the spec itself.
Gregg Kellogg:  there's an argument that maybe we should split
   things up.
   … Using sub projects might be a better way to move forward.
Gregg Kellogg:  we could use Github pages.
Manu Sporny:  Can you run JS server-side there?
Gregg Kellogg:  not sure.
   … Two separable issues. We can keep the PHP system the way we
   have it today.
Manu Sporny:  The other issue is that all the minutes are
   generated, so it needs write access. It's done automatically.
   … To me, it looks too much of a headache for the time being.
   … We'll propose the reflector to the RDF WG tomorrow and see
   what they'll say.

Topic: ISSUE-149: Create a pre-processing step option for the API

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/149
Manu Sporny:  An attempt to address some of the other concerns
   that people have.
   … First thing where pre-processing might apply would be to
   split an array into properties where each positions in an array
   is mapped to different properties
   … (example of location)
   … We could add a mechanism in JSON-LD that explicits the
   mapping.
   … A more generic way of doing this is to add a pre-processing
   step where a function gets called during expansion to do the
   mapping.
   … That would allow us to support this mapping without having
   to put the explicit mapping.
   … The argument against is that people can already do it by
   running a pre-processing step themselves.
   … What do people think? No pre-processing? declarative?
   pre-processing function?
Niklas Lindström:  I'm for declarative only or nothing.
   … You can already do that.
   … I also fear that to some extent any arbitrary JSON may be
   JSON-LD given some pre-processing hook.
   … The only way to understand the JSON would be to have
   declarative mechanism.
Gregg Kellogg:  I'm of the same opinion. I also think that it's
   not necessary.
   … It just doesn't really do anything.
   … It basically says: run any arbitrary code you want.
   … It doesn't really provide any useful thing for authors. They
   won't know how to implement that given some context.
   … I agree that if we want to support something like this, it
   should be a declarative mechanism.
Manu Sporny:  others?
Markus Lanthaler:  I agree.
Manu Sporny:  The argument in favor is to give developers some
   hook to think differently, to know how to do it.
   … They might think: "Oh, I just need to implement that
   pre-processing step to convert my JSON into JSON-LD".
Niklas Lindström:  I think that there might be general
   transformation specs around that might be more applicable to that
   case.
François Daoust:  Having given this some thought - there is one
   thing that developers very often use... [scribe assist by Manu
   Sporny]
François Daoust:  The .replace() function in JavaScript... you
   can change data in any way that you want - you can use a regular
   string, or you can use a function... it's more flexible. It gives
   developers some flexibility [scribe assist by Manu Sporny]
François Daoust:  From an external point of view, the declarative
   mechanism seems too complex, with not much added value. [scribe
   assist by Manu Sporny]
Gregg Kellogg:  good use for the Wiki to reference techniques.
Manu Sporny:  indeed, totally agree with Gregg.
Nicklas: I think that we should be careful about this notion in
   the spec. The purpose of JSON-LD is to find the precise semantics
   of a document and this all relates to arbitrary consumption of
   it.
Markus Lanthaler: don't know if you guys saw it.. I added a
   "Publications / Articles" and "Presentations" section to the
   homepage: http://json-ld.org/#publ
   … You can always say JSON + code = RDF.
Markus Lanthaler: I don't think we need a wiki (yet)
Manu Sporny: mlnt, Yep saw it - good work and we should use that.
Manu Sporny:  So proposal is: do not support a pre-processing
   step option in the JSON-LD API

PROPOSAL:  Do not support a pre-processing step option in the
   JSON-LD API to transform incoming JSON.

Manu Sporny: +1
Niklas Lindström: +1
Gregg Kellogg: +1
Markus Lanthaler: +1
François Daoust: +1
David I. Lehn: +1

RESOLUTION: Do not support a pre-processing step option in the
   JSON-LD API to transform incoming JSON.

Topic: ISSUE-146: Support array position to property binding

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/146
Manu Sporny:  This is the reason why we started with ISSUE-149
   since it would have solved this one.
   … The argument is that they have a bunch of data with lat/lon
   coordinates and they don't want to be overly verbose in their
   data, adding lat/lon properties. They'd like to work with data in
   their native form, as lat/lon couples.
   … The request is thus to support a declarative way of being
   explicit about the mapping.
   … Do we feel that it is something that is acceptable?
   … I don't think they'd be happy if we don't support but the
   previous point about introducing complexity stands.
   … Any thoughts on this? Should we add it right now? Later on?
   Not at all?
Gregg Kellogg:  One of the strongest objections against
   pre-processing was that it should have been done at the RDF
   level.
   … One way that this could be done is to use a list form,
   SPARQL, and… [scribe did not get the explanation]
   … There's also a tendency that JSON-LD is looking too much at
   having the spec adopted by anyone, adding everything to please
   everyone.
   … In this case, the tuple position seems to be very
   domain-specific.
   … I think there are other ways to do that.
Niklas Lindström:  even in JSON, using property names as keys is
   more common.
   … Also there might be more interest to define a vocabulary to
   describe such things.
   … Question is whether to keep this on the proposition list for
   a potential JSON-LD 1.1. I had this issue when I saw geo-json.
   … I think of SPARQL as a good success going to 1.0 without
   adding new ideas that were quickly finalized afterwards in 1.1.
Manu Sporny:  I agree with everything that has been said so far.
   The argument that they can do the transformation in RDF and
   SPARQL, I don't think that this is acceptable to developers all
   around toying with JSON-LD.
   … I don't think that telling them to mess with RDF or SPARQL
   is good idea.
   … So proposal is to not support a declarative mechanism to
   support such mappings.
Gregg Kellogg:  If we have a very SPARQL-like mechanism in JSON,
   that could be very useful. For another spec.

PROPOSAL:  Do not support a declarative mechanism that is capable
   of mapping array position to an RDF property.

Markus Lanthaler: +1
François Daoust: +1
Manu Sporny: +1
Gregg Kellogg: +1
David I. Lehn: +0
Niklas Lindström: +0.5 (since I like it, but probably not for
   1.0)

RESOLUTION: Do not support a declarative mechanism that is
   capable of mapping array position to an RDF property.

Topic: ISSUE-147: Add synchronous methods to the API

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/147
Niklas Lindström:  Initially, it struck as a bit odd when I tried
   to use the API in my RDF lab experiments.
   … From what I understand, the reason for expand/compact
   methods to be asynchronous is that there may be external
   resources that might be fetched.
   … I/O in JavaScript is preminently asynchronous.
   … It may be interesting to add synchronous companions.
   … In my case, I didn't have to lookup external context.
Manu Sporny:  interesting talk about Node.js forwarded by Dave.
   … Methods have "Sync" companions which is nice for people who
   have background in Python, Ruby, etc.
   … One thing he said though is that it was a mistake because
   you ended up not knowing whether the function was synchronous or
   asynchronous.
   … The same comment applies to our API. It doubles the size of
   the API. It might cause issues with developers.
   … The arguments you pass to the synchronous methods and the
   asynchronous methods are slightly different.
   … My preference would be to just provide asynchronous methods
   for the time being.
   … Even in Python or Ruby, it's not a big deal to pass on a
   function pointer as a function parameter.
Gregg Kellogg: +1
   … I'd stick to an asynchronous API until someone yells about
   adding synchronous methods.
Niklas Lindström:  I would just add a note that tells
   implementors that they are free to implement synchronous methods
   if they prefer.
Manu Sporny:  I don't think we should do that. This would create
   two different function signatures.
   … If we allow implementors to not allow callback functions,
   libraries cannot be dropped and replaced.
Gregg Kellogg:  my implementation is actually synchronous, but I
   do support the asynchronous callback of course.
   … Some languages are more suitable for synchronous-style
   programming in which case you can do the same.
   … I don't think we need anything. I also agree that we
   shouldn't add new function signatures in the spec.
   … Easy enough to add a wrapper without having to make it part
   of the spec.
http://scriptlib-cg.github.com/api-design-cookbook/#when-to-be-asynchronous
François Daoust:  Looking at another WG API - API design
   cookbook. [scribe assist by Manu Sporny]
François Daoust:  This section is empty for the time being...
   [scribe assist by Manu Sporny]
François Daoust:  We should get in touch with the editor...
   [scribe assist by Manu Sporny]
François Daoust:  I'd prefer asynchronous-only, but Robin may
   have useful feedback for us. [scribe assist by Manu Sporny]
Niklas Lindström:  in Python, it's not common at all to pass
   callbacks. It's more common to have a "sync" parameter.
   … Asynchronous code is harder to read.
   … Of course, there may be a case where you have external
   context.
   … I would favor a situation where, when you have no callback,
   you would trigger the synchronous mode.
Manu Sporny:  interesting idea. That would keep the same
   signature between functions.
Gregg Kellogg:  That's basically how things work in Ruby.
   … although more common to use a block.
   … A reasonable approach is to provide a behavior when there is
   no callback
Gregg Kellogg:  that does complicate things a bit.
Niklas Lindström:  note that in JavaScript, it might be difficult
   to convert from asynchronous to synchronous.
François Daoust:  I would be against a different behavior based
   on a parameter in a function - switching between async vs.
   sync... [scribe assist by Manu Sporny]
François Daoust:  I think developers forget parameters every now
   and then, I'd rather not go down this path. [scribe assist by
   Manu Sporny]
François Daoust:  If we decide to go down that road, I wouldn't
   use the same function for both. [scribe assist by Manu Sporny]
François Daoust:  Or, we would want an explicit parameter.
   [scribe assist by Manu Sporny]
Niklas Lindström:  I don't think it's that uncommon.
François Daoust:  I can't think of an example in JavaScript.
   [scribe assist by Manu Sporny]
Manu Sporny:  I have never seen any of the core Node.js API doing
   any of this. I do agree with Francois that it would be dangerous
   to change the behavior just because you forget a parameter.
   … On one case it's a neat trick because it keeps signature
   consistent, but changing the behavior based on the presence of a
   parameter is dangerous.
   … We could mention the synchronous methods informally without
   spec-ing them in Web IDL.
   … I.e. to add documentation to the JSON-LD API that the core
   Web IDL is going to be only asynchronous, but that if the
   developer wants to add synchronous interfaces, they could add
   "Sync", remove the callback and return the result of the call.
[discussion around asynchronous/synchronous in different
   languages]
François Daoust:  I was looking at the JSON-LD API document, at
   .compact() and .expand() - what about the error mechanism? There
   are callbacks there, right? [scribe assist by Manu Sporny]
Markus Lanthaler:
   https://github.com/json-ld/json-ld.org/issues/100#issuecomment-5719453
François Daoust:  You can't throw an exception while you're in a
   real asynchronous call... if something wrong happens, you can't
   just throw an exception and catch it from the main thread.
   [scribe assist by Manu Sporny]
Markus Lanthaler: we already resolved this, see link above
Niklas Lindström: .. another example of "synchronous" when no
   callback is passed: http://ajaxrpc.com/
François Daoust:  ok good, thanks!
Manu Sporny:  Going back to the initial problem.
   … In JavaScript, there is almost never a good reason to be
   synchronous. In Python, it's a bit of the contrary. There are
   good arguments either way. I still think we should provide
   asynchronous methods only.
   … The error mechanism is problematic as well. You cannot
   simply return an exception to stop the execution.
Niklas Lindström:  In general, I think that asynchronous APIs are
   more complex.
Manu Sporny:  I believed that three months ago, but think the
   other way around.
   … now that I've played with Node.js. I hated it in the
   beginning but now wish that Python has asynchronous interfaces
   the same way.
Niklas Lindström:  adding a callback does not mean the function
   would be asynchronous.
Manu Sporny:  true.
Markus Lanthaler: s/Niklas/Markus
Manu Sporny:  if the developer forgets to include the callback,
   it's going to act completely differently. Though we may say they
   are using the API incorrectly.
   … The proposal becomes "The API signature across all languages
   is exactly the same. If you want to have synchronous behavior,
   just don't add the callback parameter".
Niklas Lindström:  I like it better although I very much respect
   the notion of code errors.
   … Maybe we should look at other APIs.
François Daoust: +1 to reach out to other groups that produce
   APIs.
Gregg Kellogg:  We could add a note to the spec asking for
   feedback.

PROPOSAL:  The JSON-LD API method signatures across all languages
   are exactly the same. If a developer wants synchronous behavior,
   they MUST NOT add the callback parameter. Add an issue marker to
   the JSON-LD API spec stating that this functionality is at risk.

Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
François Daoust: +1
Markus Lanthaler: -0.5
David I. Lehn: +0

RESOLUTION: The JSON-LD API method signatures across all
   languages are exactly the same. If a developer wants synchronous
   behavior, they MUST NOT add the callback parameter. Add an issue
   marker to the JSON-LD API spec stating that this functionality is
   at risk.

Manu Sporny: Note that we intend to explore this mechanism
   further before finalizing the API spec.

Topic: ISSUE-80: Remove initial context from API spec

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/80
Manu Sporny:  We never quite resolved this.
Markus Lanthaler: last resolution was: If JSON-LD has an initial
   context, it MUST be specified external to the JSON-LD Syntax
   specification at a well-known location.
Manu Sporny:  There was a proposal where the initial context
   would have @type and @graph.
   … Do we have a use for the initial context? I think that we
   don't at this point, really. We can always introduce an initial
   context.
   … The initial context would future-proof the language. That's
   why it's there in RDFa. But I don't think that's needed for
   JSON-LD.
   … The proposal is not to support the initial context in v1.0.
Gregg Kellogg:  there's a big push for us to reach feature
   freeze. I think that not putting it in now would mean it's going
   to be hard to add it back later on.
   … I think it's valuable to have it in there even if it's empty
   for the reason you mention about future versions.
   … I've seen some arguments on the RDF mailing-list that we
   should leave this for now and add it back in v1.1 or v2.
   Similarly, this would make it difficult to roll back on that
   decision later on if we don't keep it in the spec.
   … And then at some point in the future, we may discuss whether
   it makes sense to define prefixes or the like.
Markus Lanthaler:  Why do you see a problem to bring it back
   later on?
   … It's mentioned once in all the algorithms?
Gregg Kellogg:  I'm thinking just from a procedure point of view.
Markus Lanthaler:  The way it's written, it's useless.
Gregg Kellogg:  I think that's something we need to address, to
   give a way for it to be modified outside of the spec.
Markus Lanthaler:  Not sure I want to see that.
Niklas Lindström:  It is more confusing for authors. It would be
   simpler if we didn't have it here. You have to monitor that
   context.
Manu Sporny:  If we had an initial context, it would be
   completely outside of the spec, maintained by Ivan.
   … The initial RDFa context was really useful to convince large
   companies to support RDFa.
Dave Longley: any security issues? does the initial context live
   at an HTTP endpoint vs. an HTTPS one?
   … The problem is more political than technical. Pure
   extractors are not going to extract data from a document that is
   not explicit about its initial context.
   … It seems that it would be a bad move not to have a mechanism
   to correct this.
   … I agree with Markus that it is not going to be a big deal
   for JSON-LD as it was for RDFa.
Dave Longley: seems like a potential security problem to require
   all JSON-LD processors to hit an insecure endpoint to initialize
   themselves
Gregg Kellogg:  I don't understand how that works if it's in the
   spec.
Manu Sporny:  My preference is still to add a URL for an initial
   context, and then leave it empty up until we need it. Not a big
   deal if it ends up not being used.
Markus Lanthaler:  If we put it in there right now, we won't ever
   be able to drop it afterwards.
   … That would then need that every JSON-LD processor would need
   to fetch the IRI.
Manu Sporny:  Processors can cache the context.
Markus Lanthaler:  But how do you fix the problem then?
Manu Sporny:  Software updates.
   … The overhead for starting a new group, creating the spec,
   adding the feature and starting to work on a standard is 9 month
   to 2-3 years.
Markus Lanthaler:  I just don't see the real scenario that would
   pop-up for that.
   … You use terms most of the time. Hopefully we won't have
   requests from large companies to put all terms in the initial
   context.
Markus Lanthaler:  The other point is that it's easy to reference
   an external context through a URI.
Manu Sporny:  good points on either side.
Manu Sporny:  If large companies could agree on something such as
   schema.org, they are in a good position to drive the inclusion of
   the vocabulary in the initial context. We may not like that or
   want that, but that's how things go.
Niklas Lindström:  It's easy for publishers to add all the terms
   from schema.org in their context.
Manu Sporny:  interesting discussion that we already had in the
   RDFa WG. We should discuss again.
Markus Lanthaler:  we already can do that with an optional
   context in expand/compact.
Markus Lanthaler:
   http://json-ld.org/spec/latest/json-ld-api/#jsonldprocessor
[discussion adjourned]

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Which is better - RDFa Lite or Microdata?
http://manu.sporny.org/2012/mythical-differences/

Received on Tuesday, 7 August 2012 17:44:19 UTC