The overall SWSL language and ontologies support many kinds of application scenarios. In this subsection, we discuss in detail how SWSL-Rules can be used to represent several (fictional) examples of policies for e-commerce. Some of these examples are given directly in the remainder of this section, in full detail. These include:
price discounting example;
refunds example;
supply chain ordering lead time example;
creditworthiness example; and
credit card transaction authorization example.
Taken together these examples include both B2C/retailing and B2B/supply-chain aspects, in several industry domains (books, appliances, and computer equipment manufacturing). Each of these policies is useful for not just one but several different kinds of tasks within an application realm. For example, price discounting rules are useful in advertising and in service contract specification. Most of these detailed examples are rather brief, for the sake of expository simplicity. However, the example dealing with authorization of credit card transactions is significantly longer and more realistic.
Additional examples of policy rules are available that use the same fundamental knowledge representation as SWSL-Rules. [Grosof2004e] gives a long example of e-contracting policy rules that combines rules with ontologies and deals with exception handling / monitoring. The [Grosof2004f] tutorial gives a collection of use cases and examples, including those for semantic mediation. The SweetRules [Grosof2004f] downloadable includes a collection of examples.
Overall, the SWSL-Rules is especially well suited to represent available knowledge and desired patterns of reasoning for several of the SWS tasks, including:
In particular, the capabilities of SWSL-Rules for logical nonmonotonicity (negation-as-failure and/or Courteous prioritized conflict handling) is used heavily in many use case scenarios for each of the above tasks and its associated kinds of knowledge.
Next, we give an 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).
Next, we give 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 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).
In B2B commerce, e.g., in supply chains (especially in manufacturing), sellers often specify how much lead time, i.e., minimum advance notice, is required when a buyer places or modifies a purchase order. Next, we give an example of a part supplier vendor's (here, Samsung supplying computer equipment) lead time policies as a set of rules. 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 first policy rule says "14 days lead time if the buyer is a preferred customer". This might be authored by the marketing part of the seller's organization. The second policy rule says "30 days lead time if the ordered item is a minor part". This might be authored by the financial accounting part of the seller's organization. The third policy rule says "2 days lead time if: the ordered item is backlogged at the vendor (i.e., the seller is having trouble fulfilling its overall set of existing orders), and the order is a modification to reduce the quantity of the item, and the buyer is a preferred customer". This might be authored by the operations part of the seller's organization. The third rule is given higher priority than the first rule, say, because operations' authority (about lead time) is greater than that of marketing. A mutex says that the lead time is unique per purchase order.
/* ordering lead time policy rules */
{leadTimeRule1}
orderModificationNotice(?Order,days14) :-
preferredCustomerOf(?Buyer,?Seller) and purchaseOrder(?Order,?Buyer,?Seller).
{leadTimeRule2}
orderModificationNotice(?Order,days30) :-
minorPart(?Order) and purchaseOrder(?Order,?Buyer,?Seller).
{leadTimeRule3}
orderModificationNotice(?Order,days2) :-
preferredCustomerOf(?Buyer,?Seller) and orderModificationType(?Order,reduce) and
orderItemIsInBacklog(?Order) and purchaseOrder(?Order,?Buyer,?Seller).
overrides(leadTimeRule3,leadTimeRule1).
!- orderModificationNotice(?Order,?X) and orderModificationNotice(?Order,?Y) | notEquals(?X,?Y).
/* some "case" facts about particular purchase orders */
purchaseOrder(po1234567,compUSA,samsung).
preferredCustomerOf(compUSA,samsung).
purchaseOrder(po5678901,microCenter,samsung).
preferredCustomerOf(microCenter,samsung).
orderModificationType(po5678901,reduce).
orderItemIsInBacklog(po5678901).
The above premises (policy rules and case facts) together entail the following conclusions about the ordering lead time for the particular purchase orders po1234567 and po5678901.
/* the entailed lead times for the particular purchase orders */
orderModificationNotice(po1234567,days14).
orderModificationNotice(po5678901,days2).
Policies about authorization, including creditworthiness and other kinds of trustworthiness to access information or perform transactions, are often naturally expressed in terms of necessary and sufficient conditions. Such conditions include: credentials, e.g., credit ratings or professional certifications; third-party recommendations; properties of a transaction in question, e.g., its size or mode of payment; and historical experience between the agents, e.g., familiarity or satisfaction.
Next, we give a simple example of policy rules of a merchant about creditworthiness (of customers) using a credit report service and a fraud alert service. These rules are useful for representing authorization policies, as part of contract negotiation, and in contract monitoring and exception handling (e.g., if the fraud alert arrives after contractual agreement has been reached).
The first policy rule says that, by default, the merchant deems a requester customer to be creditworthy if the requester has a good rating from a particular credit report service (CreditReportsRUs, a source trusted by the merchant). The second policy rule says that the merchant deems a requester to be not creditworthy if the requester has a bad rating from any fraud alert service that is recommended as expert by a particular security consultant (recommenderServiceD, again, a source trusted by the merchant). The second rule is given higher priority than the first rule. The merchant is called "self" (as is conventional in the security policy literature for the granting authority institution).
/* creditworthiness policy rules */
{credSelf}
honest(self,?Requester) :- creditRating(creditReportsRUs,?Requester,good).
{frauSelf}
neg honest(self,?Requester) :-
creditRating(?BlackballService,?Requester,bad) and
fraudExpert(recommenderServiceD,?BlackballService).
overrides(frauSelf,credSelf).
fraudExpert(recommenderServiceD,studentLoanAgency).
/* some "case" facts about particular requester customers */
creditRating(creditReportsRUs,sue,good).
creditRating(creditReportsRUs,joe,good).
creditRating(studentLoanAgency,joe,bad).
The above premises (policy rules and case facts) together entail the following conclusions about the creditworthiness of the particular requester customers Sue and Joe.
/* the entailed creditworthiness of the particular requester customers */
honest(self,sue).
neg honest(self,joe).
Next, we give a longer and more realistic example of authorization in e-commerce: authorization by a merchant of credit card transactions requested by customers. In this example, the merchant ("eSellWow") merges the authorization policies of credit card issuer (called the "bank") with the merchant's own additional authorization policies. These rules are useful for specifying authorization policies, contracts, and exception handling.
/* Some terminological abbreviations:
CVC: Card Verification Code (the three or so numbers found on the back of a credit card)
"Bank": the credit card company that is the issuer of the credit card (e.g., Mastercard)
*/
/* Predicates' meaning:
transactionRequest: a credit card transaction requested by a customer
merchant: a merchant who is established to do credit card transactions
with the credit card company
ccInGoodStanding: credit card is in good standing with the credit card company that is
the issuer of the credit card
ccInfo: credit card info about the account and its status, that is on file with the bank
authorize: the credit card transaction is authorized
transactionExpirationDateOf: customer-supplied expiration date that is part of the transaction
transactionCardholderNameOf: customer-supplied cardholder name that is part of the transaction
transactionCVCOf: customer-supplied CVC that is part of the transaction
transactionCardholderAddressOf: customer-supplied cardholder billing address
that is part of the transaction
ccFraudRating: rating of a credit card by a fraud alerting/tracking service
fraudExpert: a service is a legitimate expert in fraud alerting/tracking
fraudRecommenderFor: trusted recommender of fraud experts
customerRating: the rating of customer based on the merchant's own/other experience
Built-in predicates (used):
notEquals
lessThan
*/
/* The following group of rules are policies of the bank,
then adopted/imported as a group/module by the merchant, in this case eSellWow. */
/* bankGoodStanding: Bank says by default the transaction is authorized if the card is in
good standing */
/* expiredCard: Bank says the transaction is disallowed if the card is expired. */
/* overLimit: Bank says the transaction is disallowed if the card is above its account limit. */
/* mismatchExpirationDate: Bank says the transaction is disallowed if the expiration date from
the customer or card in the transaction does not match what's on file for the card.
However, the expiration date may not be available as part of the transaction. */
/* mismatchCVC: Bank says the transaction is disallowed if the Card Verification Code
does not match what's on file for the card.
However, note that the CVC may not be available as part of the transaction. */
/* mismatchAddress: Bank says the transaction is disallowed if customer-supplied cardholder
billing address does not match what's on file for the card.
However, the customer-supplied cardholder billing address may not be available. */
/* mismatchName: Bank says the transaction is disallowed if customer-supplied cardholder
name does not match what's on file for the card.
However, the customer-supplied cardholder billing address may not be available. */
/* The expiredCard, overLimit, mismatchExpirationDate, mismatchCVC, mismatchAddress, and
mismatchName rules all have higher priority than bankGoodStanding. */
/* The following group of rules are additional policies of the merchant eSellWow,
which it adopted/imported from a vendor and consultant when setting up its e-store website */
/* merchantRespectBank: Merchant say a transaction is disallowed if the bank does. */
/* merchantTrustBank: Merchant says, by default, that a transaction is allowed if the bank does. */
/* fraudAlert: Merchant says transaction is disallowed if a trusted fraud tracking service
rates the fraud risk as high for the card. */
/* trustTRW: Merchant relies on recommenderServiceTRW for establishing such trust. */
/* badCustomer: Merchant says transaction is disallowed if its own/other experience indicates that the
customer is a bad customer to deal with. */
/* The fraudAlert and badCustomer rules both have higher priority than merchantTrustBank. */
/* The following are additional background fact rules, known to the merchant eSellWow and the bank. */
/* eSellWow is an established merchant for mastercard and visa. */
/* The following are additional background fact rules, known to the merchant eSellWow. */
/* recommenderServiceTRW recommends fraudscreen */
{bankGoodStanding}
authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInGoodStanding(?Bank,?CreditCardNumber).
{expiredCard}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
notEquals(?ExpiredFlag,"false").
{overLimit}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
lessThan(?AccountLimit,?Amount).
{mismatchExpirationDate}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionExpirationDateOf(?TransactionID,?TransactionExpirationDate) and
notEquals(?TransactionExpirationDate,?ExpirationDate).
{mismatchName}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionCardholderNameOf(?TransactionID,?TransactionCardholderName) and
notEquals(?TransactionCardholderName,?CardholderName).
{mismatchCVC}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionCVCOf(?TransactionID,?TransactionCVC) and notEquals(?TransactionCVC,?CVC).
{mismatchAddress}
neg authorize(?Bank,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
transactionCardholderAddressOf(?TransactionID,?TransactionCardholderAddress),
notEquals(?TransactionCardholderAddress,?CardholderAddress).
overrides(expiredCard,bankGoodStanding).
overrides(overLimit,bankGoodStanding).
overrides(mismatchExpirationDate,bankGoodStanding).
overrides(mismatchName,bankGoodStanding).
overrides(mismatchCVC,bankGoodStanding).
overrides(mismatchAddress,bankGoodStanding).
{merchantTrustBank}
authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
authorize(?Bank,?TransactionID).
{merchantRespectBank}
neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
neg authorize(?Bank,?TransactionID).
{fraudAlert}
neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
fraudRecommenderFor(?Merchant,?recommenderService) and
fraudExpert(?recommenderService,?FraudFirm) and
ccFraudRiskRating(?FraudFirm,?CardholderName,high).
{badCustomer}
neg authorize(?Merchant,?TransactionID) :-
transactionRequest(?TransactionID,?Merchant,?CreditCardNumber,?Amount) and
issuer(?CreditCardNumber,?Bank) and merchant(?Merchant,?Bank) and
ccInfo(?CreditCardNumber,?Bank,?CardholderName,?AccountLimit,
?ExpiredFlag,?ExpirationDate,?CardholderAddress,?CVC) and
customerRating(?Merchant,?CardholderName,bad).
overrides(fraudAlert,merchantTrustBank).
overrides(badCustomer,merchantTrustBank).
fraudRecommenderFor(eSellWow,recommenderServiceTRW).
merchant(eSellWow,mastercard).
merchant(eSellWow,visa).
fraudExpert(recommenderServiceTRW,fraudscreen).
/* The following groups of "case" facts each specify a
particular case scenario of a requested customer transaction. */
/* Joe Goya has a card in good standing, unexpired, and
the transaction amount is below the account limit.
His customer rating is good.
Transaction expiration date, address, and CVC are unavailable, as
is fraud alert rating.
The policies thus imply that his transaction ought to be authorized
by the merchant as well as by the bank. */
/* Mary Freund has a card in good standing, unexpired, and
the transaction amount is below the account limit.
Her address matches, and her fraud report and customer rating are fine.
But the transaction CVC and address do not match the ones on file.
Thus the policies imply that the transaction on her card
ought to be disallowed by the merchant as well as the bank. */
/* Andy Lee has a card in good standing, unexpired,
and the transaction amount is under the account limit.
But his customer rating is bad.
Thus the policies imply that his transaction ought to be disallowed
by the merchant (regardless of whether the bank allows it). */
transactionRequest(trans1014,eSellWow,"999912345678",70).
issuer("999912345678",mastercard).
ccInfo("999912345678",mastercard,joeGoya,1100,"false","2007_08","43 Garden Drive, Cincinnati OH",702).
ccInGoodStanding(mastercard,"999912345678").
customerRating(eSellWow,joeGoya,good).
transactionRequest(trans2023,eSellWow,"999987654321",410).
issuer("999987654321",visa).
ccInfo("999987654321",visa,maryFreund,2400,"false","2008_02","325 Haskell Street, Seattle, WA",684).
ccInGoodStanding(visa,"999987654321").
ccFraudRiskRating(fraudscreen,maryFreund,low).
customerRating(eSellWow,maryFreund,excellent).
transactionCVCOf(trans2023,524).
transactionTransactionAddressOf(trans2023,"1493 Belair Place, Los Angeles, CA").
transactionRequest(trans3067,eSellWow,"999956781234",120).
issuer("999956781234",mastercard).
ccInfo("999956781234",mastercard,andyLee,900,"false","2006_05","1500 Seaview Boulevard, Daytona Beach, FL",837).
ccInGoodStanding(mastercard,"999956781234").
customerRating(eSellWow,andyLee,bad).
The above premises (policy rules and case facts) together entail the following conclusions about the authorization of the particular requested transactions by customers Joe Goya, Mary Freund, and Andy Lee. Notice that in the case of Andy Lee's, the merchant denies authorization even though the bank approves it, because of the merchant's own customer rating info and policies.
/* the entailed approval vs. denial by the bank, and by the merchant, of
authorization of the particular requested credit card transactions. */
authorize(mastercard, trans1014).
authorize(eSellWow, trans1014).
neg authorize(visa, trans2023).
neg authorize(eSellWow, trans2023).
authorize(mastercard, trans3067).
neg authorize(eSellWow, trans3067).