Negation in Graql Rules


I want to model negation in Graql rules like below

States sub relation is-abstract relates some-resource plays some-state;
stateA sub States relates some-resource;
stateB sub States relates some-resource;

Condition sub relation is-abstract relates some-state;
achieved sub Condition relates some-state;
holds sub Condition relates some-state;
prior sub Condition relates some-state;

$inf isa inference-rule
     (some-resource : $a) isa $st;
     $st label 'stateA';
     (some-state: $st) isa achieved;

     # not a valid Graql syntax
     (some-state: $st) isnota prior;
     (some-state: $st) isa holds;

Which is to say that if a state is achieved and it’s not a prior state, then it holds
There can be other combinations as well which might require similar negation in RHS like if a state is achieved and it’s prior, then it does not hold

How to model these kind of logic ?


We’re planning support for negation in Graql, but it’s not yet implemented.

The current plan is for it to look something like: not { $x isa $y; }.



I believe you can currently achieve the former behaviour, i.e. that states that hold are the ones that are achieved but are not prior states, by defining the rule in the following way:

$inf isa inference-rule
     (some-state: $st) isa achieved;
     (some-state: $st2) isa prior;
     $st != $st2;
     (some-state: $st) isa holds;

This will work under the assumption that a prior state exists in the database.

Also, I have removed the pattern part with the label definition:

(some-resource : $a) isa $st;
$st label 'stateA';`

as in conjunction with the remaining pattern it is trying to reify a type which is currently not allowed.

Hope that helps. Let us know if you have any more questions.


As per your assumption then if there are no prior states in the DB then these rules won’t work ? Coz the primary intent with above rule is to label all achieved states which has no prior as holds as well which means that it can possibly happen there are no instances of prior states at all in the DB.


Hi @kaychaks

There are several problems with your rules. The obvious one is that we do not have an isnot implementation. The closest you can get to it is using a notprior abstract type. In your case it would not work either, though, because you cannot have types playing roles in relations. In your rule $st is a type, so you cannot have it in a achieved relation.

If you explain me exactly what you are trying to model (it looks like you are attempting to model some finite automaton to me) then we can think of a way to get around the issues.


Let’s say there are 3 states of a system - probable, demonstrated and refuted.These states can be in one of the 3 conditions - achieved, prior and holds. If system achieves demonstrated and earlier (prior) it used to have probable then probable no longer holds. Similarly, if the system achieves demonstrated and it does not hold refuted, then it holds demonstrated.


How is “achieved” different from “holds”? I am sorry, I am still not understanding completely. It looks like a reasoner job to me, though. I think it is possible to model what you are trying to model, but I am not 100% sure I understood it correctly.


By work I meant the lhs will match anything and yield results. If there are no prior states in the database, matching the lhs against the database will yield no results as no substitution satisfying the lhs pattern will be found. Consequently, no states will be labelled as holding as if there are no prior states.


The states represent progression of domain entities like skill of an individual. If an individual enhances his skill in let’s say programming then he might go from probable to demonstrated. So when he moves from probable to demonstrated, his probable state does not hold. Similarly, if his skills are refuted for some reason then he no longer hold that skill. Does this give some clarity ?

All of this is part of a larger ontology, hence I have tried to contextualise them for the problem at hand.


Much better, yes. So “Probable”, “Demonstrated” and “Refused” are mutually exclusive.
Now what is the “prior” needed for? And what is the difference between “achieved” and “holds”?

Sorry for the amount of questions…


Prior, achieved and holds are to provide a picture of the states at some point of time.

E.g. if we represent skill of an individual as a skill statement i.e.
∀ p,s skill-statement(p,s) ^ person(p) ^ skill(s)

then if the state of a skill statement changes, its previous state does not hold any longer i.e.

∀ p,s achieved(demonstrated(skill-statement(p,s))) ∧ 
                prior(probable(skill-statement(p,s))) ⊃