Values.literal factory method with int argument should return xsd:integer datatype

[abrokenjester]

When calling ValueFactory.createLiteral(42) or Values.literal(42) the returned literal object has xsd:int as its datatype. While technically correct, this can easily catch people out: in both SPARQL 1.1 (see https://www.w3.org/TR/sparql11-query/#QSynLiterals) and Turtle syntax (see https://www.w3.org/TR/turtle/#abbrev) the assigned datatype when using shorthand syntax for integer values is xsd:integer rather than xsd:int.

This means that when first loading the following Turtle data:

<urn:a> <urn:value> 42 .

and then using Java for example to retrieve all statements with that value:

result = conn.getStatements(null, Values.iri("urn:value"), Values.literal(42)); 

We get an empty result, because literal(42) will not match with the turtle literal (wrong datatype). Workarounds are

result = conn.getStatements(null, Values,iri("urn:value"), Values.literal(BigInteger.valueOf(42)); 

or

result = conn.getStatements(null, Values.iri("urn:value"), Values.literal("42", XSD.INTEGER)); 

The difference between the two datatypes is that xsd:integer represents an unbounded integer (technically it's a restriction on xsd:decimal allowing no fraction in the lexical space), whereas xsd:int represents a 32-bit two-complement signed integer value. We originally chose to represent Java int primitives (and instances of java.lang.Integer) with xsd:int precisely because it corresponds 1:1 with the intended datatype, and use xsd:Integer only to represent a java.math.BigInteger.

I propose instead of using the datatype that technically aligns closest with the Java primitive, we use the datatype that from an API usability perspective makes the most sense. I'm suspecting that in 99 out of 100 cases people want to use xsd:integer to align with Turtle and SPARQL.