Price Discounting - W3C RIF-WG Wiki

This is one of the possible Use Cases.

1. Abstract

This is a short use case about price discounting policies in e-commerce. (By BenjaminGrosof)

It illustrates the reusability of such info across multiple tasks in e-contracting, including advertising, contract formation, and contract performance. It also illustrates the usefulness of being able to represent prioritized default rules in the manner of the Courteous extension of declarative logic programs.

2. Status

This use case is submitted by BenjaminGrosof.

It is still undergoing some editing.

This example is taken from the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof, Chitravanu Neogy, and Shashidhara Ganjugunte, available at: http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html .

The description here is modified to be closer to the requested use case template for RIF, but the rules are unmodified.

The example first appeared in this form in the SWSF design report

-> Application Scenarios document
- -> section on Policy Rules for E-Commerce.

(http://www.daml.org/services/swsf/1.0/ -> ...). Earlier similar versions appeared in an EC-99 conference paper, the SweetRules V2+ download examples, and the IBM CommonRules V1+ download examples.

A substantially longer version of a similar example appeared in the 1999 paper "DIPLOMAT: Compiling Prioritized Default Rules Into Ordinary Logic Programs, for Electronic Commerce Applications (Extended Abstract of Intelligent Systems Demonstration)", at http://ebusiness.mit.edu/bgrosof/#cr-ec-demo-rr-99b.

The rules are given in the RuleML/SWSL presentation syntax. A primer on that syntax is given below as an appended section, is also in the above paper, and full details about it are in the above SWSF design report.

Implementation:

This example has been implemented in SweetRules V2 (and in earlier form, in IBM CommonRules).

Frequency/importance in real world:

This is a very common and important kind of policy in real-world commerce, both electronic and non-electronic.

3. Benefits of Interchange

The buyer and seller can communicate in a precise, informative, and automated fashion, about an important aspect of e-selling/e-procurement: refund policies.
They can use different rule engines/languages. E.g., a production rules systems or Prolog systems.
The refund policy rules are reusable across multiple tasks in e-contracting, including: advertising, contract formation, and contract performance/monitoring.
The buyer can reason automatically with the policy rules as part of evaluating the prospective value of the proposed deal. The buyer can avoid having to have human(s) read the policies in natural language text and then integrate that understanding into procurement/purchasing decision-making.

Which Rule Systems Supported:

The Courteous LP feature is supported in RuleML/SWSL, SweetRules, and IBM CommonRules (and its BRML). SweetRules implements it on top of / in Jess production rules and/or XSB Prolog rules, by i.e., by translating to and from those via a "courteous compiler" component.

SweetRules includes an open source such courteous compiler component.

4. Requirements on the RIF

The use case shows the desirability of declarative prioritized defaults in the manner of Courteous Logic Programs. The advantages include modularity to add new rules, e.g., that represent special cases / exceptions.
The prioritized defaults here involve in particular an integrity constraint that one should conclude at most one value of the discount percentage for a given item.

5. Breakdown

5.1. Actors and their Goals

A seller/merchant wants to share rules about price discounting policies with a set of prospective buyers/customers. The buyer and seller can be using different rule engines/languages. These same rules can be used in advertising and also in contract proposals, agreed-upon contracts, as well as possibly other aspects of contract performance/execution (such as checking actual vs. expected amount of payment).

5.2. Main Sequence

This is typical example of a set of policy rules that specify personalized price discounting in an e-bookstore. These rules are useful in advertising, and also as part of a contract (proposed or final).

The policy rules specify that by default, a shopper gets no discount (i.e., gets a zero percent discount). However, there are some particular circumstances which do warrant a discount. Loyal purchasers get a five percent discount. Members of the Platinum Club get a ten percent discount. However, customers who have been late in making payments during the last year get no discount. Also there is a mutex (integrity constraint) rule which specifies that it is a contradiction to conclude two different values of the discount percentage for the same customer, i.e., that the discount percentage should be unique.

/* price discounting policy rules */

{ordinary} giveDiscount(percent00,?Cust) :- shopper(?Cust).

{loyal} giveDiscount(percent05,?Cust) :- shopper(?Cust) and loyalPurchaser(?Cust).

{platinum} giveDiscount(percent10,?Cust) :- shopper(?Cust) and member(?Cust,platinumClub).

{slowPayer} giveDiscount(percent00,?Cust) :- slowToPay(?Cust,last1year).

overrides(loyal,ordinary).

overrides(platinum,loyal). overrides(platinum,ordinary).

overrides(slowPayer,loyal). overrides(slowPayer,platinum).

!- giveDiscount(?X,?Cust) and giveDiscount(?Y,?Cust) | notEquals(?X,?Y).

/* some "case" facts about particular customers ann, cal, kim, and peg. */

shopper(ann).

shopper(cal). loyalPurchaser(cal).

shopper(kim). member(kim,platinumClub).

shopper(peg). loyalPurchaser(peg). slowToPay(peg,last1year).

The above premises (policy rules and case facts) together entail the following conclusions about the discount percentages for the particular customers Ann, Cal, Kim, and Peg.

/* the entailed discount percentages for the particular customers */

giveDiscount(percent00,ann).

giveDiscount(percent05,cal).

giveDiscount(percent10,kim).

giveDiscount(percent00,peg).

5.3. Alternate Sequences

6. Narratives

6.1. (Title of Narrative)

7. Commentary

Considerable commentary was given above, already.

More relevant commentary is in the paper "Rule-based Policies across Multiple E-Services Tasks, using Courteous Logic Programs in RuleML, SWSL, and SweetRules" by Benjamin Grosof et al, from which this example is taken (http://ebusiness.mit.edu/bgrosof/paps/policy-rules-for-sws-v4.html). Please see the Abstract and Section 1 there.

7.1. PRIMER on RuleML/SWSL presentation syntax for CLP:

Next, we give a quick primer on RuleML presentation syntax, to aid the beginner to read examples of policies, in particular to read those in the next section and in the Policy Rules for E-Commerce section of the SWSF Application Scenarios (mentioned above). Full details of this presentation syntax are given in the SWSL (i.e., SWSF Language) document. But that's rather long and technical, so it's useful to have this primer. Note this primer only covers/treats part of the overall presentation syntax.

Next we describe some key syntactic constructs:

"?" prefixes a logical variable. ":-" is the implication connective. It means "if". Thus head-expression :- body-expression means "head-expression if body-expression", i.e., "if body-expression then head-expression". Note that a rule can be simply a fact; in this case, the body expression is empty/absent, and the ":-" connective can be (and usually is) omitted. "." ends a rule statement. "{...}" encloses a rule label. The rule label precedes the rest of the rule. Such a label is essentially a a name for the rule; it is used as a handle for specifying prioritization. "overrides" is a special predicate that is used to define prioritization between rules. overrides(lab1,lab2) specifies that any rule having label lab1 has higher priority than any other rule having label lab2. "!-" begins a mutex, i.e., a mutual-exclusion integrity constraint statement. !- can intuitively be read as "It's a logical contradiction if". In such a mutex, "|" can be read as "given that". "neg" is the classical negation connective. It means "not". Intuitively, "neg p" means that p is believed to be false. By contrast, "naf" is the negation-as-failure connective. It means "not believed". Intuitively, "naf p" means that p is not believed to be true. It may be that neither "p" nor "neg p" is believed, i.e., that the truth value/status of p is unknown. "naf" is thus weaker than "neg". For those less expert in the technical aspects of rules, it can be confusing to employ both "neg" and "naf" in the same rule or ruleset, so it is often helpful to employ (explicitly) only "neg" when writing rules.