On 02/07/2021 15:36, Claude Warren wrote:
If I use an ARQParser to parse the string "?x < 10"
I get an E_LessThan object with the expected var and and XMLSchema#integer
If I use NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral(
10 )) I get the XMLSchema#int.
This means that the following fails
{noformat}
E_LessThan lt1 = new E_LessThan( new ExprVar(Var.alloc( "x" )),
NodeFactory.createLiteral(LiteralLabelFactory.createTypedLiteral( 10 ));
E_LessThan lt2 = ARQParser.parse( "?x < 10" )
ElementFilter ef1 = new ElementFilter( lt1 );
ElementFilter ef2 = new ElementFilter( lt2 );
assertTrue( ef1.equalTo( ef2 ) );
{noformat}
because equalTo is "same term" - syntactic appearance.
"+10"^^xsd:int is different again.
It fails because ElementFilter.equalTo executes lt1.equalsBySyntax( lt2 )
and by syntax they are different. Even though they will return the same
results for any set of data.
So do a lot of other forms:
"10"^^xsd:decimal
"+10"^^xsd:int
"10e0"^^xsd:double
which are different terms but same value.
While this example comparison is the same for any data, other
expressions are not because of overflow.
Should E_LessThan and other similar functions do something more akin to the
NodeValue.compare() to determine if the functions are equal?
ElementFilter records what was written. The syntax.
ARQ also prints Elements (the AST) out when doing Query.toString,
preserving the original input.
I'm not sure what a good solution would be here but I think this is a
problem.
comments?
Don't use
LiteralLabelFactory.createTypedLiteral( 10 )
use
LiteralLabelFactory.create( String lex, RDFDatatype dtype)
or better yet use NodeFactory.
10 - unquoted in SPARQL is defined to be "10"^^xsd:integer
LiteralLabelFactory.createTypedLiteral( Object ) is concerned with
mapping between java values and RDF terms.
int 10 Java is a 32 bit signed quantity
It is closest match to xsd:int
If you had uses 10L you get xsd:long.
If you had uses 10.0 you get xsd:double not xsd:decimal.
Andy
Claude
Now this doesn't make a difference during evaluation as they both evaluate
as BitInteger. However, when comparing the
