[
https://issues.apache.org/jira/browse/JENA-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14040454#comment-14040454
]
Marek Kowalczyk commented on JENA-721:
--------------------------------------
I did not intended to disable the nodeId layer, I just wanted to disable the
inline literals, ( and did that by setting private static
NodeId.enableInlineLiterals to false) because the canonization has no benefits(
in our project), and gave us a problem.
In my opinion it should be an option to enable/disable inline literals.
I know, that files are not compatible( with inline literals and without inline
literals)
Approach with a reasoner to achieve following goal seems to be a good idea:
{quote}
It makes comparisons "by value" within the derived type hierarchy for
xsd;integer so SPARQL ?s :property +1 match data :subject :property
"01"^^xsd:positiveInteger.
{quote}
But in my opinion it does not wok that way: it transforms the object before
writing to table to +1 and then, when querying it matches +1 with +1, doesn't
it?
Thanks for pointing riot.infer I will definitely have to take a closer look on
that process, and check whether such streaming approach can be used in our app.
Still, we have some more complex data validation rules that needs to be
executed as a queries.
> Inline literals, source types are discarded
> -------------------------------------------
>
> Key: JENA-721
> URL: https://issues.apache.org/jira/browse/JENA-721
> Project: Apache Jena
> Issue Type: Improvement
> Components: TDB
> Affects Versions: TDB 1.0.1
> Reporter: Marek Kowalczyk
> Priority: Minor
>
> NodeId.inline$ changes the actual type of literals from subtypes of
> xsd:integer to xsd:integer, for instance: literals of type
> xsd:positiveInteger are stored ad inline type INTEGER and during read decoded
> as xsd:integer in NodeId.extract(NodeId)
> {code}
> case INTEGER:
> {
> long val = IntegerNode.unpack(v) ;
> Node n = NodeFactory.createLiteral(Long.toString(val), null,
> XSDDatatype.XSDinteger) ;
> return n ;
> }
> {code}
> It would be nice to add support for various xsd:types and use the 7 bits
> reserved for inline type to represent more than 7 types.
> As a fastest workaround I've disabled the inline literals in NodeId( using
> reflection) , but it would be great If it would be configurable via context
> or parameter in StoreConnection.make(); or via SystemParams
--
This message was sent by Atlassian JIRA
(v6.2#6252)
