PRD review - Part 1 Syntax of Condition Language

Hi All,

 

Here the first part of the PRD review - Part 1 Syntax of PRD Condition
Language.

 

Reviews for the other parts will follow.

 

The comments are organized by section numbers.

 

Best, Adrian

 

 

1.  Does RIF-PRD extend RIF-BLD condition language or partially adopt and
specialize it to the needs of production rules representation?

1.2.2. dialects extending RIF-BLD --> dialects extending RIF-PRD

1.3.1. BNF syntax for PRD and BLD should be consistent (as well as for any
other "future" dialects)

2. In 1.2. we state that we "extend" RIF BLD condition language; in chapter
2 we state RIF Core; if RIF Core would be a subset common to both RIF BLD
and RIF PRD we would strictly extend it.

2.1. There are several new constructs introduced, such as ExTerm,
Aggregation (see discussion later)

2.1.1.1. we need to refer explicitly (e.g. by a link) to all things which we
adopt from BLD and which are defined there, e.g. we don't define LITERAL
since it is adopted from and defined in BLD.

2.1.1.1. we exclude Uniterm and introduce ExTerm; why do we need a new
construct here? we can reuse Uniterm also to define procedural attachments

2.1.1.2. as for constants we should introduce a type attribute for
variables, so that only objects (individuals/constants) of the appropriate
type can be bound to the variable. An extra Subclass construct is
inappropriate for this since (1) it unnecessarily blows up the XML code if
you want it for type checks and more importantly (2) since it is not
implicitly associated with a variable it is dependent on the order where you
place the Subclass construct in a rule (i.e. the outcome differs accordingly
and it is impossible to ensure correctness). 

2.1.1.2. In the informal semantics we only allow variable bindings to values
and individuals (btw we are not consistent in the use of the term individual
vs. value vs. constant), but variable bandings in the sense of an explicitly
defined variable renaming are need in certain applications (e.g. for large
classes of rule-based machine learning approaches).

2.1.1.3. Most modern logic derivation rule engines support some kind of
procedural attachments to call external functionalities, so we should
discuss if a construct such as ExTerm (note: I'm not discussion the name of
such a construct here - we could e.g. reuse Uniterm) would also make sense
or even would be necessary for the "logic RIF" (but that would probably not
be "Core" - so what would be the relations?) 

2.1.1.3. we state that ExTerms on the level of TERM are interpreted as
evaluated functions (as opposed to evaluated relations under ATOMIC); in
general I agree with this statement, but depending on the data model and
type system of the externally called system this might be ambiguous (note
e.g. the distinction of matching two Java instances (objects) of the Java
class Boolean returned by a Java function as compared to truth-valued
relations). We should add some further clarification here.

2.1.1.3. in the presentation syntax we introduce "APPLY"

2.1.1.3. we need to handle exceptions of function calls in PRD and
explicitly describe that

2.1.1.4. in the informal semantics we mention procedural attachments; maybe
we should add a short explanation what this is, e.g. a footnote.

2.1.2.1. The distinction in PRD between ExTerm and Uniterm seems to me
unnecessary, since Uniterm as the name indicates was introduced to cover
both relations and functions on the level of "ATOMIC" and "TERM"

2.1.2.2. see 2.1.2.1

2.1.2.1. we say that we exclude named arguments. There is a huge class of
production rule systems, e.g. all CLIPS derivates, which support something
like named arguments. Since for an implementer of RIF PRD named arguments
would mean nearly no implementation overhead I think we should adopt them
from BLD. It is very easy to implement a default strategy for named
arguments where you introduce incremented "arg 1, 2, 3, ., x slot" in your
translator, when your rule engine does not support named arguments and does
not use the slots. This is very easy to implement, even in XSLT - so really
no overhead for implementers of PRD. But on the other hand to implement an
extension for named arguments for a PRD version without named arguments is
not easy; you would need to understand the complete PRD schema, make
extensions wherever necessary, validate all and publicly deploy the extended
schema somewhere - so a huge implementation overhead for those how would
like to use PRD and need named arguments.

Note: My Prova engine does not support named arguments, so I don't need
them, but since the implementation of an translator supporting a default
strategy for named arguments, as explained above, is so easy to implement, I
don't see why we should put the burden on the others (they are already
punished by the inefficiency of their systems ;-) - just kidding)

2.1.2.3 in the last RIF telecon we decided for BLD to use Equal also for
assignment of objects (e.g. returned by function calls) to variables. This
much more declarative then having an extra Assign construct for assignment
and one for Equality testing. For instance, if a variable used as first
argument in Equal is bound it would be an equality testing comparing both
objects, if the variable in the first argument is free it would be an
assignment of the second argument to the variable (including also variable
renaming assignments).

2.1.2.4. There is a need for an explicit Member and Subclass construct so we
should keep them - but as I have written in the discussion of variables
these constructs are not adequate for type checking

2.1.2.6. The definition of Frames should be common for both, BLD and PRD

2.1.3. I agree negation as failure is needed to have a sufficiently
expressive rule language to describe real-life problem (btw: I also see the
need to the logic BLD). But when it comes to Naf things get much more
complicated and we need to give semantics for that (will discuss this later
in the semantics part)

2.1.3.2. We say that a CONDITION can be a conjunction of zero or more
statements. What would be the meaning of an empty condition? What benefit do
we get to allow empty Conditions if there is not extra information it would
carry, e.g. in an attribute field? 

2.3.3.3. similar to And

2.1.3.4. If we introduce Naf, which I think we should do, we need to give a
good semantics to it (discussion later)

2.1.4. If we exclude Forall in the condition language of PRD we only address
the very standard production rule systems, but there are also hybrid systems
on the market including systems mixing forward-directed production rules and
backward-reasoning (and many other using e.g. magic sets, compilation
approaches, .)  and when it comes to event-based systems we can not easily
build on PRD (but that's a foresight).

2.1.4.1. Aggregation is newly introduced in PRD (as compared to BLD);
Aggregations are important, but not only for PRD; at least as a kind of
"findall" (as in Prolog derivates) is urgently needed to really work with
logical lists and also quite often in meta programming. So we should start a
discussion about that. And I don't see why we need a new extra construct for
aggregations - why not using built-ins within Uniterm (keeping the syntax
minimal)