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

Date: Tue, 11 Mar 2008 17:50:53 +0100

Message-ID: <47D6B86D.10602@inf.unibz.it>

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

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

Date: Tue, 11 Mar 2008 17:50:53 +0100

Message-ID: <47D6B86D.10602@inf.unibz.it>

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

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

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

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