> 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. AndyReceived on Friday, 18 March 2011 14:13:28 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:40 GMT