Re: JSON Results doc : First complete draft ready

Hi Nico,

On 17/05/11 08:45, Nico Michaelis wrote:
>> I would like at least one other reviewer to concur. The document is not
>> long, and will not take you long to review. Please help!
>
> I've had a look.
>
> I was a little surprised that the result of an ask query is not encoded
> like other literal booleans. So instead of the
> "boolean": "true"
> I would encode the result of an ask query like
> "result" : { "type": "literal", "value": "true", "datatype": "xsd:boolean"}
> . I guess that would be a good idea for consistency and existensibility.
> If you think that "result" is a bad name, because "results" is already
> in use, I would propose "answer" - but I think that calling the object
> "boolean" does not give an appropriate meaning.

If this were a new design, I'd agree that "answer" is a better choice.
As this is an already-deployed format, there is a cost to change.

As it's an already deployed format, there's a cost to such a change. 
Unless there is a consensus in the WG to make a breaking change (even an 
alternative name breaks with old code on new data), I propose to leave 
it as-is.

Oddly, this has not been raised, to my knowledge, about the XML results 
format.  Keeping those two similar is also desirable.

The value can only be true or false, I think using the JSON value 
directly is fine although I take your point about encoding it as an RDF 
term.

In SPARQL - the keyword true is short for "true"^^xsd:boolean.  If 
javascript numbers worked more normally, we could very usefully have 
used numbers as short forms for numeric RDF terms, potentially saving a 
lot of space in a number-rich results set.

> I also noticed a little typo - a superflous "," before the ending "}" in
> the description of literals with datatypes:
>
> { "type": "literal", "value": "S", "datatype": "D",}

Now fixed.

>
> I'm satisfied with the rest of the document.

Thanks for the review

> Nico

 Andy

Received on Tuesday, 17 May 2011 08:44:02 UTC