Re: [JSON] Survey for design requirements

On 10 Mar 2011, at 14:59, Thomas Steiner wrote:
>> There seems to be a use case in there for returning plain vanilla JSON from a Linked Data website (because developers love plain vanilla JSON!). It doesn't motivate why Joe wants JSON+RDF or how it solves any of his problems.
> 
> Think the other way round. Think from the publisher's side.

Ok, then let's turn it around and write the use case from the publisher's side :-)

“Pablo is developing a new web service. He has recently started to explore RDF, and would like to build the new service with an RDF store as the backend. However, all his other services have JSON APIs. He is concerned about alienating his customers by offering only RDF and SPARQL interfaces. He would like a solution that allows him to expose a JSON-based API on top of the RDF store. It should be similar to his other APIs and feel familiar to his users. On the other hand, he also wants to expose the full RDF data model to allow those with the right tooling to make maximum use of his data.”

I added this to the JSON-TF page. It overlaps with some existing use cases. We can consolidate if needed.

So I *think* I now understand your intent.

Best,
Richard



> The thing
> IMHO is not necessarily that Joe's life gets easier, it simply doesn't
> get any more complicated if he retrieves JSON+RDF. The publisher can
> return the data closer ("triple-equivalent") to its original "correct"
> representation, maintaining the whole semantics.
> 
> If you take vanilla JSON today, there is no easy way back to the
> originating triples. With JSON+RDF there would be, while still not
> making Joe's life  any more complex. It's more about the "purity" of
> the data representation...
> 
> I might have caused more confusion than before now... Still I think my
> point makes sense.
> 
> Cheers,
> Tom
> 
> -- 
> Thomas Steiner, Research Scientist, Google Inc.
> http://blog.tomayac.com, http://twitter.com/tomayac

Received on Thursday, 10 March 2011 23:06:24 UTC