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

Semantics of Sesame’s Operation.setBinding() and Operation.getBindings()

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: BLAZEGRAPH_RELEASE_1_5_2
    • Component/s: None
    • Labels:
      None

      Description

      The semantics we’re currently implementing from Sesame’s Operation.get/setBinding()s API differs in some edge case, see the discussion at

      1. https://groups.google.com/forum/#!topic/sesame-devel/Di_ZLtTVuZA

      In particular, the differences are as follows:

      1. Bindings are not injected into subqueries, but should
      2. Sesame foresee’s an override semantics though BIND nodes for injected nodes
      3. There might be issues related to bottom up vs. top down semantics

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        @michaelschmidt - can this be closed? Did you get any resolution from the openrdf group?

        Show
        bryanthompson bryanthompson added a comment - @michaelschmidt - can this be closed? Did you get any resolution from the openrdf group?
        Hide
        michaelschmidt michaelschmidt added a comment -

        @bryanthompson what's described above is the conclusion from the Sesame discussion. However, I consider this low prio and would only tackle it if someone relies on this feature (might be quite hard to implement with only little benefit).

        Show
        michaelschmidt michaelschmidt added a comment - @bryanthompson what's described above is the conclusion from the Sesame discussion. However, I consider this low prio and would only tackle it if someone relies on this feature (might be quite hard to implement with only little benefit).
        Hide
        bryanthompson bryanthompson added a comment - - edited

        We have agreed that our implementation semantics for setBinding() are a feature and not a bug. Specifically, setBinding() only effects variables that are in scope in the top-level query. In order to effect a variable in a sub-query, the variable must be projected into the subquery. If a FILTER uses a variable that is not otherwise used in the query, then a BIND() must be used to introduce the variable into the query such that it will become visible to the FILTER.

        Assigned to @michaelschmidt to document this on the wiki and in the javadoc for set binding and close out this ticket (probably as WONT_FIX).

        Show
        bryanthompson bryanthompson added a comment - - edited We have agreed that our implementation semantics for setBinding() are a feature and not a bug. Specifically, setBinding() only effects variables that are in scope in the top-level query. In order to effect a variable in a sub-query, the variable must be projected into the subquery. If a FILTER uses a variable that is not otherwise used in the query, then a BIND() must be used to introduce the variable into the query such that it will become visible to the FILTER. Assigned to @michaelschmidt to document this on the wiki and in the javadoc for set binding and close out this ticket (probably as WONT_FIX).
        Hide
        michaelschmidt michaelschmidt added a comment -

        Just checked the code, the above statement is not 100% correct. What we implemented is the following:

        setBinding() only effects variables that are used in the top-level query. This includes FILTERs used in the top-level query, even if they are placed in (possibly nested) subgroups. So there are essentially two "changes" compared to Sesame's intended semantics (which is discussed in https://groups.google.com/forum/#!topic/sesame-devel/Di_ZLtTVuZA):

        • When passing in a binding for a variable ?x, the binding is not visible to a subquery unless the subquery contains a projection variable labelled ?x
        • Sesame foresees an override semantics though BIND nodes for injected bindings, i.e. when injecting a value X for variable ?x and re-binding ?x as Y using e.g. BIND(Y AS ?x) in the query, then the value of ?x that is passed in via the API will be overriden in scopes to which the BIND applies. In Blazegraph, we consider this a conflicting situation and, as a consequence, will not return results for the parts of the query to which the BIND applies to.
        Show
        michaelschmidt michaelschmidt added a comment - Just checked the code, the above statement is not 100% correct. What we implemented is the following: setBinding() only effects variables that are used in the top-level query. This includes FILTERs used in the top-level query, even if they are placed in (possibly nested) subgroups. So there are essentially two "changes" compared to Sesame's intended semantics (which is discussed in https://groups.google.com/forum/#!topic/sesame-devel/Di_ZLtTVuZA): When passing in a binding for a variable ?x, the binding is not visible to a subquery unless the subquery contains a projection variable labelled ?x Sesame foresees an override semantics though BIND nodes for injected bindings, i.e. when injecting a value X for variable ?x and re-binding ?x as Y using e.g. BIND(Y AS ?x) in the query, then the value of ?x that is passed in via the API will be overriden in scopes to which the BIND applies. In Blazegraph, we consider this a conflicting situation and, as a consequence, will not return results for the parts of the query to which the BIND applies to.
        Hide
        michaelschmidt michaelschmidt added a comment -

        Documented in Wiki, documentation in code is present already, see https://wiki.blazegraph.com/wiki/index.php/SesameAPICompliance.

        Closing issue.

        Show
        michaelschmidt michaelschmidt added a comment - Documented in Wiki, documentation in code is present already, see https://wiki.blazegraph.com/wiki/index.php/SesameAPICompliance . Closing issue.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: