On 11/12/16 13:06, Claude Warren wrote:
On Sun, Dec 11, 2016 at 12:28 PM, Andy Seaborne <[email protected]> wrote:
Which tests? ARQ, SPARQL ones? Graph ones?
Graph tests. I am only working on ensuring that the base graph storage
works as expected. The implementation should work with the wider
datasetgraph and others but at this stage I want to make sure that the add,
delete, query work as expected at the low level.
The notion of Capabilities.handlesLiteralTyping isn't particularly
relevant to SPARQL which has both exact term matching (SameTerm) and value
matching (in FILTERS, =, <, >). It is not part of the RDF specs either -
it's a form of entailment.
Lexical-space, value-space is part of SPARQL. The per-graph idea of
literal typing has been overtaking by specs - it's a very old feature from
a time when RDF was just coming into being and RDF wasn't well connected to
the numerical work in XML-land.
handlesLiteralTyping is only called from test cases in the code base. I
don't remember seeing it in any support questions for many years.
We should arrange to evolve it away.
In the graph contract tests there is a test where (if handlesLiteralTyping
is set) the test verifies that 42 as a typed literal created with a java
type int, byte, short or long match 42^^xsd:integer
handlesLiteralTyping is nearby in concept but its not about java int 42
becoming "42"^^xsd:int. That happens in Model and when a Literal is
created. Not in the Graph which only deals with Nodes.
handlesLiteralTyping is about Graph.find(,,42)
Some code:
https://gist.github.com/afs/914433780039b9194122783d31ca752f
What I think I am reading above is that this doesn't matter and that the
SPARQL level will handle it. But that does not seem correct to me.
So if we look at the TDB strategy for storage does it match 42^^xsd:int
with a query for 42^^xsd:byte or 42^^xsd:long?
Yes - because both data and query are mapped to "42"^^xsd:integer (or
rather an efficient binary encoding of that in a NodeId).
If so what lexical value does it return?
"42"^^xsd:integer.
Does TDB always convert to integer or does it use long?
It converts if it fits in a 56 bit integer (the other 8 bits are type
field).
Numbers (not all), datetimes, dates, booleans.
See NodeId.inline$
What does it do if a value crosses the MAX_VALUE threshold?
Reverts to storing long form.
I am trying to figure out how to do this for the Cassandra storage and I
think the answer may be to add a numeric column that would be populated
with any of the "integer" numeric types, though I was thinking perhaps a
BigDecimal would work for all the data types and would make the scanning
for ranges easier (as you mentioned before).
For string literals I might store the text without language tag in another
column for ease of scanning as well, but this may not make sense. I still
have to look at how text queries might be implemented.
thx,
Claude
Andy
