Rules are a convenient way to capture domain knowledge in the familiar format of "if this then that". Sometimes the same knowledge could be captured in OWL property restrictions and/or necessary and sufficient conditions (see Property Restrictions, Equivalent Classes). However, in other situations it is not possible to capture the knowledge in OWL. Whether it's the only possible way or just easier to write and understand, rules are an important tool for the builder of semantic knowledge-based applications. It should be noted that if rules are used in a SADL knowledge base, a reasoner should be selected (with a compatible translator) that supports both OWL and rules.
An if then rule has two parts: 1) the conditions in the if part, also known as the rule body or premises, and 2) the conclusions in the then part, also known as the rule head. In SADL there is an optional "given" part of the rule that can be used to set certain conditions apart from other conditions. Both "given" and "if" conditions are translated into the rule body in the target rule representation.
Here are some example SADL rules.
Rule AreaOfRectangle
given x is any Rectangle
then area of x= height of x* width of x.
Rule ChildRule
given x is a Person
if x has age <=
12
then x is a Child.
Rule ChildRule2: if x is a Person with age <= 12 then x is a Child.
These examples illustrate that SADL rules are constructed from graph patterns but also illustrate that graph patterns can be combined using the SADL grammar for expressions. When variables are used in multiple graph patterns, as they are in these examples, the first occurrence in the rule conditions "binds" the variable and those bindings may then be used in subsequent conditions and in the conclusions. In the first rule above, for example, x is bound to instances of the class Rectangle. Each possible binding will result in the rule being evaluated by the reasoner. The rule will translate into something like the following for most reasoners, where a "?" is placed in front of variable names to identify them as variables.
if
?x rdf:type Rectangle
?x height ?v1
?x width ?v2
product(?v1,?v2,?v3)
then
?x area ?v3
All of the conditions and the conclusion of this rule are graph patterns except "product(?v1,?v2,?v3)". This condition is a function, also referred to as a rule built-in function. Functions in a rule's conditions return true (meaning the condition is satisfied) or false (meaning the condition is not satisfied so the rule should not "fire" (that is, cause the conclusions to be processed). In a case like this, processing the function also binds the result of a procedural computation to a new variable, ?v3 in this case. Functions in a rule's conclusions implement side effects, like sending a email.
In the second example rule above, the less than or equal ("<=") also translates to a builtin function.