[ 
https://issues.apache.org/jira/browse/JENA-721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14038646#comment-14038646
 ] 

Marek Kowalczyk commented on JENA-721:
--------------------------------------

[~rvesse] - Thanks, I must have overlooked that section of documentation. In 
our app the canonization is not the most crucial feature of Jena, and 
workaround with disabling inline literals works ok. 
Despite that: would it be possible to move this canonization to a reasoner ? 
Regarding improvement: a feature to disable inline literals or change in model 
to expand the inline type would be preferable?

[~andy.seaborne]
The problem is that we would like to validate the data, and check whether that 
data match schema.
We would like to do that by executing following query:
{noformat}
SELECT ?validatedObject  ?uri WHERE {
        ?validatedObject rdfs:range ?rangeClass .   
        FILTER(?rangeClass != rdfs:Literal)     
        ?uri ?validatedObject ?value .  
        FILTER(DATATYPE(?value) != ?rangeClass )
}
{noformat} 
As you may guess, we have properties with range xsd:positiveInteger, and we 
receive false positive matches, when DATATYPE(?value) returns xsd:integer 
instead of  xsd:positiveInteger( as defined in source ontology files).

> 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
>
> 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)

Reply via email to