| Dynamic Rule Generation Approach |
By dynamically generating inference rules, we want to speed up the rule activation procedure of O-DEVICE by restricting the
search space. Based on template rules and on the information from the ontology, we create actual rules that are loaded into the system and executed. For example, consider a general rule for handling symmetric properties. This rule would have a conditional element for the symmetric property and two more conditional elements for finding the appropriate objects, e.g.:
(defrule
(object(is-a owl:SymmetricProperty)(name ?p)(rdfs:domain ?d))
(object(is-a ?d)(name ?o1)(?p $?v1))
(object(is-a ?d)(name ?o2)(?p $?v2))
....
The problem is that CLIPS does not allow the use of variables in place of properties, e.g. ?p in the second and third conditional element. We are able to implement such rule in CLIPS following an indirect approach, but in this way we introduce a great overhead in the system due to the ammount of combinations it requires in order to match all the available variables. For this reason, we have implemented template rules that contain terms wherever is necessary, which are substituted at runtime with actual values from the ontology, creating an actual rule. Below there are all the template rules for each case. Each term inside "<" and ">" is substituted by a value from the ontology.
|
|
From the previous example, we show that a general rule in CLIPS for handling symmetric properties requires three object conditional elements, one for the symmetric property and two more for the appropriate objects. With the template rule above we can see that we need only one object conditional elenent in the rule, an important factor since there is not any join operation among objects and the rule is activated quicker. The <property-domain> term is substituted by the domain value of the property in order for the rule to search only objects that belong to this class. Furthermore, the <property> is substituted by the property name.
|
|
|
This rule handles the transitivity of properties. It computes the partial transitive closure between two objects and by the time all the corresponding objects have been traversed, the complete transitive closure will be computed.
|
|
|
The values of properties defined as subproperties of others are treated by copying the values to the superproperties as well. This rule finds an object having a particlular subproperty and copies the values to the superproperty.
|
|
|
The semantics of inverse properties are used in order to insert the values into the inverse ones too. The rule finds an object having an inverse property and copies the value to the inverse one of a corresponding object. Here, the <property> is substituted by the name of a property and the <inverse property> by the name of the inverse of the first.
|
|
|
For the equivalent properties, the system generates rules in order to copy the values in all the equivalent properties. In this rule, <property1> and <property2> are substituted by all the possible mutations of the equivalent properties in order to examine all the possible combinations.
|
| owl:allValuesFrom Property |
|
|
This type of restriction denotes local constraint to the value types of a particular property. It acts as the rdfs:range constraint only for the class where it is defined. The rule finds objects of the appropriate class denoted by the domain of the corresponding property, checks if do not all the values comply with the restriction and using the function make-all-of-type, changes the types of the instances. The <class name> term is sunstituted by the class denoted by the owl:allValuesFrom property of the restriction.
|
| owl:someValuesFrom Property |
|
|
A property restricted to have some values from a particular class, should contain at least one such a value. So, the system generates rules in order to check the class types of the values of particular objects. If an object does not have a value of type <class name>, which is the value of the owl:someValuesFrom property, for the particular slot, the rule generates a Skolem constant, that is an object of the corresponding class denoted by the owl:someValuesFrom property.
|
| owl:minCardinality and owl:cardinality Properties |
|
|
This restrictions denotes that a property should have at least one value (contrary to functional properties that allow the absence of values). In the system, cardinality constraints should have the values 0 or 1 only. The system generates rules that check the number of values of such restricted properties and insert Skolem constants whenever is necessary.
|
|
|
In order for the system to materialize the sufficient information from the ontology, dynamic rules are generated that perform instance classification. These rules are generated based on the information the system stores in the sufficient slot of class meta-objects and change the type of already created instances. Sufficient conditions are derived from the owl:intersectionOf and owl:equivalentClass constructs of OWL. The information in the sufficient slot is stored as: restrictionID classificationClass and/or class classificationClass. The first format is used to store sufficient conditions defined using restriction classes and the second one using actual classes. The <classA> term is substituted by the class value, the term <classB> by the classificationClass value and the term <restrictions>by the restrictionID value. So for example, if the sufficient slot of a class meta-object contains the values: (res23 classB), then <classA> = owl:Thing since there is not class value, <classB> = classB and <restrictions> = res23. The system translates this sufficient information as follows: If there is an object that satisfies the gen23 restriction, then this object is of type classB too.
|
|
|
This rule is used for deriving identical individuals. It checks the values of functional properties and
if they contain more than one values, makes all the value objects identical, by forcing them to belong
to the same class and by exchanging their values. <property-domain> is the domain class of a functional property
<property>
|
| Inverse Functional Property |
|
|
This rule is the only rule that performs a join of KB objects. It finds two objects
that in an inverse functional property have a similar value and makes the two objects
identical. This rule is the most complicated of the system, since it requires to traverse
many objects. In the future we plan to introduce a more sophisticated method for
handlling such type of properties.
|
|
