Lesson 9.6: Using interface hierarchies

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.

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.

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.

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 usable 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.

In other words, overriding an inherited role is like a combination of subtyping and making the inherited value abstract:

Since contributor is abstract in the authoring scope, it’s not available to be instantiated in the data. However, authoring:author is a subtype of contribution:contributor that can be used in its place.

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

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

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.

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).

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 follows¹.

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:

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

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:

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 role players of the relation supertype should also be role players 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.