(Another, partial): Review of RIF Primer

Leora: a few other comments on your (nice, by the way!) primer per
http://www.w3.org/2005/rules/wiki/Primer :

1.1 What is a rule
I think the differentiation between logic rules as "declarative" versus
production rules is incorrect. Production rules are also generally
considered declarative (there is no assumed ordering in execution of the
rules) although the action parts are (usually) procedural. Of course
this is a semantic difficulty: production rules are also "logical", etc.
Perhaps the differentiator is "logic" and "production" - defining facts
across time vs at a point in time? I note you cover this further in 1.2
with the comment "all production rule languages have a core subset that
is declarative".

1.4 A note on syntax
You introduce MPS at the end of the section... but don't explain what it
is (probably an example would suffice).

2.2.1 Atomic facts
Given the primer intent ("to introduce computer professionals to basic
techniques for writing declarative rules and production rules") would it
not also make sense to provide the object model equivalents to these (or
XML document equivalents)? For example: 

    * the nullary (0-argument) predicate application itRains() could
stand for the proposition it rains; this could be a represented in a
program by some Boolean property on some object eg localWeather.itRains
= true.
    * the unary (1-argument) predicate application rapidStrepPos(John)
could stand for the proposition John's rapid-strep test is positive;
this could be represented in program by a valued property of some object
or array eg patient.symptom[1] = "rapidStrepPos"
    * the binary (2-argument) predicate application
playsRole(VivienLeigh BlancheDubois) could stand for the proposition
Vivien Leigh played the role of Blanche DuBois; this could be
represented in a program by some other property relation such as
film.actor[1] = "Vivien Leigh" and film.role[1] = "Blanche Dubois".

Alternatively the "IT version" could be just made as a note at the end
of the section, ie that there are multiple mappings of such facts to
atomic formulae, and even more mappings to typical IT data and object
representations, which have implications for rule representations as we
shall see...

2.2.3
Just for completeness it might be nice to add the example of RIF PS at
the end to compare with your MPS like you do in the end of 2.2.4 eg
thirdatom :- firstatom, secondatom

2.2/2.2.5
In 2.2.5 you reference BCR-v0.1. Might be worth introducing this
abbreviation back in 2.2 where you define Basic Combination Rule
(assuming I'm reading correctly what BCR stands for!).

2.2.5
Is it worth also explaining in this section how the IRIs relate to
object/data constructs the computer professional will be likely more
familiar with? I guess this might be difficult without lots of
convolutions.

2.2.6
Might be worth a comment that these are the main organisation features
for rules in RIF. In other words I don't have any inclusion or reference
constructs (probably not needed in BLD, and there are plenty of
workaround for the PRD world).

I'll try and finish some more reviewing later :)

Cheers

-----Original Message-----
From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
On Behalf Of Leora Morgenstern
Sent: 27 October 2010 22:15
To: Gary Hallmark
Cc: Leora Morgenstern; RIF WG
Subject: 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 Thursday, 28 October 2010 15:03:11 UTC