Warning:
This wiki has been archived and is now read-only.
User:Rcygania2/JSON-Triples
This is the text of an email I sent to the list; I'll keep it here for future reference. At this time, this is not a serious proposal or request for comments.
Contents
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 it would 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.
Shouldn't the SPARQL WG do this?
The SPARQL results in JSON format (which only covers SELECT and ASK) is clearly related and could perhaps even be used as a triple-based graph serialization just by spitting out the result of SELECT * WHERE { ?s ?p ?o }. But the SPARQL WG is not chartered to produce a JSON syntax for RDF, while the RDF WG is chartered to produce exactly that.
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.
Summary
This is the low-risk, low-reward option for fulfilling the “JSON syntax for RDF” charter item.