Re: is this query in scope for sparql-exists

good morning;

the reason i asked:

the problem is in the interaction among the various binding forms which are necessary in order to properly interpret a sparql query.
there are three:
- lexical
- combinational
- dynamic

lexical cases are things like
    { graph ?g { ?g a ?class } }
or
    { ?x :property ?x }
or
   { ?x :property ?y . filter (?y != 0) }

combinational are things like
    { ?x :property1 ?y  . ?x :property2 ?z }
or
    { ?x :property1 ?y  . ?y :property2 ?z }

dynamic enters necessarily into the process with exists
    { ?x :property ?y . filter ( not exists { ?x :property2 ?z } ) }

for which the presence of “not exists” in larger predicate forms appears to preclude an implementation based on some interaction between lexical and combinational bindings with either join or diff operators.

in the case, below, it does not surprise that, at the point where the three binding modes interact for the outer exists, there may have been some omission, which the additional ?MDxReport_B corrects.

best regards, from berlin,

> On 2016-09-27, at 08:02, james anderson <james@dydra.com> wrote:
> 
> good morning;
> 
>> On 2016-09-27, at 07:39, Jeremy J Carroll <jjc@syapse.com <mailto:jjc@syapse.com>> wrote:
>> 
>> Questions:
>> with my example (1) below:
>> A) is this an example of the defect that this group is addressing
>> B) is my workaround (3) appropriate:
>>    In particular, I would like this to be as ‘standards conferment’/interoperable as possible, given a bug in the spec.
>> […]
>> 
>> 
>> I have had an issue with the scope of the ?MDxReport_B variable in the following double negation (for all, expressed, as NOT EXISTS NOT)
> 
> 1. is it possible to reduce the query from 
> 
>> 
>> SELECT *
>> WHERE {
>>   ?Therapy_A rdf:type foo:Therapy .
>>   ?MDxReport_B rdf:type foo:fooMolecularResultsReport .
>>   ?MDxReport_B foo:hasPatient ?Patient_A .
>> 
>>   ?Patient_A rdf:type foo:Patient .
>>   ?MDxReport_B foo:hasNegativeFinding/foo:gene $j__4 .
>>   ?Therapy_A foo:hasGeneEligibilityCriteria/foo:hasNegativeFinding/foo:gene  $j__4
>>   FILTER NOT EXISTS { 
>>     ?hasGeneEligibilityCriteria_A rdf:type foo:GeneEligibilityCriteria .
>>     ?Therapy_A foo:hasGeneEligibilityCriteria ?hasGeneEligibilityCriteria_A .
>>     ?hasGeneEligibilityCriteria_A foo:isRequiredCriteria True .
>>     ?hasGeneEligibilityCriteria_A foo:criteriaType 'Inclusion'
>>     FILTER NOT EXISTS { 
>>       ?MDxReport_B foo:hasNegativeFinding/foo:gene $j__5 .
>>       ?hasGeneEligibilityCriteria_A foo:hasNegativeFinding/foo:gene  $j__5
>>     }
>>   }
>>   }
>> 
> 
> to the following, which involves just the relations among the report, the therapy and the criteria?
> 
> SELECT *
> WHERE {
>   ?MDxReport_B foo:hasNegativeFinding/foo:gene $j__4 .
>   ?Therapy_A foo:hasGeneEligibilityCriteria/foo:hasNegativeFinding/foo:gene  $j__4
>   FILTER NOT EXISTS { 
>     ?Therapy_A foo:hasGeneEligibilityCriteria ?hasGeneEligibilityCriteria_A .
>     FILTER NOT EXISTS { 
>       ?MDxReport_B foo:hasNegativeFinding/foo:gene $j__5 .
>       ?hasGeneEligibilityCriteria_A foo:hasNegativeFinding/foo:gene  $j__5
>     }
>   }
>   }
> 
> 2. did you observe that any reference to ?MDxReport_B  - that is, not just a type constraint, sufficed to mitigate the issue?
> 
> best regards, from berlin,
> ---
> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/>
---
james anderson | james@dydra.com | http://dydra.com