Forwarded message 1
Gary Hallmark wrote:
>
> Overall, I like the edits. I really would like to see the use of the
> extended Forall minimized (i.e. please remove it from the running
> example -- it is not motivated at all and really detracts from the
> message that we are very similar to BLD!)
The running example has been rewritten to make it less conspicuous: our
ta**** ******ce will see it if they use, they wont if they dont.
But, of course, I still do not agree that we should send the message
that PRD is very similar to BLD (just in case somebody missed it: the
message I think we should send is that BLD and PRD interoperate
transparently wherever their semantics agree).
> 1.1
> awkard:
> Production rules are rules where the part that describes the consequence
> of condition being satisfied specifies actions rather than logical
> statements.
> suggested:
> Production rules, like logic rules [RIF-BLD], have an "if" part and a
> "then" part. Production rules can contain actions in the "then" part
> that can modify the knowledge base.
Not just modification in the KB. What about:
"Production rules are rules: like logic rules (as covered by RIF-BLD),
they have a condition, the "if" part, and a conclusion, the "then" part;
unlike logic rules, where the conclusion is a logical statement, the
"then" part contain actions, that can have side effects other than
modifying the knowledge base."
> 1.2.1
> confusing:
> The compact URI notation is not part of the RIF-PRD syntax.
> why I'm confused: it is part of RIF-BLD presentation syntax
That sentence was copied from RIF-BLD.
> 1.2.2
> plural?: as a pseudo-schemas
Corrected
> 1.3
> I worry that this example is "too hard" to give a complete semantics for.
Many real-world rules depend on external data source that are seen as
balcboxes: that was the idea of the "fox sensor"...
> 2.1.1.1
> confusing: symbols with non-standard types
> why I'm confused: this seems to be talking about conformance and should
> be reconciled with BLD conformance which
> speaks of a "strict mode" which almost contradicts what is said here.
Yes, it might contradict the "strict mode" conformance clause in BLD.
But the conformance clauses of PRD might differ for BLD.
The question of exogeneous datatype may have different implications for
BLD and PRD.
How do we deal with it in FPWD? Editor's note? Something in the tune of:
"The case of non-standard data types, that is, of constants that do not
belong or cannot be cast in one of RIF builtin types for interchange
purposes, is still under discussion in the WG. The WG seeks feedback on
whether they should be allowed and why."?
> 2.1.1.1.e
> confusing: type="jim:DayOfTheWeek"
> Let's not claim we have a solution for this yet. Maybe we need to
> introduce some kind of "enum" type. Or, maybe we
> need disjuncts in rule heads and we can axiomitize this:
> if ?x # jim:DayOfTheWeek then ?x = "Monday" or ?x = "Tuesday" or ...
I do not understand the comment: can you clarify, please? This is an
example. It assumes that Jim specified a datatype DayOfTheWeek and taht
Tuesday belongs to that datatype.
However, if we remove the paragraph about non-standard data types, that
example will be removed too, anyway.
> 2.1.2.2
> how does one comply with: order of the side elements "must not be
> preserved"? That is a bizarre requirement...
Yes, it might my command of the english language. It was supposed to
mean that, contrary to the arguments inan Atom, the arguments in an
Equal are interchangeable.
I removed that proposition that is not needed anymore (we have
rif:ordered, and the roles names may change to left+right anyway).
> 2.3.1.2
> as everyone knows, I don't really care much for the pattern FORMULA. I
> would be agreeable to consider moving this to an extended Group element
> for WD2. I prefer putting it on Group because there are good use cases
> for when a group of rules share a common set of conditions -- e.g. in a
> Decision table.
> But can we remove this from WD1 to eliminate some confusion? It just
> makes no sense to arbitrarily split up the conditions for a single rule.
It makes sense from an usage point of view.
(Target audience! Taget audience! Target audience!)
> 2.4.3.
> Need to indicate that the <And> can have 0 or more Frame children.
Right. I corrected that.
> 3.2
> Definition (ruleset instance):
> first bullet has trailing </sub>;
Corrected.
> 3.3
> Can you give an example for Eval? maybe for Eval(jim:mash)
What about:
> 3.4.1.
> Can we get rid of the "matching theory T" until we can better define
> it? Just say x << w means x matches w.
But it is needed to take the semantics of datatypes into account; and it
is taken from the reference definition (in CIR04). I did not detail that
and mentionned it in an editor's note only, out of laziness rather than
anything else (and also because it relates to the question of
application-specific abckground knowledge).
Options:
1. keep the editor's note as it is;
2. add a paragraph in the text re how it takes into account the
semantics of data types etc, and leave an editor's note saying that this
might be extended to take application-specific theories into account
(such as app-specific object models etc).
> the formatting for the spec of InstantiateRULE(w, r) could be improved.
> List item #6 looks extraneous.
Item 6 takes into account the case where the condition is omitted (and,
thus, true by default).
Regarding the formatting: yes, if I could align the arrows, that would
be better. Any idea how I can do that, anybody?
> 3.4.2.
> No-repetition: "unless the instantiation environment has significantly"
> will be hard to pin down. The ILOG notion of refraction is quite
> different from the no-repeat notion in OBR and Jess.
My mistake, then: I misunderstood you.
> In OBR the
> strategy is per-rule or per-group and it means "nothing this rules
> actions do can directly refire the rule" although rule A can trigger
> rule B that can trigger rule A, etc.
I do not get it: can you give me an example?
> The way to prevent that in OBR is
> to put rules A and B in the same group and designate the group as
> no-repeat.
So, that is not a default strategy, right?
What do you suggest: adding an editor's note saying that the semantics
of no-repetition is still under discussion and that feedback is welcome
coould help us understand better what is really needed.
Tanx again for the comments.
Christian