- From: Andy Seaborne <andy@apache.org>
- Date: Thu, 14 Jul 2016 14:19:53 +0100
- To: public-sparql-exists@w3.org
For issue 3, what the spec says and what users expect are different. Query: --------------------- PREFIX : <http://example/> SELECT * { ?s ?p ?o FILTER EXISTS { ?s :p 1 } } --------------------- Data: --------------------- PREFIX : <http://example/> _:s1 :p 1 . _:s2 :p 2 . --------------------- Outcome 1: ----------------- | s | p | o | ================= | _:s1 | :p | 1 | ----------------- I think this is expectation - the ?s in the EXISTS becomes the blank node and the EXIST test is about triples with the blank node from the BGP. Compare this to when the data is: --------------------- PREFIX : <http://example/> :s1 :p 1 . :s2 :p 2 . --------------------- giving: ---------------- | s | p | o | ================ | :s1 | :p | 1 | ---------------- The intuition is that data blank nodes and IRIs should behave the same. But in the spec blank nodes behave like variables, not constants. Spec gives: ----------------- | s | p | o | ================= | _:s1 | :p | 1 | | _:s2 | :p | 2 | ----------------- because it is like: PREFIX : <http://example/> SELECT * { ?s ?p ?o FILTER EXISTS { ?VAR :p 1 } } and { ?VAR :p 1 } matches for any ?s ?p ?o. The bnode _:s1 or _s2 substitute into the EXISTS giving { [] :p 1 } for each row. I'm not sure of the way to address this. Peter - can an entailment regime impose a condition that blank nodes in the data only map to the same blank node? Another approach is to somehow add a restriction on the "variableness" c.f. if it were a true variable: SELECT * { ?s ?p ?o FILTER EXISTS { ?VAR :p 1 . FILTER(sameTerm(?VAR, ?s) } } Any other ideas? Andy
Received on Thursday, 14 July 2016 13:20:34 UTC