W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

Re: [JSON] Summary of direction discussion

From: Ivan Herman <ivan@w3.org>
Date: Wed, 23 Mar 2011 09:36:06 +0100
Cc: Sandro Hawke <sandro@w3.org>, Manu Sporny <msporny@digitalbazaar.com>, RDF Working Group <public-rdf-wg@w3.org>
Message-Id: <CD082A74-4749-45E4-B2E4-4923118CACD9@w3.org>
To: Steve Harris <steve.harris@garlik.com>

On Mar 23, 2011, at 09:15 , Steve Harris wrote:


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

I am a little bit bothered by the formulation here. 'JSON for SPARQL' may mean two different things:

1. a JSON serialization for SPARQL SELECT/ASK query results
2. a JSON serialization for RDF usable for a SPARQL CONSTRUCT results

I would think that #1 is not relevant for this Working Group; the SPARQL WG has a Note that they may or may not update for SPARQL 1.1 (if it is necessary) and that they may or may not promote to a Recommendation.

#2 is obviously a matter for this Working Group.

I would prefer that we would avoid using and referring to SPARQL in this respect. As far as I am concerned, it just confuses things.

> That may be true of most people in the group, but personally I think it's much more urgent than RDF-in-JSON.

Which of the two above? #1 or #2?

> From my perspective RDF-in-JSON is a bit of a niche interest, web developers aren't clamouring for it in my experience, but they are clamouring for easier to use SPARQL results.

Again the same question... If we are talking about #1, it is irrelevant for this group.

> N.B. I'm very much in the big databases world these days, not person-in-bedroom hackers, so that probably colours my viewpoint. But I do keep an eye on what linked data-y people are achieving, it seems pretty heavily SPARQL dependent from what I can tell.
> I think the Facebook API shows how important generic (if limited) query access to resources is, wouldn't it be nice if APIs of that nature were based on an open standard, rather than random SQL-like subsets?
>>> 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
>> Yeah, because I think they're both important.  :-)
> I think they're both important too, but I was sticking up for business use, as no-one else was.

I think that Manu's division is a bit harsh here because I have the impression that everybody considers both of them to be important. There may be different emphasis for people, but that is another statement.


>> In fact, I kind of like the idea of saying: if you want to propose a way
>> to transmit RDF in json, you have to provide some JS code to do the
>> conversion each direction, and we can plug those bits of code into a
>> demo/play site (even a wiki page).  :-)     Especially if we let people
>> use Pyjamas for python-to-javascript and GWT for java-to-javascript,
>> that might be reasonable.  Has anyone tried GWT on Jena?   A quick
>> search up doesn't turn up any successes, just people asking how to do
>> it.   
> +1, show me the code
> There are existing Turtle and NTriples parsers natively in Javascript. We can compare directly to those, on popular JavaScript engines.
>> I don't actually think we can rule something out at the stage because no
>> one is implementing it, but it sure would help us understand the
>> proposals to be able to play with them.
> I can imagine someone coming up with a format so obviously natural to JavaScript people, and representing a useful enough fraction of RDF that it seems like a good bet.
> If there's something that no one is implementing, you have to ask yourself why. It might be because no one has thought of it, but it might also be because no one wants it badly enough, or because it doesn't work in reality.

I think the situation here is a little bit different and it may be a chicken-and-egg issue.

Web Application developers looked at data integration issues. Fine. The may have looked at RDF, because it advertises itself as a good tool for data integration (or mashups, as this community prefers to say). For most of them RDF is equal to RDF/XML; if that is the only thing they saw, they ran away screaming. For some of them RDF may also include Turtle, the may not run away screaming but they still do not want to get into a very different world of very different parsers that they have to implement for that. Compounded to all this you have the inherent issues of RDF that might scare them, like the URI-string dualism or blank nodes. As a result, that community shuns the RDF world altogether. And the SW community does _not_ have anything to offer that would be to their taste. On the other hand, I think it would be a luxury to simply write that community off. _That_ is my main concern.


> To put it bluntly: RDF needs another mildly-popular serialisation like it needs a hole in the head.
> - Steve
> -- 
> Steve Harris, CTO, Garlik Limited
> 1-3 Halford Road, Richmond, TW10 6AW, UK
> +44 20 8439 8203  http://www.garlik.com/
> Registered in England and Wales 535 7233 VAT # 849 0517 11
> Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Wednesday, 23 March 2011 08:38:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC