No. That portion of the specification permits a CONSTRUCT query to discard
inappropriate matches. In no way does it require implementations to do format
inference.
---
A. Soroka
james anderson wrote on 5/12/17 4:56 PM:
good evening;
On 2017-05-12, at 21: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 }
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_.
this argument does not convince : cf.
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#construct
best regards, from berlin,
---
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.
---
james anderson | ja...@dydra.com | http://dydra.com
