[
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16395357#comment-16395357
]
Andy Seaborne edited comment on JENA-632 at 3/12/18 9:50 PM:
-------------------------------------------------------------
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.
was (Author: githubbot):
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.
> Generate JSON from SPARQL directly.
> -----------------------------------
>
> Key: JENA-632
> URL: https://issues.apache.org/jira/browse/JENA-632
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Fuseki
> Reporter: Andy Seaborne
> Assignee: Bruno P. Kinoshita
> Priority: Minor
> Labels: java, javacc
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The capability to generate JSON directly from a SPARQL (or extended SPARQL)
> query would enable the creation of JSON data API over published linked data.
> This project would cover:
> # Design and publication of a design.
> # Refinement of design based on community feed
> # Implementation, including testing.
> # Refinement of implementation based on community feed
> Skills required: Java, some parser work, design and discussion with the user
> community, basic understanding of HTTP and content negotiation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
