- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 10 Mar 2016 21:27:31 -0800
- To: Holger Knublauch <holger@topquadrant.com>, "public-data-shapes-wg@w3.org" <public-data-shapes-wg@w3.org>
On 03/10/2016 08:37 PM, Holger Knublauch wrote: > On 11/03/2016 13:22, Peter F. Patel-Schneider wrote: >> On 03/10/2016 06:04 PM, Holger Knublauch wrote: >>> On 10/03/2016 1:17, Peter F. Patel-Schneider wrote: >>>> On 03/09/2016 12:46 AM, Holger Knublauch wrote: >>>>> On 9/03/2016 18:17, Peter F. Patel-Schneider wrote: >>>>>> I'm pretty sure that this fails in a number of places. [...] >>>>>> The substitution can modify variables from different scopes, which will >>>>>> change >>>>>> results. >>>>> Do you have an example for this? >>>> SELECT ?this ?that >>>> WHERE { ?this ex:a ex:b >>>> SELECT ?that WHERE { ?this ex:a ?that } } >>> The definition states that substitution also happens in nested SELECTs. I >>> believe this meets user expectations, and would be needed for cases like >>> sh:minCount that use a nested SELECT. I don't quite see a problem with the >>> above. Do you have data to illustrate why this would cause problems? >> Because the ?this in the inner SELECT is a different variable. Before >> substitution it would return any ?that that is the object of any ex:a triple. >> After substitution it returns only those that have the substituted value as a >> subject. > > Yes, but that is exactly the desired outcome. > > Holger I'm not a SPARQL expert, but I don't think so. Let's pre-bind ?this to ex:c (this is a very easy case of pre-binding, so what to do is pretty obvious) in SELECT ?this ?that WHERE { ?this ex:a ex:b . SELECT ?that WHERE { ?this ex:a ?that } } against graph ex:c ex:a ex:b . ex:c ex:a ex:b . ex:d ex:a ex:f . The result set is ?this = ex:c, ?that = ex:b ?this = ex:c, ?that = ex:f Let's substitute ?this by ex:c to get (roughly) SELECT (ex:c AS ?this) ?that WHERE { ex:c ex:a ex:b . SELECT ?that WHERE { ex:c ex:a ?that } } which results in only one solution ?this = ex:c, ?that = ex:b peter
Received on Friday, 11 March 2016 05:28:03 UTC