Re: [PRD] PRD Review By Example

Christian de Sainte Marie wrote:
>
> Gary Hallmark wrote:
>>
>> Issue 1: We must state that all "initial facts" in the ruleset RS 
>> (here, p:A(0)) are removed from RS and become the initial working 
>> memory w<sub>0</sub>
>
> We did not specify constructs to represent initialisation yet. I do 
> not know if we need them, but, indeed, this is a question to be raised 
> and resolved. So, I suggest adding the sub-issue:
>
> Issue 1': Does PRD need constructs for ruleset initialisation? That 
> is, is that something that is commonly used enough in PR languages 
> that we choudl have it in PRD?
I'm not asking for a special PRD construct.  Note that my example 
ruleset is a Core ruleset:

Prefix(p someIRI)
p:A(0)
(* r1 *)Forall ?x (p:A(?x) :- p:A(External(func:numeric-minus(?x 1))))

Surely you agree we must handle the initial fact p:A(0)

BTW, I think we also need to handle initial object facts, e.g.
_o#p:myClass
p:myClass##p:mySuper
_o[p:mySlot->"foo"]

These should also be in Core (although this hasn't been officially 
decided).  They are needed for my XML schema to frames mapping proposal.
>
> Now, regarding that question of initial facts, all we can have in 
> terms of initialisation, in a RIF-PRD document, at this stage, are 
> ground assertions (actions) with empty (and thus always true) 
> conditions, and these should be handled just like regular rules.
We need to align with the Core syntax.  I think you are right, they can 
be handled in the semantics as rules that are always true. 
> If we want them to be fired first, it is for the conflict resolution 
> strategy (PICK) to say so.
Yes, I think my pick proposal will do the right thing. 
>
> So, my understanding of Gary's proposed Issue 1 is that it is really 
> equivalent to sub-issue 1'.
Actually, I think it boils down to defining the syntax for the initial 
facts.  As usual, I prefer maximum overlap with BLD/Core.
>
>> Issue 4: extractActions seems a bit underspecified as to how it 
>> "grounds" the actions in the rules,
>> which may have variables. Also, its argument should be a single rule 
>> instance, not a list.
>> I guess it is supposed to "plug in" the substitutions, so
>> s = {p:A(1)}
>
> Yes, the spec of extractActions is a bit light. The input is an 
> orderet set of rule instances and not a single instance, because we 
> have not decided yet if PICK returns always a single instance, or 
> whether there are case where it returns a list. So, I suggest 
> splitting the issue in two:
My engine fires a single rule at a time.  I don't know of any that work 
differently.  It complicates the spec.  Why can't we decide this?
>
> Issue 4: extractActions needs be specified more completely.
>
> Issue 4': does PICK always return a single rule instance? That is, is 
> it useful to have PRD prepared to handle conflict resolution 
> strategies that select more than one rule instance to be fired?
>
>
>> Issue 5: And(...) is undefined. We must define the PS before the 
>> semantics if we use the PS in the semantics.
>
> I do not understand: "And" is defined in the section about conditions. 
> It is used there in about the same way as above; and so it is in BLD 
> and FLD etc: what is it that makes its use in the spec of the 
> transition relation an issue, specifically?
Sorry, after re-reading it is fine.
>
>> Also, this And takes a set as its first argument. I'll replace the 
>> set with its member:
>
> Right, some sloppiness in the spec, indeed.
>
>> ({p:A(0)}, p:A(1), w') →RIF-PRD if and only if, for every ground 
>> formula φ in W,
>> w' |= φ if and only if And(p:A(0) p:A(1)) |= φ
>>
>> w' = {p:A(0) p:A(1)}
>>
>> Note: w' is not uniquely determined. E.g. w' = {And(1=1 p:A(0) 
>> p:A(1))} is ok, too. I guess this is fine.
>
> I do not understand why it is not uniquely determined? Either 1=1 is 
> something that is entailed by And(p:A(0) p:A(1)) or it is not. If it 
> is entailed, it is in w', if it is not entailed, it is not in w'. 
> Isn't that correct?
I just meant it doesn't seem to matter whether 1=1 in in w'.  Or whether 
p:A(0+0) is also in w'.  I guess you could say it is unique modulo 
entailment.
>
> Of course, w is not only p:A(0) and p:A(1): it also contains all the 
> ground tautologies that follow from the specification of the condition 
> language, and all the ground facts that follow from the definition of 
> the data types, builtins and, generally, all the external knowledge.
That's not at all clear.  I find no need for w to be any more or less 
than what I wrote in my Review Example.
>
> So, it is really And(w, f), T |= phi, where T represents any addtional 
> theory that is used by the system (including, typically, the 
> classification theory that is provided by an object model).
>
> You did not want such additional theories to be mentionned in the spec 
> of pattern matching, in the previous version of the document. But, 
> maybe, it is now time to include it back, as we are closer to be able 
> to represent references to these theories (as XML schema, per your 
> action)?
No.  I advocate mapping a schema-valid XML document to RIF Core "initial 
facts", i.e. ground frame, membership, and subclass formulae.  I don't 
want any unspecified additional theories.

Received on Wednesday, 22 October 2008 19:55:22 UTC