Re: Review of RIF Primer

  Leora,

There's a problem with section 6.2.1 Priorities.

Priority simply orders the rule firing. It does not provide any kind of mutual exclusion. All the rules will fire, regardless of priority. The 2 examples in this section are equivalent.

In order to demonstrate priority, you must have something order-dependent in your rules.
For example, you could use a print action and see that the priority affects the order of the printouts (but not what gets printed).
That's why I combined priority and negation, because there order matters.

On 10/27/2010 7:53 AM, Leora Morgenstern wrote:
> Gary,
>
> Thank you again for your very helpful review. Below,  I explain how I
> addressed each of your comments.
>
> On Sat, September 25, 2010 3:23 pm, Gary Hallmark wrote:
>>    Overall this is well-written but neglects PRD. I have suggestions and
>> new text to set PRD on an equal footing with BLD/Core. [Suggestions in
>> square brackets.] Replacement text not in square brackets. Section
>> heading numbers are given for easier reference.
> I modified the entire document to put PRD on an equal footing with BLD.
> First, I made clear that the initial portion of the Primer dealt with Core
> as a whole, not just BLD.
> Second, I added examples, not only the examples you gave, but an example
> highlighting the importance of priorities (separate from the interaction
> with negation).
> Third, I discussed operational semantics in the Reasoning section.
> Fourth, I gave an overview of what PRD adds to Core.
>
> Plus more.
>
>> 1.0 Introduction
>> There are many declarative rule languages, ...
>> [add]
>> Jess, Drools, IBM ILog, Oracle Business Rules, etc. Note that many rules
>> languages are not purely declarative. For example, prolog provides a cut
>> operator and production rule languages provide action with side-effects.
>> However, all these rule languages have a core subset that is declarative.
> I got this content in, though I modified the wording to some degree.
>> This document focuses on the Basic Logic Dialect [RIF-BLD]
>> [change to]
>> This document focuses on the Core Logic Dialect [RIF-Core], a common
>> subset of the Basic Logic Dialect [RIF-BLD] and the Production Rule
>> Dialect [RIF-PRD]. A few of the features specific to BLD and to PRD are
>> also considered.
> Content in doc, wording is changed.
>> 1.1
>> [change to]
>> This document focuses on the RIF Core dialect and on the commonly used
>> built-in functions and datatypes described in DTB. Existing RIF dialects
>> [BLD] and [PRD] are also briefly considered. This document does not
>> discuss [FLD].
>>
>> This document does not include any discussion of the model-theoretic or
>> operational semantics of any of the dialects of RIF. An intuitive
>> understanding of the notions of pattern matching, assumption and
>> consequence ought to be sufficient to understand the Primer and to
>> enable a computer scientist to write rules in RIF. The reader who is
>> interested in learning more about the model-theoretic semantics of
>> RIF-BLD is encouraged to read the BLD document [BLD]. The reader who is
>> interested in learning more about the operational semantics of RIF-PRD
>> is encouraged to read the PRD document [PRD].
> I added a bit more than that, and have some discussion of operational
> semantics.
>
>> This Primer is targeted at getting computer scientists to quickly learn
>> how to write rules in RIF, but not necessarily to cover all aspects of
>> syntax. As a result, there may be some details of RIF syntax,
>> specifically, those that are not necessary for writing most rules in
>> RIF, which are not covered in this document. All details of syntax are
>> covered in RIF-BLD and RIF-PRD.
>>
>> 2.1
>> [please use a more readable convention (consistently throughout)  for
>> multi-word symbols. I suggest "-" separating the words. E.g. plays-role,
>> role-in-film, Vivien-Leigh, Blanche-Dubois, etc.]
> I followed Mike Dean's suggestions, and switched to camelcase.
>> 2.2.3
>> [There is no need to introduce "Convenience Syntax". Use RIF-PRD
>> presentation syntax, which also uses If/Then instead of :- ]
> I introduced Mixed Presentation Syntax, which essentially does what
> everyone wants, but doesn't sound as weird and overblown as Convenience
> Syntax.
>
>> Throughout this document we will use RIF-PRD Presentation Syntax in
>> which this implication is written almost unchanged in mixfix notation
>>
>> If A Then B.
>>
>> Note that in RIF-BLD Presentation Syntax [RIF-BLD] --- this is written
>> in infix notation as B :- A, where the antecedent A and consequent B are
>> reversed, but the implication expresses the exact same meaning.
>>
>> 2.2.4
>> [Need to globally replace "RIF Convenience Syntax" with RIF-PRD
>> Presentation Syntax and replace "RIF Presentation Syntax" with RIF-BLD
>> Presentation Syntax. In general, search for "Convenience Syntax" and
>> change each based on surrounding context.]
> Changed to Mixed Presentation Syntax, as explained above.
>> 2.2.6
>> [following is misleading because it is not valid BLD or PRD syntax:]
>> This is semantically equivalent to the rule And(Rule1 Rule2)
>>
>> 2.3
>> [change to]
>> it is now possible to write the complete Basic Combination Rule in RIF
>> PRD:
>>
> This is now presented as being in Core, as previously explained.
>> 4.
>> [change/add]
>> The precise conditions that allow one to draw a conclusion from a set of
>> rules and facts in RIF is discussed in great detail in [RIF-BLD] and
>> [RIF-PRD], which give a model-theoretic semantics and an operational
>> semantics, respecively, for inference in RIF. A full discussion of
>> model-theoretic and operational semantics is beyond the scope of this
>> Primer.
> Discussion of semantics expanded.
>> 5.1
>> [retitle this section]
>> BLD Extensions to RIF Core: Functions and Equality
>> [In this section we use BLD Presentation Syntax, i.e. ":-" rather than
>> If/Then]
> Fixed
>> [insert a new section between 5.1 and 5.2]
> Done
>
>
> For the example below: I didn't want to conflate issues of negation and
> priority, so I added an extra example, and also added discussion of the
> examples.
>
>
>> 5.2 PRD Extensions to RIF Core: Negation, Priority, and Modification
>> So far, rule conditions have been positiive. RIF-PRD adds negation to
>> rule conditions. For example, the following rule set computes awardless
>> film actors:
>> [in an example box]
>> Document(
>>     Prefix(rdfs<http://www.w3.org/2000/01/rdf-schema#>)
>>     Prefix(imdbrel<http://example.com/imdbrelations#>)
>>     Prefix(dbpedia<http://dbpedia.org/ontology/>)
>>
>>    Group( 2
>>      Forall ?Actor ?Film ?Role (
>>        If   And(imdbrel:plays-role(?Actor ?Role)
>> imdbrel:role-in-film(?Role ?Film))
>>        Then dbpedia:starring(?Film ?Actor)
>>      )
>>    )
>>
>>     Group( 1
>>       Forall ?Actor (
>>         If   Not(Exists ?Film ( And(
>>                     dbpedia:starring(?Actor ?Film)
>>                     imdbrel:win-award(?Actor ?Film)) ))
>>         Then dbpedia:awardless-film-actor(?Actor)
>>       )
>>     )
>> )
>>
>> The numbers 1 and 2 associated with each group are priorities.
>> According to the operational semantics of PRD, rule groups are evaluated
>> in order of descending priority. Priorities are important here to ensure
>> that the dbpedia:starring relation is computed before the
>> dbpedia:awardless-film-actor relation is computed.
>>
>> RIF-PRD also allows rule actions to modify facts, as discussed later in
>> section 6.2.
>>
>> 5.2 Datatypes and Builtins
>> [either change to 5.3, or better, because DTB is in Core, move out of
>> Section 5 so that section 5 contains only extensions to Core (i.e. BLD
>> and PRD)]
> Yes, I reorganized.
>> 6.2
>> [The RIF example is invalid. ex:e1 # ex:Example[ex:a ->  1] is not legal
>> syntax.]
>>
>> [change/add]
>> This is a direct consequence of the fact that RIF-Core has the semantics
>> of first-order logic.
>>
>> Object-oriented languages, on the other hand, have the semantics of
>> programming languages. The slot a is therefore understood as a variable
>> which can be overwritten.
>> RIF-PRD has a modify action with operational semantics that can
>> overwrite slot values. For example,
>> [example box]
>> Document(
>>    Prefix(ex<http://example.com/exampleconcepts#>)
>>    Group (
>>      Do (
>>        (?e1 new())
>>        Assert(?e1 # ex:Example)
>>        Assert(?e1[ex:a ->  1])
>>        Modify(?e1[ex:a ->  2])
>>      ))
>> )
>>
>> At the end of the action block (identified using the keyword "Do"), the
>> slot a has the value 2.
> Fixed.
>
>> 9
>> This design criterion led the designers of RIF Core, BLD, and PRD to
>> make choices that maximize the number of rules systems that can
>> effectively interchange rules through RIF, often at the expense of
>> expressiveness. The absence of negation in Core and BLD, for example, is
>> clear in the standard RIF logic dialects (Core, BLD), and this design
>> choice in BLD was made because different rule systems implement negation
>> in so many different ways, selecting a specific semantics for negation
>> in BLD would have prevented interchange between all the languages that
>> used a different semantics. Production rule systems, on the other hand,
>> typically use the same kind of negation semantics, called inflationary
>> negation. PRD presentation syntax provides an alternate keyword, INeg,
>> that may be used instead of Not to explicitly indicate that inflationary
>> negation is being used.
>>
>>
> I deleted this entire section, on Sandro's advice. Will move to FAQ
>
> Thanks again!
>
> Leora