W3C home > Mailing lists > Public > public-rif-wg@w3.org > October 2008

Re: [PRD] PRD Review By Example

From: Gary Hallmark <gary.hallmark@oracle.com>
Date: Wed, 22 Oct 2008 12:53:14 -0700
Message-ID: <48FF84AA.4030206@oracle.com>
To: Christian de Sainte Marie <csma@ilog.fr>
CC: rif WG <public-rif-wg@w3.org>

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)
(* 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.

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 
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:53 UTC