RIF Use Cases and Requirements

This use case illustrates a setfundamental use of rules) back to Emptor. Among other things,the policy states that:RIF: to supply a buyer must provide credit card information together with delivery information (address, postal code, city, and country).vendor-neutral representation in RIF BLD (Abridged) Presentation Syntax: allow(access(?Resource)) :- valid_payment_method(?C), valid_delivery_address(?D). valid_payment_method(?C) :- credential(payment_card, ?C#<ex:CreditCard>). valid_delivery_address(?D) :- declaration(delivery_address,?D[address->?A, postal_code->?P, city->?CI, country->?CO]). Rules express compactly possible ways in which a resourceof rules, so that rule-system developers and stakeholders can be accessed; by exchanging them negotiations are shorterdo their work and make product investments without concern about vendor lock-in, and privacy protection is improved.in our example, Venditor reveals part of its policy in form of rules to enable Emptor to choose how to answer, i.e. to decide which credentials to disclose. Note, however,particular without concern that this isa deliberately simplified example in which credentials' requests can be handled more directly. For determining whether Venditor's request for information is consistent with Alice's policy, Emptor takes its rules into account, which state for example: Disclose Alice's credit card information only to online shops belonging to the Better Business Bureau. Representation in RIF BLD (Abridged) Presentation Syntax: allow(release(credential(?C#<ex:CreditCard>))) :- credential(bbb, ?Cred[issuer->"Betterbusiness Bureau"]). By disclosing (interchanging)partner does not have the above given rule, Emptor asks Venditor to provide credentials saying thatsame vendor technology. It belongs toalso illustrates the Better Business Bureau, Alice's most trusted source of information on online shops. eShop has such a credentialfact that the RIF can be used to foster collaborative work. Each developer and its policy containsstakeholder can make a rule stating to release itcontribution to any potential purchaser. Hence, Venditor passesthe credentialjoint effort without being forced to Emptor. Emptoradopt the tools or platforms of the other contributors.

John is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing allnegotiating an electronic business contract regarding the information does not break Alice's denial constraints. Alice has stated two constraints stating: Never disclose two different credit cards tosupply of various types of items that Jane's company is manufacturing. Jane and John interchange the same online shop. For anonymity reasons, never provide both her birth datecontract-related data and postal code. Representationrules involved in RIF BLD (Abridged) Presentation Syntax: :- allow(release(credential(?C1#<ex:CreditCard>))), allow(release(credential(C2#<ex:CreditCard>))), ?C1 != ?C2. Different choices exist for implementing the above constraints as rules; choosingthe type of rules for implementing policies depends alsonegotiation in electronic form so that they can run simulations. Both agree on the capabilities of the Emptor system.a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved - in this purchase, anonymity is no issuecase an XML schema and only information on one credit card is requested. Thus, Alice's constraintsappropriate test XML documents are respected. Emptor therefore provides Alice's credit card information to Venditor. Venditor checks that Alice is not on eShop's blacklist, then confirms the purchase transaction. Companies that provide software such as Venditorinterchanged with their rules. Since John and Emptor would make use of the RIF in a number of ways. The rules expressing Alice's and/or eShop's policies could be expressed inJane run applications based on different vendors' rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditorengines and Emptor are products of different companies using different internalrule languages, it would still be possible for them to work together in real-time. When these two systems need to exchange policy or preference information of their respective clientsthey would useinterchange the RIF to enablerules using the interchange in real-time. When Venditor sends its initial policy information to Emptor it usesRIF; both vendors used can interpret the RIF. Emptor takes that policyXML schema and translates it fromdata, and produce the RIF to its internal representationresults as an amended XML document. John's company defines its purchase orders in order to determine what it needs to do. Motivates: Default behavior Theterms of an XML description of goods, packaging, delivery location and date with delivery and payment rules. A rule systems employedproposed by the agents involved in a negotiation, Emptor and Venditor here,John might have different capabilities. Thus, situations may occur where an agent does not understand (part of) the rules received from the other agent, even though they were interchanged through RIF. In such cases, a way to specify the default behavior would at least ease the understanding of the reasons whybe the negotiation failed or entailed just partial results, such as accessfollowing:

If an item is perishable and it is delivered to  part ofJohn more than 10 days after the  data or services. Limited number of dialects Because ofscheduled delivery date
then the  rich diversity of agentsitem will be rejected by him.

Representation in the setting of automatically establishing trust through negotiations, a limited number ofRIF dialects would decreaseBLD Presentation Syntax:

Here the  number of negotiations that failed because of incompatible dialects. Rule language coverage Intuitively, itprefix ppl is  clear that RIF should cover features found in most of the existing policy languages. A more detailed discussion onan abbreviation for http://example.com/people#,
the  rule language coverage follows. Syn 1.7 Means to access data in Web formats Policies frequently contain simple ontologies; means to accessprefix cpt for http://example.com/concepts#,
and  reason with OWL data is neededop stands for  applications involving such policies. SeS 2.9 Prioritya  conflict resolution mechanism is needed e.g. in situations where different policies may apply; prioritizing policies would be useful in such cases. ECA 5.1 General Policies may need support for event detection, event communication, and execution of actions; thus, supportyet-to-be-determined IRI for  reactive behaviourRIF builtin predicates.

Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
    "cpt:reject"^^rif:iri("ppl:John"^^rif:iri ?item) :-
        And("cpt:perishable"^^rif:iri(?item)
            "cpt:delivered"^^rif:iri(?item ?deliverydate "ppl:John"^^rif:iri)
            "cpt:scheduled"^^rif:iri(?item ?scheduledate)
            External("fn:subtract-dateTimes-yielding-dayTimeDuration"^^rif:iri(?deliverydate ?scheduledate ?diffduration))
            External("fn:get-days-from-dayTimeDuration"^^rif:iri(?diffduration ?diffdays))
            External("op:numeric-greater-than"^^rif:iri(?diffdays "10"^^xsd:integer)))
)

Abridged syntax:

Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
    <cpt:reject>(<ppl:John> ?item) :-
        And(<cpt:perishable>(?item)
            <cpt:delivered>(?item ?deliverydate <ppl:John>)
            <cpt:scheduled>(?item ?scheduledate)
            External(<fn:subtract-dateTimes-yielding-dayTimeDuration>(?deliverydate ?scheduledate ?diffduration))
            External(<fn:get-days-from-dayTimeDuration>(?diffduration ?diffdays))
            External(<op:numeric-greater-than>(?diffdays 10)))
)

Jane replies with some suggested rule changes:

If an item is  needed. ECA 5.4 Actions Different kinds of actions are needed, such as updates to data, sending events, procedural attachments, etc. Types 6 Support for datatypesperishable and it is  needed; the kinds of datatypes depend ondelivered to John more than 7 days after the  considered application. Dialect Identificationscheduled delivery date
but less than 14 days after the  dialect specificationscheduled delivery date
then a discount of  the interchanged rules together with information on the compatibility between the (standard) RIF dialects used by the parties, which need to establish trust by interchanging rules, can18.7% will be  used in this setting for decidingapplied to  continuethe  negotiation or not. Incompatible (standard)delivered item.

Representation in RIF dialects do not support the negotiation of the parties involved. Merge Rule Sets Often, agent softwares need to adopt existing policies, such asBLD (Abridged) Presentation Syntax:

Forall ?item ?deliverydate ?scheduledate ?diffduration ?diffdays (
    <cpt:discount>(?item 18.7) :-
        And(<cpt:perishable>(?item)
            <cpt:delivered>(?item ?deliverydate <ppl:John>)
            <cpt:scheduled>(?item ?scheduledate)
            External(<fn:subtract-dateTimes-yielding-dayTimeDuration>(?deliverydate ?scheduledate ?diffduration))
            External(<fn:get-days-from-dayTimeDuration>(?diffduration ?diffdays))
            External(<op:numeric-greater-than>(?diffdays 7))
            External(<op:numeric-less-than>(?diffdays 14)))
)

John considers this and agrees with Jane. Both organizations utilize these rules regulating some application domain, which might be writtenin othertheir operational systems using disparate rule languages thanrepresentations internally to compute prices for this order and determine contract compliance.

Future requests for the one usedsupply of items by John's company are defined on their purchasing web site, as the agent. In such cases, these existing policies need to be merged with agent's own policies, i.e. there is a need for merging rule sets. Concrete examples given in Protune 2.3 Collaborative Policy Development for Dynamic Spectrum Access This use case demonstrates how theappropriate XML schema and a RIF leadsruleset (or rulesets). This allows Jane's company and its competitors to increased flexibility in matching the goals of end-users of a service/device,respond electronically with the goals of providers and regulators of such services/devices.XML cost sheets. Suppliers respond with multiple cost sheets with different variations on the RIF can do that because it enables deployment of third party systems that can generate various suitable interpretations and/or translations ofrules proposed by John's company, allowing John's company to review the sanctionedalternative rules governingwith their associated costs to determine whether they, as a service/device.business, would benefit by relaxing or adding new rules as proposed by suppliers.

This use case demonstrates how the top levelRIF leads to increased flexibility in matching the policy artifact hierarchy wheregoals of end-users of a service/device, with the goals of providers and regulators of such services/devices. The RIF can do that because it should be; possible operational interpretationsenables deployment of third party systems that change are inserted at the next level down;can generate various suitable interpretations and/or translations of the implementation implicationssanctioned rules governing a service/device.

This use case concerns Dynamic Spectrum Access for thewireless communication devices. Recent technological and regulatory trends are converging toward a more flexible architecture in which reconfigurable devices may operate legally in various regulatory and service environments. The ability of a device architectures is generated automatically atto absorb the lowest level. Motivates: Default Behaviorrules defining the regulatorypolicies specify certain constraints, e.g., "if radar is sensed onof a channelregion, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in use,a form that the channel must be evacuated within 10 seconds," whichdevice can be vieweduse, as a default for a devicewell as their being tailored to bework with devices in compliance. However, the RIF-based specifications promulgated by the consortium will not simply statethe constraint, but rather containsame class having different capabilities.

In this use-case we suppose a set of implementable rules that make it possible forregion adopts a suitably configured devicepolicy that allows certain wireless devices to meet this constraint.opportunistically use frequency bands that are normally reserved for some configurations and device types these rules may go beyond simply ceasing transmission oncertain high-priority users. (The decision by the channel, e.g.,European Union to allow "Dynamic Frequency Selection" (DFS) use of the device might send5 GHz frequency band by wireless systems, a control message toband intermittently used by military and weather radar, is a recent example - See http://europa.eu.int/eur-lex/lex/LexUriServ/site/en/oj/2005/l_187/l_18720050719en00220024.pdf.)

Suppose the policy states:

A  masterwireless device  (an access point) askingcan transmit on a 5 GHz band if  an alternate channelno priority user is  available, etc. As long as these additional steps do not prevent devices from vacating the channel within 10 seconds (and do not violate any other constraints) they are allowed. So,currently using that band.

Representation in RIF BLD (Abridged) Presentation Syntax:

How does a device know that no priority user is currently using a band it would be worthwhilewants to allowuse? The RIF-based specifications to "point" to a RIF-based versionanswer will depend on the specific capabilities of the general 10-second constraint as a default behavior ifdevice. One type of device may answer this question by sensing the more detailed rules cannot be applied. Different semantics Depending upon the needs of an application, there are a numberamount of waysenergy it is receiving on that band. That is, it might employ the rule:

If no energy is detected on a  formaldesired band then assume no other device is using the band.

Representation of a policy can be achieved.in RIF BLD (Abridged) Presentation Syntax:

Forall 

A devicesecond type of device, may need to reason about whatget information from a policy requires andcontrol channel that lets it may also need to allow its behavior to be guided by the policy. Inknow whether the former case, deductive logic can bedesired band is being used to formulate statements and draw valid inferences as to what the policy entails. For example, relative to the 10 second channel evacuation requirement mentioned above, it turns out that ifby a device (or its associated master) checks for radar every 9 seconds then there will be enough time to evacuatepriority user. That is, it might employ the channelrule:

If  needed. So a RIF-based specification might containno control signal indicating use of a  declarative rule that states "ifdesired band by a  channelpriority user is  in use, and it's last radar check was 9 seconds ago,detected then  a radar check on that channel is due." The important thing to note here is thatassume the  ruleband is  a statement (capableavailable.

Representation in RIF BLD (Abridged) Presentation Syntax:

Forall 

So each type of being truedevice will need to employ different "interpretations" or false)"operational definitions" of whatthe implementation requires.policy in order to utilize such statements to guide the behaviorquestion.

Now assume that there are 10 manufacturers of these 2 different types of wireless devices. Suppose that each of these manufacturers uses a device, connections must be forged between conclusions reached and actions to be taken. Production rules, specifically, ECA rules can be useddistinct rule-based platform in designing its devices. Each manufacturer needs to establish those connections. For example, "if it has been concludedwrite 2 interpretations of the policy (for each of the two types of device). That a radar check for a channel is due, then do <action>!" Since this use case envisions devicesmeans that are both capable20 different versions of reasoning aboutthe policy requirements and being guided by them, we expect that these RIF-based specifications will require rules having both declarativemust be written, tested and imperative semantics. Limited Number of Dialects Asmaintained.

Enter the use case states, RIF-based specifications are beneficial because they allowRIF. The 10 manufacturers form a consortium. This is a third-party group of interested parties (the consortium) to write machine-usable specificationsthat can be deployedis responsible for translating regional policies into the RIF. When it does so, however, it provides different versions corresponding to a wide varietythe possible interpretations (operational definitions) of devicesthe policy. So in this case, 2 RIF versions of the DFS policy are provided for the 2 types of device manufacturer, or other party, writesmentioned above. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a "RIF-compiler," i.e., translator,RIF-Compiler for the giventarget device platform. If RIF-based specifications were themselves allowed to take on many different forms in a non-cohesive fashion, and specifications using them were generated,architecture exists. Clearly it is possible that this benefit wouldwill be compromised.in other words, athe interest of each device manufacturer or third party might find it necessaryto invest too much time in maintaining translators to make use of the RIF worthwhile. OWL data The rules in these applications will utilize conceptsdevelop such compilers. That are defined in accordance withis because the definitions devised by standard organizations. The use of OWL ontologies is likelymanufacturer only needs to develop such a compiler once for that task. Moreoverevery architecture it is possibleowns. Contrast that future protocol message payloads might contain OWL data. Coverageinvestment with having to produce, test, and maintain different versions of various policies over the rules require support for negation.lifetime of a product.

This arrangement also allows the rules reactoverall process to changesbe organized in a fashion that maintains the environment. Features from production rulesnatural division of labor in the corresponding division of artifacts produced by that labor: the policy and ECA rules such as forward chaining, events,its various interpretations are written and actions will be useful. 2.4maintained in platform-independent artifacts (the RIF); knowledge about how to translate from the RIF to a particular device architecture is maintained in the compilers. A change in policy is inserted at the top level in the policy artifact hierarchy where it should be; possible operational interpretations of that change are inserted at the next level down; the implementation implications for the various device architectures is generated automatically at the lowest level.

A business process (BP) designer designs processes that can span multiple departments in the same business as well as other business partners. A classic example of this is the integration of supply chain business processes which typically involve multiple partners. Supply chain integration involves exposing a certain amount of business logic between partners as well as integrating processes across partners. In such activities it is therefore often necessary to access or invoke rules that originate in other ownership domains.

A key part of a business process is the logic used to make decisions within the process. Such logic is often coded in rules because rule languages are easier for BP designers to understand and manipulate than procedural code (as in Java) -- although both forms of business logic are prevalent. Where business logic is represented in different rule languages this presents a significant burden to the BP designer in designing an integrated process.

Two primary integration modalities are possible: importing the different rulesets into a single engine and processing them in a uniform manner, or accessing the rulesets by querying remote engines and processing the results. Each modality has its uses and contra-indications. Where there are strong ownership boundaries involved it may not be permitted to merge rule sets of partners.

For example, in an insurance adjustment process, the inspection of a damaged vehicle is often performed by independent inspectors. The critical decision in how an insurance claim will proceed is whether the damage results in a total loss or whether a repair is feasible:

If inspector believes vehicle is repairable then process as repair otherwise process as total loss.

Representation in RIF BLD (Abridged) Presentation Syntax:

repair(?Vehicle) :-
   believes("inspector",?Vehicle, "repairable").
loss(?Vehicle):-
   believes("inspector",?Vehicle, "notRepairable").

The question of whether a vehicle is repairable is one that is dependent on the processes executed by the inspector and cannot be directly integrated into the insurance companies own adjustment process. The insurance company effectively queries the inspector's logic. Within the adjustment process, the overall flow will be quite different for repairable claims and total loss claims.

Even in the case of a single company, which is nominally under a common ownership domain, information and business logic is often controlled by multiple stakeholders. For example, a large company will often be organized into semi-independent profit centers (business units). Each unit will be motivated differently, will have different ontologies and business logic and may use different rule languages to represent their logic (this is particularly the case where one company acquires another company).

The RIF should be used to permit the BP designer a unified view of the different partners' business rules in designing the process, while at the same time permitting the partners to continue to leverage their own business rules without changing their own technologies.

How such a unifed view of the business rules can be realized in a deployed BP will depend on both technical and non-technical factors. Even where all the parties are required to use a common rule language, there may be compelling ownership issues that mitigate against a simple merge of the rule sets. In the situation where merging of rulesets is not possible, then a query-style access to partners' business rules may be used. In this way, the RIF permits a unified dynamic view of the business rule logic no matter what the original form of the rules.

For this to be viable from a business perspective it is critical that the semantics of the rules and query exchange be completely predictable and preferably loss-less.