On 12/05/17 20:55, aj...@apache.org wrote:
Suppose your dataset contains:
:me :hasEmail "aj...@apache.org" .
:you :hasEmail "laure...@gmail.com" .
The query:
SELECT ?s ?p ?o WHERE {?o :hasName :s }
Nor is SELECT DISTINCT ?s { ... }
And then there are OPTIONALs. Result set are not necessarily regular.
One could encode a result set into RDF, then decode it back again in the
client.
But
1/ That's slow.
2/ The client needs an RDF parser at least, maybe a whole RDF toolkit.
Now a simple parser is N-triples ... which is huge.
But it likely already has an XML parser and/or a JSON parser (not JSON-LD).
Jena has code to produce a graph for a result set and it was discussed
for SPARQL 1.0 but it did not get traction.
Andy
is completely valid and will return perfectly fine results in a
non-triple format, like SPARQL XML. Those results are not triples. In
order to _know_ that they are not triples and that only certain result
formats may therefore be used, the SPARQL impl would have to inspect
every result row, _before beginning to return even the first_.
---
A. Soroka
Laura Morales wrote on 5/12/17 3:50 PM:
For that to happen, the implementation in question would have to be
able to infer that the SELECT statement in question was sure to
produce _only_ legitimate
triples. In other words, not only that the form was a simple 3-tuple,
but that neither the first nor second positions would ever contain
literals and that the
second position would never contain bnodes. That's not impossible,
but it would be extremely difficult.
Remember, an RDF triple is _not_ just a 3-tuple. It is specifically a
tuple of IRI-or-bnode, IRI, IRI-or-bnode-or-literal. [1]
I also don't understand why this would be necessary. Mainly because,
as far as I can see, triples are already validated before inserting
them into the dataset (for example when using tdbloader). Are all
triples checked for correctness before outputting any of
XML/JSON/CSV/TSV? If they do, it would seem very strange to me.
