- From: Daniel Hernandez <daniel@degu.cl>
- Date: Wed, 13 Jul 2016 02:11:18 -0300
- To: "" <public-sparql-exists@w3.org>
Peter, you are right. Thanks you for your feedback!
I think that these problems does not affect the main ideas presented
in the technical report, but need to be solved.
> I took a quick look at this version and found a problem.
>
> Consider query Q
>
> SELECT ?x WHERE { ?x :p :b . FILTER ( 1=0 ) }
>
> There can never be any solutions returned for this query, so dom(Q) = {}, but
> Lemma 1 says that dom(Q) = { ?x }.
You are right. I have not considered the case where the result of a graph pattern
is empty for every result. I will work on fixing the definitions for this case.
> Consider also
>
> SELECT ?x WHERE { }
>
>
> The discussion of in-scope in 18.2.1 of the spec has similar problems.
I'm surprised about how many details are involved with the definition of dom(P).
> You are also missing SELECT *
We intentionally exclude several SPARQL features because I guess that
they may introduce another problems with our definition.
I used to think that the query
SELECT * WHERE {P}
is equivalent with
SELECT X WHERE {P},
where X is the list of variables that are in dom(P).
I noticed that not all implementations interpret this in the same way.
Indeed, the output table produced by the implementations that we
studied has columns for variables ?x, ?y and ?z, except in rdf4j where a
column for ?v is included.
Daniel
Received on Wednesday, 13 July 2016 05:11:46 UTC