Re: [DTB] a counterproposal to negative guards

Michael Kifer wrote:
>> Thinking a bit about implementation, implementing built-ins such as 
>> isNotString might not be as straightforward as I had originally thought.
>>
>> Namely, isString and isNotString will give rise to multiple minimal models:
>> for every IRI a there will be one minimal model in which isString(a) is 
>> true and one minimal model in which isNotString(a) is true.  The lack of 
>> a single minimal model prevents the use of the usual fixpoint operator 
>> for computation.
> 
> Why is that? You are probably thinking of them as complements, while they
> should not be. Both isNotString(a) and isString(a) should be false in the
> minimal model in the absence of other information.

They should be complements. I cannot think of any other reasonable 
definition:

isString is defined as the value space of xsd:string; given an 
interpretation I with a domain D, isNotString is defined as D - (value 
space of xsd:string)

What did you have in mind?

Best, Jos

> 
> What we should avoid is the possibility of both isString(a) and
> isNotString(a) being true (being false is not a problem). This should be
> treated as inconsistency.  But this is not a problem - at least in rule
> languages. None of these predicates is allowed to be in the conclusion of a
> rule. So, the only way to make an IRI a string is to equate it to a
> string. So, if you equate an iri xyz to "abc" and 123 then you get
> inconsistency anyway.
> 
> For non-rule dialects, e.g., FOL, they will need to work out the
> restrictions on the builtins anyway. 
> 
> 
> 	--michael  
> 
> 
>> Best, Jos
>>
>> Jos de Bruijn wrote:
>>>> I was talking to Harold about the DTB document again and we agreed 
>>>> both that we do not really like the "negative guards", because they 
>>>> seem to introduce some special form of negation, which is a bit weird, 
>>>> as otherwise negation is not part of bld...
>>>>
>>>> Now let's take the use case, which I suppose brought up the whole idea 
>>>> about negative guards:
>>>>
>>>>
>>>>  I assume the idea was that guards where meant to do some type 
>>>> checking to prevent other builtins to fail with an error... so we need 
>>>> these for instance to right something like:
>>>>
>>>>  q(X+1) :- p(X)    if X is numeric.
>>>>  q(0)   :- p(X)    if X is not Numeric.
>>> the most natural way to write these rules is:
>>>
>>> q(X+1) :- p(X), isNumeric(X).
>>> q(0)   :- p(X), isNotNumeric(X).
>>>
>>> In fact, I would be surprised if we would not have the isNumeric and 
>>> isNotNumeric built-in predicates. (we already have built-ins such as 
>>> numeric-add and numeric-subtract, so it will be rather silly not to have 
>>> the isNumeric and isNotNumeric predicates)
>>>
>>> Now, your first example is an approximation of this, which can be 
>>> simplified, as Michael pointed out.
>>>
>>> Your second example is an encoding that one can only understand if one 
>>> would know about the intricacies of the way RIF deals with errors.
>>> Guards are a way to prevent errors occurring in the first place, thereby 
>>> not requiring users to know about the intricacies of the semantics of 
>>> errors.
>>>
>>>
>>> Then, I would argue that having "negation" in built-in predicates does 
>>> not introduce negation in the language.
>>> In fact, we already have negation in our built-in predicates.  For 
>>> example, greater-than is the negation of less-or-equal.
>>> Perhaps negation is also not the proper term in this context.  Perhaps 
>>> we should rather talk about "complement".  Greater-than is the 
>>> complement of less-or-equal; numeric-equal is the complement of 
>>> numeric-unequal; isNumeric is the complement of isNotNumeric.
>>> Implementing the complement of a built-in predicate is as complex as 
>>> implementing the built-in predicate itself.
>>>
>>> Finally, complement of built-in predicates is quite different from the 
>>> (default) negation usual in logic programs.
>>> Consider isNotString(ex:myiri).  This statement may be true in some 
>>> models, and false in others.
>>> Consider now not isString(ex:myiri). This statement is true in the 
>>> minimal model, because it is not known that ex:myiri is a string.
>>>
>>>
>>> Best, Jos
>>>
>>>
>>>> i.e. to make a case distinction, concerning whether the arbuments are 
>>>> "allowed" for the built-in which should e "guarded".
>>>>
>>>> Now with the current means we would need to  write this something like 
>>>> as follows:
>>>>
>>>>  q(numeric-add(X,1)) :- p(X), isInteger(X) .
>>>>  q(numeric-add(X,1)) :- p(X), isDecimal(X) .
>>>>  q(numeric-add(X,1)) :- p(X), isLong(X) .
>>>>
>>>>  q(0)   :- p(X), isNotInteger(X), isNotLong(X), isNotDecimal(X).
>>>>
>>>> whereas we could write this simpler and without negative guards if we 
>>>> just add one more guard except the current datatypeguards:
>>>>
>>>>  q(numeric-add(X,1)) :- p(X), isInteger(X) .
>>>>  q(numeric-add(X,1)) :- p(X), isDecimal(X) .
>>>>  q(numeric-add(X,1)) :- p(X), isLong(X) .
>>>>  q(0)   :- p(X), isError(X+1).
>>>>
>>>> I don't know whether this solves all use cases for negative guards, but,
>>>> before buying into sneaking in some form of negation which we can later
>>>> on have in dialects with negation for free... maybe adding the 
>>>> isError() guard for the moment and leaving out the negative guards 
>>>> would do for the moment?
>>>>
>>>> Axel
>>>>
>>>>
>> -- 
>>                           debruijn@inf.unibz.it
>>
>> Jos de Bruijn,        http://www.debruijn.net/
>> ----------------------------------------------
>> One man that has a mind and knows it can
>> always beat ten men who haven't and don't.
>>    -- George Bernard Shaw

-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw