- 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