- From: William Waites <ww@styx.org>
- Date: Fri, 25 Mar 2011 10:41:14 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>
* [2011-03-23 20:42:10 +0000] Richard Cyganiak <richard@cyganiak.de> écrit: ] I moved the JSON use cases to a separate page: ] http://www.w3.org/2011/rdf-wg/wiki/TF-JSON-UC While I agree broadly with this categorisation and the consensus that seems to be forming that #1-3 are in-scope and #4 is out of scope I think there is a general skew towards representing RDF in JSON and too little consideration given to the reverse. This shows up throughout the discussions where people use phrases like "to publish JSON" which except for a degenerate meaning where a client might "publish" JSON to a server that then transforms it to RDF in some way seems to show that the thinking is about how to look at RDF data and not how to create it piecewise. I am not talking about an unconstrained thing like #4. The interaction might require some external shared knowledge between the client and server in the case of a lossy transformation. I certainly wouldn't want to get into completely aribtrary JSON. But where the main data store is RDF, and the interaction with the client software is JSON, we need some consistent way to consume this JSON. I hope we don't come up with something that means this always has to be done in a hand-crafted application-specific way. Just suggesting that some more explicit attention be given to the process of *de*serialisation when considering the various proposals. Cheers, -w -- William Waites <mailto:ww@styx.org> http://river.styx.org/ww/ <sip:ww@styx.org> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
Received on Friday, 25 March 2011 09:41:43 UTC