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.



---

Reply via email to