Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-827

Inconsistent treatment of bind and optional property path

    Details

      Description

      The following 2 queries should return equivalent data, but the 2nd version does not return data on identical database contents. The only difference is that the 2nd version uses a BIND to a variable, while the 1st version directly substitutes the IRI into the query. Of note is that the query involves an optional property path "syapse:part?".

      It might relate to trac734. I have a workaround by performing direct substitution, but this still would be nice to fix.

      Jeremy Carroll has said he will work on this. Actually found in BIGDATA_RELEASE_1_3_0, at r7390.

      This query works:
      --
      BASE <http://localhost:8000/>
      PREFIX base: </bdm/api/kbobject/base:>
      PREFIX based: </bdm/api/appindividual/based:>
      PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
      PREFIX syapse: </graph/syapse#>
      SELECT *
      FROM </graph/stoogesInc/abox>
      FROM </graph/ontology/base>
      WHERE {
      ?referrer syapse:part? ?part .
      ?part ?predicate based:Protocol_113 .
      }
      LIMIT 1000

      This query doesn't work (returns no results):
      --
      BASE <http://localhost:8000/>
      PREFIX base: </bdm/api/kbobject/base:>
      PREFIX based: </bdm/api/appindividual/based:>
      PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
      PREFIX syapse: </graph/syapse#>
      SELECT *
      FROM </graph/stoogesInc/abox>
      FROM </graph/ontology/base>
      WHERE {
      BIND(based:Protocol_113 as ?s)
      ?referrer syapse:part? ?part .
      ?part ?predicate ?s .
      }
      LIMIT 1000

        Activity

        Hide
        jeremycarroll jeremycarroll added a comment -

        Test cases added in r7437 bigdata-rdf/src/test/com/bigdata/rdf/sparql/ast/eval/TestTickets.java.
        The curcial failing test is disabled by having been renamed as xtest_ticket_739b

        Show
        jeremycarroll jeremycarroll added a comment - Test cases added in r7437 bigdata-rdf/src/test/com/bigdata/rdf/sparql/ast/eval/TestTickets.java. The curcial failing test is disabled by having been renamed as xtest_ticket_739b
        Hide
        jeremycarroll jeremycarroll added a comment -

        The current actual execution path exercises a ZLPP defect.

        The root ZLPP defect is, in my opinion, in the spec.

        eval(Path(X:var, ZeroOrOnePath(P), Y:var)) = 
            { (X, xn) (Y, yn) | either (yn in nodes(G) and xn = yn) or {(X,xn), (Y,yn)} in eval(Path(X,P,Y)) }
        

        is not realistically implementable, and so, what a surprise, we don't implement it.

        I note there is some zombie code concerning zlpp's with comments about getting cardinalities wrong.

        Maybe a missing optimization is:

        ?x p-expr * ?y
        
        =>
        
        zlpp(?x, ?y ) union { ?x p-expr + ?y FILTER (?x != ?y) }
        

        where the filter is needed to ensure cardinalities are correct;
        and similarly for zero or one.

        I will review to see if I can get the optimizer to execute the BIND before the zero or one path in order to side step things.

        Show
        jeremycarroll jeremycarroll added a comment - The current actual execution path exercises a ZLPP defect. The root ZLPP defect is, in my opinion, in the spec. eval(Path(X:var, ZeroOrOnePath(P), Y:var)) = { (X, xn) (Y, yn) | either (yn in nodes(G) and xn = yn) or {(X,xn), (Y,yn)} in eval(Path(X,P,Y)) } is not realistically implementable, and so, what a surprise, we don't implement it. I note there is some zombie code concerning zlpp's with comments about getting cardinalities wrong. Maybe a missing optimization is: ?x p-expr * ?y => zlpp(?x, ?y ) union { ?x p-expr + ?y FILTER (?x != ?y) } where the filter is needed to ensure cardinalities are correct; and similarly for zero or one. I will review to see if I can get the optimizer to execute the BIND before the zero or one path in order to side step things.
        Hide
        jeremycarroll jeremycarroll added a comment -

        Corrected estimates in
        r7442

        which fixes the bug, without attempting to correctly implement the unimplementable zlpp specification

        Show
        jeremycarroll jeremycarroll added a comment - Corrected estimates in r7442 which fixes the bug, without attempting to correctly implement the unimplementable zlpp specification

          People

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

            Dates

            • Created:
              Updated:
              Resolved: