GraphDB Constraint Validation

Consistency checks
GraphDB inference engine background
Operations on rulesets

GraphDB Enterprise supports consistency violation checks using standard OWL2RL semantics. It is possible to define rulesets which contain consistency rules.

Consistency checks

Materialisation and consistency mix: the rulesets support the definition of a mixture of materialization and consistency rules. This follows the existing naming syntax “id:” and “Consistency:”
Multiple named rulesets: GraphDB Enterprise supports multiple named rulesets
No down time deployment: The deployment of new/updated rulesets can be done to a running instance
Update transaction ruleset: Each update transaction can specify which named ruleset to apply. This is done using “special” RDF statements
within the update transaction
Consistency violation exceptions: GraphDB Enterprise throws exceptions if a
consistency rule is violated. The exception includes detail as to which RDF statements
violated a rule and which rule has been violated
Consistency Rollback: if a consistency rule is violated within an update transaction
the transaction will be rolled back and no statements will be committed

GraphDB inference engine background

GraphDB requires the .pie file of each ruleset to be compiled first in order to instantiate an inferencer. The process includes several steps:

A generation of a java code out of the pie file contents using the builtin Owlim rule compiler
Then, this java code is compiled (it requires JDK instead of JRE so that the java compiler to be available through standard java instrumentation infrastructure)
Once compiled, that code is instantiated using a custom bytecode class loader. Current implementation instantiate such inferencer when repository is initialized. The process is slow and may take some time depending on the ruleset used and the rules included.

Operations on rulesets

All examples below assume the sys: namespace, defined as:

Operation	Add a custom ruleset from .pie file
Predicate	sys:addRuleset
Description	Will add a custom ruleset from the specified .pie file. The ruleset will be named after the filename, without the .pie extension.
Example	INSERT DATA { _:b sys:addRuleset <file://c:/graphdb/test-data/test.pie> } This will create a new ruleset "test"

Operation	Add a built-in ruleset
Predicate	sys:addRuleset
Description	Will add a built-in ruleset (one of the the rulesets that GraphDB supports natively)
Example	INSERT DATA { _:b sys:addRuleset "owl-max" } This will add the "owl-max" ruleset to the list of rulsets in the repository.

Operation	Add a custom ruleset with SPARQL INSERT
Predicate	sys:addRuleset
Description	Will add a custom ruleset from the specified .pie file. The ruleset will be named after the filename, without the .pie extension.
Example	INSERT DATA { <:custom> sys:addRuleset "Prefices {} Axioms {} Rules {} "} This will create a new ruleset "custom"

Operation	List all rulesets
Predicate	sys:listRulesets
Description	Will list all ruleset available in the repository.
Example	SELECT ?state ?ruleset { ?state sys:listRulesets ?ruleset }

Operation	Explore a ruleset
Predicate	sys:exploreRuleset
Example	SELECT * { ?content sys:exploreRuleset "custom" }

Operation	Set a default ruleset
Predicate	sys:defaultRuleset
Description	Switch the default ruleset to the one, specified in the object literal.
Example	INSERT DATA { _:b sys:defaultRuleset "test" } This will set the default ruleset to "test". All transaction will use this ruleset, unless they specify another ruleset as the first operation in the transaction.

Operation	Rename a ruleset
Predicate	sys:renameRuleset
Description	Will rename the ruleset from "custom" to "test". Note that "custom" is specified as the subject URI in the default namespace.
Example	INSERT DATA { <:custom> sys:renameRuleset "test" }

This will rename the ruleset "custom" to "test"

Operation	Delete a ruleset
Predicate	sys:removeRuleset
Description	Will delete the ruleset "test", specified in the object literal.
Example	INSERT DATA { _:b sys:removeRuleset "test" }