- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 23 Mar 2011 08:15:38 +0000
- To: Sandro Hawke <sandro@w3.org>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, RDF Working Group <public-rdf-wg@w3.org>
On 2011-03-23, at 05:24, Sandro Hawke wrote: > On Tue, 2011-03-22 at 21:04 -0400, Manu Sporny wrote: >> 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 That may be true of most people in the group, but personally I think it's much more urgent than RDF-in-JSON. 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. 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. >> 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 > > It depends on the context I think, but I'm mostly in the "vital" camp. I'm more or less in the good, not vital camp. >> 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 > > Ummm, I'm skeptical that you can serialize arbitrary RDF in JSON that > feels nice enough to work with, without a library, that people will be > willing to use it, unless they have other strong reasons to use RDF. > > In a perfect world, we could come up with a perfect way to serialize RDF > in JSON that just felt right to Javascript users, without them even > needing to use a library. I don't see how that's possible. I don't > even see how namespaces (aka IRI abbreviation) could be handled. > > >> 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. > > I'm not sure we need to go through the documents. I prefer the idea of > just looking at side-by-side examples, as Tom suggested. Agreed. If you think it's important, put it on a reading list. > 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. 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
Received on Wednesday, 23 March 2011 08:16:15 UTC