[Entailment] D-entailment (and upwards) issue?

When thinking about what we called "D^-"-entailment at the f2f, I realised the following possible issue for all 
datatype aware entailment regimes (D-entailment, OWL, RIF, ...):

Entailment regimes in general are defined only in terms of BGP matching, but nothing else in the algebra, particularly FILTER evaluation
is independent from the entailment regime. FILTER evaluation is specified solely in the query document at this point.

However, I am afraid this might lead to unexpected behaviors... take the following example:

G:  :s :p "1"^^xs:integer

Query1: 

 SELECT * WHERE {?S ?P "1.00"^^xs:decimal }

Query2: 

 SELECT * WHERE {?S ?P ?O FILTER(?O = "1.00"^^xs:decimal) }


Since constants in FILTERs are not affected by canonicalisation, D-Entailment, would only give an answer to Query1, right?
I find this quite awkard since it'd mean that whenever I pose a query to a datatype aware store, I'd still need to know the 
internal representation of typed constants when it comes to FILTERs... is this observation correct?

However, a system that applies canonicalisation of typed constants not only in the graphs but including those in the query, 
could easily cope with that. I ask myself, whether we couldn't in the Section on canonical representations (4.1) also mention 
the option that not only the graphs, but also the queries could (or even should?) be canonicalised?

Any opinions?

Axel

p.s.: think I also found a small typo in the section 4.1 .... 

"If the parsing process involves canonicalization, then the obtained graph will contain just two nodes (one for ex:s and one for the 
            data value 100.0) connected by one edge (for ex:s)"

should be:

"If the parsing process involves canonicalization, then the obtained graph will contain just two nodes (one for ex:s and one for the 
            data value 100.0) connected by one edge (ex:p)"

Received on Tuesday, 11 May 2010 06:54:17 UTC