W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2006

my action item

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 1 Aug 2006 11:19:45 -0700
Message-Id: <p06230919c0f547dd207c@[192.168.1.6]>
To: Eric Prud'hommeaux <eric@w3.org>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>

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.

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.

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
Received on Tuesday, 1 August 2006 18:20:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:27 GMT