Officially out now: The TypeDB 3.0 Roadmap

Lesson 9.6: Using interface hierarchies

In the previous lesson, we improved the type hierarchies in our book data model by using the principle of composition over inheritance. In this lesson, we’ll explore the behaviour of interface hierarchies and see how they can be used to adapt our model in different ways.

Data table
ISBN-13 ISBN-10 Title Format Authors Editors Illustrators Other contributors Publisher Year City State Country Page count Genres Price Stock

9780008627843

0008627843

The Hobbit

ebook

J.R.R. Tolkien

J.R.R. Tolkien

Harper Collins

2023

New York City

New York

United States

310

fantasy;fiction

16.99

9780060929794

0060929790

One Hundred Years of Solitude

paperback

Garcia Marquez, Gabriel

Perennial

1998

New York City

New York

United States

458

fiction;historical fiction

6.12

4

9780195153446

0195153448

Classical Mythology

paperback

Lenardon, Robert J.;Morford, Mark P. O.

Oxford University Press

2002

New York City

New York

United States

820

history;nonfiction

34.98

12

9780375801679

0375801677

The Iron Giant

ebook

Hughes, Ted

Davidson, Andrew

Knopf Books for Young Readers

1999

New York City

New York

United States

79

fiction;children’s fiction

33.97

9780387881355

0387881352

Electron Backscatter Diffraction in Materials Science

hardback

Schwartz, Adam J.;Kumar, Mukul;Adams, Brent L.;Field, David P.

Springer

2009

New York City

New York

United States

425

nonfiction;technology

230.37

9

9780393045215

0393045218

The Mummies of Urumchi

paperback

Barber, Elizabeth Wayland

W.W. Norton & Company

1999

New York City

New York

United States

240

history;nonfiction

21.6

1

9780393634563

0393634566

The Odyssey

ebook

Homer

Wilson, Emily

W.W. Norton & Company

2017

New York City

New York

United States

656

fiction;classics

13.99

9780446310789

0446310786

To Kill a Mockingbird

paperback

Harper Lee

Grand Central Publishing

1988

New York City

New York

United States

281

fiction;historical fiction

21.64

16

9780451162076

0451162072

Pet Sematary

paperback

King, Stephen

Signet

1984

New York City

New York

United States

374

horror;fiction

93.22

1

9780500026557

0500026556

Hokusai’s Fuji

paperback

Wada, Kyoko

Katsushika, Hokusai

Thames & Hudson

2024

London

United Kingdom

416

art;nonfiction

24.47

11

9780500291221

0500291225

Great Discoveries in Medicine

paperback

Bynum, William;Bynum, Helen

Thames & Hudson

2023

London

United Kingdom

352

history;nonfiction

12.05

18

9780553212150

055321215X

Pride and Prejudice

paperback

Austen, Jane

Bantam Classics

1983

New York City

New York

United States

295

fiction;historical fiction

17.99

15

9780575104419

0575104414

Dune

ebook

Herbert, Frank

Hachette Book Group

2010

New York City

New York

United States

624

fiction;science fiction

5.49

9780671461492

0671461494

The Hitchhiker’s Guide to the Galaxy

paperback

Adams, Douglas

Pocket

1982

New York City

New York

United States

215

fiction;science fiction

91.47

9

9780679425601

0679425608

Under the Black Flag: The Romance and the Reality of Life Among the Pirates

hardback

Cordingly, David

Random House

1996

New York City

New York

United States

296

history;nonfiction

34.73

13

9780740748479

0740748475

The Complete Calvin and Hobbes

hardback

Watterson, Bill

Watterson, Bill

Andrews McMeel Publishing

2005

Kansas City

Missouri

United States

1451

comics;fiction

128.71

6

9781098108274

1098108272

Fundamentals of Data Engineering

ebook

Reis, Joe;Housley, Matt

O’Reilly Media

2022

Sevastopol

California

United States

450

nonfiction;technology;children’s fiction

47.99

9781489962287

148996228X

Interpretation of Electron Diffraction Patterns

paperback

Keown, Samuel Robert;Andrews, Kenneth William;Dyson, David John

Springer

1967

New York City

New York

United States

199

nonfiction;technology

47.17

15

9781859840665

1859840663

The Motorcycle Diaries: A Journey Around South America

paperback

Guevara, Ernesto

Wright, Ann

Verso

1996

London

United Kingdom

160

biography;nonfiction

14.52

4

9783319398778

Physical Principles of Electron Microscopy: An Introduction to TEM, SEM, and AEM

ebook

Egerton, R.F.

Springer

2016

London

United Kingdom

196

nonfiction;technology

19.5

9798691153570

Business Secrets of The Pharoahs

paperback

Crorigan, Mark

British London Publishing

2020

London

United Kingdom

260

business;nonfiction

11.99

8

Lesson 9.5 schema
define
book sub entity,
    abstract,
    owns isbn-13,
    owns isbn-10,
    owns title,
    owns page-count,
    owns genre,
    owns price,
    plays contribution:work,
    plays publishing:published;
paperback sub book,
    owns stock;
hardback sub book,
    owns stock;
ebook sub book;
contributor sub entity,
    owns name,
    plays contribution:contributor;
publisher sub entity,
    owns name,
    plays publishing:publisher;
place sub entity,
    abstract,
    owns name,
    plays locating:location,
    plays locating:located;
city sub place,
    plays publishing:location;
state sub place;
country sub place;
contribution sub relation,
    relates contributor,
    relates work;
authoring sub contribution;
editing sub contribution;
illustrating sub contribution;
publishing sub relation,
    relates publisher,
    relates published,
    relates location,
    owns year;
locating sub relation,
    relates located,
    relates location;
isbn-13 sub attribute, value string;
isbn-10 sub attribute, value string;
title sub attribute, value string;
page-count sub attribute, value long;
genre sub attribute, value string;
price sub attribute, value double;
stock sub attribute, value long;
name sub attribute, value string;
year sub attribute, value long;

Interfaces as types

In the PERA model, interfaces are themselves types, as we saw in Lesson 9.1. Like the data storing types, interface types are able to form hierarchies. Role hierarchies are derived from their dependent relation type hierarchies, while ownership hierarchies are derived from their dependent attribute type hierarchies. Let’s examine an example.

define
isbn sub attribute, abstract, value string;
isbn-13 sub isbn;
isbn-10 sub isbn;

As we saw in Lesson 9.1, the isbn attribute type exposes an ownership interface, which we’ll call isbn:OWNER for this discussion. Likewise, isbn-13 and isbn-10 expose the interfaces isbn-13:OWNER and isbn-10:OWNER respectively. As isbn-13 and isbn-10 are subtypes of isbn, this means that isbn-13:OWNER and isbn-10:OWNER are subtypes of isbn:OWNER.

Role hierarchies work in a similar way, but have a major difference. Whereas all attribute types have an associated ownership interface, some relation types do not have role interfaces of their own, instead inheriting them from supertypes. We saw this in Lesson 9.5 with the following relation type hierarchy.

define
contribution sub relation,
    relates contributor,
    relates work;
authoring sub contribution;
editing sub contribution;
illustrating sub contribution;

Here contribution defines two interfaces: contribution:contributor and contribution:work, and these are also inherited by its subtypes, which have no roles of their own. This means that all four relation types expose these same two interfaces. Consider the following instead.

define
contribution sub relation,
    relates contributor,
    relates work;
authoring sub contribution,
    relates author as contributor;
editing sub contribution,
    relates editor as contributor;
illustrating sub contribution,
    relates illustrator as contributor;

Here authoring, editing, and illustrating each expose a new interface: authoring:author, editing:editor, and illustrating:illustrator respectively. These interfaces override the interface contribution:contributor, meaning that it is no longer exposed by the subtypes of contributor. Because the newly defined interfaces override an interface from the parent type, these interfaces authoring:author, editing:editor, and illustrating:illustrator are subtypes of the parent interface contribution:contributor. Meanwhile, the interface contribution:work is still exposed by all four relation types.

Interface variance

The way in which interface implementations are inherited is determined by their variance. Interface implementations, as defined in owns and plays statements, are:

  • Covariant in the implementing object type. This means that the statement also applies to subtypes of the object type by inheritance.

  • Invariant in the implemented interface type. This means that the statement does not also apply to subtypes of the interface type.

Let’s consider the following example, featuring two plays statements.

define
book plays contribution:work;
contributor plays contribution:contributor;

In the first statement, the implementing object type is book and the implemented interface type is contribution:work. The object type has three subtypes paperback, hardback, and ebook, and they also implement contribution:work by inheritance because the statement is covariant in book.

In the second statement, the implementing object type is contributor and the implemented interface type is contribution:contributor. The interface type has three subtypes authoring:author, editing:editor, and illustrating:illustrator, but contributor does not also implement them because the statement is invariant in contribution:contributor.

Let’s consider another example, this time with an owns statement.

define
book owns isbn;

The implementing object type is book and the implemented interface type is isbn:OWNER. This time, both have subtypes. The object type has three subtypes paperback, hardback, and ebook, and they also implement isbn:OWNER. Meanwhile, the interface type has two subtypes isbn-13:OWNER and isbn-10:OWNER, and book does not also implement them (nor do its subtypes).

As we learned in Lesson 5.5, if an attribute type is abstract, then any owners must also be abstract. Because the implementation of isbn:OWNER is inherited by the subtypes of book (which are not themselves abstract), this will result in a violation of schema validation rules, and the schema will not commit! However, we will see how we can use this property to our advantage in Lesson 12.4, where we will explore schema design by contract.

Because implementations are invariant in the interface, this means that we must separately declare implementations of their subtypes if we wish to use them, as follows1.

define
contributor plays authoring:author;
contributor plays editing:editor;
contributor plays illustrating:illustrator;
book owns isbn-13;
book owns isbn-10;

Using role overrides effectively

Earlier in this lesson, we encountered two possible design strategies for the subtypes of contribution: one in which the subtypes inherit the role contribution:contributor, and one in which the role was overridden with specialized subtypes. The two strategies result in identical querying capabilities. When the role is inherited, we can query contribution and its subtypes with the following patterns:

  • To describe an instance of contribution or one of its subtypes:

    (contributor: $person, work: $book) isa contribution;
  • To describe an instance of a specific subtype of contribution (e.g. authoring):

    (contributor: $person, work: $book) isa authoring;
  • To describe an instance of contribution only, not one of its subtypes:

    (contributor: $person, work: $book) isa! contribution;

When the role is overridden, we can do the same with the following patterns instead:

  • To describe an instance of contribution or one of its subtypes:

    (contributor: $person, work: $book) isa contribution;

    Here, using contributor in the relation tuple matches both contribution:contributor and its subtypes by inheritance polymorphism.

  • To describe an instance of a specific subtype of contribution (e.g. authoring):

    (author: $person, work: $book) isa authoring;
  • To describe an instance of contribution only, not one of its subtypes:

    (contributor: $person, work: $book) isa! contribution;

The only thing that changes is the way we query the specific subtypes of the relation type. Even then, we can easily use role inference to omit the roles from the pattern as we saw in Lesson 7.2, and use the same queries throughout. Thus, the querying capabilities of the model are the same regardless of whether we inherit or override a role. In fact, this is true of any model involving roles that can be inherited or overridden.

However, there is a key difference in the way the roles must be implemented in these two cases. Consider the following definition:

define
contributor plays contribution:contributor;

If contribution:contributor is inherited by the subtypes of contribution, then contributor will be able to play the role in those relation types as well, as they will all expose the same role interface. Conversely, if the role is overridden in the subtypes of contribution, then contributor will not be able to play roles in the subtypes as the plays statement is invariant in the role, as we saw above.

As a result, when building a relation type hierarchy, the primary factor to consider when deciding whether to inherit or override a role is whether roleplayers of the relation supertype should also be roleplayers of the relation subtypes. In this particular case, anyone capable of making a contribution to a book is also able to author, edit, or illustrate a book, by definition. As such, it makes most sense for the subtypes of contribution to inherit the role contribution:contributor rather than override it.

In other cases, it may be more appropriate to override roles. The following schema excerpt for a filesystem access management model is such an example. Here, we ensure that all users are able to execute system actions, but only admins are able to execute them with admin privileges.

define
user sub entity,
    plays action-execution:executor;
admin sub user,
    plays privileged-execution:priveleged-executor;
action-execution sub relation,
    relates action,
    relates executor;
privileged-execution sub action-execution,
    relates privileged-executor as executor;

Footnotes

  1. ^ In some cases, it might seem cumbersome to have to explicitly define each implementation of an interface’s subtypes, but the invariance is essential to prevent logical fallacies in data model. Consider the following set of facts:

    • All humans are animals.

    • All geese are animals.

    • All animals can join animal groups.

    • All flocks are animal groups.

    • All geese can join flocks.

    Now consider the following deduction:

    • All animals can join animal groups, and all flocks are animal groups, therefore all animals can join flocks.

    If this deduction were correct, it would allow humans to join flocks, despite the fact that only geese should be able to join flocks! The deduction is obviously fallacious, specifically by affirming the consequent. Now consider if we translated our list of facts into TypeQL. It might look something like this:

    define
    animal sub entity, abstract;
    human sub animal;                             # all humans are animals
    goose sub animal;                             # all geese are animals
    animal-group sub entity, abstract;
    group-membership sub relation,
        abstract,
        relates group,
        relates group-member;
    animal-group plays group-membership:group;
    animal plays group-membership:group-member;   # all animals can join animal groups
    flock sub animal-group;                       # all flocks are animal groups
    flock-membership sub group-membership,
        relates flock as group,
        relates flock-member as group-member;
    flock plays flock-membership:flock;
    goose plays flock-membership:flock-member;    # all geese can join flocks

    If definitions of interface implementations were covariant in the interface type instead of invariant, then animal, and all of its subtypes including human, would inherit the ability to play flock-membership:flock-member!