Archive

Posts Tagged ‘pellet’

Short Tutorial on using Pellet + OWLAPI + SWRL Rules

December 1, 2009 9 comments

I’ve been looking through Pellet and OWLAPI documentation over the past few days, looking for a good example of running existing SWRL rules via the OWLAPI using Pellet’s built-in DL-safe SWRL support. SWRL is used in ontology mappping, and is a powerful tool. Up until now, I’ve just used the SWRLTab, but needed to start running my rules via plain Java programs, and so needed to code the running of the mapping rules in the OWLAPI (which I’m more familiar with than Jena). Once I clean up the test code, I’ll link it from here so others can take a look if they feel like it.

This example uses the following versions of the software:

Pre-existing Examples

Pellet provides a SWRL rule example (RulesExample.java in the Pellet download), but only for Jena, and not the OWLAPI. The OWLAPI Example3.java covers the creation of SWRL rules, but not their running. Therefore, to help others who may be walking the same path as I, a short example of OWLAPI + Pellet + SWRL follows.

New Example

This example assumes that you already have the classes, individuals, and rules mentioned below in an OWL file or files. Here is how the test ontology looks, before running the rule (you can use reasoner.getKB().printClassTree() to get this sort of output):


owl:Thing
source:SourceA
- (source:indvSourceA)
source:SourceB - (source:indvSourceB)
target:TargetA
target:TargetB

The example SWRL rule is this (the rule.toString() method prints this kind of output, while iterating over ontology.getRules()):


Rule( antecedent(SourceA(?x)) consequent(TargetA(?x)) )

Please note that if you want to modularise your OWL files, as I do (I have different files for the source classes, the target classes, the source individuals, the target individuals, and the rules) then make sure your owl:imports in the primary OWL ontology are correct, and that you’ve mapped them correctly with the SimpleURIMapper class and the manager.addURIMapper(mapper)method. I will update this post with some unit tests of this setup once I’ve cleaned up the code for public consumption.

Once you have your ontology properly loaded into an OWLAPI OWLOntology class, you should simply realize the ontology with the following command to run the SWRL rules:


getReasoner().getKB().realize();

After this command, all that’s left to do is save the new inferences. In this simple case, one individual is asserted to also be a child of the TargetA class, as follows:


owl:Thing
source:SourceA - (source:indvSourceA)
source:SourceB - (source:indvSourceB)
target:TargetA - (source:indvSourceA)
target:TargetB

You can do this by using the following code to explicitly save the new inferences to a separate ontology file. You can modify InferredOntologyGenerator to just save a subset of the inferences, if you like. Have a look in the OWLAPI code or javadoc for more information. Alternatively, you could just iterate over the ABox and just save the new individuals to a file. Here’s the code for saving the ontology to a new location:


OWLOntology exportedOntology = manager.createOntology( URI.create( outputLogicalUri ) );
InferredOntologyGenerator generator = new InferredOntologyGenerator( reasoner );
generator.fillOntology( manager, exportedOntology );
manager.saveOntology( exportedOntology, new RDFXMLOntologyFormat(), URI.create( outputPhysicalUri ) );

I hope this helps some people!

Follow

Get every new post delivered to your Inbox.

Join 493 other followers