A simple use of these rules would be to assert that the combination of the hasParent and hasBrother properties implies the hasUncle property. Informally, this rule could be written as:
hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)
In the abstract syntax the rule would be written like:
Implies(Antecedent(hasParent(I-variable(x1) I-variable(x2)) hasBrother(I-variable(x2) I-variable(x3))) Consequent(hasUncle(I-variable(x1) I-variable(x3))))
From this rule, if John has Mary as a parent and Mary has Bill has a brother then John has Bill as an uncle.
An even simpler rule would be to assert that Students are Persons, as in Student(?x1) ⇒ Person(?x1).
Implies(Antecedent(Student(I-variable(x1))) Consequent(Person(I-variable(x1))))
However, this is a bad use for rules in OWL, as it just duplicates the OWL subclass facility. It would be much better to write instead:
Class(Student partial Person)
or
SubClassOf(Student Person)
A very common use for rules is to move property values from one individual to a related individual, as in the following example that expresses the fact that the style of an art object is the same as the style of the creator.
Artist(?x) & artistStyle(?x,?y) & Style(?y) & creator(?z,?x) ⇒ style/period(?z,?y)
Implies(Antecedent(Artist(I-variable(x)) artistStyle(I-variable(x) I-variable(y)) Style(I-variable(y)) creator(I-variable(z) I-variable(x))) Consequent(style/period(I-variable(z) I-variable(y))))
It is often useful to include OWL descriptions in rules, instead of using named classes. The above rule could be augmented with a separate rule to provide information about exclusivity of style (assuming that style is not always exclusive).
Artist(?x) & (≤1 artistStyle)(?x) & creator(?z,?x) ⇒ (≤1 style/period)(?z)
Implies(Antecedent(Artist(I-variable(x)) (restriction(artistStyle maxCardinality(1)))(I-variable(x)) Style(I-variable(y)) creator(I-variable(z) I-variable(x))) Consequent((restriction(style/period maxCardinality(1)))(I-variable(z))))