- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Tue, 27 Sep 2016 05:13:41 -0700
- To: Jeremy J Carroll <jjc@syapse.com>, public-sparql-exists@w3.org
- Cc: Bryan Thompson <bryan@blazegraph.com>
It appears that the SPARQL implementation that you are using is somehow losing
the binding for ?MDxReport_B. As far as I can tell, this is a bug in the
implementation and not a problem with the SPARQL specification. Therefore
this is not in scope for the CG.
peter
On 09/26/2016 10:39 PM, Jeremy J Carroll 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.
>
> This query is matching cancer patients to potential experimental therapies
> matching their genetic profile.
>
> If A is answered in the affirmative, please feel free to use this query in any
> documentation you are developing.
>
> thanks
>
> Jeremy
> Senior Principal Architect, Syapse Inc.
>
>
> 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)
>
> 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
> }
> }
> }
>
>
> This is being executed as if it were:
>
>
> (2)
>
> 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 {
> ?A_different_MDxReport_B foo:hasNegativeFinding/foo:gene $j__5 .
> ?hasGeneEligibilityCriteria_A foo:hasNegativeFinding/foo:gene $j__5
> }
> }
> }
>
>
>
> where the variable in the doubly-nested EXISTS is not treated as the same variable as in the outer graph pattern
>
>
> It seems I can fix this by simply repeating the type triple:
>
>
> (3)
>
>
> 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 {
>
> ?MDxReport_B rdf:type foo:fooMolecularResultsReport .
>
> ?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
> }
> }
> }
>
>
> and then the SPARQL implementation I am using does seem to see that all
> instances of ?MDxReport_B
> are one and the same variable.
>
>
>
>
>
>
Received on Tuesday, 27 September 2016 12:14:13 UTC