W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

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

From: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
Date: Mon, 16 Jun 2008 17:33:17 +0200
To: "'Christian de Sainte Marie'" <csma@ilog.fr>, "'RIF WG'" <public-rif-wg@w3.org>
Message-Id: <20080616153305.B50A370000E2@mailserver.biotec.tu-dresden.de>

Hello Christian,

Thanks, I will take a look at the new compatibility section and the extended
operational semantics. 

I already looked at the reworked PRD syntax (see my comments below). 

In my opinion several of the expressive features, such as a general execute
action or negation, are critical! There is no generally accepted semantics
for these in the production rules community, the relation to procedural
attachments and negation in logical dialects is not completely clear, and we
have not thoroughly discussed such very expressive features in the RIF
working group, yet. They might also have many unexpected consequences, e.g.
for future reaction rules dialects which generally support external actions.
What about external function calls with side-effects, if we apply for a "rif
+ xml" MIME media type? Etc.

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 can
be 'wrong'): perhaps only retract+assert (and maybe: modify / update), but
no execute and negation for now. Of course, they are needed for many
real-word use cases, but that is also true for BLD and the reason to exclude
them was, that we need more time to discuss them (there are many different
semantics) and their consequences for RIF in general. My proposal would be
to release a basic un-critical PRD which is closely aligned with BLD as soon
as possible and then directly start with a more expressive PRD dialect.

Cheers, Adrian

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

- 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 different
specific negation constructs instead of one independent “Not”, which would
make rule interchange possible.

Even more important, negation in combination with retract is critical and
makes the semantics very complicated. I would propose to remove it from the
basic PRD dialect – similar to BLD which does not support negation for the
same reason (although it is very useful and needed to adequately formalize
many real-world use cases).

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

- 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 BLD,
the basic PRD document should disallow user-defined type systems.

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

- Section Equal
See discussion
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0046.html. An
oriented equality assignment is more intuitive for users/programmers.

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

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

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

- 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 in

-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im
Auftrag von Christian de Sainte Marie
Gesendet: Montag, 16. Juni 2008 13:03
Betreff: [RIF] section 6 - compatibility with RIF-BLD complete

All (and, in particular, Gary and Adrian),

I have completed the appendix about the compatibility between PRD and 
BLD [1] : I added a comparison table with all constructs in either PRD 
or BLD, with their PS and XML and a short section about the semantic 
compatibility, essentially saying that, when a doc is the same in PRd 
and BLD, then it means the same according to both dialects.

*Harold*, re garding the syntax, I did not add entries for 'Prefix' nor 
'Base' in the comparison table, because there is no such entries in the 
PS2XML translation table in BLD 4.3.2 (and I was too lazy to check in 
the XML schema)...

I will complete the comparison table as soons as the translation table 
is completed. Btw, maybe I should add an editor's note in the appendix, 
to warn, once again, that all this may change as PRD evolves?



Received on Monday, 16 June 2008 15:33:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC