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?

I do not know what I had in mind :-)

But maybe we can minimize isSomething with higher priority than isNotSomething.


	--michael  


> 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

Received on Tuesday, 11 March 2008 17:17:29 UTC