This is an archive of an inactive wiki and cannot be modified.

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: .

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

( -> ...). 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.


Frequency/importance in real world:

3. Benefits of Interchange

Which Rule Systems Supported:

SweetRules includes an open source such courteous compiler component.

4. Requirements on the RIF

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 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 */



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 ( 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.