AW: AW: [RIF] section 6 - compatibility with RIF-BLD complete - Review PRD


A quick answer - will read through your comments when I have more time. 

I'm not aware of one "agreed-upon" unifying semantics for Production Rules
with negation and retract. Instead I know that there is a lot of discussion
in the community that the way negation is treated by several of the
production rule systems is not correct and leads to problems. An there are
many proposals for the semantics of negation in production rules including
argumentation semantics, stratified production rules, transformation based
semantics, inflationary semantics, just to name some. 

Yes, naf conditions in production rules can be seen as hypotheses which can
be assumed if there is no possible course of actions to achieve l. So far on
the idea; the whole problem is to understand formally what it means that
there is no possible course of actions starting from a given state S to
achieve the result l.

Inflationary semantics for semantics start out from a state S with a
possible empty set of intensional facts, the rules fire and assert new facts
to the intensional knowledge (leading to state transitions). However, once
asserted the intensional fact CAN NEVER BECOME FALSE.

Here just one quick CLIPS example to illustrate the general problem with
truth maintenance in production rules:

(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. 

Several other problems wrt to negation in combination with retract have been
pointed out in the production rules community.

So, I see a big risk if we include negation (and other expressive
constructs) and define a normative semantics for it, unless we are totally
sure that this semantics is correct and general enough to cover all common
production rule systems and future extensions.



PS.: Negation together with retract easily leads to loops.
PS2.: For the RIF-xml media types we need to list all possible security
concerns in the spec., such as semantics external data which is transported
or execution of external procedural code, etc.
PS3.: To overcome the above problem of truth maintenance 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.

-----Ursprüngliche Nachricht-----
Von: [] Im
Auftrag von Christian de Sainte Marie
Gesendet: Dienstag, 17. Juni 2008 13:28
An: Adrian Paschke
Cc: 'RIF WG'
Betreff: Re: AW: [RIF] section 6 - compatibility with RIF-BLD complete -
Review PRD



Thanx for the comments. Discussion inlined, below.

Adrian Paschke wrote:
> In my opinion several of the expressive features, such as a general
> action or negation, are critical! There is no generally accepted semantics
> for these in the production rules community,

This is, indeed, something you mentionned already: can you elaborate? I
would have said, instead, that negation (in the condition) is pretty
much the same in most PR systems: can you point to differences? At
least, there is one kind of negation (close to the inflationary
semantics in logic dialects) that is pretty much universal, isn't it?

> the relation to procedural
> attachments and negation in logical dialects is not completely clear, and
> have not thoroughly discussed such very expressive features in the RIF
> working group, yet.

In logical dialects, maybe; but, again, they are quite clear in PR
languages, aren't they? At least with the restriction that no
side-effect is allowed in the condition.

> They might also have many unexpected consequences, e.g.
> for future reaction rules dialects which generally support external
> What about external function calls with side-effects, if we apply for a
> + xml" MIME media type? Etc.

Interesting: I know nothing about the consequences of a MIME media type.
Can you elaborate?

Re unexpected consequences: do you have negation or execute in mind?
What kind of unexpected consequences?

> Given that we want a first PRD document soon, I would propose we do not
> include such expressive constructs in the basic PRD dialect (so nothing
> be 'wrong'): perhaps only retract+assert (and maybe: modify / update), but
> no execute and negation for now.

I would be in favour of including Modify in PRD FPWD if we can find a
syntax that works reasonably: it is probably too late at this stage.

Update, we can do without, I believe. Actually, we *should* do without:
since the semantic of whatever operation is "executed" is specified
externally, that specification can specify what has to be updated as
well, so that the engines that need to update know what they have to do
(see the discussion of update in PRR; btw, I will propose that update be
removed from PRR).

Execute? Yes, we could stay at the most basic level and remove it. What
would be the benefit? The syntax is pretty clear: it may still be
changed, but it will be a matter of style, not of substance. And the
semantics is not specified in the current draft anyway. On the other
hand, having it in the syntax tells our target audience that they will
have it for sure (as I said: if we had a reasonable syntax for modify, I
would support having modify too, at least in the syntax).

About being 'wrong': I prefer to float something where some features are
incompletely specified (e.g., assert and retract are underspecified wrt
object creation and deletion; execute has no formal semantics etc), and
may even change in depth to accomodate further extensions, than
something with too many features missing, for fear that they may have to
change. We are seeking public comments, after all: if we show them only
what we are dead sure about and that will not change, what is the benefit?

> Of course, they are needed for many
> real-word use cases, but that is also true for BLD and the reason to
> them was, that we need more time to discuss them (there are many different
> semantics) and their consequences for RIF in general.

I defended adding at least one kind of negation in BLD: I was told that
it was not possible because negation is where logic dialects start to
diverge. Good point and good reason not to have negation in BLD.

But the situation is completely different in the PR world: the semantics
of negation (in the condition) is pretty universal. So, what would be
the rationale for not including it?

> My proposal would be
> to release a basic un-critical PRD which is closely aligned with BLD as
> as possible and then directly start with a more expressive PRD dialect.

As I said at F2F10, catching the attention of the PR community is a much
higher priority than keeping pace with BLD, at this stage, in my
opinion. The two reactions to PRD I had already (beside yours and
Gary's) both complain about the restriction of attribute access to
equality (you cannot say "person.age > 30" directly), the absence of
"modify" etc. All these are features that were proposed in previous
drafts, and that we removed because "not basic enough", "we should start
as close to BLD as possible" etc.

I would strongly object to publishing a FPWD of PRD without negation:
again, we are not trying to attract the logic programming crowd; we are
trying to attract the PR crowd. If we offer them something that is too
far from what they expect, as close as it may be to BLD, the risk is
high that they will just lose interest. And never look at the 2nd draft.

So, what about *adding* some expressive feature, instead? Like, changing
the syntax of Frame to:
   <slot rif:ordered="yes">TERM TERM Const?</slot>*
where the optional third term would be the identifier, 'op', of a binary
boolean function, and the semantics would be that the accessor is (op
object.TERM_1 TERM_2)?

> - Section 1.3. 
> I really like your example – it is quite funny ;-)  That is, I do not have
> problem with this toy example style. But, I’m not sure about the audience
> PRD which we try to reach – maybe we need a more serious business rules
> example?

You are right: business people are sooo serious...


We can make up an example based on UC1, instead; or the (in)famous
shopping cart; or whatever.

On the other hand, making up an example for making up an example... Our
target audience is PR systems developers, not business people; these are
more likely to care about the structure of the rules than their content.

But, whatever... If you have a preferred example and everybody agrees, I
will change it. Jim the Hen Handler was meant for internal fun, anyway :-)

> - Section 2.1. and 2.1.3. NmNot
> Do we really want a new construct for non-monotonic not? Why not a general
> construct “Not” which is shared with the logical dialects? Of course, the
> semantics, e.g. inflationary negation, is different. But that is also true
> for different non-monotonic negations, e.g. default negation,
> negation-as-finite-failure, weak negation. This would lead to many
> specific negation constructs instead of one independent “Not”, which would
> make rule interchange possible.

If I get you correctly, you propose to use the same XML tag, <Not>, for
different kinds of negations in different dialects, right?

You say that it would make rule interchange possible, but wouldn't it
harm interoperability, instead, as well as extensibility,
backward/forward compatibility etc?

Or we could have a generic construct for negation, with an attribute to
specify which kind of negation, like:
<Not rif:style=["classical"|"naf"...>

Is that what you have in mind?

I do not have a preference. Actually, I am not have sure if I have an
opinion. And <NmNot> can definitely be changed for a better tag name, if
you have one: I used it only because I wanted one that was not
overloaded, so that the discussion can focus on the content, not the name.

> Even more important, negation in combination with retract is critical and
> makes the semantics very complicated.

Doesn't the operational semantics as it is described in section 3
account adequately for it?

I think I am missing you point: can you elaborate, please?

> - Section .2.1.1 Constant types
> The supported built-in types are / should be defined in DTB, i.e. simply
> a reference to DTB from PRD

Agreed. I did not do it yet, because the latest version of DTB I read
was specific to BLD (in the language), so that just pointing to it might
be confusing for the reader. But if DTB FPWD is neutral wrt the
dialects, of course, PRD will simply refer to DTB.

> - Section .2.1.1 Symbols with non-standard types
> In BLD, after long discussion, we excluded non-standard types (future
> dialects may introduce such a typed logic). In order to be aligned with
> the basic PRD document should disallow user-defined type systems.

BLD and PRD are different in many ways: for instance, production rule
languages, usually, have no logic functions; only built-in and
user-defined ones. So that, even the most basic PR interchange format
must allow user-defined functions.

On the other hand, I have no hard feeling about that one. I do not see
the problem in mentionning user-defined types: they do not impact the
description of the operational semantics, not at the level where it is
specified; but if there is a consensus to remove the mention, we can
just replace it with an editor's note.

I object to the "alignment with BLD" type of arguments, however:
maximising compatibility is a worthy objective; but arbitrarily removing
a feature from one dialect because that feature cannot be including as
easily in another one does not make sense to me.

> - Section Atom
> PRD does not support a slotted version for Atoms (as BLD does). However,
> many well-known production rule systems such as CLIPS derivates, Jess, …
> allow an unordered representation using slots.

Same discussion as with BLD: including named-arguments atoms in PRD will
force all the languages that do not have them to implement the feature,
whereas not including them will force all the languages that have them
to positionalize the arguments when serialising in RIF-PRD.

So, the question is: what is the respective weight of "all the
languages" on each side (and the answer may be different for logic
languages and PR languages). My understanding is that, wrt PR languages,
the balance is heavily tilted towards positional only. But I may be wrong.

What do we do?

> - Section Equal
> See discussion
> An
> oriented equality assignment is more intuitive for users/programmers.

I would have said, instead, that an oriented equality would be
confusing, as it is usually assignment that is oriented, while equality
is not. But since the content of <left> and <right> would be
interchangeable anyway (because equality is not oriented), I do not
really care.

Whichever the WG agrees on, I will leave or change in PRD (which is my
duty as editor, anyway :-)

> - Section Frame
> Example with XPath style for the keys: We could use the type attribute to
> distinguish between “rif:iri” and XPath style selection 

Or using XPointer, instead? XPointer expressions are IRI, arent't they?

ANyway, this is open for discussion.

How do we deal with that in the draft? Editor's note? I think we can
refer to ISSUE-37.

> - Section 2.2. Actions
> Execute is critical (e.g. side-effect full external function calls) and I
> would propose to remove it from the basic PRD dialect. 
> We also would need a general execute construct which can be shared with
> reaction rules dialects and logical dialects which provide procedural
> attachments, e.g. reuse “External” to call external functions, including
> built-in functions. An attribute could distinguish between standard RIF
> built-in functions (defined in DTB), user-defined built-in functions and
> side-effect full procedural attachments.

Yep. If the assertion of Externals is not allowed, which is the case,
there is no ambiguity that an External in the right hand side of a PR is
an execute. If External seems to be the best way to represent procedural
attachments in the head of logical rules, then it should be the same in
PRD, for compatibility's sake.

On the other hand, I understand that the semantics of a procedural
attachment in the head of a logic rule is quite different, semantically,
from an external: e.g. the semantics of External in
External(greater-than(age(?x), age(?y))) :- Father(?x, ?y)
seems quite different from the semantics of Execute in
Execute(print(?x " is the father of "?y)) :- Father(?x, ?y)

Or isn't it?

I suggest keeping Execute for PRD FPWD, however: this is what the PR
crowd is used to. We may change it later, when we know what we will do
on the LD side, and the PR people are addicted to RIF already.

> - Section
> Some production rule systems, including hybrid rule systems which combine
> forward and backward-reasoning, allow firing actions and additionally
> deriving conclusions. We don’t distinguish between doing actions (do) and
> deriving conclusions (then). Ok, I agree such hybrid systems are not
> mainstream (but maybe they will be in the future), so we might not care
> about this in the basic PRD document.

Yes. Logical conclusion are an obvious candidate for inclusion at some
point: even if they are not the most used feature, I think that most PR
languages have them.

Maybe we can add an editor's note to that effect?

> - Section 2.5 Presentation syntax
> Whenever possible the presentation syntax should reuse the presentation
> syntax defined in DTB. In particular, rules could be written in a neutral
> from as “consequences <- conditions”. Then it would be possible to present
> business rules in an independent format, which could be either serialized
> PRD XML or in BLD XML.

As you know, I disagree on this: the presentation syntax should be
targeted towards its audience. That's quite different fro mthe XML,
where interoperability is a factor.

Whereas aligning the PS of different dialects is nice everywhere the
different users communities do it the same way or have no widely
accepted usage, the PS of each dialect must follow the widespread usage
of its target community where one exist.

PR rules are written with the condition on the left and the actions on
the right; this is widespread to the point that the condition is often
called the "left hand side" or LHS and the actions, the "right hand
side" or RHS.

Proposing something different, like "consequences <- conditions" will
just tell that crowd that we do not care about their usages (or, worse,
that we do not know them), to the risk of losing their interest.

Thanx again for the comments. Looking forward for more :-)



Received on Tuesday, 17 June 2008 14:35:53 UTC