CommentResponse:MH-2

In response to 2011Jan/0013

Michael,

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 [1] 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

[1] http://www.w3.org/2009/sparql/docs/json-results/json-results.xml

All,

I've been asked by Axel to give LC comments on 'Serializing SPARQL Query
Results in JSON' [1] - here we go:

===
+ My overall impression is that there is a tacit assumption that one is
familiar with 'SPARQL Query Results XML Format' [2] in order to understand
and use [1]. 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.