- From: Gary Hallmark <gary.hallmark@oracle.com>
- Date: Wed, 22 Oct 2008 12:53:14 -0700
- 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) 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