Something related which I noticed is that the "AS" appears to disappear within a GROUP BY (?x AS ?y). The ?x and ?y show as the children of a GroupBywithout the AS being represented by a dominating AS node. You can see this would be the case by looking at the grammar. I think that it might be more convenient to represent the { Expr AS Var } as an "AS" grammar production so it was always just a single AST node. This would also solve the problem in the SELECT expressions since an AS would always be represented as a binary relation regardless of the number of nodes involved in the left hand side.

void GroupCondition() :
{}
{
FunctionCall()
| BuiltInCall()
| <LPAREN> Expression() [ <AS> Var() ] <RPAREN> <==
| Var()
}

Jeen,

This problem with IN and NOT IN was driving me nuts. I modified the sparql.jjt grammar as follows:

void RelationalExpression() #void :
{}
{
NumericExpression()
[
<EQ> NumericExpression() {jjtThis.setOperator(CompareOp.EQ);} #Compare(2)
| <NE> NumericExpression() {jjtThis.setOperator(CompareOp.NE);} #Compare(2)
| <LT> NumericExpression() {jjtThis.setOperator(CompareOp.LT);} #Compare(2)
| <LE> NumericExpression() {jjtThis.setOperator(CompareOp.LE);} #Compare(2)
| <GE> NumericExpression() {jjtThis.setOperator(CompareOp.GE);} #Compare(2)
| <GT> NumericExpression() {jjtThis.setOperator(CompareOp.GT);} #Compare(2)
// | In()
// | NotIn()
| In() #Infix(2)
| NotIn() #Infix(2)
]
}

This ensures that the IN() construction does not cause there to be more than one AST node in the value expression for the parent.

I then added a production to handle the Infix operator:

    /**
     * Unwrap an {@link ASTInfix} node, returning the inner {@link FunctionNode}
     * constructed for it.
     */
    @Override
    public FunctionNode visit(ASTInfix node, Object data) throws VisitorException {

        final Node left = node.jjtGetChild(0);

        final Node op = node.jjtGetChild(1);
        
        op.jjtInsertChild(left, 0);

        return (FunctionNode) op.jjtAccept(this, data);

    }

This fixes the problem for me.

Thanks for the suggestions. I have added the Infix approach for the productions of In and Not In, which fixes the issues with this kind of operation appearing in the projection. The TupleExprBuilder now reads an Infix object by first visiting the leftArg and then injecting that arg immediately into the production for the rightArg, so the operator has both operands available, resulting in a ValueExpr (in this case, a OR-ed set of Compare objects).

Have to run a few more quick tests before I commit, to see if I don't break any existing queries.