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

Ah, phew, that solves the issue for numerics, and for "=" with custom datatypes 
this issue can be solved by Operator Extensibility (Section 11.3.1) right? 

thanks for clarification,
Axel, awaking from early morning confusion ;-)

On 11 May 2010, at 08:54, Andy Seaborne wrote:

> 
> 
> On 11/05/2010 7:53 AM, Axel Polleres wrote:
> > 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?
> 
> Query 2 will return at least one row for any entailment regime,
> including simple.
> 
> "=" in FILTERs is a value-based comparison. (c.f. sameTerm)  Here, it
> dispatches to op:numeric-equals.
> 
> http://www.w3.org/TR/xpath-functions/#func-numeric-equal
> 
>         Andy
>

Received on Tuesday, 11 May 2010 08:32:34 UTC