openRDF.org Issue Tracker http://www.openrdf.org/issues This file is an XML representation of an issue en [SES-818] Incorrect TupleExpression created for "SELECT (?s IN (?p,?o) AS ?x) ... ". http://www.openrdf.org/issues/browse/SES-818 The incorrect TupleExpression is created for &quot;SELECT (?s IN (?p,?o) AS ?x) ... &quot;. It produces the following AST tree. You can see that Var(s), In, and Var(x) are all children of the ProjectionElem. However, getAlias() assumes that the child at index 1 will be the alias when there are at least two children of the ProjectionElem. That is In() rather than Var(x). It seems likely that it would be easier if IN were treated as an infix operator such that the parse tree would be ProjectionElem(IN(s,p,o),x) and thus always have either one or two children which would make identifying the alias much easier. This might be done by a rewrite step. Other solutions are of course possible, but if the expression in the &quot;left&quot; hand side of the AS has more than one node then getAlias() should return the last element rather than the 2nd element. <br/> <br/> &gt; QueryContainer <br/> &gt; SelectQuery <br/> &gt; Select <br/> &gt; ProjectionElem <br/> &gt; Var (s) <br/> &gt; In <br/> &gt; Var (p) <br/> &gt; Var (o) <br/> &gt; Var (x) <br/> <br/> public String getAlias() { <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (children.size()&gt;= 2) { <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Node aliasNode = children.get(1); <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (aliasNode instanceof ASTString) { <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return ((ASTString)aliasNode).getValue(); <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else if (aliasNode instanceof ASTVar) { <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return ((ASTVar)aliasNode).getName(); <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return null; <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;} any SES-818 Incorrect TupleExpression created for "SELECT (?s IN (?p,?o) AS ?x) ... ". Bug Major Resolved Fixed Jeen Broekstra Bryan Thompson Tue, 23 Aug 2011 00:58:27 +0200 (CEST) Sun, 28 Aug 2011 23:41:19 +0200 (CEST) 2.4.2 2.5.1 SPARQL 0 Something related which I noticed is that the &quot;AS&quot; 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 &quot;AS&quot; 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. <br/> <br/> void GroupCondition() : <br/> {} <br/> { <br/> FunctionCall() <br/> | BuiltInCall() <br/> | &lt;LPAREN&gt; Expression() [ &lt;AS&gt; Var() ] &lt;RPAREN&gt; &lt;== <br/> | Var() <br/> } <br/> Jeen, <br/> <br/> This problem with IN and NOT IN was driving me nuts. I modified the sparql.jjt grammar as follows: <br/> <br/> void RelationalExpression() #void : <br/> {} <br/> { <br/> NumericExpression() <br/> [ <br/> &lt;EQ&gt; NumericExpression() {jjtThis.setOperator(CompareOp.EQ);} #Compare(2) <br/> | &lt;NE&gt; NumericExpression() {jjtThis.setOperator(CompareOp.NE);} #Compare(2) <br/> | &lt;LT&gt; NumericExpression() {jjtThis.setOperator(CompareOp.LT);} #Compare(2) <br/> | &lt;LE&gt; NumericExpression() {jjtThis.setOperator(CompareOp.LE);} #Compare(2) <br/> | &lt;GE&gt; NumericExpression() {jjtThis.setOperator(CompareOp.GE);} #Compare(2) <br/> | &lt;GT&gt; NumericExpression() {jjtThis.setOperator(CompareOp.GT);} #Compare(2) <br/> // | In() <br/> // | NotIn() <br/> | In() #Infix(2) <br/> | NotIn() #Infix(2) <br/> ] <br/> } <br/> <br/> This ensures that the IN() construction does not cause there to be more than one AST node in the value expression for the parent. <br/> <br/> I then added a production to handle the Infix operator: <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;/** <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* Unwrap an {@link ASTInfix} node, returning the inner {@link FunctionNode} <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;* constructed for it. <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*/ <br/> &nbsp;&nbsp;&nbsp;&nbsp;@Override <br/> &nbsp;&nbsp;&nbsp;&nbsp;public FunctionNode visit(ASTInfix node, Object data) throws VisitorException { <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;final Node left = node.jjtGetChild(0); <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;final Node op = node.jjtGetChild(1); <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;op.jjtInsertChild(left, 0); <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;return (FunctionNode) op.jjtAccept(this, data); <br/> <br/> &nbsp;&nbsp;&nbsp;&nbsp;} <br/> <br/> 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). <br/> <br/> Have to run a few more quick tests before I commit, to see if I don't break any existing queries.