RIF-PRD Review - Part 1

Hi Christian,

The new PRD version improved much and the structure and syntax presentation of PRD is now very clear.

Here my comments on the first syntax part of PRD. I will send my comments on the semantics in another email. 

- Section 2.1: … and the recursively specified And, …, Naf 
Later in the PRD draft Naf is called NmNot. 

- Section 2.1.1. In the editor note you say that a term can not be a logical function, i.e. exclude Expr (functional expressions).
There are production rule systems, including e.g. CLIPS, which support logical functions, e.g. to overcome the problem of truth maintenance and there are many hybrid systems which combine the production rules approach with logic based semantics and backward-reasoning resolution for logical functions/goals (e.g. DROOLS is working on a combination or Prova) . I would propose, to keep logical functions in order to cover also these production rule systems.
Here e.g. a CLIPS example for illustration:

(defrule cardiac-risk
 (person (name ?name) (smoker yes) (weight ?weight))
 (test (> ?weight 100))
=>
 (assert (cardiac-risk ?name))
)
This rule tests whether a person is overweight and a smoker. If he is, then it asserts a warning that his heart is at risk. Now what happens if the person gives up smoking, or loses weight? The warning fact will still be present, because it is not linked in any way to the rule which created it. This means that the fact base is no longer consistent with reality. 
To overcome this problem CLIPS provides a logical conditional element which assists with the perennial problem of truth maintenance:
(defrule cardiac-risk
 (logical (person (name ?name) (smoker yes) (weight ?weight)))
 (logical (test (> ?weight 100)))
=>
 (assert (cardiac-risk ?name))
)

By using the logical keyword there is a link between the fact asserted and the premises on which it was based. When the premises changed, their results were no longer valid, so they were removed.

- Section 2.1.1.1 In the example you say type = “IRI”, it should be type=”rif:iri”
An alternative approach would be to use an optional iri attribute directly to specify the IRI reference, i.e. <Const iri=”An IRI”/>

- Section 2.1.1.1 “Symbols with non-standard types” …
That would lead to a typed language. Later you even mention … “cannot be cast” …. and in the section about variables (Var) that they should be also typed.  
I really would leverage this proposal of a type rule language where the types a directly attached to the symbols, as it is need e.g. to efficiently use external Semantic Web vocabularies or object-oriented class hierarchies as type systems. For a typed language approach the additional member construct is not very useful and additionally blows up the syntax.

However, I remember that we already had a typed language (a multi-sorted logic) at the beginning of RIF and that we decided to discard sorts. 

In any case, RIF PRD and BLD should have the same approach for types/sorts.


- Section 2.1.1.3  In the editors note you say “… This version of PRD draft does not use named argument UNITERMs”.
I totally agree with you that an assumption of ordered arguments allows much more efficient rule engine implementations. Nevertheless, CLIPS and many derivates such as Jess provide an unordered representation using a slot-like syntax. We need to support these widely known and used PR systems.
  
- Section 2.1.2.3. Yes, “object” and “class” are more intuitive, I think also for BLD. So, maybe the terminology of BLD should be changed and we don’t need to differ from BLD. 

- Section 2.1.3  You rename Naf to NmNot
Yes, the semantics of default negation in production rules if different from the semantics in logic programming. But, there many have criticized inflationary negation and have pointed out that there is a mistake in using negation in production rules. Several proposals for the semantics of negation in production rules exist.

To allow easy (syntactic) mapping from a production rules representation to a RIF logic representation, I would propose to use the same construct for default negation. It is then much easier to interchange e.g. a business rule set between a logical rule engine and a production rule engine.

I don’t think we should include negation into this basic PRD dialect. It complicates the (transition) semantics with update actions quite a lot. Of course, negation is need to represent many real-world problems. But similar to BLD an extended dialect could add negation to the basic PRD dialect. 

- Section 2.2.1. A (later) logic dialect will probably also introduce actions. For instance, the ISO Prolog standard, which is widely used, defines assert and retract actions. Why not use the terminology of this existing and widely known standard, i.e. instead of “Remove” use “Retract”.

- Section 2.2.1.4 Instead of introducing a new Execute construct, I would propose to reuse the External construct. An additional attribute can distinguish between fixed built-ins and user-defined procedural attachment calls with side effects.

- Section 2.2.1.5 Assign construct
Proposal: Use Equal instead of a new Assign construct. 
The declarative semantics can be implemented by an appropriate definition of substitution. 
This leads to a much more expressive rule language and we can also use this general approach for assignment in a logic rule language - hence leading to easy interchange beteen production rule representation and derivation rule representation.
 
- Section 2.3. Rename Implies to ConditionalStatement
I neither like Implies (in BLD) nor ConditionalStatement. Implicational truth formulas are not the same as derivation rule as pointed out by several people. 
Why not use a general <Rule> construct (in BLD, PRD and all other dialects) which can be specialized to different rule types, e.g. by an attribute denoting the type (this would be a minimal and compact syntax approach)?

- Section 2.3.2 If-then-else rules
That also complicates the semantics and I would propose to move the else part to enhance PRD dialect together with negations.


My comments on the semantics described in section 3 will follow in another email.

Cheers,

Adrian

-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

Received on Sunday, 25 May 2008 16:08:22 UTC