- From: Gary Hallmark <gary.hallmark@oracle.com>
- Date: Wed, 27 Oct 2010 13:12:05 -0700
- To: Leora Morgenstern <leora@cs.nyu.edu>
- CC: RIF WG <public-rif-wg@w3.org>
- Message-ID: <4CC88795.1090605@oracle.com>
Also, the examples have 2 "IF" clauses nested in a single "Forall" clause. Each "IF" needs its own containing "Forall". On 10/27/2010 1: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
Received on Wednesday, 27 October 2010 20:12:00 UTC