Re: UNSAID - two test cases (dawg:unbound, issues#useMentionOp)

Pat Hayes wrote:
 > I would suggest that the simplest way for us to go would be to say that
 > if any arguments are unbound, then any operator is false. So if ?x and
 > ?y are unbound then neither of ?x=?y, ?x!=?y are true.
 >
 > Notice that we don't need to give these a value in the unbound case: all
 > we need to know is that they are not true in this case, so if a
 > constraint has them in it, then it fails. Our logic is always 2-valued,
 > and the values are <true> and <anything other than true>

For all the operators we take from F&O, I agree that any unbound variable should 
make the operator false.

For extensibility, to any datatypes, we allow other operators - any operator is 
just a filter that says "yes" or "no" to a solution, based on some variables of 
the solution.

The corner case is an operator to test whether a variable is bound.  I'm not 
sure this is very important to include though - a little rearrangement can get 
the right effects if the operator returns false rather than making the whole 
expression it is involved is as false:

e.g. solutions with people's ages less than 21 or not specified.

Either "unbound(?age) || ?age < 21"
or     "! (?age >= 21)"

This could be seen as operators taking names of variables; the F&O operators all 
dereference their variables and work on the values.

	Andy


------------------

Pat Hayes wrote:
>> On Wed, Dec 22, 2004 at 05:26:01PM +0000, Andy Seaborne wrote:
>> > >Yes, but SQL for eg. has tri-value logic (true, false and NULL), so you
>> > >can meaningfully apply operators and functions to unbound values 
>> (NULL).
>> >
>> > It doesn't quite work out that simply.  It's fine for operators and
>> > functions but pattern matching isn't so straight forward.
>> >
>> > OPTIONAL (<x> ?p ?o)
>> >  (?o ?q <y>)
>> >
>> > so ?o may be NULL then we have the (?o ?q <y>) and it needs to handle
>> > ?o = NULL differently.  NULL is different.
>>
>> Yes, bun in RDF you cant have a triple like (NULL ?q <y>), so that match
>> will always fail. Unless I'm missing something.
>>  
>> > Talking about NULLs, with all it special cases for matching and function
>> > handling, like NULL != NULL, is no different to talking about unbound
>> > variables.  Both need special handling.
>>
>> There are no special cases. Any arithemtic operation involving NULL is
>> NULL, so NULL == NULL is NULL, NULL > 3 is NULL, ...
> 
> 
> OK, that is 'weak' 3-valued logic.  Is there/ any/ way to write an 
> expression whose value is true when its argument is NULL? If not, then 
> NULL is just a kind of universal error-mark, and does not really change 
> the underlying logic; it just makes everything more complicated  and 
> messier to state, and provides no useful functionality. In fact it is 
> not really a value in the usual sense at all; its really 'below' the 
> real values, and acts as the bottom element of a semilattice. All this 
> will do is create confusion when we try to define instance, matching 
> etc.; and I can't see that it would buy us anything positive to make up 
> for all the complication and confusion.
> 
>>  
>> > >I have said a few times that DAWG I think should come down off the 
>> fence
>> > >about tri-value logic.
>> >
>> > Do you have a test case where it makes a difference?  I have difficulty
>> > seeing this as other than a difference of linguistic approach, trying to
>> > use the same language for matching and for operators.
>>
>> Yes,
>>
>>     SELECT ?foo
>>      WHERE [ (?foo :p ?x) ] [ (?foo :q ?y) ]
>> AND ?x != ?y
>>
>> In a tri-value logic, this will only succeeed if ?x and ?y are bound, I
>> think.
> 
> 
> There is no way to tell until someone comes up with an exact account of 
> what != means. But why would this case differ in a 3-valued logic from 
> the way it would be handled in a 2-valued logic? It only has the effect 
> you say because the inequality requires its arguments to be bound. We 
> can specify this as a constraint on the != operator without changing the 
> underlying logic.  (BTW, there are 3-valued logics in which NULL=NULL is 
> true.)
> 
>>
>> > It seems to me that we have to say what happens with 
>> op:numeric-less-than
>> > encounters anything unexpected through the casting rules of F&O extended
>> > for bNodes anyway.
>>
>> Yes, but what. The Perl/PHP/ECMAScript convention is that
>>
>>       ?x is unbound, ?y = 3
>>
>>    ?x != ?y is true
>>         ?x > 3 is false (for various reasons)
>>   
>> In SQL they are both NULL, again, I think, My SQL is rusty. e.g:
>>
>>         $y = 3;
>> if ($x != $y) { print "true\n"; } else { print "false\n"; }
>>      if ($x > 3) { print "true\n"; } else { print "false\n"; }
>>
>> prints
>>
>> true
>>     false
>>
>> In PHP and Perl.
>>
>> In Perl $x > -1 is true (unbound = 0, I guess), in PHP its false.
> 
> 
> I would suggest that the simplest way for us to go would be to say that 
> if any arguments are unbound, then any operator is false. So if ?x and 
> ?y are unbound then neither of ?x=?y, ?x!=?y are true.
> 
> Notice that we don't need to give these a value in the unbound case: all 
> we need to know is that they are not true in this case, so if a 
> constraint has them in it, then it fails. Our logic is always 2-valued, 
> and the values are <true> and <anything other than true>
> 
> Pat
> 
>>
>> - Steve
> 
> 
> 
> -- 
> 
> ---------------------------------------------------------------------
> 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
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>

Received on Thursday, 6 January 2005 11:47:33 UTC