Re: [JSON] Summary of direction discussion

> 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

Ivan split it into :
1. a JSON serialization for SPARQL SELECT/ASK query results
2. a JSON serialization for RDF usable for a SPARQL CONSTRUCT results
and I'll add
3. JSON CONSTRUCT{} for direct templating of JSON output.

but, from watching the LDA (= Linked Data API) work, I also see that 
there the goal included the JSON output customized.  It is a lot more 
complicated than a one-fromat-fits-all approach.  It is not yet ready 
for standardization by W3C as it being deployed and refined now.

Just one example:
What about arrays of values in the output: natural in JSON.

So, if the app wants: how is that [] going to get done?  What if it's a 
variable length of results (e.g. measurements over the last 24 hours - 
and the site can't always be contacted) in a specific order?

{
   "CWOP station":  "http://weather.gladstonefamily.net/site/C2888" ,
   "latest":
          "http://www.findu.com/cgi-bin/wxpage.cgi?last=24&call=CW2888"
   "location": [ 51.5000, -2.5764 ] ,
   "date":     "2011-03-23T09:02:30+00:00",
   "hourly temp": [ 7.9, 8.2, 8.4, 9.1 ] ,
   "last7days":
 
"http://weather.gladstonefamily.net/cgi-bin/wxobservations.pl?site=C2888&days=7"
}

or making all the display-intended strings the Welsh form because the 
user prefers it that way.  And the temp is in C -- half that site is F 
and half C.

(This is a real weather station in Bristol BTW)

> Key Communities
> ---------------
>
> There are two very different classes of communities that we're
> personally motivated to address:
>
>     Government/Enterprise and Independent Web Developer

For me, these aren't separate.  I gave examples from the gov domain 
because they are public and we can all look at them.  But the data 
consumers are as much the independent web developer as an enterprise IT 
developer.  In fact, there aren't "web developers", there are people 
trying to produce community websites with data from several places.  Web 
technology is the means to the end.

> 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

Another dimension is "data currently JSON" and "data currently RDF". 
What do people focus on here?

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

My point is are we, up front on day one, ruling out sending 
RDF-equivalent data back from the webapp from the design space?  To 
date, the discussion is almost entirely about the webapp consuming data 
but not giving back.

Personally, I think that what we produce must stand good for several 
years so targetting a particular known issue without a bigger picture is 
dangerous (opart of the "close but not right" effect).

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

Are we joining that discussion?

JSON-LD: sec 1.1:
"""
encode Microformats, RDFa, or Microdata in a way that is cross-language 
compatible via JSON.
"""
so where's large-scale published RDF?

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

The barrier I am encountering with JSON-LD is that it while it says in 
the intro it is for "Web developers that want to understand the design 
decisions and language syntax for JSON-LD." there is no discussion of 
the design choices and why decisions were made; it explains (tutorial) 
and defines one design. (No, sec 2 does not do discuss the choices)

 Andy

Received on Wednesday, 23 March 2011 09:30:51 UTC