Build your skills and learn how TypeDB's native inference engine works. Good for: - Beginners to TypeDB and TypeQL - Those who have been using TypeDB and want a refresher on inference in TypeDB - Experienced software engineers - Those who want to better represent their domain in a model that allows for logical reasoning at the database level Description: TypeDB is capable of reasoning over data via pre-defined rules. TypeQL rules look for a given pattern in the database and when found, infer the given queryable fact. The inference provided by rules is performed at query (run) time. Rules not only allow shortening and simplifying of commonly-used queries, but also enable knowledge discovery and implementation of business logic at the database level. Takeaways: - Understanding of fundamental components of TypeDB's inference engine and how to write rules for your domain - Write at least 1 rule for your use case - Utilise the rule you wrote in a query Tomás Sabat: Tomás is the Chief Operating Officer at Vaticle, dedicated to building a strongly-typed database for intelligent systems. He works directly with TypeDB's open source and enterprise users so they can fulfil their potential with TypeDB and change the world. He focuses mainly in life sciences, cyber security, finance and robotics.

1. TypeDB Academy | Inference with Rules

2. Agenda
a. Review concepts and patterns of TypeDB rules, written in TypeQL
b. Modelling functional relationships between concept and schema
c. Present the structure, requirements, implications and techniques
d. Discuss as a group some applications of rules in the wild

3. Deductive Reasoning
Reasoning via backward-chaining allows us to reach a conclusion based on the facts we already
have.
Composed of two parts:
1. Condition
2. Conclusion
The Condition checks the facts we currently have, to see if we can reach the conclusion.
Example
Condition - When it’s raining outside
Conclusion - I should take an umbrella

4. Other types of reasoning (not supported)
There are other types of reasoning that don’t lead to definite outcomes,
and so are less suitable to be implemented by a knowledge graph.
Inductive Reasoning
It rained every day for the last week, so it will probably rain tomorrow
Abductive Reasoning
The ground is wet, therefore it probably rained

5. What’s the value of automated reasoning?
Automated reasoning can be re-computed on-the-fly and can take care of
logical reasoning beyond human capabilities:
• vertically in terms of number of rules applied / chained
• horizontally over big data

6. How does TypeDB’s reasoner work?
• Takes in rules, defined the same way as schema and applies those rules at query-time.
• The conclusions from reasoning are held in memory, not written to disk – necessary as the causes
of the rule conditions may change. This dynamic nature means:
• reasoned facts are never stale
• the size on disk doesn’t increase with the number of facts that can be reasoned over
(could be exponential)
• Works in first-order logic
• Operates on a set
• Doesn’t accept functions as predicates.

7. Where might we use reasoner?
Thinking about our own domain, where or what questions
might we make use of reasoner, to answer?

8. A TypeDB rule
Rules in TypeQL are used to determine the Conditions that lead to a
Conclusion.
When a query is made, TypeDB checks (recursively) whether any of the
stored rules apply. If they do, then the Conclusion is inferred.

9. Rules are defined and undefined the same way as schema:
Since rules don’t have any interdependencies, they can be added and removed easily.
Writing rules
define
rule my-rule-label:
when {
## the condition, a TypeQL pattern (the body)
} then {
## the conclusion, a TypeQL pattern (the head)
};
undefine rule my-rule-label;

10. Writing rules
As an example:
define
mutual-friendship sub relation,
relates mutual-friend,
relates one-degree-friend;
rule people-have-mutual-friends:
when {
$r1($p1, $p2) isa friendship;
$r2($p2, $p3) isa friendship;
} then {
(one-degree-friend: $p1,
one-degree-friend: $p3,
mutual-friend: $p2) isa mutual-friendship;
};

11. Writing rules
This lets us quickly find the mutual friends between two people. It’s triggered
when we ask for something in the rule body; e.g. a mutual-friendship:
match
$p1 isa person, has full-name “Ahmed Frazier”;
$p2 isa person, has full-name $n;
$p3 isa person, has full-name “Raphael Santos”;
(one-degree-friend: $p1,
one-degree-friend: $p3,
mutual-friend: $p2) isa mutual-friendship;
get $n; limit 5;

12. What can we infer?
What can go in the then {…}, the conclusion of a rule?
Relations
then { (sibling: $x, sibling: $y) isa siblings; };
Attribute ownership of a constant attribute
then { $p has nickname ”Anne”; };
Attribute ownership of a variable attribute
then { $p has $is-graduated; };

13. When to use rules?
We use rules:
• To abbreviate a commonly asked query.
• To test a hypothesis which has multiple possible causes (or to future-proof for
this scenario): and get an explanation for why.
• this moves application logic to the database for cleaner code and easier
maintenance.
• To create chained logic and recursive queries, which aren’t otherwise possible.
• For investigation.
• Rules are very flexible, so they can be used to try things that you don’t want to
persist.
• To create complex types that you can’t with schema alone.

14. Abbreviating queries to find insights
It is clear that reproducing the Condition of this rule is not trivial, so we can
certainly justify writing a rule to yield this insight for us.
rule events-overlap:
when {
$e1 isa periodic-event;
$e1 has start-date $sd1, has end-date $ed1
$e2 isa periodic-event;
$e2 has start-date $sd2, has end-date $ed2
$sd2 > $sd1; $sd2 < $ed1;
not {$e1 is $e2; };
} then {
(overlapped-event: $e1,
overlapped-event: $e2) isa event-
overlapping;
};

15. rule public-permission
when {
(shared-content: $sc) isa public-sharing;
$pu isa public-user;
}, then {
(permitted-content: $sc,
(permission-grantee: $pu) isa permitted-to-see;
};
rule friends-permission:
when {
(shared-content: $sc, shared-by: $sb) isa friends-sharing;
(friend: $sb, $f) isa friendship;
}, then {
(permitted-content: $sc,
(permission-grantee: $f) isa permitted-to-see;
};
rule author-permission:
when {
(shared-content: $sc, shared-by: $sb) isa sharing;
}, then {
(permitted-content: $sc,
(permission-grantee: $sb) isa permitted-to-see;
};
Content
permissions

16. Hypothesis testing
This means we can now ask a simple question (our hypothesis), and TypeDB
will tell us whether the conclusion is true. We can ask who is permitted to see
a specific post:
match
$sb isa person, has email $e;
$sc isa post, has identifier “$per-3-pos-1”;
$p(content: $sc, grantee: $sb) isa content-permission;

17. Inferring more than one atom
Multiple atoms in the rule head is in the feature roadmap for TypeDB.
For now, we need as many rules as things we want to infer.

18. A couple more notes on rules
We can’t use disjunctions (or) in rule bodies. Instead, split each of the
conditions in { condition-1 }; or { condition-2 }; into separate rules.
Remember that rules can be written programmatically, so we can auto-
generate them for disjunctions with lots of conditions.

19. Let’s write some rules
Derive a rule that states that the owner of a social-group must therefore be a
member of that social-group.

20. Let’s write some rules
Derive a rule that states that the owner of a social-group must therefore be a
member of that social-group.
rule owner-is-always-member:
when {
$group isa social-group;
(owner: $owner, owned-group: $group) isa group-
ownership;
} then {
(member: $owner, membership-group: $group) isa
membership;
};

21. Let’s write some rules
Derive a rule that states that people who are married are therefore friends.

22. Let’s write some rules
Derive a rule that states that people who are married are therefore friends.
rule married-couples-are-friends:
when {
$mar(wife: $w, husband: $h) isa marriage;
} then {
(friend: $w, friend: $h) isa friendship;
};

23. Discussion
What are some concepts that we might want to infer
within our own domain?

24. Thank you!!