pellet.owldl.com

The information on this page is kept for historical/archival reasons. These pages are not updated any more. Please update your link.

Frequently Asked Questions

Index

Answers

General

Does Pellet support Unique Name Assumption (UNA)?

With UNA every named individual is assumed to be different from each other. OWL semantics do not adopt UNA but it is possible to mimic UNA by having an owl:AllDifferent description and adding all the named individuals in the owl:distinctMembers list. However, maintaining such a list is costly (size of the input file is increased considerably and each individual addition and removal affects the list). Pellet provides an option USE_UNIQUE_NAME_ASSUMPTION to enable UNA in the reasoning process. You can set turn this option on by changing the configuration file or programmatically accessing the PelletOptions class.
Can I use Pellet to do Closed World Reasoning?

Some forms of closed world can be encoded in an OWL ontology by explicitly limiting the universe to the known individuals, e.g. setting owl:Thing equivalent to an enumeration of all the known individuals (using owl:oneOf). The extension of a class can also be closed by settng it equivalent to the numeration of all members. Similar can be done for property assertions.

There's an implementation of ALCK (ALC + the K operator) in an SVN branch. There are two ways of using K right now: either restrictedly in the TBox, in the form of an epistemic rule, or in query, where you can use K arbitrarily on classes/properties. See this paper for more information. There are also some examples in the SVN branch and an online demo. Note that, this implementation is in a preliminary state and not heavily tested. Let us know about bugs/problems by sending an e-mail to the Pellet mailing list.
How can I configure Pellet

Several feature of Pellet can be controlled by changing the configuration file. A sample configuration file named "pellet.properties" can be found in the Pellet distribution. The location of the used configuration file should be specified by setting the system property "pellet.configuration". The location should be specified as a (relative or absolute) URL. For example, the following command would use the local file located at the current directory:

java -jar lib\pellet.jar -Dpellet.configuration=file:pellet.properties

If the system property is not set, the configuration file inside pellet.jar will be used. By rebuilding the jar file you can change the default configuration. See the sample configuration file for the description of parameters that can be configured. Note that, these configuration parameters can also be controlled programmatically by accessing the PelletOptions class.

Jena Interface

How can I use Pellet in my Jena based program?

There are two different ways to use Pellet in a Jena program 1) using direct Pellet interface (highly recommended) 2) using Jena DIG interface (not recommended). Direct Pellet interface is much more efficient (e.g. does not have the HTTP communication overhead) and provides more inferences (DIG protocol has some limitations). Using the direct interface is not any different any other Jena reasoner. See the following example code:

// ontology that will be used String ont = "http://www.mindswap.org/2004/owl/mindswappers"; // create an empty ontology model using Pellet spec OntModel model = ModelFactory.createOntologyModel( PelletReasonerFactory.THE_SPEC ); // read the file model.read( ont ); // get the instances of a class OntClass Person = model.getOntClass( "http://xmlns.com/foaf/0.1/Person" ); Iterator instances = Person.listInstances();

See the examples directory in the Pellet distribution for more examples.

Why do I get different results when I use Pellet through Jena DIG interface?

There is one fundamental difference between Pellet reasoner implementation in Jena and other existing Jena reasoners. Pellet treats the anonymous restrictions defined in an OWL ontology as syntactic expressions and do not return them as answers to any query. Consider the following example:
```
  Class(<a:Person> partial restriction(<a:hasAddress> someValuesFrom(<a:Address>))
  Class(<a:Student> partial <a:Person>))
  ObjectProperty(a:hasAddress Functional)
```
If this ontology is loaded in an OntModel backed by Pellet calling Student.listSuperClasses() would not include the restriction in the result. There are several reasons for this behavior: Treating each restriction as a named class would make it harder to reason with the ontology and the results you get in the end is not that useful. For example, in the above example, the reasoner can also return restriction(<a:hasAddress> minCardinality(1)) or restriction(<a:hasAddress> maxCardinality(1)) or restriction(<a:hasAddress> allValuesFrom(<a:Address>)) as a super class because they are all entailed by the above definition. Once class expression are considered, there are infinitely many possibilities, e.g. maxCardinality(1) implies maxCardinality(2) and so on. For this reason, Pellet will not return a restriction in an answer just because they physically exists in the ontology. However, one needs to get the syntactic definitions in the ontology and all the results Pellet returns are concatenated by the answers from the raw model. This means calling Person.listSuperClasses() for the above example would include the restriction in the results.

Note that, all the boolean functions would still work as expected. For example, asking the question like Student.hasSuperClass( restriction ) where restriction is the anonymous resource corresponding to the someValuesFrom restriction, Pellet will return true.

OWL-API Interface

How can I use Pellet in my OWL-API based program?

Pellet implements various reasoner interfaces provided in the OWL-API. You can create a Pellet reasoner and then use it as any other reasoner. See the following code:


    // import 
    org.mindswap.pellet.owlapi.Reasoner

    

    // create the Pellet 
reasoner

    Reasoner reasoner = new Reasoner();



    // ontology that will be used


    String file = "http://www.mindswap.org/2004/owl/mindswappers";



    // Load the ontology


    OWLOntology ontology = OntologyHelper.getOntology( 
URI.create( file ) );   

    reasoner.setOntology( ontology );

        

    // get 
the instances of a class


    OWLClass Person = reasoner.getClass( URI.create( "http://xmlns.com/foaf/0.1/Person" ) );    

    Set instances  = reasoner.allInstancesOf( Person );

DIG Interface

How can I use Pellet with Protégé?

Pellet comes with a DIG server that you can use with Protégé. You can start the DIG server by running pellet-dig.bat on Windows systems and by running pellet-dig.sh on Unix-like systems. You need to make sure that the port number used by Pellet and Protégé is the same. When Pellet DIG server start you will see a message like the following:

PelletDIGServer Version 1.3 (April 17 2006)
Port: 8081

In Protégé, go to "OWL" menu and select "Preferences". For the "Reasoner URL" value enter "http://localhost:8081" and hit the close button. Or alternatively you can start Pellet DIG server using the port number defined in Protégé, e.g. type pellet-dig -port 8080 in the command prompt.

KRSS Interface

How can I use Pellet to process KRSS files?

There is a separate simple command line program provided to process files written in KRSS syntax. This program is similar to the Pellet command line version and provides options to classify or realize KRSS ontologies. You can run the following command to see the options available:

java -cp lib/pellet.jar org.mindswap.pellet.PelletKRSS

The KnowledgeBase.loadKRSS(Reader) function also provides programmatic support to load KRSS files to a Pellet knowledge base

Mindswap

Maryland Information and Network Dynamics Lab Semantic Web Agents Project

Pellet has been moved to http://pellet.owldl.com

Frequently Asked Questions

Index

General

Jena Interface

OWL-API Interface

DIG Interface

KRSS Interface

Answers

General

Jena Interface

OWL-API Interface

DIG Interface

KRSS Interface