Skip to : [Content] [Navigation]
 

Pellet FAQ: Single Page Version

Alternatively, check out the Pellet FAQ: Multi-Page Version.

General

Are there any known bugs or issues with Pellet?

Yes, like any complex software system, Pellet has some bugs and lacks some features that you might want. Those issues that have been documented can be reviewed in the public issue tracker. Additionally, in some releases known bugs are documented in the BUGS.txt file included with the distribution.

If you believe you’ve found a new bug, please review the tickets that already exist the issue tracker. If your bug does not match an existing ticket, send a report detailing the error condition and including the data necessary to reproduce the bug to the pellet-users mailing list.

Which version of library X is shipped within Pellet?

Libraries shipped with Pellet come in a separate directory which, as of Pellet 1.5, contains a file named “version.txt” giving the information about the version of that library.

Which version of Pellet am I using?

If you are using an official release of Pellet, you can get version info by passing the -version option to the Pellet command line utility. For example, on a Unix-like system, from the distribution directory one would run

sh pellet.sh -version

And expect to see something like

Version : 1.4 Released: March 16 2007

Alternately, the org.mindswap.pellet.utils.VersionInfo class can be used in a Java program to determine the Pellet version.

I’m new to Pellet. How can I start?

Pellet’s basic functionality can be accessed through a command line interface using the class org.mindswap.pellet.Pellet. The Pellet distribution includes convenient shell scripts that will run this on most Java platforms. When run without arguments, it will produce a usage message describing available options and arguments.

To access this tool, download the latest release, unzip the distribution and get a command shell in the base directory of the distribution. If you are on a Windows platform, run the pellet.bat script. If you are on a Unix-like platforms (including a newer Mac), run the pellet.sh script.

For example, the following uses Pellet to classify the commonly referenced wine ontology

sh pellet.sh -s off -c TREE -if http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine.rdf

If you are new to OWL-DL, you may find the OWL Guide helpful. If you are comfortable with OWL DL but new to the additional features of OWL 1.1, you may find the OWL 1.1 Overview helpful.

If you are interested in using the reasoner in a Java program, a good place to start is the collection of example code included in the examples directory of the Pellet distribution. It includes source code demonstrating the use of Pellet with Jena and OWL-API.

Which version of Java does Pellet require?

Pellet requires a Java 5 (or greater) JVM; we test each Pellet release with Sun JVM. Other JVMs may or may not work, or work as well, as Sun JVMs.

Configuration

How can I control logging messages printed by Pellet?

Pellet uses log4j for logging. The verbosity of this logging can be controlled with a log4j configuration file. The distribution includes a sample configuration, src/log4j.properties. The location of the configuration file can be specified by setting the system property log4j.configuration. The location should be specified as a (relative or absolute) URL. For example, the following command would use a local file located in the current directory:

java -Dlog4j.configuration=file:my-logging.properties -jar lib\pellet.jar

If the system property is not set, the filename defaults to log4j.properties and the corresponding file inside pellet.jar will be used. By rebuilding the jar file you can change the default configuration.

Note that jena.jar also contains a log4j.properties file that will take precedence if it precedes pellet.jar in the classpath.

There has been some sample code posted to the mailing list that might be helpful.

How is Pellet configured?

Several Pellet features can be controlled by changing the configuration file. A sample configuration file, pellet.properties, can be found in the Pellet distribution. The location of the 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  -Dpellet.configuration=file:pellet.properties -jar lib\pellet.jar

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.

Reasoning

Does Pellet reason with OWL-Full ontologies?

OWL-DL restricts OWL-Full ontologies in several different ways as explained in Section 8.2 of OWL reference. Pellet relaxes most of the OWL-DL restrictions and handles OWL-Full ontologies (see the list below for more details).

Any OWL-Full feature that is not supported by the reasoner will be ignored. When an OWL-Full ontology is loaded to the reasoner, a series of warning messages will be printed about the axioms violating the OWL-DL restrictions. This behavior can be changed such that Pellet will refuse to load the OWL-Full ontology by throwing an exception. This can be achieved by setting the configuration option IGNORE_UNSUPPORTED_AXIOMS to false.

The following list contains all the OWL-DL restrictions defined in the OWL specification and for each restriction explains if/how Pellet relaxes that restriction:

  • OWL-DL Restriction: OWL-DL requires a pairwise separation between classes, datatypes, datatype properties, object properties, annotation properties, ontology properties (i.e., the import and versioning stuff), individuals, data values and the built-in vocabulary. This means that, for example, a class cannot be at the same time an individual.

    Pellet Restriction: Pellet uses punning semantics of OWL 1.1 to partially overcome the vocabulary separation restriction. The punning support in Pellet is explained here.
  • OWL-DL Restriction: In OWL-DL the set of object properties and datatype properties are disjoint. This implies that the following four property characteristics: o inverse of, o inverse functional, o symmetric, and o transitive can never be specified for datatype properties.

    Pellet Restriction: Pellet has these restrictions with the exception of inverse functional datatype properties. Pellet fully supports inverse functional datatype properties. Axioms violating other restrictions are ignored.
  • OWL-DL Restriction: OWL DL requires that no cardinality constraints (local nor global) can be placed on transitive properties or their inverses or any of their superproperties.

    Pellet Restriction: Pellet requires this restriction. Any transitivity axiom violating these restrictions are ignored (cardinality restrictions are not ignored).
  • OWL-DL Restriction: Annotations are allowed only under certain conditions. See Sec. 7.1 for details.

    Pellet Restriction: Annotations have no effect on reasoning results and will be completely ignored by Pellet regardless of the configuration option.
  • OWL-DL Restriction: Most RDF vocabulary cannot be used within OWL DL. See the OWL Semantics and Abstract Syntax document [OWL S&AS] for details.

    Pellet Restriction: Pellet relaxes this restriction by extending punning to built-in RDFS vocabulary. For example, if rdf:List is used in individual assertions it will be treated as a new class.
  • OWL-DL Restriction: All axioms must be well-formed, with no missing or extra components, and must form a tree-like structure. This constraint implies that all classes and properties that one refers to are explicitly typed as OWL classes or properties, respectively.

    Pellet Restriction: Pellet partially requires this restriction. All axioms need to be well-formed and any other axiom will be ignored. However, some URI’s might be untyped and Pellet will uses some heuristics to infer the type for those URI’s. For example, if a URI is used in a owl:subClassOf then that URI will be treated as if it is defined as an OWL class.
  • OWL-DL Restriction: Axioms (facts) about individual equality and difference must be about named individuals.

    Pellet Restriction: Pellet requires this restriction. If one uses owl:sameAs or owl:differentFrom on URI’s that are not defined as individuals, Pellet will use punning to infer that same URI’s are also used as individuals.

Does Pellet support 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 setting it equivalent to the enumeration of all members. A similar thing can be done for property assertions.

There’s an experimental implementation of ALCK (ALC + the K operator). There are two ways of using K right now: either restrictedly in the TBox, in the form of an epistemic rule; or in a query, where you can use K arbitrarily on classes and properties. More details are available. This implementation is in a preliminary state and not heavily tested. Let us know about bugs or problems by mailing the “Pellet list”mailto:pellet-users@lists.owldl.com.

Does Pellet support the Unique Name Assumption (UNA)?

With UNA every named individual is assumed to be different from every 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—the 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 turn this option on by changing the configuration file or programmatically accessing the PelletOptions class.

Does Pellet support rules?

Pellet supports a subset of SWRL called DL-Safe Rules. The following SWRL features are not currently supported by Pellet: class atoms with anonymous classes, data valued property atoms, and built-in functions.

You don’t need to use any utility function to use SWRL in Pellet. You can directly load the SWRL file into Pellet and rules will be parsed and processed. See the examples directory in the Pellet distribution for a sample program that shows how to use DL-safe rules with Pellet. You can either use the OWLAPI or Jena interface; they both handle SWRL. Using the configuration option DL_SAFE_RULES, the reasoner can be configured to ignore SWRL rules. Rules support is enabled by default and only the rules that use one of the mentioned unsupported features will be ignored (or an exception will be thrown based on the value of the configuration option IGNORE_UNSUPPORTED_AXIOMS).

What is punning? Does Pellet support punning?

Punning is the meta-modeling practice of using a single name to refer to any or all of an individual, a class, or a property. Complications of this practice are managed by restricting its use such that, for a given use of a name, context sufficiently disambiguates the entities to which it may refer. Punning is discussed in the OWL 1.1 overview document.

Yes, Pellet supports punning with a minor caveat. The same name should not be used for both an object property and a datatype property. Similarly, the same name should not be used for both a class and a datatype.

Query

How can I answer SPARQL queries with Pellet?

Pellet includes an optimized query engine capable of answering ABox queries. It can be accessed directly, using the API defined in the org.mindswap.pellet.query Java package. It has also been integrated with Pellet’s Jena bindings so that Jena’s query objects can be used with the Pellet’s query engine (see org.mindswap.pellet.jena.PelletQueryExecution). Note that if the query to be answered is not an ABox query, the Pellet query engine is inapplicable and the bindings will fall-back to using the default Jena query engine.

An example demonstrating use of the Pellet query engine in Jena is included in the examples directory of the Pellet distribution.

For interactive use, Pellet’s command line interface provides access to the query engine (through the Jena interface).

What is an ABox query?

An ABox query is a query about individuals and their relationship to data and other individuals through (datatype or object) properties. In SPARQL, an ABox query must satisfy three conditions:

  1. They contain no variables in the predicate position.
  2. Each property used in the predicate position is either a (datatype or object) property defined in the ontology or one of the following built-in properties: rdf:type, owl:sameIndividualAs, owl:differentFrom.
  3. If rdf:type is used in the predicate position, a constant URI denoting an OWL class (or a class expression) is used in the object position.

Jena Interface

How can I use Pellet with Jena?

There are two different ways to use Pellet in a Jena program: either using direct Pellet interface (highly recommended); or using Jena DIG interface (not recommended). The 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 than any other Jena reasoner:

// 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 does Pellet run slowly in TopBraid Composer?

We don’t support TopBraid Composer or any TopQuadrant products. Often, Pellet appears to run slowly in TopBraid Composer due to the nature of the integration performed by TopQuadrant. If you are experiencing problems using Pellet via TopBraid Composer, we recommend trying Pellet directly before reporting an issue or bug.

Why does Pellet produce different results than the Jena OWL reasoner?

There is one fundamental difference between Pellet in Jena and other existing Jena reasoners. Pellet treats the anonymous restrictions defined in an OWL ontology as syntactic expressions and does 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 are 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 expressions 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 it 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 still work as expected. For example, asking the question Student.hasSuperClass( restriction ) where restriction is the anonymous resource corresponding to the someValuesFrom restriction, Pellet will return true.

h2. How do I use Pellet with Jena concurrently? We document here the thread-safe use of Pellet in Jena applications, including operations and configuration options that may be problematic. We assume that the KB is represented and manipulated using a Jena @InfModel@ associated with a @PelletReasoner@. (Examples demonstrating this use model are included in the Pellet release distribution: see @examples/org/mindswap/pellet/examples/JenaReasoner.java@.) Concurrency in Jena, independent of Pellet, is discussed in the "Jena documentation":http://jena.sourceforge.net/how-to/concurrency.html. This includes discussion of locking mechanisms to control concurrent access to a single @Model@ object. h3. Basic Approach Pellet cannot be used via the Jena interface in a multi-threaded fashion without explicit calls to prepare the knowledge base following any model modification. Without explicit calls, the knowledge base will perform processing operations as needed, which may lead to concurrent modification of internal data structures and incorrect query results. To insure thread safety, modifications should be followed by a call to classify method on the @PelletInfGraph@ underlying the @InfModel@. The following code example illustrates this pattern. 

Model model = ModelFactory.createOntologyModel( PelletReasonerFactory.THE_SPEC, model );
model.read( "http://example.org/ontology" );

/* ... any additional model modification ... */

((PelletInfGraph) model.getGraph()).classify();
model.query( ... );
Note that because the classify method performs many operations, including loading the knowledge base, classification, and individual realization, it may be a costly operation. @classify@ does not need to be called after each modification, but it must be called between any modification and query operations. h3. Constraints In addition to forcing processing between modification and query operations, some additional use constraints should be enforced. h4. Incremental Reasoning Incremental reasoning, as implemented in Pellet-1.5.1, is not-thread safe. It is disabled by default, and should not be enabled if Pellet is used concurrently by multiple threads. h4. Complex Concept Descriptions Concurrent query answering is possible, in part, because the reasoner is able to classify the concept hierarchy, as a batch operation, prior to any query requests. Queries that involve unnamed concepts require classification of the concept at query time, causing modifications to internal data structures that are not thread-safe. The following SPARQL query includes a concept that makes the query unsafe 

SELECT ?C WHERE {?C rdfs:subClassOf [
        rdf:type owl:Restriction ;
        owl:onProperty ub:takesCourse ;
        owl:minCardinality 2
            ]
}
To avoid problems during concurrent querying, queries should only use named concepts. If necessary, queries using unnamed concepts should be executed without any concurrent model access. h4. Queries with Posited Models Jena provides a method @listStatements(Resource,Property,RDFNode,Model)@ in the @InfModel@ interface that permits queries to use vocabulary terms that exist in a posited @Model@, but not in the @InfModel@ being queried. This method causes temporary modifications to internal data structures and cannot safely be used with concurrent query operations. If necessary, the method should be executed without any concurrent model access.

What is the difference between the Pellet and Jena query engines?

The Jena query engine is RDF triple based, so to produce variable bindings it works one triple at a time. In contrast, the Pellet query engine considers the entire conjunctive query. This difference causes the engines to have different performance characteristics and in some cases yields different results.

First, by using a level of representation consistent with the logic, the Pellet query engine can perform optimizations that are inaccessible to the Jena query engine. These optimizations often yield a significant speed-up in query answering.

Second, results may differ based on handling of blank nodes in queries. The semantics of SPARQL are such that blank nodes need not be bound to asserted individuals and can match individuals that are inferred (such as those from existential restrictions and minimum cardinality constraints). The Pellet engine will produce results using these inferred individuals and the Jena engine will not. An example demonstrating how this can change results is included in the examples directory of the Pellet distribution and is accessible in the svn repository.

OWL-API Interface

How can I use Pellet with OWL-API?

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

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

// create an ontology manager
OWLOntologyManager manager = OWLManager.createOWLOntologyManager();

// create the Pellet reasoner
Reasoner reasoner = new Reasoner( manager );

// ontology that will be used
String file = "http://www.mindswap.org/2004/owl/mindswappers";

// Load the ontology 
OWLOntology ontology = manager.loadOntology( URI.create( file ) );
reasoner.loadOntology( ontology );

// get the instances of a class
URI PersonURI = URI.create( "http://xmlns.com/foaf/0.1/Person" );
OWLClass Person = manager.getOWLDataFactory().getOWLClass( PersonURI );   
Set instances  = reasoner.getInstances( Person, false );

Pellet 1.5 uses a newer snapshot of OWL-API including support for OWL 1.1, built from development sources. See version.txt included with OWL-API in the Pellet source tree for details on obtaining the source for this revision of OWL-API.

OWL-API is under rapid development and the best source of documentation, including general examples, is likely to be the project page at SourceForge

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 starts you will see a message:

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 the following command at the command prompt:

pellet-dig -port 8080

KRSS

How can I process KRSS files with Pellet?

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

What parts of the KRSS syntax does Pellet support?

Pellet’s KRSS support was implemented to process the KRSS ontologies found at the DL Benchmark Suite. These ontologies use a slightly different syntax than the official KRSS specification. The main difference is in define-primitive-role definitions where super roles need to be defined with the identifier :parents. Pellet also support the definition of domain and range restriction inside define-primitive-role definitions via :domain and :range identifiers respectively (some example KRSS ontologies can be found at Pellet SVN).

Pellet does not support any KRSS feature that is not directly expressible in OWL-DL, e.g. role composition, transitive closure, role closure, rules, etc. As in KRSS specification, Pellet requires any concept, role, or individual name defined before its first use.

Pellet also supports the native FaCT++ syntax which is similar to but not compatible with KRSS syntax. As far as we know, there is no explicit documentation describing this syntax but the OWL Ontology Converter can be used to convert OWL ontologies into FaCT++ syntax.

Note that, KRSS support in Pellet is not considered to be robust or usable. There is limited support for loading KRSS files into Pellet (see the other FAQ entry) and there are no plans to update or maintain the KRSS parser in the future.

Tuning Performance

How can I tune Pellet for ontologies with rules?

Pellet 1.5.1 and 1.5.2 include an optimization that is disabled by default, but has shown to be stable and much faster when reasoning with ontologies that include DL-Safe rules. To enable this optimization, add the following initialization.


org.mindswap.pellet.PelletOptions.USE_CONTINUOUS_RULES=true;

This setting will be the default beginning with Pellet 2.0.

News

More →