Re: RIF Internal reviews

Changhai,

Thanx for the thorough review of PRD.

We implemented most of your proposed changes.

Regarding the numbered comments in the MSWord document, here are our 
answers, comments (numbers refer to your comments):

1. We removed the sentence;

2. We changed the sentence;

3, 4, 35. We added two sentences, just before the "rif:forwardChaining" 
specification, about future conflict resolution strategies possibly 
returning more than one instance, to explain why the previous section 
considers that case;

5. The sentence is a remnant of an earlier version. We replaced "as 
defined by the condition formulas that they entail, " by "represented by 
ground condition formulas".

6. Such restrictions are motivated by computational logic reasons;

7. We changed the wording;

8. The parapgraph was rewritten: "To emphasize interoperability with 
RIF-BLD, positional terms may also be written: External(t(t1 ... tn))", 
that is, without trying to explain why RIF-BLD needs to expose the fact 
that the function is externally defined;

9. done

10. We had changed that paragraph, following a comment from Harold.

11. When n is greter or equal to zero, the indices must go from 1 to n, or 
there is still one item left when n=0...

12. That notion of context will certainly be obscure for many readers, but 
it is clearly specified what the sentence means, in the following 
paragraph;

13-25. See Adrian reply [1]

[1] http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0175.html

26. We changed the organisation of the document, and made clear that the 
two specification are equivalent;

27. we rewrote the paragraph at the end of the syntactic specification, 
and we added one, slightly more detailled, at the end of the 
model-theoretic specification.

28. we added pointers to the definitions. We all agree that any individual 
can be an object identifier in a frame, including a list, right?

29. We changed the sentence

30. Not al lthe syntactic restrictions can be expressed in an XML Schema 
or BNF; and there are good reasons to separate the basic syntax from the 
well-formedness conditions; including that it makes for a more easily 
readable, more understandable and more modular specification :-) We just 
left them as they are;

31. We changed the sentence

32. We changed the sentence

33. We reformulated the definition of Group, based on Harold's comment.

34. we do not understand the comment, here, since the sentence says 
explicitely that it means no free varaibales.

36. Let's not re-start the discussion at this stage. .We had agreed on 
that ordering, last year. If somebody wants to specify other conflict 
resolution strategies, they can just do that as an extension.

37. We think that you are wrong and that the case is covered correctly: 
consider the rule

Forall ?x such that (?x # Widget)
  if Exists ?v (And ?x[property->?v] func:numeric-greater-than(?v 10))
  then Do(?v ?x[property->?v]) Modify(?x[property->func:numeric-add(?v 
1)]))

and the fact base: _w#Widget, _w[property->12]

The rule will fire once, and then it be retracted forever, although its 
condition always hold and the value of _w's property has changed.

On the other hand, the following rule will fired forever:
Forall ?x such that (?x # Widget)
  Forall ?v such that (?x[property->?v])
  if func:numeric-greater-than(?v 10)
  then Do( Modify(?x[property->func:numeric-add(?v 1)]))

Is that what you meant?

Thanx again for your many useful comments.


Christian, Gary and Adrian

----------------------------------------------------
ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10


Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430