GraphDB Constraint Validation

compared with
Current by Ruslan Velkov
on Nov 06, 2014 17:07.

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (33)

View Page History
{toc}

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

{info} *Important*: When creating a new repository, the parameter {{check-for-inconsistencies}} should be set to {{true}}. It is {{false}} by default - for compatibility with previous OWLIM releases.
{info}

h2. 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 by using “special” RDF statements within the update transaction.
within the update transaction
* Consistency violation exceptions: GraphDB Enterprise throws exceptions if a consistency rule is violated. The exception includes details as which rule has been violated and to which RDF statements.
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.
the transaction will be rolled back and no statements will be committed

h2. 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.
In order to instantiate an inferencer, first GraphDB requires the .pie file of each ruleset to be compiled. The process includes several steps:
* Generating a java code out of the pie file contents using the built-in GraphDB rule compiler.
* Compiling the java code (it requires JDK instead of JRE, hence the java compiler will be available through the standard java instrumentation infrastructure).
* Instantiating the java code using a custom bytecode class loader.

In prior-GraphDB 6 versions, this inferencer was instantiated when the repository was initialized. The process was slow and took some time depending on the ruleset used and the rules included.
In GraphDB 6, the inferencer can be dynamically extended with new rulesets, as specified in the text section.

h2. Operations on rulesets

All examples below assume use the sys: namespace, defined as:
{code}
prefix sys: <http://www.ontotext.com/owlim/system#>
|| Operation | Add a custom ruleset from .pie file ||
|| Predicate | *sys:addRuleset* ||
|| Description | Will add Adds a custom ruleset from the specified .pie file. The ruleset will be is named after the filename, without the .pie extension. ||
|| Example | INSERT DATA \{ \_:b sys:addRuleset <[file://c:/graphdb/test-data/test.pie]> <{nolink:file:c:/graphdb/test-data/test.pie}> \} \\
This will create a new ruleset "test" ||
This creates a new ruleset "test". If the absolute path to the file resides on e.g. /opt/rules/test.pie then it can be specified as <{nolink:file:/opt/rules/test.pie}>, <{nolink:file://opt/rules/test.pie}>, or <{nolink:file:///opt/rules/test.pie}>, i. e. with 1, 2, or 3 slashes.Relative paths are specified without the slashes or with dot between the slashes: <{nolink:file:opt/rules/test.pie}>, <{nolink:file:/./opt/rules/test.pie}>, <{nolink:file://./opt/rules/test.pie}>, or even <{nolink:file:./opt/rules/test.pie}> (with dot in front of the path). Relative paths can be used in case we know the work directory of the Java process in which GraphDB runs. Because colon means specifying a port number after the host, if we want to specify the drive letter on a Windows machine, we should NOT use slashes after 'file:', like in the example above. ||
| {color:#000080}{*}Example{*}{color} | INSERT DATA \{ <:custom> sys:addRuleset <{nolink:file:c:/graphdb/test-data/test.pie}
> \}\\
Same as above but creates a ruleset called 'custom' out of the test.pie file found in the given absolute path.\\ |
| {color:#000080}{*}Example{*}{color} | INSERT DATA \{ \_:b sys:addRuleset <{nolink:http://example.com/test-data/test.pie}
> \}\\
Retrieves the PIE file from the given URL. We can again use <:custom> to change the name of the ruleset to 'custom' or whatever we want.\\ |
\\

|| Operation | Add a built-in ruleset ||
|| Predicate | *sys:addRuleset* ||
|| Description | Will add Adds a built-in ruleset (one of the the rulesets that GraphDB supports natively) ||
|| Example | INSERT DATA \{ \_:b sys:addRuleset "owl-max" \} \\
This will add adds 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 Adds a custom ruleset from the specified .pie file. The ruleset will be is named after the filename, without the .pie extension. ||
|| Example |
INSERT DATA \{ <:custom> sys:addRuleset "Prefices \{ a : http://a/ \} Axioms \{\} Rules \{
Id: custom
a b c
a <a:custom1> c
-----------------------
b <a:custom1> a
\}
"\}\\
This will create a new ruleset "custom" ||
|| Example | INSERT DATA \{ <:custom> sys:addRuleset "Prefices \{ a : {nolink:http://a/}\n\n\} Axioms \{\} Rules \{\nId: custom\na b c\na <a:custom1> c\n-----------------------\nb <a:custom1> a\n\}"\} \\
This creates a new ruleset "custom". ||
\\

|| Operation | List all rulesets ||
|| Predicate | *sys:listRulesets* ||
|| Description | Will list Lists all ruleset available in the repository. ||
|| Example | SELECT ?state ?ruleset \{ ?state sys:listRulesets ?ruleset \} ||
\\
|| Operation | Set a default ruleset ||
|| Predicate | *sys:defaultRuleset* ||
|| Description | Switches the default ruleset to the one, specified in the object literal. ||
|| Example | INSERT DATA \{ \_:b sys:defaultRuleset "test" \} \\
This will set sets the default ruleset to "test". All transaction will transactions use this ruleset, unless they specify another ruleset as the a first operation in the transaction. ||
\\

|| Operation | Rename a ruleset ||
|| Predicate | *sys:renameRuleset* ||
|| Description | Will rename Renames 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"
This renames the ruleset "custom" to "test".
\\

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

|| Operation | Consistency check ||
|| Predicate | *sys:consistencyCheckAgainstRuleset* ||
|| Description | Checks if the repository is consistent with the specified ruleset. ||
|| Example | INSERT DATA \{ \_:b sys:consistencyCheckAgainstRuleset "test" \} ||
\\