Re: ISSUE-68: Updated definition

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

Yes, but the same things can be achieved.

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


Received on Friday, 11 March 2016 04:38:24 UTC