0

I'm looking for a large triple store database management system that provides a mechanism to guarantee that the commited transactions do not alter the ABox of an ontology in a way that it becomes inconsistent with its TBox.

So far the only one that I've identified to provide this mechanism is Stardog (https://www.stardog.com/docs/#_validating_constraints).

Does GraphDB provides any mechanism similar to this?

RobV
  • 28,022
  • 11
  • 77
  • 119
Elton
  • 1

1 Answers1

1

GraphDB's rule language supports inference and consistency checking rules. You can rewrite the same published Integrity Validation Constraints (ICV) using the GraphDB's PIE syntax like:

Managers must be employees

A more generic version of this rule is to replace the "RDFS range" inference rule:

Id: prp_rng

  a <rdfs:range> b
  c a d
------------------------------------
  d <rdf:type> b

with the consistency checking equivalent:

Consistency: prp_rng_constraint

  a <rdf:type> b
  a <rdfs:range> c [Constraint b != c]
------------------------------------

If a rule with an empty consequence fires, it will generate a validation error.

Only employees can have an SSN

I would express the rule in a more generic way like that every type must have at least one property:

Consistency: min_cardinality

   a <owl:minCardinalityConstraint> "1"^^xsd:nonNegativeInteger
   a <owl:onType> b
   c <rdf:type> b
   ------------------------------------
   c a y

and then state in the ontology:

INSERT DATA {
     :ssn owl:minCardinalityConstraint "1"^^xsd:nonNegativeInteger;
          owl:onType :Employee.
};

A rule with consequence indicates that the statement must exist in the repository if the rule fires.

You can check more examples in the built-in ruleset.

vassil_momtchev
  • 1,173
  • 5
  • 11
  • Thank you vassil_momtchev! In the link you shared, It is said that GraphDB performs these consistency checks within the transaction lifecycle, rolling back commits that fail to comply with the rulesets defined. Provided that, there is one think that is not clear in neither GraphDB or Stardog documentation... If two concurrent transactions modify the same instances, at the same time. When they get commited, they will not individually inflict the constraints defined in the rulesets, but in conjunction, they could. How does GraphDB handles that? – Elton Jun 27 '18 at 13:55
  • The internal transaction mechanism is explained in: http://graphdb.ontotext.com/free/storage.html#transaction-control – vassil_momtchev Jun 27 '18 at 16:30