From: Michael Kifer <kifer@cs.sunysb.edu>

Date: Tue, 11 Mar 2008 12:44:36 -0400

To: Jos de Bruijn <debruijn@inf.unibz.it>

Cc: axel@polleres.net, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Message-ID: <12006.1205253876@cs.sunysb.edu>

Date: Tue, 11 Mar 2008 12:44:36 -0400

To: Jos de Bruijn <debruijn@inf.unibz.it>

Cc: axel@polleres.net, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Message-ID: <12006.1205253876@cs.sunysb.edu>

> 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. 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 ShawReceived on Tuesday, 11 March 2008 16:54:25 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:49 UTC
*