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