[
https://issues.apache.org/jira/browse/JENA-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14272869#comment-14272869
]
Andy Seaborne commented on JENA-632:
------------------------------------
h4. Q1
The grammar looks OK (visual inspection of the JavaCC ... not by reading the
machine
generated version :-)).
{{QueryExectuion}} can have a new {{execJson}} (better name?) to make this
class of query a new, top level type. {{SPARQL_Query#executeQuery}} then
have
{noformat}
if ( query.isJsonType() ) {
JSONArray results = qExec.execJSON
log.info(format("[%d] exec/json",action.id)) ;
return new SPARQLResult(results) ;
}
{noformat}
To break up the work into tasks, maybe start with execution in ARQ, and
move onto Fuseki. The Fuseki part has some additional stuff around content
types, nothing mysteryious, just more machinary.
h4. Q2
The content negotation is presumably {{application/json}} - see Q3 as
well. As the results are also triggered by the query type (here, JSON, not
SELECT or a model), we don't get into a circularity of content negotation
and query execution interaction.
h4. Q3
Not sure I quite understand the question. We can be quite liberal on
conneg if you want, include any common, but wrong, MIME types that people
use. If asked for {{text/plain}}, or {{&format=text}, we can either return
text/plain (conventient when working in a browser to force {{text/plain}},
or return {{application/json}} (maybe better for environments where it is
tricky to set the outgoing "Accept" header). Fine tuning.
h4. Q4
Yes - there are 4 choices for what to substitute for {{?abcde}}, maybe
more:
# A Json value as you suggest. This is my preference.
# RDF terms written {{application/sparql-results+json}} style.
# RDF terms written JSON-LD style.
# RDF terms written RDF/JSON style.
I think the utility of the JSON query feature is use the data in JSON
/javascript programs. Choices 2,3,4 are about keeping the RDF term
details, where as 1 is lossey. But if the app wants the details, there are
other good formats to use, such as {{application/sparql-results+json}}.
Therefore, idiomatic JSON is the choice I favour.
That's your second
example.
So how to map each kind of term encountered:
_URI_ => JSON string.
_Blank Node_ => JSON String "_:label". The only real use of blank nodes is
to see when they are the same as else where in the results. Nice if the
label is "b0", "b1" etc.
_Literal_ : most complicated.
# An XSD number should become a JSON number
# An XSD boolean should become a JSON boolean.
# Anything else, take the lexical form.
I can't see anything sensible to handle language tags.
_undefined_ => Either JSON {{null}} or omit the field. {{null}} is is more
JSON idiomatic maybe?
h4. Other
We even have our own JSON subsystem, {{org.apache.jena.atlas.json}}, which
post-dates {{JSONOuput}}.
Key features include streaming input (({{JSONParser}}/{{JSONHandler}}) and
output ({{JSWriter}}), and to some extent predates some of the commonly
used libraries. No JSON-Java object-model. It's just
the JSON language so pared down for speed.
I can well imagine that query type JSON will be used for large extractions
from a dataset. Streaming matters.
> 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
> Priority: Minor
> Labels: java, javacc
>
> 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
(v6.3.4#6332)
