Re: Review of RIF Primer

Gary,

Thank you for pointing this out. This wasn't clear to me from reading PRD.

In a later email, I'll point out the PRD passage that was unclear on this
point.

I'll work on making a new example in the next few days. (In any case, this
has missed the publication deadline for Oct., so the good news is that
this buys us a little time.)

In the meantime, I'll take out the example from the current version of the
Primer, and I will just put a note saying that an example will be
forthcoming.

Leora

On Wed, October 27, 2010 4:08 pm, Gary Hallmark wrote:
>   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
>


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

Received on Wednesday, 27 October 2010 21:15:35 UTC