Re: [PRD] Issues to resolve before publication (et proposed resolutions)

Christian de Sainte Marie wrote:
> #1. Section 1.1: Introduction. I propose that we keep that section as it
> is in the current version, except for typos and blatantly bad english. 
I still object to this section because it introduces 2 presentation 
syntaxes but one is never fully defined.
This document needs to be split into a specification and a tutorial, but 
we can do that after FPWD.
> I
> added an editor's note about the presentation syntax and will open the
> corresponding issue. (Gary, could you check that I got the PS right in
> example 1.2, please?)
PRD does not support logic functions so your example won't work.  I 
changed it.
> #2. Section 1.3: Running example. I propose that we keep it as in the
> current version. I added a paragraph at the end of the section to clarify
> some of the assumptions (per [4]):
In your new informal PS, the repeated use of the term "which" is awkward 
(but then, so is the notion of a second PS)
> "The assumption is that a system that consumes a RIF
> document published by Jim knows how to map Jim's published data model
> and specification of fact predicates and functions to/from its own
> underlying data representation. What a consumer is expected to do when
> this is not the case is still under discussion and will be specified as
> a conformance clause in a future version of this document."
The semantics of Execute doesn't make sense because it does not follow 
from the syntax.  There is no way to derive Eval(f,w) from f, the name 
of the external function, and w, the current state.  For this to work, 
you'd have to add syntax so users can define their own external 
functions and then you'd have to define Eval(f,w) in terms of the syntax 
of f.

Assuming we don't want to define an external function definition 
language, a better option is to insist that w=Eval(f,w), i.e. that 
Execute does not change the KB.
> #3. Section Non-standard data types in the spec of Const.
> Proposal: keep as in the current version. As proposed in [2]:
>  * I removed the second sentence (from "They can also..." to the end 
> of the alinea) from the first alinea of the paragraph about symbols 
> with non-standard types, as well as the following alinea;
>  * I changed the last alinea to start with "Dialects and applications
> that extend...";
>  * I added the editor's note.
jim:today is not a valid xml serialization. 
> As a consequence, I also removed the example 2.1.e (but I would still
> like to understand your comment in [3], Gary).
my point is that we don't have any support for user-defined datatypes 
and it's not necessary for the example, so it should be removed.
> #4. Sections (External) and (Atom): Named Arguments
> Uniterm (NAU). I really believe that we should not have them in PRD. But
> I understand that others think we should. I propose that we decide by
> simple majority vote, between the following two options (for FPWD only,
> and we open an issue to keep the discussion open):
>  1. No NAU (in FPWD), that is, leave the draft as it is (in the current
> draft, I commented out the NAU in the PS, as this was easier to do that
> to add them in the XML syntax etc);
>  2. NAU in FPWD, with an editor's note asking for feedback (if this is
> the majority decision, I will uncomment the NAU in the PS, and add them
> in the XML syntax).
We should be consistent with BLD on this point.  Simply support them, 
and no editor's note!
I think having a case-by-case ad hoc voting strategy for a spec is not a 
good idea.  I think we need to
establish an architectural principle that PRD should not deviate from 
BLD without very strong technical arguments.
What would those arguments be in this case?
> #5. Section (NmNot): tag name? I do not care, but we must choose
> one. I see two options, here again, and I propose, again, that we decide
> by a simple majority vote:
>  1. Keep NmNot, pr PRnot, or whatever other name that is not overloaded
> (but rather meaningless, as a consequence);
>  2. Change for Not.
> In any case, add an editor's note that name may change (I added one in 
> the current draft).
> #6. Section 2.2 (Actions): Assign or not Assign in FPWD? I propose to 
> keep it, now that it has been re-included with Ed: Adrian wants it, Mark
> wants it, I am rather in favor, Gary balances. I added an editor's 
> note in section (Assign) to the effect that this was still 
> under discussion and that the syntax was liable to evolve.
> Gary, I see that you changed the examples: I did not check exactly 
> how, but if we agree on the above solution, you will have to revert 
> that change, right?
No, I will not revert the change because the syntax that was there did 
not work.  Because, as you say, the semantics of assign is exactly the 
semantics of retract+assert, and we have no better syntax than 
retract+assert, one wonders why we want an assign action.  If someone 
has a better syntax than retract+assert, then please propose it.
> #7. Section 2.3.1 (Rule): Adrian added ATOMIC as a form of RULE, to 
> allow a RULE to be used to represent facts. However, a production rule 
> without a condition is not a fact: it is an unconditional action. I
what are you talking about?  PRD and BLD both need ground facts, and 
both should use the same syntax (ATOMIC) to express it.
> propose to revert to the previous version, as in [1], where the "if"
> part can be omitted (meaning ture by default) , to represent rules where
> the action part is intended to be executed for all the bindings of the
> varaibles.
No. This is an unjustified deviation from BLD.
> #8. Section (Forall): Gary does not want the CMP example to be 
> presented with binding patterns. On the other hand, they are included 
> in this version of RIF-PRD because all the mainstream PR languages use 
> them, and there is an editr's note asking for feedback about them and 
> the nested forall: so, providing an example makes sense.
I want binding patterns to go away.  They are trivially converted to the 
BLD format and though they may have their place in legacy PR languages, 
they have no place in RIF.  I don't want any new material added to the 
spec that mentions these.  I want them all gone eventually, even if I 
can't have that for FPWD.
> I propose that we include a small example with patterns, and that the 
> XML rendering of the complete CMP rule be moved to an appendix, where 
> it can be serialized without patterns nor nested Forall, as Gary 
> prefers, with a comment to the  effect that the serialization of a 
> rule is not unique, and that that specific serialization correspond to 
> the PS rendering as stated in 1.3 and 2.5.
> #9. Section 3.3 (Operational semantics of actions):
>  a. Semantics of Assign. I added a transition that defines the 
> semantics of Assign, basically as a set of Retracts followed by an 
> Assert; and I added an editor's note warning that this was unstable;
>  b. Semantics of Execute. I added an example, as suggested by Gary.
> Proposed: leave it as in the current draft.
I think we should get rid of assign, unless someone has a great notation 
for it that makes it easier than retract+assert.

As I mentioned above, the Execute semantics don't seem to work. 
> #10. Section 3.4.1: matching theory. As I explain in [2], it is needed 
> to take the semantics of datatypes into account. That is mentionned in 
> an editor's note only, out of laziness rather than anything else (and 
> also because it relates to the question of application-specific 
> background 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).
> I propose that we go by option 1 for the FPWD.
I wouldn't even talk about application-specific theories until we first 
have defined what matching means for the datatypes and builtins in DTB.
> #11. Section 3.4.2 (PICK) and (fireableINSTANCES): No-repeat. 
> I have not looked at that one yet. I will propose a, hopefully 
> consensual, solution by Monday night (my time).
> If we could agree that these 11 question are the only ones we want to 
> deal with before FPWD, and, further, if we could agree on the proposed 
> solutions or some variation of them, and if we could do that by email 
> before the telecon Tuesday, then, we can essentially freeze PRD for 
> FPWD on Tuesday!
I think we may first need a meta-agreement that we need to make PRD have 
the same "look and feel" as, and of course maximally reuse, BLD/FLD and 
DTB.  Extended examples, tutorials, etc. should go in a separate document.
> Cheers,
> Christian

Received on Monday, 30 June 2008 01:19:27 UTC