GraphDB Constraint Validation

Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

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

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.

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.
  • 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 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

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.

Operations on rulesets

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

Operation Add a custom ruleset from .pie file
Predicate sys:addRuleset
Description Adds a custom ruleset from the specified .pie file. The ruleset is named after the filename, without the .pie extension.
Example INSERT DATA { _:b sys:addRuleset <file:c:/graphdb/test-data/test.pie> }
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 <file:/opt/rules/test.pie>, <file://opt/rules/test.pie>, or <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: <file:opt/rules/test.pie>, <file:/./opt/rules/test.pie>, <file://./opt/rules/test.pie>, or even <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.

Operation Add a built-in ruleset
Predicate sys:addRuleset
Description Adds a built-in ruleset (one of the rulesets that GraphDB supports natively)
Example INSERT DATA { _:b sys:addRuleset "owl-max" }
This 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 Adds a custom ruleset from the specified .pie file. The ruleset is named after the filename, without the .pie extension.
Example INSERT DATA { <:custom> sys:addRuleset "Prefices { a : 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 Lists 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 "test" }

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 sets the default ruleset to "test". All transactions use this ruleset, unless they specify another ruleset as a first operation in the transaction.

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

Operation Delete a ruleset
Predicate sys:removeRuleset
Description 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" }

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.