Ok, the operation i am trying to perform is: myMethod((Long) quad.getObject().getLiteralValue())
where the method signature is: public void myMethod(Long value); and where the initial value inserted as a typed literal was declared as xsd:long. One of the solution I have found is: myMethod(Long.parseLong(quad.getObject().getLiteralLexicalForm())) I have understood that Jena returns an Integer because the value fit into a 32 bits value but the literal was created and tagged with a xsd:Long (which is defined as a signed 64-bit integer) that's why I expect to get a Java Long when I call quad.getObject().getLiteralValue(). Even if the value can fit in a Java Integer. Laurent On Wed, Jul 20, 2011 at 2:27 PM, Andy Seaborne <[email protected]> wrote: > > > On 20/07/11 13:15, Laurent Pellegrino wrote: >> >> Just to fix a mistake in my previous message : Long are 64 bits and not >> 128. >> >> On Wed, Jul 20, 2011 at 2:02 PM, Laurent Pellegrino >> <[email protected]> wrote: >>> >>> Thanks for your explanations. However, my problem is that >>> node.getLiteralValue() on the node returns an Integer Java object. >>> >>> DatasetGraphTDB dataset = TDBFactory.createDatasetGraph(); >>> >>> dataset.add(new Quad( >>> Node.createURI("http://openjena.org";), >>> Node.createURI("http://openjena.org";), >>> Node.createURI("http://openjena.org";), Node.createLiteral( >>> "-628675214", null, XSDDatatype.XSDlong))); >>> >>> Iterator<Quad> res = >>> dataset.findNG(Node.ANY, Node.ANY, Node.ANY, Node.ANY); >>> >>> Quad quad = null; >>> while (res.hasNext()) { >>> quad = res.next(); >>> >>> System.out.println(quad.getObject().getLiteralValue().getClass()); >>> } >>> >>> dataset.close(); >>> >>> It prints: >>> class java.lang.Integer >>> >>> Or the problem is that I use quad.getObject().getLiteralValue() as a >>> parameter of a method that expects a Java Long object because the >>> value that was initially stored was a Long: >>> >>> myMethod((Long) quad.getObject().getLiteralValue()) >>> >>> Or I get a ClassCastException due to the fact that >>> quad.getObject().getLiteralValue() returns an Integer. > > because the value (-628675214) can be fitted into an Java Integer. It's > just a class choosen because it can represent the value. Ditto xsd:byte. > > > >>> Indeed, it is not possible to store a full Long (128 bits) as a typed >>> literal (due to the fact that numbers are encoded into 56 bits). > > If it does not fit in 56 bits, then TDB stores the thing in the long form. > 56 bits is not a limitation on the values that can be stored - its the > limit on what can be stored compactly. If it does not fit, TDB falls back > on storing the lexical form and type. > >>> Hence, I have to store it as a non-typed literal and to parse it >>> manually but it also means that I cannot apply any method specific to >>> numbers on that field from a SPARQL query. That's why I was thinking >>> it is an issue :( > > You should be able to > > class Integer extends Number > Number.longValue() > > What operation are you wishing to perform? > > Andy > >>> >>> Laurent >>> >>> On Wed, Jul 20, 2011 at 11:45 AM, Andy Seaborne >>> <[email protected]> wrote: >>>> >>>> >>>> On 19/07/11 14:56, Laurent Pellegrino wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I am currently using a TDB instance with Quadruples (DatasetGraphTDB). >>>>> I insert some quads with a literal value which is typed with xsd:long: >>>>> >>>>> Node.createLiteral(Long.toString(myIdWhichIsAJavaLong), null, >>>>> XSDDatatype.XSDlong) >>>>> >>>>> At this step if I print the content to the standard output I get >>>>> something >>>>> like: >>>>> "1900023546"^^http://www.w3.org/2001/XMLSchema#long >>>>> >>>>> Then, I execute a query that return the quadruples that contain the >>>>> literal values that were initially typed as xsd:long. When I print the >>>>> content to the standard output I get: >>>>> "1900023546"^^http://www.w3.org/2001/XMLSchema#integer >>>>> >>>>> Why does the datatype is not the same? Is it an issue? >>>> >>>> No - or at least, it shouldn't. >>>> >>>> xsd:long is a XSD 64 bit number >>>> xsd:integer is an arbitrary precision >>>> >>>> xsd:integer is a more general datatype than xsd:long (xsd:int is the 32 >>>> bit >>>> XSD integer). >>>> >>>> TDB stores numbers (integers, decimals, doubles), and dates and >>>> dateTimes >>>> and booleans, as their value, not as their lexical form. Actually, it >>>> encodes them into 56 bits (currently). If the number does not fit it is >>>> stores via the node table and lexical form. >>>> >>>> This saves space and makes queries involving FILTERs on values go >>>> faster. >>>> Much faster. >>>> >>>> See NodeId.inline(Node) >>>> >>>> Andy >>>> >>> >
