Pellet—The Open Source OWL DL Reasoner.

Standard Reasoning Services

Pellet supports reasoning with the full expressivity of OWL-DL (SHOIN(D) in Description Logic jargon) and has been extended to support OWL 1.1 (the DL SROIQ(D)). OWL 1.1 adds the following language constructs to OWL DL:

Pellet also provides reasoning with the following features from OWL Full:

Pellet provides all the standard inference services that are traditionally provided by DL reasoners:

Consistency checking

Ensures that an ontology does not contain any contradictory facts. The OWL Semantics standard provides the formal definition of ontology consistency used by Pellet.

Concept satisfiability

Determines whether it’s possible for a class to have any instances. If a class is unsatisfiable, then defining an instance of that class will cause the whole ontology to be inconsistent.

Classification

Computes the subclass relations between every named class to create the complete class hierarchy. The class hierarchy can be used to answer queries such as getting all or only the direct subclasses of a class.

Realization

Finds the most specific classes that an individual belongs to; i.e., realization computes the direct types for each of the individuals. Realization can only be performed after classification since direct types are defined with respect to a class hierarchy. Using the classification hierarchy, it is also possible to get all the types for each individual.

Multiple Interfaces to the Reasoner

Pellet provides many different ways to access its reasoning capabilities:

Please see the documentation provided in the distribution package for details about these interfaces, as well as example programs for using Pellet from Jena and OWL-API libraries.

Conjunctive Query Answering

Pellet includes an ABox query engine which supports answering conjunctive ABox queries with or without non-distinguished variables. Answering queries that contain cycles through non-distinguished variables with respect to an OWL-DL ontology is an open problem and is not presently supported. Cycles through distinguished variables can be handled and several optimizations have been implemented in Pellet’s query engine. In the presence of non-distinguished query variables, rolling-up technique the is used to answer the queries.

Queries can be formulated using SPARQL. The SPARQL query forms SELECT, CONSTRUCT, and ASK are supported; DESCRIBE isn’t, neither are OPTIONAL or FILTER. It’s possible to answer such queries using Jena’s SPARQL query engine on a Pellet-backed inference model. Please see the Pellet FAQ for the differences between the two query engines.

Datatype Reasoning

OWL allows ontologies to use simple built-in datatypes from XML Schema. XML Schema has a rich set of basic datatypes including various numeric types, strings, and date-time types. It also has several mechanisms for creating new types out of the base types, e.g. defining an integer interval as a new datatype that extends the built-in integer type.

OWL 1.1 specification defines an inline syntax for embedding the definitions of user-defined datatypes in OWL files as in this example ontology. Pellet supports reasoning with all the built-in datatypes defined in XML Schema plus any user-defined datatype that extends numeric or date/time derived types.

Rules Support

Pellet has a preliminary implementation of a direct tableau algorithm for a DL-safe rules extension to OWL-DL. This implementation allows one to load and reason with DL-safe rules encoded in SWRL but some features of SWRL are not supported (See this FAQ entry for more details). The initial empirical results are encouraging. We think that the DL-safe implementation is practical for small to mid-sized ontologies.

Pellet has also been coupled with a Datalog reasoner to support AL-log (Datalog + OWL DL). This coupling implements the traditional algorithm and a new pre-compilation technique that is incomplete but more efficient. The key idea is to preprocess all of the DL atoms that appear in the Datalog rules and include them as facts in the Datalog subsystem. Once the preprocessing is done, queries can be answered by the Datalog component using any of the known techniques for Datalog query evaluation. You can find more information about this coupling here.

Ontology Analysis and Repair

OWL has two major dialects, OWL DL and OWL Full—the former is a subset of the latter. All OWL ontologies are encoded as RDF graphs.

OWL DL imposes a number of restrictions on RDF graphs, some of which are substantial (e.g., that the set of class names and individual names be disjoint) and some less so (that every item have a rdf:type triple). Ensuring that an RDF document meets all the restrictions can be a relatively difficult task for authors. Many existing OWL documents are nominally OWL Full, even though their authors intend for them to be OWL DL.

Pellet incorporates a number of heuristics to detect OWL Full ontologies that can be expressed as OWL DL ontologies and can repair them accordingly.

Ontology Debugging

Detection of unsatisfiable concepts in an ontology is a simple task. However, the diagnosis and resolution of the bug is generally not supported at all. For example, no explanation is typically given as to why the error occurs (e.g., by pinpointing axioms in the ontology responsible for the clash) or how dependencies between classes cause the error to propagate (i.e., by distinguishing root from derived unsatisfiable classes).

Pellet provides support for both kinds of tasks by pinpointing axioms that cause an inconsistency and the relation between unsatisfiable concepts.

Incremental Reasoning

An important challenge for Pellet is to reason with changing knowledge bases. The current state of the art in DL reasoners does not try to handle updates incrementally. Pellet presently has some support to maintain reasoner state. For example, if there are additions only to the ABox (and there are no nominals), then the previous classification tree is kept and reused. Work is ongoing to improve Pellet’s incremental reasoning services.

Preliminary results show up to three orders of magnitude improvement in consistency checking after an ABox addition or deletion.

Features