sparql-view-unfold
    Preparing search index...

    Function nullifyJoinOverIncompatibleBounds

    • Optimization transformation that detects and eliminates incompatible join branches.

      After query rewriting, a JOIN may contain UNION branches where different alternatives bind variables to incompatible values. This transformation:

      1. Analyzes variable bindings across JOIN operands
      2. Computes the intersection of possible values for each variable
      3. Replaces EXTEND operations with incompatible values with FILTER(FALSE)

      It reads each join operand's top-level EXTEND chain and its recursion halts at a PROJECT, so a bind still inside a sub-SELECT is invisible to it. That is why the default pipeline runs it after removeProjections and pullUpExtends, and why it is inert anywhere earlier.

      Type Parameters

      • T extends Operation

      Parameters

      Returns T

      The transformed operation with incompatible branches eliminated

      // Given query: SELECT * { ?s ?p ?o . <ex://a> ?p ?o }
      // With mappings: CONSTRUCT WHERE { <ex://a> <ex://a> ?o }
      //                CONSTRUCT WHERE { <ex://b> <ex://b> ?o }
      //
      // The first pattern creates a UNION binding ?s to <ex://a> or <ex://b>
      // The second pattern requires subject <ex://a>, constraining ?p
      // Since ?p from the <ex://b> mapping (value <ex://b>) doesn't match
      // the ?p from the second pattern (which works with <ex://a>),
      // the <ex://b> branch is eliminated.

      // With 3 mappings where the third has subject <ex://b>:
      // CONSTRUCT WHERE { <ex://a> <ex://a> ?o }
      // CONSTRUCT WHERE { <ex://a> <ex://b> ?o }
      // CONSTRUCT WHERE { <ex://b> <ex://c> ?o }
      //
      // The third mapping would bind ?s = <ex://b>, but the second pattern
      // in the query has subject <ex://a>. Since these are incompatible,
      // only the first two mappings (both with ?s = <ex://a>) survive.

    Settings

    Member Visibility