Re: my action item

On Tue, Aug 01, 2006 at 11:19:45AM -0700, Pat Hayes wrote:
> 
> Re. my action item from today's telecon.
> 
> After looking at Andy's examples in 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2006AprJun/0104.html
> more closely, his example 6 seems to behave correctly for the issue 
> that you were raising, if I understand it properly. In which case no 
> further examples are needed, and my action item is moot.
> 
> So let me see if I have got this right.
> 
> My understanding of your concern was that we had a nonmonotonic 
> situation because a not-equal ( !=) filter, as in example 6, behaved 
> as follows: when faced with an unknown datatype, it would revert to a 
> string-not-equal test on the literal string, and so succeed when the 
> literal strings were distinct but the type URI matches; and then this 
> success might transform to a failure when better datatyping 
> information is available.

Our measure of monotinicity is that adding knowledge to the system
does not cause us to rescind conclusions. We should never get answers
from the naive implementation that we don't get from the omniscient
one (adding support for a datatype should not cause us to rescind
answers). The current text in rq2{3,4} has:

[[
When selecting the operator definition for a given set of parameters,
the definition with the most specific parameters applies. For
instance, when evaluating xsd:integer = xsd:signedInt, the definition
for = with two numeric parameters applies, rather than the one with
two RDF terms. The table is arranged so that upper-most viable
candiate is the most specific.
...
A != B 	numeric	      numeric	    fn:not(op:numeric-equal(A, B))
A != B 	xsd:boolean   xsd:boolean   fn:not(op:boolean-equal(A, B))
A != B 	xsd:dateTime  xsd:dateTime  fn:not(op:dateTime-equal(A, B))
...
A != B 	RDF term      RDF term	    fn:not(RDFterm-equal(A, B))

The naive implementation sees
  "2"^^xsd:integer != "II"^^roman:numeral
and says "are they both numerics? no, boolean? no ... RDF terms? yes"
and does the RDFterm-equal test. They are not the same term so the
answer is TRUE (remember, *not* equal).

Some wise-guy adds support for roman:numeral to make the omniscient
implementation from the following schema (note: restriction of decimal):

  <xs:simpleType name="numeral" id="numeral">
    <xs:restriction base="xs:decimal">
      <xs:fractionDigits fixed="true" value="0" id="romanNumeral.fractionDigits"/>
      <xs:pattern value="[IVDXLC]+"/>
      <xs:minInclusive value="0" id="romanNumeral.minInclusive"/>
    </xs:restriction>
  </xs:simpleType>

Now the implementation says "are they both decimals? yep" and returns
FALSE (II is *not* != 2), causing us to lose an answer that we had in
the naive implementation.


> But this is not what the test examples indicate. With this rule, in 
> case #6, it would give the answer binding [ x/x1, v/"b"^^t:type1 ], 
> but in fact it does not: it gives no answers, as it should in order 
> to be monotonic when more datatype information is available. And the 
> comment on text 6 seems to  indicate that 'no result' is determined 
> in this case for reasons of preserving monotonicity, and works 
> symmetrically for equality and not-equality.

I believe that this test does illustrate the problem. I can concoct a
type system where the two are, in cleverer systems, known to be the
same value. Therefor, we need to spell it

SELECT *
{ ?x :p ?v
     FILTER ( ?v !sameLiteral "a"^^t:type1 )
}

or something like this.

> So, either the tests are OK, or I have misunderstood your point.
> 
> Eric? Or indeed, anyone with anything useful to say?
> 
> Pat
> -- 
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 

-- 
-eric

home-office: +1.617.395.1213 (usually 900-2300 CET)
	    +33.1.45.35.62.14
cell:       +33.6.73.84.87.26

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Thursday, 3 August 2006 10:04:42 UTC