There are two principle strategies for rule-based inference called 'forward-chaining' and 'backward-chaining'. They can be briefly explained as follows:
Both of these strategies have their advantages and disadvantages, which have been well studied in the history of KR and expert systems. Attempts to overcome the weak points have led to the development of various hybrid strategies (involving partial forward- and backward-chaining) which have proven efficient in many contexts.
Reasoning and materialization are discussed in some detail in the GraphDB Primer .
RDFS inference is achieved via a set of axiomatic triples and entailment rules. These rules allow the full set of valid inferences using RDFS semantics to be determined. Herman ter Horst in  defines RDFS extensions for more general rule support and a fragment of OWL, which is more expressive than DLP and fully compatible with RDFS. First, he defines R-entailment, which extends RDFS-entailment in the following ways:
GraphDB uses a notation almost identical to R-Entailment defined by Horst. One major difference is that consistency checking rules are not supported. GraphDB performs reasoning based on forward-chaining of entailment rules defined using RDF triple patterns with variables. GraphDB reasoning strategy is 'total materialisation', which is introduced in the GraphDB Primer in the Reasoning Strategies topic.
The rule format and the semantics enforced is analogous to R-entailment (see the Rule-Based Inference topic on page and ) with the following differences:
GraphDB can be configured via "rule-sets" – sets of axiomatic triples and entailment rules - that determine the applied semantics. The implementation of GraphDB relies on a compile stage, during which the rules are compiled into Java source code that is then further compiled using the Java compiler and merged together with the inference engine.
A rule-set file has three sections named Prefices, Axioms, and Rules. All sections are mandatory and must appear sequentially in this order. Comments are allowed anywhere and follow the Java convention, i.e. "/* ... */" for block comments and "//" for end of line comments.
This section defines abbreviations for the namespaces used in the rest of the file. The syntax is:
A typical prefices section might look like this:
This section is used to assert 'axiomatic triples', which are usually used to describe the meta-level primitives used to define the schema, such as rdf:type, rdfs:Class, etc. This section contains a list of the (variable free) triples, one per line. For example, the RDF axiomatic triples are defined thus:
This section is used to define entailment rules. Each definition consists of premises and corollaries that are RDF statements defined with subject, predicate and object components. Any component can be a variable, blank node, literal, full URI or the short name for a URI. Variables are alpha-numeric and must begin with a letter.
Where each premise and consequence is on a separate line. The following example helps to illustrate the possibilities:
The symbols p, x, y, z and a are variables. The second rule contains two constraints that reduce the number of bindings for each premise, i.e. they 'filter out' those statements where the constraint does not hold.
A GraphDB repository will use the configured rule-set to compute all inferred statements at load time. To some extent, this process increases processing cost and time taken to load a repository with a large amount of data. However, it has the desirable advantage that subsequent query evaluation can proceed extremely quickly.
GraphDB stores explicit and implicit statements, i.e. those statements inferred (materialised) from the explicit statements. It follows therefore, that when explicit statements are removed from the repository, any implicit statements that rely on the removed statement must also be removed.
There are a number of pre-defined rule-sets provided with GraphDB-Lite that cover various well known knowledge representation formalisms. The following table gives the details:
The GraphDB-Lite reasoner does not support the quad patterns that are available in GraphDB-SE. Therefore, it manages auxiliary ternary predicates (associated with the expansion of LIST structures in the bodies of GraphDB2-RL entailment rules) using blank nodes. This is much less efficient than GraphDB-SE, so it is provided in two versions. owl2-rl-conf contains all the rules, but is not recommended for datasets larger than a few tens of thousands of statements. owl2-rl-reduced is identical, except that the prp-key rule has been removed. This makes it suitable for datasets of several hundreds of thousands of statements.
The implementation of OWL2 QL is non-conformant with the W3C OWL2 profiles recommendation  as shown in Table 3:
GraphDB has an internal rule compiler that can be used to configure a custom set of inference rules and axioms. The user may define a custom rule-set (see section 7.1.2) in a .pie file (e.g. MySemantics.pie). The easiest way to create a custom rule-set is to start modifying one of the .pie files that were used to build the precompiled rule-sets. All of these are provided as part of the GraphDB-Lite distribution.
There are several features in the RDFS and OWL specifications that result in rather inefficient entailment rules and axioms, which can have a significant impact on the performance of a reasoning engine. Such examples are:
Although the above inferences are correct and important for the completeness of the formal semantics, users rarely execute queries whose results are affected by the existence of such statements. Moreover, these inferences generate so many inferred statements that performance and scalability can be severely degraded.
These optimisations were previously achieved using the partialRDFS parameter, but are now achieved by using a previously optimised built-in rule-set, see the ruleset parameter in the configuration section for a complete list.
Skip to end of metadata Go to start of metadata