Details

      Description

      SELECT *
      {
      OPTIONAL {
      OPTIONAL {
      BIND (3 as ?x)
      }
      BIND (4 as ?x)
      }
      }

      should evaluate as 3, but currently evaluates as 4

        Activity

        Hide
        jeremycarroll jeremycarroll added a comment -

        The file ASTJoinOrderByTypeOptimizer.java concedes:

             *   TODO: the placement of OPTIONALS should really be more complicated than this.
             *   e.g. consider interaction with SERVICE calls etc.
             *   Optional joins:
             *   10. Simple optionals & optional subgroups
        
        Show
        jeremycarroll jeremycarroll added a comment - The file ASTJoinOrderByTypeOptimizer.java concedes: * TODO: the placement of OPTIONALS should really be more complicated than this. * e.g. consider interaction with SERVICE calls etc. * Optional joins: * 10. Simple optionals & optional subgroups
        Hide
        jeremycarroll jeremycarroll added a comment -
        SELECT * 
        {
        OPTIONAL {
        OPTIONAL {
        BIND (3 as ?x)
        }
          BIND (5 as ?z)
         <eg:a> <eg:a> ?x .
          hint:Prior hint:runLast true .
        }
        }
        

        is close to a work-around for the first case

        Show
        jeremycarroll jeremycarroll added a comment - SELECT * { OPTIONAL { OPTIONAL { BIND (3 as ?x) } BIND (5 as ?z) <eg:a> <eg:a> ?x . hint:Prior hint:runLast true . } } is close to a work-around for the first case
        Hide
        jeremycarroll jeremycarroll added a comment -
        SELECT * 
        {
        OPTIONAL {
        OPTIONAL {
        BIND (3 as ?x)
        }
          BIND (4 as ?x).
          hint:Group hint:optimizer "None" .
        }
        }
        

        is a work around to the original problem

        Show
        jeremycarroll jeremycarroll added a comment - SELECT * { OPTIONAL { OPTIONAL { BIND (3 as ?x) } BIND (4 as ?x). hint:Group hint:optimizer "None" . } } is a work around to the original problem
        Hide
        bryanthompson bryanthompson added a comment -

        Jeremy,

        This looks like an issue with the static optimizer freely reordering the OPTIONALs. I believe that you have looked at this code in some depth before. Can you please take a look at suggest a patch for Mike to review?

        Thanks,
        Bryan

        Show
        bryanthompson bryanthompson added a comment - Jeremy, This looks like an issue with the static optimizer freely reordering the OPTIONALs. I believe that you have looked at this code in some depth before. Can you please take a look at suggest a patch for Mike to review? Thanks, Bryan
        Hide
        michaelschmidt michaelschmidt added a comment -

        Actually, there were two orthogonal problems discussed in the ticket:

        1. Comments 3 to 8 are discussion a problem related to the ASTComplexOptionalOptimizer, which is disabled meanwhile. These queries work fine now, giving the correct multiplicities and results. Added a test case, see ticket BLZG-882 for more details.

        2. The original query mentioned in the desciption. Imho, the result for this query is correct, { ?x -> 4}, see the argumentation below:

        First of note that (I believe that) this query is invalid according to the SPARQL standard: http://www.w3.org/TR/sparql11-query/, 18.2.1 says that "In BIND (expr AS v) requires that the variable v is not in-scope from the preceeding elements in the group graph pattern in which it is used.". However, there's no problem evaluating it according to the W3C semantics, which applies here as well.

        To see why I believe that { ?x -> 4 } is is correct, look at the following as a replacement for the second version:

        # DATA:
        <http://s> <http:/is3> "3" .
        <http://s> <http:/is4> "4" .
        
        # QUERY:
        SELECT * WHERE
        {
          <http://s> <http:/is4> ?x .
          OPTIONAL {
            <http://s> <http:/is3> ?x .
          }
        }
        

        The result, "4", is pretty obvious (that's what blazegraph returns here). The result actually does not change when adding another OPTIONAL around:

        SELECT * WHERE
        {
          OPTIONAL {
            <http://s> <http:/is4> ?x .
            OPTIONAL {
              <http://s> <http:/is3> ?x .
            }
          }
        }
        

        The additional OPTIONAL constitutes just a join of the empty (universal) solution set with the solution of the previous query, thus exactly the solution of the previous query.

        Bridging to the example provided in the bug: I don?t see why BIND should be treated differently here than binding triple patterns. Imho, the syntactic restriction imposed by the W3C standard is unnecessarily strict (though there are cases where such restrictions are needed, consider for instance the pattern ?BIND(?x AS ?y) BIND(?y AS ?x)? with mutual (unresolvable) dependencies.

        Note that there are also no "bottom-up" issues here, both queries are perfectly well designed, so we can safely evaluate top-down or bottom-up, as we like.

        Test cases from this ticket have been added, see pull request in branch ticket_933.

        Show
        michaelschmidt michaelschmidt added a comment - Actually, there were two orthogonal problems discussed in the ticket: 1. Comments 3 to 8 are discussion a problem related to the ASTComplexOptionalOptimizer, which is disabled meanwhile. These queries work fine now, giving the correct multiplicities and results. Added a test case, see ticket BLZG-882 for more details. 2. The original query mentioned in the desciption. Imho, the result for this query is correct, { ?x -> 4}, see the argumentation below: First of note that (I believe that) this query is invalid according to the SPARQL standard: http://www.w3.org/TR/sparql11-query/ , 18.2.1 says that "In BIND (expr AS v) requires that the variable v is not in-scope from the preceeding elements in the group graph pattern in which it is used.". However, there's no problem evaluating it according to the W3C semantics, which applies here as well. To see why I believe that { ?x -> 4 } is is correct, look at the following as a replacement for the second version: # DATA: <http://s> <http:/is3> "3" . <http://s> <http:/is4> "4" . # QUERY: SELECT * WHERE { <http://s> <http:/is4> ?x . OPTIONAL { <http://s> <http:/is3> ?x . } } The result, "4", is pretty obvious (that's what blazegraph returns here). The result actually does not change when adding another OPTIONAL around: SELECT * WHERE { OPTIONAL { <http://s> <http:/is4> ?x . OPTIONAL { <http://s> <http:/is3> ?x . } } } The additional OPTIONAL constitutes just a join of the empty (universal) solution set with the solution of the previous query, thus exactly the solution of the previous query. Bridging to the example provided in the bug: I don?t see why BIND should be treated differently here than binding triple patterns. Imho, the syntactic restriction imposed by the W3C standard is unnecessarily strict (though there are cases where such restrictions are needed, consider for instance the pattern ?BIND(?x AS ?y) BIND(?y AS ?x)? with mutual (unresolvable) dependencies. Note that there are also no "bottom-up" issues here, both queries are perfectly well designed, so we can safely evaluate top-down or bottom-up, as we like. Test cases from this ticket have been added, see pull request in branch ticket_933.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: