Re: Review of RIF Primer

Thank you, Gary.

I'll address some of your comments in this email, and others later tomorrow.

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.

Thanks for the suggestions for new text, as well as the example specific
to PRD. (Later in your review, the computation of awardless actors.) In
fact, upon rereading the Primer, I realized I'd also have to rework the
first few paragraphs of the intro, since if PRD is discussed, the current
discussion of declarative rules contrasted with instructions is misplaced.
>
> 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.
>
> 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.
>
> 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].
>
> 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.]
>

That's fine with me.

> 2.2.3
> [There is no need to introduce "Convenience Syntax". Use RIF-PRD
> presentation syntax, which also uses If/Then instead of :- ]

But the fact is that much of the Primer is in Core / BLD, and the
Presentation Syntax there is not If Then. I will reword to explain that
Convenience Syntax is identical to Presentation Syntax for PRD, but
replaces the :- construct with the If Then construct for BLD.

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

> 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.
>
> 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]
>
> [insert a new section between 5.1 and 5.2]
> 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, a slight re-organization will clarify the structure

>
> 6.2
> [The RIF example is invalid. ex:e1 # ex:Example[ex:a -> 1] is not legal
> syntax.]

I'll check and fix.

>
> [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.
>
> 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'll address your other points in a later email.

-- 
Leora Morgenstern, Ph.D.
http://www-formal.stanford.edu/leora

Received on Sunday, 26 September 2010 16:26:48 UTC