Details

    • Type: Bug
    • Status: Closed - Won't Fix
    • Resolution: Duplicate
    • Affects Version/s: BIGDATA_RELEASE_1_3_0
    • Fix Version/s: None
    • Component/s: Query Plan Generator
    • Labels:
      None

      Description

      Given the following data:

      @prefix  :     <http://sample.com/> .
      
      <http://graph.com/test> {
      :I :am   "a" .
      :I :live "a_live" .
      :I :work "a_work" .
      }
      
      <http://graph.com/test_1> {
      :I :am   "a" .
      :I :am   "b" .
      :I :work "a_work" .
      :I :work "b_work" .
      }
      
      

      Now when I write this query , Since <http://sample.com/I> <http://sample.com/live> "a_live" does not exist in test_1 graph , it should write the new triples. But it does not write anything to test_1 graph, presumably because the same triple exists in graph test.

      INSERT {
        GRAPH <http://graph.com/test_1> {
          <http://sample.com/I> <http://sample.com/test>  "a_test_value".
        }
      }
      WHERE {
        GRAPH  <http://graph.com/test_1> {
          FILTER NOT EXISTS { <http://sample.com/I> <http://sample.com/live>  "a_live". }
        }
      }
      

      When I try executing the same SPARQL request with a triple that DOES NOT EXIST in both graphs, then it updates test_1 graph.

      INSERT {
        GRAPH <http://graph.com/test_1> {
          <http://sample.com/I> <http://sample.com/test>  "a_test_value".
        }
      }
      WHERE {
        GRAPH  <http://graph.com/test_1> {
          FILTER NOT EXISTS {<http://sample.com/I> <http://sample.com/live>  "a_a_live".}
        }
      }
      

      On first glance, this ticket appears to be a problem where the graph variable is not being respected by the FILTER NOT EXISTS clause. Therefore, this ticket might be a duplicate of BLZG-874

      See BLZG-874 (GRAPH ?g { FILTER NOT EXISTS { ?s ?p ?o } } not respecting ?g)

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        This appears to be exactly the issue in BLZG-874. If I modify the query by pushing the GRAPH into the FILTER then the behavior is as expected by the person reporting the issue. This is the workaround suggested by BLZG-874.

        Running the following query reports ?g as "test_1" and ?s ?p and ?o as the statements in "test_1"

        SELECT * {
          GRAPH ?g { ?s ?p ?o. }
          FILTER NOT EXISTS{graph ?g {<http://sample.com/I> <http://sample.com/live>  "a_live".}}
        }
        
        Show
        bryanthompson bryanthompson added a comment - This appears to be exactly the issue in BLZG-874 . If I modify the query by pushing the GRAPH into the FILTER then the behavior is as expected by the person reporting the issue. This is the workaround suggested by BLZG-874 . Running the following query reports ?g as "test_1" and ?s ?p and ?o as the statements in "test_1" SELECT * { GRAPH ?g { ?s ?p ?o. } FILTER NOT EXISTS{graph ?g {<http://sample.com/I> <http://sample.com/live> "a_live".}} }
        Hide
        bryanthompson bryanthompson added a comment -

        Added unit test for this bug and a workaround for this bug.

        r8120

        Show
        bryanthompson bryanthompson added a comment - Added unit test for this bug and a workaround for this bug. r8120
        Hide
        jeremycarroll jeremycarroll added a comment -

        I wonder whether we can handle this problem as an 'optimizer' that sticks the missing GRAPH ?g inside the EXISTS.

        Show
        jeremycarroll jeremycarroll added a comment - I wonder whether we can handle this problem as an 'optimizer' that sticks the missing GRAPH ?g inside the EXISTS.
        Hide
        jeremycarroll jeremycarroll added a comment -

        At http://www.w3.org/TR/sparql11-query/#defn_evalExists
        we read: 'EXISTS returns true/false depending on [?] the active graph' which suggests that the expectation that the graph scope applies is in accordance with the specification

        Show
        jeremycarroll jeremycarroll added a comment - At http://www.w3.org/TR/sparql11-query/#defn_evalExists we read: 'EXISTS returns true/false depending on [?] the active graph' which suggests that the expectation that the graph scope applies is in accordance with the specification
        Hide
        jeremycarroll jeremycarroll added a comment -

        There are some cases that are significantly more difficult, e.g. when the graph is identified by a variable and there are no triples in the pattern:

        GRAPH ?g
        { FILTER EXISTS { ?s ?p ?o } }
        

        I think such a case should be outside the scope of this ticket.

        Show
        jeremycarroll jeremycarroll added a comment - There are some cases that are significantly more difficult, e.g. when the graph is identified by a variable and there are no triples in the pattern: GRAPH ?g { FILTER EXISTS { ?s ?p ?o } } I think such a case should be outside the scope of this ticket.
        Hide
        michaelschmidt michaelschmidt added a comment -

        Resolved in branch quads_issues. The problem was that the triple pattern inside the FILTER NOT EXISTS clause did not inherit the graph context, but was evaluated over the DEFAULT_CONTEXT. This was an issue while translating the Sesame parse tree into a bigdata AST.

        Executed CI, looks good. Issuing pull request.

        This issue is a duplicate of BLZG-874.

        Show
        michaelschmidt michaelschmidt added a comment - Resolved in branch quads_issues. The problem was that the triple pattern inside the FILTER NOT EXISTS clause did not inherit the graph context, but was evaluated over the DEFAULT_CONTEXT. This was an issue while translating the Sesame parse tree into a bigdata AST. Executed CI, looks good. Issuing pull request. This issue is a duplicate of BLZG-874 .

          People

          • Assignee:
            michaelschmidt michaelschmidt
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: