You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All constraints in TypeQL are explicitly declared with a keyword a few exceptions.
One is the use of a relation variable and a relation tuple:
$r (friend: $x) isa friendship, has start-date...;
and the other is implicit attribute/value assignment:
$x 10;
?x 10;
These points make TypeQL harder to interpret to the user. Instead, we should consider making all constraints have an explicit keyword.
Proposed Solution
For attributes, we will simply require that we use predicates:
$x == 10;
?x == 10;
For relations, we will introduce of to denote the constraint between a variable and a role players tuple, and ban the usage of implicit value predicates.
So relations will look like the following:
$r of (friend: $x, friend: $y) isa friendship, has name ...;
Which will continue to be syntactic sugar over:
$r of (friend $x, $friend: $y);
$r isa friendship;
$r has name...
Open question: would we allow splitting of and isa into a comma separated list in the same multiple has constraints can be chained? We will need to come up with a consistent pattern for describing contractions constraints into a single comma-separated line.
$r isa friendship, of (friend: $x, friend: $y);
Additional information
Dropping a relation variable would generate an implicit variable with the of:
(friend: $x, friend: $y) isa friendship;
Should represent:
$_ of (friend: $x, friend: $y) isa friendship;
The text was updated successfully, but these errors were encountered:
Problem to Solve
All constraints in TypeQL are explicitly declared with a keyword a few exceptions.
One is the use of a relation variable and a relation tuple:
and the other is implicit attribute/value assignment:
These points make TypeQL harder to interpret to the user. Instead, we should consider making all constraints have an explicit keyword.
Proposed Solution
For attributes, we will simply require that we use predicates:
For relations, we will introduce
of
to denote the constraint between a variable and a role players tuple, and ban the usage of implicit value predicates.So relations will look like the following:
Which will continue to be syntactic sugar over:
Open question: would we allow splitting
of
andisa
into a comma separated list in the same multiplehas
constraints can be chained? We will need to come up with a consistent pattern for describing contractions constraints into a single comma-separated line.Additional information
Dropping a relation variable would generate an implicit variable with the
of
:Should represent:
The text was updated successfully, but these errors were encountered: