Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
The OWL 2 W3C Recommendation is described in a series of documents, which contain both a high level overview of the OWL 2 DL language and it formal specification. One of these documents contains a description of several so-called language profiles. These profiles are restricted subsets of OWL DL that trade some expressivity to provide more desirable computational guarantees. These profiles restrict the types of OWL axioms that can be used in an ontology and place syntactic restrictions on how axioms can be used. Many real world ontologies do not use the full set of features provides by OWL 2 DL and often fall into one or more of these profiles.
Three profiles are provided. These are: OWL 2 EL, which is designed for ontologies that contain a large number of classes or properties; OWL 2 QL, which is aimed primarily at query answering; and OWL 2 RL, which is aimed at application that require quite a bit of the expressivity provided by OWL 2 DL but also require scalable reasoning.
Table of Contents
A notable feature of the OWL 2 RL is that the profile is designed to be implementable using a rule-based reasoner. The specification document contains a set of first order implication rules of rules that can be used to implement such a reasoner. The rules are described in terms of an RDF serialization of an OWL ontology. In the document, the rules are divided into seven tables and each rule is given a unique name. For example, a rule called eq-sym that describes the symmetric property of the owl:sameAs axiom is written:
T(?x, owl:sameAs, ?y) -> T(?y, owl:sameAs, ?x)
Based on their functionality, rules are subdivided into eight groups. Each group is presented as a table in the specification (numbered 3 to 9). For example, table 5 contains rules relating to reasoning with OWL object and data properties.
Reasoning with the OWL 2 RL profile is polynomial with respect to the size of the ontology.
As mentioned above, reasoning in OWL 2 RL can be implemented using a set of implication rules. These rules are divided into seven tables (numbered 3 to 9) in the specification document and each rule is given a unique name.
Each provides a subtab that allows control of the OWL 2 RL inference process by allowing the selective enabling and disabling of the rules or tables of rules. This interface also provides a control tab to indicate if rule tables are active or inactive.
The following is an example of this interface as displayed in the SWRL Drools Tab.
The interface contains subtabs for tables 4 to 9, which represent six of the seven OWL 2 RL rule tables. Table 3 is omitted because it contains unnamed low-level list processing that can not meaningfully be disabled. All rules in table 7, which relate to literal reasoning, are also permanently on.
These subtabs list these rule names, indicate their support status, and allow supported rules to be enabled or disabled. A check next to each rule indicates whether that rule is enabled or disabled. Greyed-out rules are either permanently enabled or currently unsupported and cannot be toggled.
Each inferface provides the method getOWL2RLController, which returns a controller. This controller provides an API for switching on and off rules or tables of OWL 2 RL rules.
The following examples shows how to create a SWRL rule engine and get an OWL 2 RL controller from it. (Instructions for creating an OWLOntology instance using the OWLAPI can be found here.)
OWLOntology ontology = ... // Create using OWLAPI SWRLRuleEngine ruleEngine = SWRLAPIFactory.createSWRLRuleEngine(ontology); OWL2RLController controller = ruleEngine.getOWL2RLController(); controller.enableTables(OWL2RLNames.Table.Table4); controller.enableRules(OWL2RLNames.Rule.PRP_AP);
The method reset must be called on the rule engine after these settings are changed so that the rule engine reflects the updates.
The SWRLAPI can also save the OWL 2 RL rule settings for a particular ontology. These settings are saved as annotation properties in that ontology.
If you wish to save these settings, the SWRL Annotations Ontology must be imported by the ontology.