RIF Use Cases and Requirements

As the name implies, a Rule Interchange Format (RIF) should enable interchange of rules. The use cases presented in section 2 of this document illustrate situations in which such interchanges enable some desirable functionality. In this section we attempt to clarify in more general terms what rule interchange is and why it is important.

By "rules" we mean formal entities in some "executable rule-language." An executable rule-language, as we understand that term here, consists of the following elements: 1) a precise syntax and/or effective procedure for determining whether or not any expression is a well-formed formula (wff) of the language, and 2) a derivation procedure, which is defined as a partial function that takes a set of wffs in the language, together with a set of zero or more queries (also wffs), and for each query either returns an answer after some finite time, or terminates without returning an answer. (The notion a "derivation procedure" is in line with the notion of a "load-and-query rule engine" in the RIF charter, section 2.2.3, except that we here explicitly account for the possibility that a bona-fide rule-engine can "go on forever" in certain cases.)

Let r-1 represent a set of wffs in a rule language RL-1, let q-1 represent a set of query wffs in the same language, and let RL-1(r-1,q-1) represent the result of executing the derivation procedure of rule language RL-1 on the given arguments. Let RL-2 represent a rule language distinct from RL-1. Then a fundamental question regarding the possibility of rule-interchange between these two rule-languages for this case is whether there is a mapping M from r-1 and q-1 into RL-2 sets r-2 and q-2 such that r-2 = M(r-1) and q-2 = M(q-2), and such that RL-2(r-2,q-2) = M(RL-1(r-1,q-1)). In words: is there a way to translate the items in r-1 and q-1 into RL-2 such that equivalent results are achieved?

In any particular case there seem to be three possible answers of interest to this question: 1) such a mapping exists, 2) such a mapping does not exist, but a mapping that is "close enough" to make the interchange useful does exist, and 3) such a mapping does not exist and there is also no mapping "close enough" to make the interchange useful.

Let RL-1, RL-2,...RL-n represent n rule-languages. Suppose that for these languages the answer to the fundamental question regarding rule-interchange falls into categories (1) and (2) enough of the time that it is clear that automating interchange of rules among this family of languages is worth the effort. One way to facilitate rule-interchange among these languages would be to design pairwise translation alogrithms for each possible pair in the family. For n languages we need to design n(n-1) algorithms: for each rule-language we have to implement a translation algorithm to each of the other n-1 lanaguages.

An alternative approach is to design one overarching representation mechanism, a RIF, that allows the structure of each language in RL-1, RL-2,...RL-n to be expressed in some standard way. Then for each language one would only have to write two translation algorithms: one from the language to the RIF and vice versa, for a total of 2n.

Besides representing an order of magnitude less effort for the implementation of translation algorithms, the use of a RIF has the potential for additional benefits. For example, in cases where rule-interchange mappings cannot be reliably automated, the information provided by the RIF representation should, at the very least, be useful in automatically constructing explanations of the translation impasse.

It is important to understand, however, that the RIF itself provides neither a translation algorithm nor an explicit mapping between rule languages. Rather the RIF includes a framework of concepts, represented as tags in a markup language, that can be used to provide information about the meaning of wffs in a rule language. For rule authors who wish to make their rules accessible across languages and platforms, the more completely, precisely, and accurately they tag their creations using the RIF, the more likely it is that their rules will be capable of being automatically translated correctly.

Information integration, merging multiple sources of information to allow processing the information in a unified manner, is one of the oldest uses of knowledge based systems. This unified information could be directly displayed to a user or included in business logic deep within an application.

Many sources of heterogeneity can arise in information integration, including:

• multiple ownership domains

• different forms

• conflicting semantic bases or meta models

• physical and/or temporal distribution

Two primary integration techniques 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.

Individuals often have to combine information from multiple sources. For example, a job seeker might use a search engine that supports a unified search for job offers that are published on distributed websites of corporations and universities. If she is unlucky, there will not be a suitable website and she will have to integrate the various sources herself. In the case of job-hunting there are some standard domain-specific ontologies available to help with the integration, but many employers require additional concepts to describe their specific requirements. In order to facilitate searching over their offerings, these employers sometimes supply rule-based descriptions of the relationships between their ontologies and the more general domain ontologies.

Company information is nominally under a common ownership domain but is in practice controlled by multiple stakeholders. A situation that is almost guaranteed to arise in a company is one where different databases and other sources of information are in incompatible forms that need mapping before they can be used.

The following scenario illustrates the enterprise context, where managers often have to combine multiple sources of information across different ownership domains:

Suppose that a product manager wants to predict the effect of announcing a new version of his product. Folklore suggests that as soon as a new product is announced orders for the existing version rapidly dry up as customers wait for the new version. The size of the gap between the announcement and actual availability will have a marked effect on sales. In order to predict this effect, our product manager integrates the current estimate of sales -- both actual orders and prospective orders -- together with estimates for manufacturing. The information for the sales is held in a database which has an RDF interface; the sales department has a supporting ontology in OWL that allows analysis and aggregation of the raw information (such as what kinds of customers and orders there are).

The supply chain is composed of a number of contractors and the corporate warehousing facilities, together with a shipping agent. Again, the different enterprises are not owned or controlled by our product manager except for predefined contracts that have been put in place. Those contracts have a representation as a collection of RuleML/OWL/Prolog facts; this enables the contract manager to use them to incorporate service level predictions in his automated planning.

Finally, the product manager has access to a desktop utility called GoPlan that allows him to prepare a plan for the rollout of the new version and have the system automatically query the different stakeholders for their information. This is possible because GoPlan is aware of the RIF, as are all the other stakeholders, and is able to accommodate the differences in semantics of the different sources of information. As a result, the new version is announced and rolled out in a smooth way, and sales grow!

Decision support systems aid in the process of human decision making, especially decision making that relies on expertise. Rules are a critical part of this expert decision making. Interchange is also especially important, since different systems and knowledge bases are often involved (e.g., medical knowledge bases, hospital patient databases, pharmaceutical knowledge bases, etc.).

The following scenario illustrates various medical decision support systems:

Bob, 62 years old and reasonably healthy, has been going to his internist, Dr. Rosen, for several years for control of his Type II diabetes. Originally his diabetes was controlled through diet and moderate exercise.

When his blood glucose became too high under this regimen, he was prescribed the drug Glucor (50 mg. tid). This helped temporarily. When Bob's blood glucose levels rose, he was switched to Hemi-daonil (1.25 mg., tid). When this no longer sufficed, he was switched to Diamicron (80 mg., tid), and finally to Metformin (70 mg., tid), which has thus far controlled Bob's blood glucose level.

Bob recently suffered a concussion and has become increasingly forgetful. He went to see a neurologist, Dr. Cervello, who prescribed a contrast MRI. When asked about current medication, Bob told Dr. Cervello that he was taking Diamicron to control his diabetes, forgetting that he had been switched to Metformin. This was potentially problematic, since Metformin should not be taken close to the administration of a contrast injection.

Fortunately, when Bob came to take the MRI, the radiology tech checked the hospital database and found that Bob was taking Metformin rather than Diamicron. The radiology tech put this information into MEDIC (Medical Event and Drug Interaction Consultant), the hospital’s new automated system, which checks for incompatible medical events and/or drugs (e.g., liposuction scheduled during pregnancy, blood thinners prescribed before surgery, etc.) The rules in MEDIC have been automatically generated using the rules for product and medical event compatibility from other knowledge bases (e.g, more general knowledge about effects of drugs on kidneys, drugs’ clearance time, etc.).

After being informed, the radiologist told Bob that he needed to discontinue the Metformin for a few days before taking the MRI. The MRI was rescheduled for a few days later, after which time Bob began taking the Metformin again. The day after the MRI was performed, Dr. Bild, a radiologist who specializes in interpreting neurology scans, went over the MRI scan. He used the hospital’s new Brain Reasoning System, an expert system that helps interpret brain scans, and determined that Bob may have suffered some mild damage due to his recent concussion. Unfortunately, the brain anatomical changes that he has seen also indicate that Bob may be suffering from mild Alzheimer’s disease.

Dr. Bild transmits his report to Bob’s neurologist Dr. Cervello. The next morning, Dr. Cervello gives a short summary of his and Dr. Bild’s findings to his fellows and residents and asks them how they would treat Bob. For various reasons, most can’t follow his brief presentation, and can’t respond to Dr. Cervello’s questions. Resident X missed the lecture on brain anatomy last week due to the flu; Resident Y just transferred from a program that emphasized CAT scans rather than MRIs, and fellow Z has focused on traumatic rather than degenerative changes to the brain. None of them are familiar with medical protocols for treating mild Alzheimer’s. Dr. Cervello tells them that they had better be better prepared the next day. That evening, they hunker down in the residents’ lounge and, each on a separate laptop, use the hospital’s new e-learning system to prepare themselves for the next day’s encounter. Each starts the e-learning session by answering a short questionnaire that assesses their knowledge or lack thereof of various subareas of neurology. The e-learning system then brings back materials that will fill in their gaps of knowledge. X, Y, and Z each spend several hours going through their customized materials. The next day, they are able to answer Dr. Cervello’s questions.

John is negotiating an electronic business contract regarding the supply of various types of widgets that Jane's company is manufacturing. Jane and John interchange the contract-related data and rules involved in the negotiation in electronic form so that they can run simulations. Both agree on a standard Business Object Model / data model (i.e., vocabulary / ontology) for the goods and services involved. Since John and Jane run applications based on different vendors' rule engines and rule languages, they interchange the rules using the RIF. John's company defines its purchase orders in terms of an XML description of goods, packaging, delivery location and date with delivery and payment rules:

IF widget.type = "foodstuff" 
AND delivery.date > order.deliverydate + 10 days
THEN goods.rejected = true

Jane replies with some suggested rule changes:

IF widget.type = "foodstuff" 
AND delivery.date > order.deliverydate + 7 days
AND delivery.date < order.deliverydate + 14 days
THEN widget.orderdiscount = 18.7%

John considers this and agrees with Jane. Both organizations utilize these rules in their operational systems using disparate rule representations internally to compute prices for this order.

This use case concerns the ability of parties involved in formal transactions or procedures, e.g., credit card authorization of a purchase, access of private medical records, etc., to express and protect their interests within a policy-governed framework. The goal is to formally encode the preferences, priorities, responses, etc., of the parties in such a way that the overall policy can work as intended while providing opportunity for automatic negotiation of terms when allowed by the policy. Utilization of the RIF in this use case would extend the scope of this technology, affording a higher degree of interoperability, as well as enabling re-use and sharing of preferences, etc., through interchange. The detailed scenario below shows how this would work.

Alice wants to buy a device at an online site called "eShop." Alice employs software called "Emptor" that functions as an automated negotiating agent for buyers. eShop employs software called "Venditor" as an automated negotiating agent for sellers. These two systems negotiate so as to automatically establish trust with the goal of successfully completing the transaction. The negotiation is based on the policies and the credentials each system has. Alice's and eShop's policies describe who they trust and for what purposes.

When Alice clicks on a "buy it" button at the eSho's Web site, Emptor takes over and sends a request to eShop's site. Venditor receives the request and sends the relevant policy back to Emptor. Among other things, the policy states that "a buyer must provide credit card information together with delivery information (address, postal code, city, and country)."

Emptor now determines whether Venditor's request for information is consistent with the policy Alice has provided. Alice has a credit card but her Emptor policy states that she is not willing to disclose it to everyone. Since Alice has never bought anything from eShop in the past, Emptor asks Venditor to establish its credentials by, for example, proving it belongs to the Better Business Bureau (BBB), Alice's most trusted source of information on online shops. eShop has such a credential and its policy is to release it to any potential purchaser. Hence, Venditor passes the credential to Emptor. Emptor is now ready to disclose Alice's credit card information to Venditor but it still must check whether disclosing all the information does not break Alice's denial constraints. Alice has stated two constraints stating

• to never disclose two different credit cards to the same online shop and

• for anonymity reasons never to provide both her birth date and postal code.

For this purchase, anonymity is no issue and only information on one credit card is requested. Thus, Alice's constraints are respected. Emptor therefore provides Alice's credit card information to Venditor. Venditor checks that Alice is not on eShops blacklist, then confirms the purchase transaction.

Companies that provide software such as Venditor 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 in different rule languages but still work with the software, using RIF-based interchanges. Secondly, assuming Venditor and Emptor are products of different companies using different internal rule 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 clients they would use the RIF to enable the interchange in real-time. When Venditor sends its initial policy information to Emptor if uses the RIF. Emptor takes that policy and translates it from the RIF to its internal representation in order to determine what it needs to do.

Interchange of Organisation-directed Rules

This use case demonstrates how the RIF could support business people in sharing guidance on how to run their business. The RIF could do this by enabling interchange of rules that are directed at the organization rather than its IT systems (e.g. where “customer” is the real person that buys the business’s goods and services, rather than a row in the business’s database). Some of these rules will not be automatable.

The “rule engine” that deals with such rules is a combination of a tool and a person; that should not make any difference to the RIF. The people using the tools will categorize the rules stored in the tool and decide:

• Which are about real world activity. They will be transformed into procedural guides for people in the business.

• Which are about IT. There are three possibilities (not mutually exclusive):

  • They will be mapped to existing IT rules that will support them

  • They will transformed to new IT rules

  • New IT rules will be acquired from some external provider.

There are many areas of business application for this capability, including:

• Regulatory compliance
  Many businesses are overwhelmed by the volume of regulation they have to comply with, and the number of uncoordinated sources of regulation. They are increasingly dependent on external sources - shared interest groups such as industry associations, and paid advisors such as lawyers and consultants - for guidance on how to comply.
  

• Terms and conditions for outsourcing of business services
  Some companies provide outsourcing of business services, which may be (from their clients’ perspective) outward-facing, such as deliveries to customers, or inward-facing, such as premises maintenance. Contracts usually include rules about how staff will act - for example, how a maintenance crew will deal with building security - as well as how IT systems will interact.
  

• Guidance for business conduct in different countries and regions
  Multinationals need rules for localizing business behaviour. They have a wide range of application - etiquette, advertising, pricing, incentives, contracts, after-sales support, etc. Such rules are likely to require input from local experts, either paid advisors or official sources in the home country and/or the target country.
  

• Operational policy changes in distributed organizations
  When a business decides to change what it is doing - ranging from strategic innovations to continuous improvement - it needs to distribute the rules for the new regime. These kinds of change may originate within the business, or be adopted as a general recommendation from an industry association or an external advisor.
  

• Trading agreements
  Rights and obligations of participants in trading agreements.
  

• Changes to employment terms and conditions
  Examples include: agreements negotiated with unions or staff associations; changes in working practice after outsourcing of services; pension provision; introduction of new work practices such as flexi-time or teleworking.
  

One capability that support tools should have is cross-referencing of rules in different domains; for example, relating employee rights, operational policies, employment regulations and privacy regulations.

Suppose that there are several software vendors that supply support tools of the kind described. They form an agreement to extend their tools with capabilities:

• To accept rules received in the RIF, for integration into their tools’ knowledge bases.

• To generate rules in the RIF from their tools’ knowledge bases, for transmission to others.

Then, as an example of use, think about regulation. Suppose that there are advisors - industry associations, lawyers, consultants, etc. - who provide interpretation of regulations and recommendations on compliance. They negotiate with regulators:

• “If our members/clients took your regulations to mean this … would that adequately capture your intent?”

• “If our members/clients did this … in response to your regulations, would that be acceptable compliance?”

This negotiation may be complex. Regulations from different regulators may interact - for example, there are conflicts between privacy regulations and Sarbanes-Oxley - and regulators don’t often talk to each other. The advisors store their conclusions in support tools that can generate RIF, so they provide guidance to their members/clients in a platform-independent form. They may also provide some pro-bono, for anyone who needs them.

Now consider compliance officers in organizations that are clients/members of these advisors. They have support tools that can accept guidance in the RIF.

They rely on external advisors for general interpretation - what the regulations mean to businesses in their industries, in the countries where they operate, and what rules they should follow for compliance. When new interpretations and recommended compliance appear (because of new regulation or new rulings on existing regulations), the advisors’ support tools prompt the compliance officers’ tools, and deliver the rules in the RIF.

When compliance officers have a general interpretation, they have to relate it specifically to their organizations - how it impacts their policies and operations, including all the guidance (employment, trading, localization etc.) stored in their support tools.

Sometimes, company-specific interpretations are difficult. Obvious courses of action may conflict with what is already in place for other regulations. There may be possibilities for adapting something already in place to serve new regulations in addition to its current purpose, rather than creating a new, specific solution.

Compliance officers may need more help. There are web sites that can provide it - industry groups and paid advisors (in addition to the ones subscribed to), regulators’ advisory services, national advisory services, other companies willing to share their experience. But a compliance officer needing help may not know them by URL.

A support tool should be able to deal with this, finding web sites that can provide relevant content, preferably in directly-usable form in the RIF. Then it should organize the results (by topic, by regulation, by relevance, by reliability of source, whether available in RIF or not, etc) and deliver them to the compliance officer, for local interpretation.

Publication of factual information on the Semantic Web often needs to be complemented by conditional information to communicate precisely what it means and/or how it may be used. Rules are an unambiguous and potentially machine-processable way of providing these extra conditions. Rules with variables also allow to generalize specific cases to (conditional) situation patterns.

A case where rules add clarity and precision to factual information is the publication of a new Semantic Web vocabulary, where the goal is to specify (proof-theoretic) semantics for some of the vocabulary elements with a low barrier to entry. Examples include the RDFS and SKOS specifications. Where appropriate, inference rules are expressed using the Jena 2 rule syntax, or as RDF statements using the OWL vocabulary. They are described in prose when this is not possible or when the expression would be too cumbersome to be a useful communication tool. A RIF provides implementation neutrality whereby the publisher can convey rule-based expression of semantics in implementation-neutral form, leaving the consumer free to choose whatever implementation approach is appropriate.

Rules may also be used to precisely communicate how data should be used. For example, a future FOAF user might publish not only unconditional information about their preferences but also conditional information, i.e. a rule set. This would complement their normal FOAF profile, e.g. describing which of their phone numbers should be used at which time of day depending on the day of the week:

Monday to Friday 
      IF 09:00 - 12:00 OR 13:00 - 17:00, THEN call my office number
      IF 12:00 - 13:00 OR 17:00 - 18:00, THEN call my cell number
      IF 18:00 - 21:00, THEN call my home number
      IF 21:00 - 09:00, THEN do not call me

Saturday, Sunday and Holidays
      IF 09:00 - 21:00, THEN call my cell number
      IF 21:00 - 09:00, THEN do not call me

In some cases, the publication of rules may more precisely communicate both what the accompanying information means and how it may be used. For instance, the IDM laboratory wants to publish an ontology of the anatomy of the brain cortex and a vocabulary to describe facts about items on brain images, such as can be provided by computer-assisted or automated image analysis tools. Hospital, medical practices and medical imagery laboratories want to use the ontology and vocabulary to improve and streamline their communication.

To communicate the semantics of the properties defined as part of the ontology and vocabulary in a precise and unambiguous way, IDM publishes a set of rules to capture relationships between ontology and/or vocabulary properties, e.g.:

Two MaterialAnatomicalEntities (MAE) having a shared boundary are connected: 
      isMAEBoundedBy(?x1,?x3) Λ isMAEBoundedBy(?x2,?x3) Λ MAE(?x1) Λ MAE(?x2) Λ GyriConnection(?x3)
      ->
      isMAEConnectedTo(?x1,?x2)

Two MAE entities having a shared connection are connected:
       connectsMAE(?x3,?x1,?x2) Λ MAE(?x1) Λ MAE(?x2) Λ GyriConnection(?x3)
       ->
       isMAEConnectedTo(?x1,?x2)

One MRI laboratory uses an automated image analysis tool to extract facts about brain images and wants to use the ontology and the vocabulary to describe items on the images. The rules are retrieved in the RIF and translated into the rule language specific to the engine used by the application. They are executed to automatically label the brain cortex structures - sulci and gyri - in the brain images, based on the facts extracted by the image analysis.

This use case demonstrates how the RIF leads to increased flexibility in matching the needs and goals of end-users of a service or a service-delivery device, such as a cell phone, with the needs and goals of providers and/or regulators of such services. The RIF can do that by enabling deployment of third party systems designed to allow service providers and regulatory agencies to write the rules defining and governing their services once, leaving it to the third-party service to generate suitable interpretations and/or translations of those rules for any consumer process or device interested in using the service. There are at least two broad areas in which such third-party services could be deployed:

• Wireless Communications & Dynamic Spectrum Access

  • 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 to absorb the rules defining the policies of a given region, or the operational protocols required to dynamically access available spectrum, is contingent upon those rules being in a form that the device can use, as well as their being tailored to work with devices in the same class having different capabilities. This use case is developed in detail below.

• Web Services and Service Oriented Architecture

  • The advent of web-based service architectures offers the possibility of a more dynamic and flexible approach in which differentiated service definitions, or Service Level Agreements (SLAs), can be matched to particular circumstances automatically as required. For example, what constitutes a certain level of service, or an acceptable premium for such a level, might vary depending upon the laws in the region in which the service is provided or contracted. The ability of a consumer process to understand the rules defining and governing differentiated SLAs is contingent upon those rules being in a form that the consumer process can use.

Suppose a region or nation adopts a policy that allows certain wireless devices to opportunistically use frequency bands that are normally reserved for certain high-priority users (e.g. government). The decision by the European Union to allow "Dynamic Frequency Selection" (DFS) use of the 5 GHz frequency band by wireless systems , a band 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 that such a device can transmit on such a band if no priority user is currently using that band. From the point of view of the device (and its designers) the question is how does it know that no priority user is currently using a band it wants to use? The answer will generally depend on the specific capabilities of the device. For example, one type of device may only be able to answer this question by means of sensing the amount of energy it is receiving on that band. If it senses no energy on the desired band it assumes no other device is using the band. However, a more sophisticated type of device, may be able to get information from another control channel that lets it know whether the desired band is ok to use at a given time or not. So each class of device will need to employ different "interpretations" of the policy in question.

Now assume that there are 10 manufacturers of the these 2 different classes of wireless devices. Suppose that each of these manufacturers uses a distinct rule-based platform in designing the "policy engines" of its devices. Each manufacturer needs to write 2 interpretations of the policy (for each of the two classes of device). That means that 20 different versions of the policy must be written, tested and maintained.

Enter the RIF. The 10 manufacturers form a consortium. This is a third-party group that is responsible for translating such policies into the RIF. When it does so, however, it provides different versions corresponding to the possible interpretations (operational definitions) of the policy. So in this case 2 RIF versions of the DFS policy are provided for the 2 general classes of device - those that only use energy sensing to determine band use versus those that can use the control channel. Each of these RIF specifications can be automatically translated into the appropriate rule-platform provided a RIF-Compiler for the target device architecture exists. Clearly it will be in the interest of each device manufacturer to develop such compilers for their device architectures. That is because the manufacturer only needs to develop such a compiler once for every architecture it owns. Contrast that investment (plus the cost of its membership in the consortium) with having to produce, test, and maintain different versions of various policies over the lifetime of a product. Moreover, this arrangement also allows the overall process to be organized in a fashion that follows and maintains the natural division of labor and the division of artifacts produced by that labor. In other words, the policy and its various interpretations are written and maintained in platform-independent artifacts. The 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 artifacts where it should be, possible operational interpretations of that change are inserted at the next level down, and then the implications for the various device architectures is generated automatically at the lowest level.

Rules are often used in conjunction with other declarative knowledge representation formalisms, such as ontology languages (e.g. RDF and OWL), in order to extend their expressive power. Knowledge representation enriched by rules may involve other expressiveness-enhancing techniques such as fuzziness, incomplete information, semistructured data, reification, and frames. A typical example, as detailed below, is the use of rules to describe complex relationships between binary predicates which cannot be captured in ontology languages alone.

A web ontology designer discovers that it's not easy to come up with a general description of the hasUncle property. He tries to do it anyway by first defining the Uncle class using suitable property restrictions:

ObjectProperty(hasSibling Symmetric) 
ObjectProperty(isUncleOf inverseOf(hasUncle))
Class(Man partial Human)
Class(Parent complete
   Human
   restriction(hasChild someValuesFrom(Human)))
Class(Uncle complete
   Man
   restriction(hasSibling someValuesFrom(Parent)))

Individual(Sam type(Human))
Individual(John type(Man))
Individual(Bob type(Human) value(hasChild Sam) value(hasSibling John))

He is pleased to discover that the above axioms entail that John actually belongs to the Uncle class, since John is a Man and has a sibling Bob who is (implicitly) a Parent (Bob is a Human and has a child, Sam, who is also a Human).

However, the axioms do not entail that "John isUncleOf Sam". After further attempts, the ontology designer finally realizes that it is impossible to describe the desired relationship between the hasSibling, hasChild and hasUncle properties in OWL. Instead of explicitly specifying each and every instance, he would obviously prefer to describe the hasUncle property in a general way so that instances of the property can be derived from Parent-Child and Sibling relationships. This is easily accomplished by extending the web ontology definition with a rule:

ObjectProperty(hasSibling Symmetric) 
ObjectProperty(isUncleOf inverseOf(hasUncle))
Class(Man partial Human)
Class(Parent complete
  Human
  restriction(hasChild someValuesFrom(Human)))
Class(Uncle complete
   Man
   restriction(hasSibling someValuesFrom(Parent)))
(Class(Uncle partial 
  restriction(isUncleOf someValueFrom(Human)))

Individual(Sam type(Human))
Individual(John type(Man))
Individual(Bob type(Human) value(hasChild Sam) value(hasSibling John))

Uncle001: hasUncle(?x,?y) :- hasChild(?z,?x) ^ hasSibling(?z,?y) ^ Man(?y) ^ Person(?z) ^ Person(?x)

Now, anybody who uses this extended ontology doesn't have to enumerate hasUncle property instances as they are now entailed by the added rule. The rule, Uncle001, and the ontology are publicly published as OWL ontologies are. The rule should be authored in a standard interchangeable format so that many different rule engines can process it.