Comment: Changed text to show that all sections in the rule file are required.
Reasoning and materialization are discussed in some detail in the OWLIM Primer .
rules without consequences are used to detect inconsistency (integrity constraints).
OWLIM-SE can be configured via "rule-sets" – sets of axiomatic triples, consistency checks and entailment rules - that determine the applied semantics. The implementation of OWLIM-SE 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.
This section is used to define entailment rules and consistency checks, which share a similar format. Each definition consists of premises and corollaries that are RDF statements defined with subject, predicate, object and optional context components. The subject, predicate and object can each be a variable, blank node, literal, full URI or the short name for a URI. If given, the context must be a full URI or a short name for a URI.
Furthermore, inequality constraints can be used to state that the values of the variables in a statement must not be equal to some specific full URI (or its short name) or to the value of another variable within the same rule. The behaviour of an inequality constraint depends whether it is placed in the body or head of a rule. If it is placed in the body of a rule, then the whole rule will not 'fire' is the constraint fails, i.e. the constraint can be next to any statement pattern in the body of a rule with the same behaviour (the constraint does not have to be placed next to the variables it references). If the constraint is in the head, then its location is significant, because a constraint that does not hold will prevent only the statement it is adjacent to from being inferred.
The RIF rules that implement prp-spo2 use a relation (unrelated to the input or generated triples) called _checkChain. The OWLIM implementation maps this relation to the 'invisible' context of the same name with the addition of [Context <onto:_checkChain>] to certain statement patterns. Generated statements with this context can only used for bindings to rule premises when the exact same context is specified in the rule premise. The generated statements with this context will not be used for any other rules.
Consistency checks are used to ensure that the data model is in a consistent state and are applied whenever an update transaction is committed. The syntax is similar to that of rules, except that Consistency replaces the Id tag that introduces normal rules and furthermore consistency checks do not need to have any consequences. Consistency checks that have no consequences will indicate an inconsistency whenever their premises can be satisfied, e.g.
These inconsistency checks will output an error message to standard output whenever their premises are satisfied. No other action will be taken (no exception is thrown and the behaviour of the repository is not changed). The second consistency check describes a contradiction, which are typically expressed by inconsistency checks without consequences.
Consistency checks can have multiple consequences, but the semantics will remain the same – when all the premises are satisfied and one of the consequences is not found in the repository, then the data is inconsistent and an error message is written to standard output. The error message will include the statements that caused the inconsistency. The mechanism of inconsistency checking is switched off by default. It can be switched on by using the boolean parameter check-for-inconsistencies, see section 8.5.
An OWLIM 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.
Apart from a number of optimisations, the approach taken by OWLIM is one of 'total materialization', where the inference rules are applied repeatedly to the asserted (explicit) statements until no further inferred (implicit) statements are produced.
OWLIM stores explicit and implicit statements, i.e. those statements inferred (materialized) 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.
In previous versions of OWLIM, this was achieved with a re-computation of the full closure (minimal model), i.e. applying the entailment rules to all explicit statements and computing the inferences. This approach guarantees correctness, but does not scale - the computation is increasingly slow and computationally expensive in proportion to the number of explicit statements and the complexity of the entailment rule-set.
If the statement is purely implicit statement (a statement can be both explicit and implicit and if so then it is not considered purely implicit) then mark it as deleted (prevent it from being returned by the iterators) and check whether it is supported by other statements. The isSupported() method uses queries which contain the premises of the rules and the variables of the rules are preliminarily bound using the statement in question. That is to say the isSupported() method starts from the projection of the query and then checks whether the query will return results (at least one), i.e. this method performs backward chaining.
If a result is returned by any query (every rule is represented by a query) in isSupported() then this statement can be still derived from other statements in the repository, so it must not be deleted (its status is returned to 'inferred').
Special care is taken is taken when retracting owl:sameAs statements, so that the algorithm still works correctly when modifying equivalence classes. By default, OWLIM-SE uses the approach described above to dramatically improve performance when statements are deleted from the repository. This behaviour can be switched on and off with the repository parameter enableSmoothDelete described in the configuration section.
One consequence of this algorithm, is that deletion can still have poor performance when deleting schema statements, due to the (probably) large number of implicit statements inferred from them.
The forward chaining part of the algorithm terminates as soon as it detects that a statement is read only, because if it cannot be deleted there is no need to look for statements derived from it. For this reason, performance can be greatly improved when all schema statements are made read-only by importing ontologies (and OWL/RDFS vocabularies) using the imports repository parameter.
where ?subject and ?object can be anything, OWLIM will use the smooth-delete algorithm, but will also traverse read-only statements and allow them to be deleted/inserted. Such transactions are likely to be be much more computationally expensive to achieve, but are intended for the occasional, offline update to otherwise read-only schemas. The advantage is that fast-delete can still be used, but a repository export and import is not required when making a modification to a schema.
Note that all rule-sets do not support data-type reasoning, which is the main reason that OWL-Horst is not the same as pD*. The rule-set to be used for a specific repository is defined through the ruleset parameter. There are optimized versions of all rule-sets that avoid some little used inferences.
OWLIM has an internal rule compiler that can be configured with a custom set of inference rules and axioms. The user may define a custom rule-set (see 'The Rule Language' on page ) 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 OWLIM-SE distribution.
The user should specify the custom rule-set via the ruleset configuration parameter. The value of the ruleset parameter is interpreted as a filename and '.pie' is appended when not present. This file is processed to create Java source code that is compiled using the compiler from the Java Development Kit (JDK). The compiler is invoked using the mechanism provided by the JDK version 1.6 (or later). Therefore a prerequisite for using custom rule-sets is that the Java Virtual Machine (JVM) from a JDK version 1.6 (or later) is used to run the application. If all goes well, the class is loaded dynamically and instantiated for further use by OWLIM-SE during inference. The intermediate files are created in the folder that is pointed by the java.io.tmpdir system property. The JVM should have sufficient rights to read and write to this directory.
An important issue with custom rule sets is that at least one of the following RDF(S) resources be specified/mentioned within an axiomatic triple or a rule: rdf:type, rdfs:range dfs:doman, rdfs:subClassOf, rdfs:Class and rdfs:subPropertyOf. These are used in specific implementations related to basic RDF support and are hard-coded into OWLIM-SE.
Due to some of the optimisation techniques used in OWLIM-SE, the set of rules in a custom rule set require at least one of the rules to derive the following triple patterns: x rdf:type y, x rdfs:subClassOf y and x rdfs:subPropertyOf y (the actual variable names do not matter).
A class is inferred as being a rdfs:Class whenever an instance of the class is defined with I rdf:type C.
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.
For this reason, optimized versions of standard rule-sets are provided. These have '-optimized' appended to the rule-set name, e.g. owl-horst-optimized, and use the optimizations listed in Table 4.
These optimization were previously achieved using the partialRDFS parameter, but are now achieved by using a previously optimized built-in rule-set, see the ruleset parameter in the configuration section for a complete list.
which declares that the two URIs are equivalent. owl:sameAs is probably the most important OWL predicate when it comes to merging data from different data sources.
In the above example, we had two alignment statements (S1 and S7), two statements carrying specific factual knowledge (S2 and S3), one statement inferred due to a transitive property (S4), and seven statements inferred as a result of owl:sameAs alignment (S5, S7, S8, S9, S10, as well as the inverse statements of S1 and S7). As we see, inference without owl:sameAs inflated the dataset by 25% (one new statement on top of 4 explicit), while the presence of the owl:sameAs statements increased the full closure by 175% (7 new statements). Considering that Vienna has a URI also in UMBEL, which is also declared equivalent to the one in DBpedia, the addition of one more explicit statement for this alignment, will cause the inference of 4 new implicit statements (duplicates of S1, S5, S6, and S8). Although this is a small example, it provides a indication about the performance implications of using owl:sameAs alignment statements from Linked Open Data. Also, because owl:sameAs is a transitive, reflexive, and symmetric relationship, for a set of N equivalent URIs N2 (N squared) owl:sameAs statements will be generated for each pair of URIs (in reality there are not that many examples of large owl:sameAs equivalence classes). Thus, although owl:sameAs is useful for interlinking RDF datasets, its semantics causes considerable inflation of the number of implicit statements that should be considered during inference and query evaluation (either through forward- or through backward-chaining).
To overcome this problem, OWLIM-SE handles owl:sameAs in a specific manner. In its indices, each set of equivalent URIs (equivalence class with respect to owl:sameAs) is represented by a single super-node. This way, OWLIM-SE does not inflate the indices and, at the same time, retains the ability to enumerate all statements that should be inferred using the equivalence during retrieval requests, i.e. during inference or query evaluation. Special care is taken to ensure that this optimisation does not hinder the ability to distinguish explicit from implicit statements.
The handling of owl:sameAs is technically a kind of backward chaining that occurs at query time, when equivalent URIs are enumerated and substituted in to query results. It should be noted that this will occur even when the 'empty' (no inference) rule-set is selected, i.e. even with no semantics selected owl:sameAs is still interpreted in a special way.
However, the owl:sameAs optimisation can be disabled completely using the disable-sameAs configuration parameter, see the [configuration section] for details.