Forwarded message 1
Adrian,
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
> 2.2.2.2. variable bindings only to constants is an oversimplification, even
> many classical production rule systems support more expressive bindings
Same comment as 2.1.1.2, I assume?
> 2.2.3.1 and 2.2.3.2. 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 2.1.1.1 in [2].
[2] http://lists.w3.org/Archives/Public/public-rif-wg/2008Feb/0092.html
> 2.2.3.3. 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 2.1.2.3 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.
> 2.2.3.6. 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 :-)
Christian