[JSON] Summary of direction discussion

Hey folks,

The chairs have set aside some time during the call tomorrow to discuss
the direction of the JSON work. This will be in addition to the
discussion we had yesterday. Since both Chris and Richard wanted to make
the call but couldn't, this will hopefully give them a chance to let
their point of view be known as well (as anyone else that has an opinion
on the JSON stuff). The complete minutes for the call can be found here:

http://www.w3.org/2011/rdf-wg/meeting/2011-03-21

Having had a whole day to process the meeting, I'll try to summarize how
the discussion may affect our direction. This is my take on the current
state of discussions, so it may be off slightly or may have completely
missed the mark.

There are a few generalizations that became more clear as a result of
the discussion on Monday. I'm going to put names beside the people that
I think support each general initiative because it helps me figure out
if I'm reading them correctly. It may also help them understand whether
or not they're communicating their position clearly:

JSON for SPARQL
---------------

It seems that everyone seems to think that JSON for SPARQL data streams
would be not only useful but would be beneficial. However, nobody seems
to be gung-ho about it - it's somewhat important, but nobody has said
that they see a large problem if it doesn't exist in the next 2-4 years.

People that think JSON for SPARQL is a good idea:
   Everyone

People that think this can be accomplished on our timeframe:
   Everyone

Sense of urgency:
   Moderate to Low

Key Communities
---------------

There are two very different classes of communities that we're
personally motivated to address:

   Government/Enterprise and Independent Web Developer

While Sandro's chart has a whole range of communities, when asked, many
of the people on the call tended to focus on the two communities above.
There didn't seem to be much talk about the middle - and I don't really
know if we've been able to identify exactly who is in the middle.

People that lean more toward Government/Enterprise:
   Andy Seaborne, Steve Harris, Lee Feigenbaum

People that lean more toward Independent Web Developer:
   Manu Sporny, Thomas Steiner, Ivan Herman, Nathan Rixham

People that I don't have a good read on:
   Sandro Hawke

Lossy Encoding
--------------

Round tripping the RDF data is import to some, not so much to others.
Some of this has to do with whether or not the RDF data is encoded in
JSON in a way that is lossy. Lossy encoding means that you may not be
able to round-trip all RDF data.

People that think round tripping is vital:
   Andy Seaborne

People that think round tripping is good, but not vital:
   Manu Sporny, Ivan Herman, Nathan Rixham

People that I don't have a good read on:
  Steve Harris, Sandro Hawke, Lee Feigenbaum, Thomas Steiner

Standardizing "Barely Works"
----------------------------

There is a concern about standardizing something that is barely good
enough, but will prevent a great solution from emerging. For example, if
we adopt JSN3 or JSON-LD, and it turns out that they're not really good
at addressing the general Web Developer Community, we'll have put a road
block in place for innovation to happen in this area. Some would argue
that this is what happened with RDF/XML.

People very concerned about "barely works":
   Steve Harris, Lee Feigenbaum

Needs strong proof/evidence that problems are addressed:
   Andy Seaborne, Sandro Hawke,

Unknown:
   Thomas Steiner, Ivan Herman

Thinks that we have the start of something that will work:
   Manu Sporny, Nathan Rixham

Skeptical that you can take arbitrary RDF and serialize it to JSON:
   Steve Harris, Sandro Hawke

Unfamiliarity with Formats
--------------------------

There were two points in the discussion where it became apparent that
there were large misunderstandings about the design rationale behind the
formats being taken as input documents.

I had looked at the JSN3 spec countless times but missed that it was
keyed by subject. Nathan had thought that JSON-LD was attempting to be a
kitchen-sink spec, rather than attempting to outline every possibility
and then allowing this group to whittle down the functionality into a
reasonable set.

Nathan and I have spent a considerable amount of time thinking about
these problems and discussing them over the past year. If /we/ can't
even keep the design rationale straight between the two formats that
we've been working on, I have a strong feeling that those just joining
the discussion are having a very hard time understanding the options on
the table... which is leading to skepticism.

I think we're going to have to go through the input documents on the
calls in order to ensure that all of us have done the due diligence
necessary to understand the problem space. I know that sounds like
overkill, but I think there is a large degree of mis-communication that
is happening right now as a result of unfamiliarity with the input
documents.

------------

So, that's what I took away from the discussion on Monday - where did I
misunderstand positions?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Payment Standards and Competition
http://digitalbazaar.com/2011/02/28/payment-standards/

Received on Wednesday, 23 March 2011 01:05:26 UTC