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

Date: Tue, 11 Mar 2008 13:14:40 -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: <14023.1205255680@cs.sunysb.edu>

Date: Tue, 11 Mar 2008 13:14:40 -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: <14023.1205255680@cs.sunysb.edu>

> 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 ShawReceived on Tuesday, 11 March 2008 17:17:29 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 2 June 2009 18:33:47 GMT
*