desired rule types and expressive power

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.

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.

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.

Something like:


    if { ?x a :Dinosaur }

    then { ?x a :Bird }


and


    if { ?person :firstName ?fn; :lastName ?ln }

    then { ?person :name xs:concat(?fn, ' ', ?ln) }

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) }


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