[JSON] The case for a triple-based approach

Manu argued forcefully against doing the a triple-based JSON format. I'd like to balance this a bit. A decent case for the triple-based approach can be made as well:


WHAT IS IT

A simple format for serializing RDF triples in JSON. Starting points could be just an array of s-p-o objects, or Talis' RDF/JSON proposal. It would probably be quite verbose, but when looking at the JSON it's easy to see the triples. There wouldn't be many ways of serializing the same RDF graph into different JSON structures (besides ordering, whitespace etc).


HOW WOULD IT BE USED

The main motivation would be as a result format for CONSTRUCT and DESCRIBE queries against SPARQL stores. So, server-side implementors would be SPARQL store vendors.

It would be convenient for JS application developers who want to use the data in the store. They would probably use the format without an API or parser library. They have to be somewhat familiar with RDF and triples, otherwise the format won't make much sense to them because some of the RDF's structure is not explicit in the JSON structure.


WHAT THIS PROPOSAL IS NOT

This is not a game-changer. It won't get masses of new developers in touch with RDF. It's simply a convenience for people who are already developing JS-based applications over triplestores.


WHY WE SHOULD DO IT ANYWAYS

Almost all SPARQL stores already support JSON as a result format for SELECT, and this is useful and popular among SPARQL users. A number of stores also support JSON as a result format for CONSTRUCT and DESCRIBE, but there are multiple incompatible formats for this. So a good case can be made that standardization is necessary to solve a current interoperability problem.

Given that there's already prior art and proposals with major deployment, doing this would probably be easy.


WHY WE MAYBE SHOULDN'T DO IT

The main argument that would be brought forward against this proposal is, I think this:

It might pre-empt another higher-impact JSON-based format for RDF. Manu and the JSON-LD approach is aiming much higher, at masses of new developers who aren't using RDF at the moment. That's something that the triple-based approach clearly is not designed to achieve, simply because it addresses a use case that relatively few developers have (but nevertheless it's a concrete and real use case, relevant today).

Some have already argued that the WG shouldn't try to do two different formats, and I might add that the existence of two different JSON-based formats will confuse people to no end. And the triple-based format is much easier to do than something like JSON-LD, and would tick the [JSON] box on the charter checklist. There's a danger that the WG chooses the “easy way out” of doing just this triple-based approach and then kills the higher-potential-impact approach because it's no longer needed to fulfill the charter.



I honestly don't know what the WG should ultimately do, but I think it boils down to a choice between two possible formats. A boring and low-impact triple-based format that appeals to RDF developers. And a much harder, riskier, and much more controversial, but potentially also more successful, “JSON-plus-something-to-get-them-hooked-on-RDF” format with broad appeal. The third option would be to do both.

Best,
Richard

Received on Thursday, 10 March 2011 15:03:06 UTC