[Fwd: Re: PRD review, part 2 Operational Semantics of Conditions]

Ooops. For some reason I sent that reply to Adrian only...


Forwarded message 1

  • From: Christian de Sainte Marie <csma@ilog.fr>
  • Date: Tue, 19 Feb 2008 14:36:43 +0100
  • Subject: Re: PRD review, part 2 Operational Semantics of Conditions
  • To: Adrian Paschke <adrian.paschke@biotec.tu-dresden.de>
  • Message-ID: <47BADB6B.3010600@ilog.fr>

More replies, comments, requests for clarification, below...

Adrian Paschke wrote:
> Here Part II, Operational Semantics of Conditions
> The definition of an operational semantics for production rules is certainly
> appealing since several reference semantics already exit in literature and
> many PR engines only discuss an operational semantics. Nevertheless, it is
> not necessarily the best way, since there have been many different
> operational semantics implemented, in particular if we also consider
> negation-as-failure and assert/retract actions - a unifying declarative
> semantics seems to be the better approach.

Not sure what you mean with "an unifying declarative semantics": do you 
have a pointer? Is it something like what I copied in the introduction 
of the first strawman?

What I tried to do, based on my first attempt and the discussion that 
followed in Boston, and on discussion in the framework of OMG PRR, is to 
  describe the intended semantics in a way that is neutral enough wrt 
the actual implementation, that PR systems that operate similarly if not 
identically can map onto it.

I am reasonably confident that the specification works basically for 
standard PR systems such as ILOG, Blaze (FIC), JBoss, Jess (basically, 
that is, the semantics may need adjustments, improvements etc, but the 
approach should work).

> Also, concerning the structure of
> the PRD draft, it would be better to define notations and basic
> terminologies first and then define a general (declarative) semantics for
> production rule systems (without NAF)m instead of a separated semantics only
> for conditions with NAF.

Yes. Gary already suggested that there should be an introductive 
description of the semantics that gives the reader a general idea before 
going into the details of each construct.

To late for the F2F, but I am working on such an introduction (too bad 
that everybody found the one I proposed in the first strawman 
confusing... But I agree that it would be even more confusing as an 
introduction to this version :-)

> To define an operational semantics as normative, i.e. to which implementers
> MUST be compliant (as stated in section 2.2.1) would mean we exclude all
> other operational semantics. That is very dangerous; then we really need to
> prove that our normative operational semantics is the most appropriate
> semantics as compared to all other operational semantics

There might be a misunderstanding, here: the purpose is not to specify 
the semantics PR systems must implement in general, but how conformant 
systems must understand RIF-PRD instances. That spec is about allowing 
compliant systems to determine how to translate rules to/from their own 
language from/to RIF-PRD in order to preserve the intended semantics, 
not about telling them how they should work.

In that sense, the semantics of RIF-PRD (like that of any RIF dialect) 
has to be normative, or no meaningful interchange would be possible.

> and we need to
> ensure that it can handle all frequently used, important cases in production
> rule systems.

Agreed. Of course, the normative semantics of RIF-PRD must be specified 
in a way that makes the translation to/from the target systems as easy 
as possible.

> Looking through the current description of the operational
> semantics for the condition part, it's not clearly defined and I already
> missing several things, e.g. with respect to equality, not, treatment of
> exceptions, variables,.

Ok. Can you be more specific?

> In short, the semantics approach for Production Rules needs a thorough
> discussion and needs to be defined e.g. to capture the non-deterministic
> nature of production rule systems in the possible course of actions. 

Right. Apart from presentation issues (obviously, a genera introduction 
is missing), how is the proposed specification, after you have read the 
semantics of rulesets, in section 4?

> 2.2.1. working memory (WM) is never explicitly mentioned only the
> abbreviation WM is introduced

Yes. This is on purpose, see reply to Gary [1]. I should have avoided 
using the abbreviation WM, which is overloaded. What about KB instead? 
It is overloaded too, but in an implementation-neutral sense.

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0088.html

> variable bindings only to constants is an oversimplification, even
> many classical production rule systems support more expressive bindings 

Same comment as, I assume?

> and the distinction between Uniterm and ExtTerm needs to be
> discussed, Uniterms could be also defined as ExTerms

This has already be discussed and resolved. See reply to in [2].

[2] http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0092.html

> What about assignments to variables via Equal? Syntactically this
> would be a minimal approach, otherwise we would need to define a new
> assignment function and give it a semantics 

You mean; in the action part? See in [2].

On afterthought, there is the case of assigning values to parameters (as 
opposed to rule variables)... I did not mention that because we do not 
have parameters associated to a ruleset in the current version, but 
having to assign them a value will be a consequence of their introduction.

Not using the Equal construct, though: my argument against it in [2] 
stands for that case too, I think.

> What does it mean in the operational semantics if we now speak of a
> frame to be true? We have not defined that before, but defined everything in
> terms of matching against ground values in the WM

You are right: this is remant of a previous attempt that I forgot to 
change. I will correct that for the frozen version.

> 2.2.5. beside aggregations and variable-constant bindings further variable
> bindings need to be supported and semantically defined

Ok. As I wrote in [2], if you can provide examples, that will help in 
that discussion.

> Part III will follow.

And replies, comments, requests for clarification regarding it too :-)


Received on Tuesday, 19 February 2008 14:14:43 UTC