Github user afs commented on the issue:
https://github.com/apache/jena/pull/114
I applied 114.patch locally and it integrated just fine.
I tried `JSON { "s": ?s , "p": ?p , "o" : ?o } WHERE { ?s ?p ?o }` on data
```
:s :p 123 .
:s :p "abc" .
:s :p "def"@en .
```
and got:
```
[ { "o" : "123^^http://www.w3.org/2001/XMLSchema#integer"; } ,
{ "o" : "abc" } ,
{ "o" : "def@en" }
]
```
I think we should use a more aggressive version of the conversion from RDF
term to JS used in the upcoming [JS custom
Functions](http://jena.staging.apache.org/documentation/query/javascript-functions.html#arguments-and-function-results),
code
https://github.com/apache/jena/blob/master/jena-arq/src/main/java/org/apache/jena/sparql/function/js/NV.java.
That works on `NodeValue`s to make functions more natural to write and is
two-way.
For JSON-SELECT we only need a one way conversion and getting info out even
if it is some string is better IMO.
| RDF | Javascript |
| ---- | ---- |
| String | String |
| XSD numeric | JSON number |
| XSD boolean | boolean |
| String@lang | String, no lang |
| URI | String |
| "lex"^^SomeDatatype | String, no datatype |
| Unbound | JSON null |
If the app wants RDF term details, it can use
`application/result-set+json`. This feature provides provides a simpler, more
JSONy view of the data for consuming RDF-unaware applications.
---
