Troubleshooting Reasoning

This page provides some guidance for troubleshooting common issues with reasoning.

Page Contents

Performance Hints
Not Seeing Expected Results?

Performance Hints

The query rewriting approach suggests some guidelines for more efficient query answering.

Hierarchies and Queries

Avoid unnecessarily deep class/property hierarchies.

If you do not need to model several different types of a given class or property in your schema, then don’t do that! The reason shallow hierarchies are desirable is that the maximal hierarchy depth in the schema partly determines the maximal size of the EQs (equivalent queries) produced by Stardog. In general, the larger the EQ, the longer it takes to evaluate.

For example, suppose our schema contains a very thorough and detailed set of subclasses of the class :Employee:

:Manager rdfs:subClassOf :Employee
:SeniorManager rdfs:subClassOf :Manager
...

:Supervisor rdfs:subClassOf :Employee
:DepartmentSupervisor rdfs:subClassOf :Supervisor
...

:Secretary rdfs:subClassOf :Employee
...

If we wanted to retrieve the set of all employees, Stardog would produce an EQ containing a query of the following form for every subclass :Ci of :Employee:

SELECT ?employee WHERE { 
  ?employee rdf:type :Ci 
}

Thus, ask the most specific query sufficient for your use case. Why? More general queries – that is, queries that contain concepts high up in the class hierarchy defined by the schema – will typically yield larger EQs.

Avoid variable predicates and variable types.

When reasoning is enabled, triple patterns with a variable in the predicate position or a variable in the object position for rdf:type often cause performance problems, especially with large class hierarchies. In some cases, Stardog’s optimizer could address this issue by using other patterns in the query which bind those variables, but it is not always possible. You may consider enumerating values for those variables explicitly, for example, instead of:

SELECT * WHERE { 
  ?employeeX ?property ?employeeY 
}

use:

SELECT * WHERE { 
  ?employeeX :colleague | :manager ?employeeX 
}

or, if all relevant properties have a common super-property, say, :worksWith, then:

SELECT * WHERE {
    ?employeeX ?property ?employeeX .
    ?property rdfs:subPropertyOf :worksWith
}

should also work better than the first query (though likely less efficient than the second).

Domains and Ranges

Specify domain and range of the properties in the schema.

These types of axioms can improve query performance significantly. Consider the following query asking for people and the employees they manage:

SELECT ?manager ?employee WHERE
  { ?manager :manages ?employee.
    ?employee rdf:type :Employee. }

We know this query would cause a large EQ given a deep hierarchy of :Employee subclasses. However, if we added the following single range axiom:

:manages rdfs:range :Employee

the EQ would collapse to:

SELECT ?manager ?employee WHERE 
{ ?manager :manages ?employee }

which is considerably easier to evaluate.

Very Large Schemas

If you are working with a very large schema like SNOMED, there are couple things to note. First of all, Stardog reasoning works by pulling the complete schema into memory. This means you might need to increase the default memory settings for Stardog for a large schema. Stardog performs all schema reasoning upfront and only once but waits until the first reasoning query arrives. With a large schema, this step can be slow, but subsequent reasoning queries will be fast. Also note that Stardog will update schema reasoning results automatically after the database is modified, so there will be some processing time spent then.

Reasoning with very expressive schemas can be time consuming and use a lot of memory. To get the best performance out of Stardog with large schemas, limit the expressivity of your schema to OWL 2 EL. You can also set the reasoning type of the database to EL, and Stardog will automatically filter any axiom outside the EL expressivity. See Reasoning Types for more details on reasoning types. OWL 2 EL allows range declarations for properties and user-defined datatypes, but avoiding these two constructs will further improve schema reasoning performance in Stardog.

Not Seeing Expected Results?

Here are a few things you might want to consider.

Are variable types ambiguous?

When a SPARQL query gets executed, each variable is bound to a URI, blank node, or a literal to form a particular result (a collection of these results is a result set). In the context of reasoning, URIs might represent different entities: individuals, classes, properties, etc. According to the relevant standard, every variable in a SPARQL query must bind to at most one of these types of entity.

Stardog can often figure out the right entity type from the query itself (e.g., given the triple pattern ?i ?p "a literal", we know ?p is supposed to bind to a data property); however, sometimes this isn’t possible (e.g., ?s ?p ?o). In case the types can’t be determined automatically, Stardog logs a message and evaluates the query by making some assumptions (which may not be what the query writer intended) about the types of variables.

You can add one or more “type triples” to the query to resolve these ambiguities. These are harmless and won’t otherwise affect query evaluation. They can also be added to the data (instead of to queries) if that fits your use case better.

These type triples have the form ?var a TYPE, where TYPE is a URI representing the type of entity to which the variable ?var is supposed to bind. The most common are owl:ObjectProperty or owl:DatatypeProperty; in some cases, you might want owl:NamedIndividual, or owl:Class. For instance, you can use the following query to retrieve all object properties and their characteristics; without the type triple, ?s will bind only to individuals:

SELECT ?o
WHERE {
   ?s rdf:type ?o.
   ?s a owl:ObjectProperty.
}

Since Stardog now knows that ?s should bind to an object property, it can now infer that ?o binds to property characteristics of ?s.

Is the schema where you think it is?

Stardog will extract the schema from all named graphs and the default graph.

If you require that the schema only be extracted from one or more specific named graphs, you must tell Stardog where to find the schema. See the database option reasoning.schema.graphs’s description for details. You can also use the reasoning schema command to export the contents of the schema to see exactly what is included in the schema that Stardog uses. This is discussed under Reasoning Schemas earlier in this section.

Are you using the right reasoning type?

Perhaps some of the modeling constructs (a.k.a. axioms) in your database are being ignored. By default, Stardog uses the SL reasoning type. You can find out which axioms are being ignored by looking at the Stardog log file.

Are you using DL?

Stardog supports full OWL 2 DL reasoning, but only for data that fits into main memory.

Are you using SWRL?

SWRL rules – whether using SWRL syntax or Stardog Rules Syntax – are only taken into account using the SL reasoning type.

Performance Hints
Not Seeing Expected Results?