The OWL Reasoner
The default OWL rule reasoner (ReasonerRegistry.getOWLReasoner()) supports the constructs as listed below.
| Constructs | Supported by | Notes |
| rdfs:subClassOf, rdfs:subPropertyOf, rdf:type | all | Normal RDFS semantics supported including meta use (e.g. taking the subPropertyOf subClassOf). |
| rdfs:domain, rdfs:range | all | Stronger if-and-only-if semantics supported |
| owl:intersectionOf | all | |
| owl:unionOf | all | Partial support. If C=unionOf(A,B) then will infer that A,B are subclasses of C, and thus that instances of A or B are instances of C. Does not handle the reverse (that an instance of C must be either an instance of A or an instance of B). |
| owl:equivalentClass | all | |
| owl:disjointWith | full, mini | |
| owl:sameAs, owl:differentFrom, owl:distinctMembers | full, mini | owl:distinctMembers is currently translated into a quadratic set of owl:differentFrom assertions. |
| Owl:Thing | all | |
| owl:equivalentProperty, owl:inverseOf | all | |
| owl:FunctionalProperty, owl:InverseFunctionalProperty | all | |
| owl:SymmeticProperty, owl:TransitiveProperty | all | |
| owl:someValuesFrom | full, (mini) | Full supports both directions (existence of a value implies membership of someValuesFrom restriction, membership of someValuesFrom implies the existence of a bNode representing the value). Mini omits the latter "bNode introduction" which avoids some infinite closures. |
| owl:allValuesFrom | full, mini | Partial support, forward direction only (member of a allValuesFrom(p, C) implies that all p values are of type C). Does handle cases where the reverse direction is trivially true (e.g. by virtue of a global rdfs:range axiom). |
| owl:minCardinality, owl:maxCardinality, owl:cardinality | full, (mini) | Restricted to cardinalities of 0 or 1, though higher cardinalities are partially supported in validation for the case of literal-valued properties. Mini omits the bNodes introduction in the minCardinality(1) case, see someValuesFrom above. |
| owl:hasValue | all |
The OWL rule set does include incomplete support for validation of datasets using the above constructs. Specifically, it tests for:
- Illegal existence of a property restricted by a maxCardinality(0) restriction.
- Two individuals both sameAs and differentFrom each other.
- Two classes declared as disjoint but where one subsumes the other (currently reported as a violation concerning the class prototypes, error message to be improved).
- Range or a allValuesFrom violations for DatatypeProperties.
- Too many literal-values for a DatatypeProperty restricted by a maxCardinality(N) restriction.
.
As an example of using the OWL inference support, consider the sample schema and data file in the data directory - owlDemoSchema.xml and owlDemoData.xml.
The schema file shows a simple, artificial ontology concerning computers which defines a GamingComputer as a Computer which includes at least one bundle of type GameBundle and a component with the value gamingGraphics.
The data file shows information on serveral hypothetical computer configurations including two different descriptions of the configurations "whiteBoxZX" and "bigName42".
We can create an instance of the OWL reasoner, specialized to the demo schema and then apply that to the demo data to obtain an inference model, as follows:
Model schema = FileManager.get().loadModel("file:data/owlDemoSchema.owl");
Model data = FileManager.get().loadModel("file:data/owlDemoData.rdf");
Reasoner reasoner = ReasonerRegistry.getOWLReasoner();
reasoner = reasoner.bindSchema(schema);
InfModel infmodel = ModelFactory.createInfModel(reasoner, data);
A typical example operation on such a model would be to find out all we know about a specific instance, for example the nForce mother board. This can be done using:
Resource nForce = infmodel.getResource("urn:x-hp:eg/nForce");
System.out.println("nForce *:");
printStatements(infmodel, nForce, null, null);
where printStatements is defined by:
public void printStatements(Model m, Resource s, Property p, Resource o) {
for (StmtIterator i = m.listStatements(s,p,o); i.hasNext(); ) {
Statement stmt = i.nextStatement();
System.out.println(" - " + PrintUtil.print(stmt));
}
}
This produces the output:
nForce *:
- (eg:nForce rdf:type owl:Thing)
- (eg:nForce owl:sameAs eg:unknownMB)
- (eg:nForce owl:sameAs eg:nForce)
- (eg:nForce rdf:type eg:MotherBoard)
- (eg:nForce rdf:type rdfs:Resource)
- (eg:nForce rdf:type a3b24:f7822755ad:-7ffd)
- (eg:nForce eg:hasGraphics eg:gamingGraphics)
- (eg:nForce eg:hasComponent eg:gamingGraphics)
Note that this includes inferences based on subClass inheritance (being an eg:MotherBoard
implies it is an owl:Thing and an rdfs:Resource), property inheritance (eg:hasComponent eg:gameGraphics
derives from hasGraphics being a subProperty of hasComponent) and cardinality reasoning (it is the sameAs eg:unknownMB because computers are defined to have only one motherboard and the two diffferent descriptions of whileBoxZX use these two different terms for the mother board). The anonymous rdf:type statement referencesthe "hasValue(eg:hasComponent, eg:gamingGraphics)" restriction mentioned in the definition of GamingComputer.
A second, typical operation is instance recognition. Testing if an individual is an instance of a class expression. In this case the whileBoxZX is identifiable as a GamingComputer because it is a Computer, is explicitly declared as having an appropriate bundle and can be inferred to have a gamingGraphics component from the combination of the nForce inferences we've already seen and the transitivity of hasComponent. We can test this using:
Resource gamingComputer = infmodel.getResource("urn:x-hp:eg/GamingComputer"); Resource whiteBox = infmodel.getResource("urn:x-hp:eg/whiteBoxZX"); if (infmodel.contains(whiteBox, RDF.type, gamingComputer)) { System.out.println("White box recognized as gaming computer"); } else { System.out.println("Failed to recognize white box correctly"); }
Which gnerates the output:
White box recognized as gaming computer
Finally, we can check for inconsistencies within the data by using the validation interface:
ValidityReport validity = infmodel.validate(); if (validity.isValid()) { System.out.println("OK"); } else { System.out.println("Conflicts"); for (Iterator i = validity.getReports(); i.hasNext(); ) { ValidityReport.Report report = (ValidityReport.Report)i.next(); System.out.println(" - " + report); } }
Which generates the output:
Conflicts - Error (conflict): Two individuals both same and different, may be due to disjoint classes or functional properties Culprit = eg:nForce2 Implicated node: eg:bigNameSpecialMB ... + 3 other similar reports
This is due to the two records for the bigName42 configuration referencing two motherboards which are explicitly defined to be different resources and thus violate the FunctionProperty nature of hasMotherBoard.