RE: desired rule types and expressive power

Hi Doerthe,

 

But now that we are on it: I personally would like to include negation and go for some kind of scoped negation as failure to keep monotonicity, but I am open to suggestions here. Since the people in this group work with different applications, I am really curious, what we all need.

 

                +1! See my previous message for my thoughts on that.

 

 

William

 

From: Doerthe Arndt <doerthe.arndt@ugent.be> 
Sent: December-14-18 1:16 PM
To: public-n3-dev@w3.org
Subject: Re: desired rule types and expressive power

 

Dear Sandro,

your mail reminds me on a talk I saw one year ago at RuleML where Bob Kowalski explained that different people have totally different understandings of the concept of "rules" (the slides are available here, but I think they do not really speak for themselves: http://2017.ruleml-rr.org/wp-content/uploads/2018/03/LPS-slides-merged.pdf). The talk was eye-opening for me in the sense that it showed me that we always have to ask the question you raise below.

I added my comments below:

 

Am 12.12.18 um 14:27 schrieb Sandro Hawke:

A response to two recent messages:

On 12/11/18 7:32 PM, David Booth wrote:


Also, I think it may be wise to separate forward-chaining rules from backward-chaining rules, except in those (rare?) cases where a single rule definition can easily be run either way.  The reason for this is that I -- as a developer -- generally know exactly when/why I want to apply my rules, and if I am using an "alternative" rules language such as SPARQL or JavaScript then the implementation would be completely different for forward versus backward rules. 

Returning now to my question: What is your take on whether/how we could achieve both the simplicity of a convenient rules language and the control and power of a general-purpose programming language? 

Actually, I guess this question is both for you and anyone else who wants to address it.  :) 


and also

On 12/12/18 5:12 AM, Doerthe Arndt wrote:

Now, imagine, that the case is not that clear and to you Tom actually looks more like a dog. Then we could state

 :ruben :denies  {:tom a :Cat}.

meaning "Ruben denies that Tom is a cat.". The interesting point is now that with our local scoping in N3 this does not entail:

 :ruben :denies  {_:x a :Cat}.


These raise the basic issue of what kind of language we're talking about here.  How expressive is it, what features does it have?  Forward-chaining vs backward-chaining raises this, as does negation.

With my remark I did not want to raise the question for negation (even though I think it should be asked), I just wanted to show how cited graphs could be used in practice. But now that we are on it: I personally would like to include negation and go for some kind of scoped negation as failure to keep monotonicity, but I am open to suggestions here. Since the people in this group work with different applications, I am really curious, what we all need.

For forward vs backward chaining: In EYE (http://eulersharp.sourceforge.net/) both is implemented and the user can indicate by the use of the arrow whether he wants a rule to be applied forward or backwards: 

{:a :b :c}=>{:c :d :e}. 

will be applied as a forward-chaining rule and

{:c :d :e}<={:a :b :c}.

is the same rule backwards.

If possible, I would like to keep the whole topic of forward vs backward chaining out of the standardisation and let the developers of the reasoners decide that for themselves. The rules above should for example have the exact same logical meaning and the different arrows are just an operational detail for the reasoner.

 


Quoting from RIF Overview: <https://www.w3.org/TR/rif-overview/>  

Known rule systems fall into three broad categories: first-order, logic-programming, and action rules.

    ...

The RIF Working Group has focused on two kinds of dialects: logic-based dialects and dialects for rules with actions. Generally, logic-based dialects include languages that employ some kind of logic, such as first-order logic (often restricted to Horn logic) or non-first-order logics underlying the various logic programming languages (e.g., logic programming under the well-founded <https://www.w3.org/TR/rif-overview/#ref-wf-model>  or stable <https://www.w3.org/TR/rif-overview/#ref-stable-model>  semantics). The rules-with-actions dialects include production rule systems, such as Jess <http://www.jessrules.com/> , Drools <http://jboss.org/drools/>  and JRules <http://www.ilog.com/products/jrules/> , as well as reactive (or event-condition-action) rules, such as Reaction RuleML <http://reaction.ruleml.org/>  and XChange <http://reactiveweb.org/xchange/> . Due to the limited resources of the RIF Working Group, it defined only two logic dialects, the Basic Logic Dialect <https://www.w3.org/TR/rif-overview/#ref-rif-bld>  (RIF-BLD) and a subset, the RIF Core Dialect <https://www.w3.org/TR/rif-overview/#ref-rif-core> , shared with RIF-PRD; the Production Rule Dialect <https://www.w3.org/TR/rif-overview/#ref-rif-prd>  (RIF-PRD) is the only rules-with-actions dialect defined by the group.

Here's the question in graphic form, from a 2010 talk <https://www.w3.org/2010/Talks/0624-rif-sandro/#(18)> :



BLD languages are usually backward-chained, and can grow to FOL nicely.  PRD are usually forward-chained, and include programming language elements. The intersection, RIF-Core, is nice in that it works in either engine technology.

I don't think that we should go for production rules here (but can change my mind if anyone convinces me). Maybe RIF Core is a good base (as you also suggest). 




Cwm is an exception to the "usually" above, in that I think it's aiming to be "logical" and near FOL, but it's implemented as forward chaining. As such, I think it's very unlikely to be sound and complete for any definition of N3 semantics other than "whatever cwm implements".


There's an instinct to want as much expressive power as possible, but it comes with significant costs.  There's a lot to be said for just making a nice syntax for RIF-Core (I think Ivan Herman calls this "turtle rules").  The graphic doesn't show it, but I might even leave out non-frame atomic formulas.

I like that idea. I think that it is because I did not spend enough time with it, but find the distinction between frames and non-frame formulas confusing.

 

Something like:

 

if { ?x a :Dinosaur } 
then { ?x a :Bird }


and

 

if { ?person :firstName ?fn; :lastName ?ln }
then { ?person :name xs:concat(?fn, ' ', ?ln) }

I would prefer to have your function with a relation and an output variable, something like:

 

if { ?person :firstName ?fn; :lastName ?ln. ?concat xs:concat (?fn, ' ', ?ln) }
then { ?person :name ?concat }

I am afraid that by using your notation with built-in functions in the consequence of a rule the user could overwrite built-in functions, like for example in:

 

if { ?person :firstName ?fn; :lastName ?ln }
then { "O" log:equalTo xs:concat(?fn, ' ', ?ln) }
 

I guess you would use other functions for equality, but I hope you understand what I mean.

 

 

and stopping there.   I might also forget RIF Datatypes and Builtins <https://www.w3.org/TR/rif-dtb/>  and instead just use JavaScript, so maybe:

if { ?person :firstName ?fn; :lastName ?ln }
then { ?person :name $(?fn + ' ' + ?ln) }

 

Till here, I liked your proposal, but why would you want to have javascript functions here?  

Doerthe

 

 

That would be my proposal of the morning for an MVP, the smallest possible thing that might address many of the use cases here.

    -- Sandro

-- 
Dörthe Arndt
Researcher Semantic Web
imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems
Technologiepark-Zwijnaarde 19, 9052 Ghent, Belgium
t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be <mailto:doerthe.arndt@ugent.be>