Lesson 9.8: Interface constracts
Abstractness allows you to build forms of contracts on types, with more forms of contracts to be allowed in the future.
Abstractness
TypeDB’s semantics around abstractness are simple. Let’s say you define an abstract attribute, such as isbn and an owner:
define
attribute isbn @abstract, value string;
entity book,
owns isbn;In TypeDB, @abstract simply means that one type is not instantiable. However, there are no further restrictions on how this restriction translates to other types. This means that because book is not abstract, it can still be instantiated, but it would be impossible for an instance to own an isbn instance - simply because isbn cannot be instantiated.
Granular abstractness
These semantics mean you don’t have to make an owner abstract when it owns an abstract type.
define
attribute isbn @abstract, value string;
attribute price, value double;
entity book,
owns isbn,
owns price;You can freely instantiate books, but you can’t create any books owning an isbn.
However, if you make book abstract, now you’ve created a simple contract of what a book may have: all books may have an isbn. Further, you can add both abstract and concrete types onto the same owner, allowing generic querying (find any books with any kind of isbn), while eliminating redundancy (directly allow any future book subtype to re-use isbn-10 and isbn-13 to fulfill the isbn contract).
define
attribute isbn @abstract, value string;
attribute isbn-10, sub isbn;
attribute isbn-13, sub isbn;
attribute price, value double;
entity book,
owns isbn,
owns isbn-10,
owns isbn-13,
owns price;
entity paperback, sub book; # no need to repeat ownerships of concrete isbn-10 and isbn-13: inherited instead!
entity hardback, sub book; # no need to repeat ownerships of concrete isbn-10 and isbn-13: inherited instead!Note that, you can’t (yet) guarantee that all types of books have some type of isbn attached. This behaviour is expected in future versions of TypeQL. Please contact us if this is interesting to you!