• Refund Policies in E-Commerce

This is one of the possible Use Cases.

1. Abstract

This is a short use case about refund 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/monitoring. 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's mostly done, but 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.

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 refund percentage for a given item.

5. Breakdown

5.1. Actors and their Goals

A seller/merchant wants to share rules about refund 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, and post-agreement monitoring of contract compliance/performance, as well as possibly other aspects of contract performance/execution.

5.2. Main Sequence

This is a typical example of a seller's refund policy, as a set of policy rules that specify refunds in an e-retailer (here, of small consumer appliances) These rules are useful in advertising, and as part of a contract (proposed or final), and as part of contract monitoring / exception handling (which is in turn part of contract execution). The policy rules knowledge thus can be reused across multiple SWS tasks. This example is a reformatted variant of example 1 of [Grosof99b].

In the main sequence scenario:

• The seller posts the refund policy rules on their website, or sends in a message to a prospective buyer (e.g., a quotation/contract-proposal or an advertisement).
• Various buyers get the refund policy rules and reason with them as part of making their decision about whether to purchase. Some do indeed purchase
• Some buyers return the item to the seller, and want a refund. The rules determine how much percentage of their money paid is refunded, depending on the circumstances.

The unconditional guarantee rule says that if the buyer returns the purchased good for any reason, within 30 days, then the purchase amount, minus a 10 percent restocking fee, will be refunded. The defective guarantee rule says that if the buyer returns the purchased good because it is defective, within 1 year, then the full purchase amount will be refunded. A priority rule says that if both of the previous two rules apply, then the defective guarantee rule "wins", i.e., has higher priority. A mutex says that the refund percentage is unique per customer return.

/* refund policy rules */

{unconditionalGuarantee}

• refund(?Return, percent90)
  • :- return(?Return) and delay(?Return, ?D) and lessThanOrEqual(?D, days30).

{defectiveGuarantee}

• refund(?Return, percent100)
  • :- return(?Return) and reason(?Return, defective) and
    • delay(?Return, ?D) and lessThanOrEqual(?D, years1).

overrides(defectiveGuarantee, unconditionalGuarantee).

!- refund(?Refund, percent90) and refund(?Refund, percent100).

/* some background facts (typically provided by lessThanOrEqual being a built-in predicate */

lessThanOrEqual(days12, days30). lessThanOrEqual(days44, years1). lessThanOrEqual(days22, years1). lessThanOrEqual(days22, days30).

/* some "case" facts about particular customer returns of items */

return(toaster02). delay(toaster02, days12).

return(blender08). delay(blender08, days44). reason(blender08, defective).

return(radio04). delay(radio04, days22). reason(radio04, defective).

The above premises (policy rules, background facts, and case facts) together entail the following conclusions about the discount refund percentages for the particular customer returns of the toaster, blender, and radio.

/* the entailed refund percentages for the particular customer returns */

refund(toaster02, percent90).

refund(blender08, percent100).

refund(radio04, percent100).

5.3. Alternate Sequences

The use case is straightforwardly extended, by adding action rules, to actually do notifications or payments via side-effect-ful procedural attachments triggered by the rules. This can use action rules cf. the Situated extension of LP, which can in turn be implemented on top of / in Production Rules or various other rule systems. We will not give a lot of details in this version, since we plan to submit one or more other use cases that illustrate that kind of thing.

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.