W3C home > Mailing lists > Public > public-rif-wg@w3.org > February 2009

Re: [Core] updated safeness condition

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Wed, 04 Feb 2009 17:04:48 +0100
Message-ID: <4989BCA0.2060800@inf.unibz.it>
To: Changhai Ke <cke@ilog.fr>
CC: RIF WG <public-rif-wg@w3.org>
>>From the view of PRD, the safeness means that each variable in the
> conditions part (or the "body") must be initialized. So for each
> variable, the engine must be able to find the expression that
> initializes it.

This is also precisely what safeness means to me, and the condition was
written with precisely this in mind.

> Unlike the backward chaining rules, or the logic programming, which can
> stack goals in a recursive way until they encounter facts, production
> rules do not stack goals, they are data driven.
> 
> With this in mind, I try to read the definitions. It is indeed not
> obvious to find to what extent this notion of "variable initialization"
> is expressed in the new definition, while in the old one, the first

It says:
A rule implication h :- b is safe iff ?V1, ..., ?Vn are the variables
appearing in h or b, ?V1, ..., and ?Vn are safe in b.

This means that every variable must occur in the body and from the
definitions of safeness of variables and of binding patterns it should
be clear that when doing reasoning in a forward-chaining manner (e.g.,
with a production rule system), one can always find a binding for the
variables.

> bullet reflects clearly this. If the old definition has a shortcoming,
> can we adapt it?

I did not understand the old definition.  Also, it does not seem to take
disjunction and equality into account and seems to be overly restrictive
when it comes to external predicates. These issues all complicate the
definition.

> 
> If the new definition is indeed more precise, can you add a short text
> saying that "intuitively the whole definition specifies each variable in
> the body should be initialized".

Yes, I guess it makes sense to add some text capturing the intuition
behind safeness.

how about:
"Intuitively, safeness of rules guarantees that when performing
reasoning in a forward-chaining manner, it is possible to find bindings
for all the variables in the rule before it is "fired"."


Best, Jos

> 
> Regards,
> 
> Changhai
> 
>> -----Original Message-----
>> From: public-rif-wg-request@w3.org
> [mailto:public-rif-wg-request@w3.org]
>> On Behalf Of Jos de Bruijn
>> Sent: Tuesday, February 03, 2009 7:05 PM
>> To: RIF WG
>> Subject: [Core] updated safeness condition
>>
>> I updated the safeness condition to fix the technical problem I
> noticed
>> during the telephone conference and to improve the presentation.  I
> hope
>> it is now easier to follow.
>> Please let me know if there are still problems in the presentation.
>>
>> The problem with the previous version of the definition was that it
>> allowed to assign "bound" to all variables, even those appearing only
> in
>> external terms.
>> I now make a distinction between safe and strongly safe variables,
> where
>> the strongly safe variables are those that are made safe by
> non-external
>> atoms.  It is required that all variables that are not strongly safe
> are
>> assigned "unbound".
>>
>> Please *read carefully* and criticize.
>> And I remind you that it is not necessary to wait until the next
>> telephone conference before starting to read the definition.
>>
>>
>> Best, Jos
>>
>> [1] http://www.w3.org/2005/rules/wiki/Core#Safeness
>> --
>> Jos de Bruijn            debruijn@inf.unibz.it
>> +390471016224         http://www.debruijn.net/
>> ----------------------------------------------
>> No one who cannot rejoice in the discovery of
>> his own mistakes deserves to be called a
>> scholar.
>>   - Donald Foster
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster


Received on Wednesday, 4 February 2009 16:04:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:03 GMT