From SPARQL Working Group
In response to 2011Jan/0013
In response to the comments from yourself and Richard, the JSON results document has undergone major changes. It is now called 'SPARQL 1.1 Query Results JSON Format' to align with the other documents this working group is producing.
The editors working draft  addresses your comments. In particular, the description is now in terms of just the JSON format, not by analogy with the XML format. The design of the format has not changed. Please feel free to comment on the new document.
The working group intends to apply for the content type registration. A stable definition of the content type is needed; that is what that section contains.
We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.
Andy, on behalf of the SPARQL-WG
All, I've been asked by Axel to give LC comments on 'Serializing SPARQL Query Results in JSON'  - here we go: === + My overall impression is that there is a tacit assumption that one is familiar with 'SPARQL Query Results XML Format'  in order to understand and use . If so, please state it explicitly and loudly in the beginning. + The document starts with an example (right after the sentence 'SPARQL variable binding and boolean query results may be serialized in JSON') that is not only highly repetitive in itself but also inconsistent with the other examples throughout the document. It's a short document, so can you have *one* example throughout? + The section '3.1 Variable Binding Results' has issues, IMHO: 'Blank Node label I' needs more explanation; as it stands it's not self-contained. Also the para after 'No binding' would benefit from a bit more attention to detail (incl. Examples). + Appendix A, the document registers a media type: [[ The Internet Media Type / MIME Type for the SPARQL Query Results JSON Format is "application/sparql-results+json". ]] Is this reality? I know that some (incl. OpenLink, etc.) do send this, but how far spread is this? + Appendix B - References: I don't understand why JSON is not normative ATM. I hence suggest to only use http://tools.ietf.org/html/rfc4627 for JSON and make it normative (if you need to, then use http://json.org/ as informative reference, additionally). === Overall, hope these comments help and looking forward to see this document going REC Track soon.