Re: ISSUE-68: Updated definition

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.
>>>>
>>>> It can break the shared variable connection for MINUS.   (I think that FILTER
>>>> is OK, but I'm not sure.)
>>> Do you have an example for this?
>> SELECT ?this
>> WHERE { ?this ex:a ex:b MINUS { ?this ex:a ex:b } }
> 
> Ok, this requires further thought. Thanks for bringing this up. In the worst
> case, we exclude the MINUS keyword - it is rarely used and work-arounds
> (FILTER) exists. Queries that use MINUS would be reported as error. There are
> precedents for this, e.g. we also don't support CONSTRUCT queries. Would this
> be an OK minimal solution for now? We could revisit this if there is spare
> time at the end of the WG.

MINUS and filter work differently.

>>>> 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.


peter

Received on Friday, 11 March 2016 03:22:52 UTC