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). Sometimes it is not possible to capture the knowledge in OWL. Sometimes the knowledge can be captured in OWL or rules, but rules are easier to write and understand. 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 premise, and 2) the conclusions in the then part, also known as the rule head. In SADL there is an optional "given" part 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
ChildRuleRule 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 are then used in subsequent conditions or 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 are graph patterns except "product(?v1,?v2,?v3)". This condition is a 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" (cause the conclusions to be processed). In a case like this, the functional also binds the result of a procedural computation to a new variable, ?v3 in this case.
Equations, also known as functions, are snippets of procedural code that provide instructions for computing an output from a set of inputs. The inputs are type variables. The output is implicit but its type is the return type. These functions can be very important in modeling a domain. For example, many reasoners allow rules to have built-in functions to handle math operations, and without the ability to do math operations it may not be possible to construct a useful model.
The SADL grammar supports two kinds of equations, one in which the body of the function (the set of instructions for computing) is defined in the SADL statement, and another where the body of the function exists somewhere outside of the ontology. The first kind uses the Equation keyword.
Equation areaOfCircle (float radius) returns float: PI*radius^2 .
Equation volumeOfCylinder (float radius, float height) returns float: areaOfCircle(radius) * height.
As the example illustrates, one Equation may use another in its body. Here the volumeOfCircle Equation uses areaOfCircle in its body.
The second kind of equation uses the External keyword. This kind of equation needs a means of specifying where, outside of the ontology, the complete specification may be found. Consistent with W3C identity by URI, the instance of External is given an externalURI identity. It may also have an optional location to help code using the External to find it.
External
abs (float
x)
returns
float:
"http://java.lang.Math.abs"
located
at "java.lang.Math.abs".
The named functions declared with either the Equation or External keyword can be used in expressions in SADL or derivative grammars. Using the functions to do actual computation is a task for the reasoner or other related processors.
Variables were introduced in the section above discussing Rules and Built-in Functions. Variables can show up in SADL models in rules, queries, equations, and tests. One of the potential benefits offered by authoring rules, queries, and tests in SADL is that many fewer variables may be needed than in the translation to the target representation. The AreaOfRectangle rule above provides an example of this. There is only one variable, x, in the SADL rule but the translation contains 4 variables. This reduction in the number of variables is because SADL a) allows nesting of patterns, b) uses common symbols for functions, e.g., "*" for "product(...)", and c) uses more English-like syntax than most target representation, which allow only graph triple patterns and functions. However, the translation to triple patterns and functions is important--it defines the semantics of SADL in terms of the semantics of OWL plus functions, which can be equivalently represented in predicate logic.
Consider these example expressions and their pseudo rule translations (triple patterns in square brackets to facilitate identification):
Note that examples 3 and 4 have the same meaning. In the first case the triple patterns in SADL are in the form of <subject> <predicate> <object> where as in the second case the triple patterns are in the form of <predicate> of <subject> is <object>. In either case, "y" is defined (bound) as the object of the second triple and then used as a bound variable for the subject of the last triple pattern.
A list differs from a set in that the members of a list are in a specified order and there can be duplicate members. From a modeling perspective, this is a big difference. It is typical in many modeling languages to represent a list using a construct with two pointers: the first points to the current member of the list and the second points to a list which is the rest of the list. A typed list has further constraints to specify that members of the list must also be members of a specified class.
OWL does not have a standardized mechanism for typed lists. OWL builds on RDF which does have a list construct but an RDF list is not typed and, because of the way it is constructed, it’s use makes reasoning over a model theoretically undecidable. Because of the significant importance of lists in modeling many real-world domains, SADL provides a typed list construct defined in SadlListModel.owl, which is automatically added to the OwlModels folder of a project and automatically imported into any .sadl file (and its corresponding OWL file) that uses a typed list. The basic construct in SadlListModel.owl, in SADL syntax is:
uri "http://sadl.org/sadllistmodel" alias sadllist.
^List is a class
described by ^first,
described by rest with values of type ^List,
described by lengthRestriction with values of type int,
described
by
minLengthRestriction
with
values
of
type
int,
described
by
maxLengthRestriction
with
values
of
type
int.
A typed list is created in a SADL ontology by referencing the type followed by the keyword List. (In the sadllist model above, the caret (^) in front of List tells the editor that this is not the SADL grammar keyword List but a user-defined concept named List.) Note that the property ^first is an RDF properties, as indicated by the more florescent green color, so that the members of the list can either be instances or data types. Since first is also a keyword in the SADL grammar it must be preceded by a caret. Below are two typed list declarations, the first with members from the Person class and the second a list of XSD strings.
Person List
string List
In a SADL model using a list construct, the type list definition creates a subclass of sadllist:List with some additional restrictions.
· first can only have values of the specified type, e.g., Person or string in the above examples.
· rest can only have values of which belong to the class being defined, e.g., Person List or string List
Note that the other properties in the sadllist model (lengthRestriction, minLengthRestriction, maxLengthRestriction) are used to constrain the length of lists belonging to the defined sadllist:List subclass. These can only be added to named lists. For example,
ChildrenList is a type of Person List length 1-*.
creates a subclass of sadllist:List named ChildrenList and whose members can only be instances of Person and which must contain at least one element but can contain any number larger number of elements. Please do not confuse a cardinality restriction on a property whose range is a List subclass with restrictions on the length lists belonging to the List subclass. To illustrate:
Person is a class.
ChildrenList is a type of Person List length 1-*.
children describes Person with values of type ChildrenList.
children of Person has at most 1 value.
The second line in this example includes a
list length restriction that instances of the class ChildrenList should
have at least one and may have any number of members.
The fourth line in the example is a maximum cardinality restriction indicating
that an instance of Person should have at most one value of the
children property.
It is also possible to create declared instances of a typed list class. For example,
John is a Person. Sue is a Person. Craig is a Person.
JoesChildren is the ChildrenList [John, Sue, Craig].
creates an instance of ChildrenList with ordered members John, Sue, and Craig.
This part of the documentation does not address when and how one might use Lists. There are a number of list expressions which can be used where expressions are allowed, e.g., in Equations or in Rules.
See also Implied Properties.
It is often the case in natural language that we leave out information that can easily be inferred by the recipient of the communication. For example, we might say “Sue is 23.” or “Joe is at least 250.” What we mean by these statements can probably correctly be inferred to be “Sue has age 23 years.” “The weight of Joe >= 250 lbs.” (See Unitted Quantities below.)
SADL tries to allow similar incompleteness as in these English examples, as long as it is not ambiguous, by supporting the concept of an implied property. Implied properties are defined in terms of a specific class using the impliedProperty annotation property defined in the SadlImplicitModel.
impliedProperty is a type of annotation.
This statement creates impliedProperty as an instance of owl:AnnotationProperty. Note that annotation properties in SADL are green but not bold.
Suppose that we created the following model.
The “i” to the left of line 9 is an information marker which, when moused over, displays the information
“Implied property 'age' used (left side of 'is') to pass type check”.
Whenever implied properties are applied in SADL to resolve type checking, an information marker is created to make the behavior more transparent to the user.
There are some limitations to the the use of implied properties in type checking. There must be no ambiguity. For example, if both age and weight were defined to be implied properties of Person, both with a numeric range, it would not be possible to know which implied property to apply in the example above so the expression would be ambiguous. This would therefore create an error.
Expanded properties are another application of implied properties, this time to the case of expanding both sides of a comparison or assignment statement. Instead of comparing or assigning the individual(s) matching the left and right hand sides of the statement, the statement is expanded to a set of statements adding the "expandedProperty" implied properties of the class being compared to the left and right side property chains. See Expanded Properties.
Suppose that we have a domain model defining age and weight as examples of data type properties.
Person is a class described by age with values of type decimal,
described by weight with values of type decimal.
We could use these properties in instance data statements like
George is a Person with age 23, with weight 165.
Jim is a Person with age 2, with weight 9.5.
The problem of course is that many numerical values require a specification of the unit in order to be unambiguous. These statements might more precisely be expressed as
George is a Person with age 23 years, with weight 165 lbs.
Jim is a Person with age 2 days, with weight 9.5 lbs.
The SADL grammar supports placing a unit designation after a numeric value in such statements. If the unit has spaces, e.g., “feet per second”, it must be placed in quotes.
The translation of such SADL statements to OWL depends upon a SADL preference setting. If the preference “Ignore Unitted Quantities (treat as numeric only) during translation” is checked, the translation will happen as if the units were not present.
If this preference is not checked, the definition of UnittedQuantity from the SadlImplicitModel.sadl is used. The basic unit model is
UnittedQuantity is a class,
described by ^value with values of type decimal,
described by unit with values of type string.
The translation to OWL is made as if the SADL statements were
George is a Person
with age (a UnittedQuantity with ^value 23, with unit "years"),
with weight (a UnittedQuantity with ^value 165, with unit "lbs").
Jim is a Person
with age (a UnittedQuantity with ^value 2, with unit "days"),
with weight (a UnittedQuantity with ^value 9.5, with unit "lbs").
SADL 3 supports the inclusion of imported models that are not in the current project in two ways.
To make a SADL project reference another project in the Eclipse environment:
To make an external OWL file available for import in a SADL project:
This will create a ".url" file if it doesn't exist and open it in the External URL editor. If it does already exist it can be opened directly from the Project Explorer. Once the ".url" file is open:
Note that if an external OWL model imports other external models those models must also be added to the .url file so that they will be found and their concepts will be available.