Re: (Another, partial): Review of RIF Primer

Paul,

Thanks very much for these comments and suggestions. I will add these to
my to-do list, and hopefully get a new draft out within the week.

I'll email you as questions on your specific points if I have any further
questions.

Thanks again,
Leora

On Thu, October 28, 2010 11:02 am, Paul Vincent wrote:
> 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
>
>
>
>
>


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

Received on Thursday, 28 October 2010 21:41:25 UTC