- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Fri, 18 Mar 2011 14:12:52 +0000
- To: Manu Sporny <msporny@digitalbazaar.com>
- CC: RDF WG <public-rdf-wg@w3.org>
> I think there are some assumptions being made here that should not be > made. Why does the process need to be reversible? Why are we assuming > that the storage mechanism is a graph store? Why aren't the requirements > and expectations application/standard specific? We aren't assuming that the storage mechanism is a graph store, but given a work package that is RDF-izing JSON, we seem to be assuming it definitely isn't and can't be with that service having to understand some domain-specific translation. Effectively, ruling out (web) graph stores. It's a writable web - so far, the emphasis is on reading JSON as RDF. Those applications are level 5(?), 6 and 7 may wish to output to graph stores or other RDF-based systems. It's webapps working acorss more than one service. What about the complement to parseJsonAsRDF(str)? outputRDFfromJSON(obj). > I'm assuming that the main thing you want is for the output format to be > the same as the input format, but I don't see why that necessarily has > to be the case. For example, Twitter supports the following output > formats: JSON, XML, RSS, ATOM. However, it only supports XML and JSON as > input. Twitter is defining it's own ecosystem. RSS and ATOM are much more about output than input anyway - it's their primary focus. Andy
Received on Friday, 18 March 2011 14:13:28 UTC