Perspectives Technical Documentation

Queries are inverted in design time, as we process a model. As we follow an inverted query one step back to its origin through the web of types, we store the remaining query with the node we’ve arrived at with that step, along the way.

We can pass through a role instance node in a number of ways:

We store inverted queries with Role types, except for those that start with a role <type> step: these are stored with context types.. We let the type of the first step of the inverted query determine the member of the type where we store it: so if the first step is filler, we’ll store the inverted query in fillerInvertedQueries.

The table below gives the overview for all four steps.

Figure 1 illustrates all four cases.

Figure 1. Inverted queries in relation to various nodes in the graph. Green lines and text represent the original query; red lines and text represent the inverted query. The user has a perspective on role (type) r4. Blue lines start in a filler and end in a filled node. The boxes show inverted queries as stored in various members of role types.

Consider the example of the inverted query stored in roleInvertedQueries of c3 in Figure 1. The query step that we would apply to c3 would have been: role r3. So we would expect roleInvertedQueries to hold the full query

Role r3 >> filler >> filled role r1 >> context

That will take us from c3 to c1, as intended. Yet, as the diagram shows, we skip the first query step (storing just filler >> filled role r1 >> context) and apply it to r3 (instead of c3). Why?

We will apply the inverted query when we handle a ContextDelta. Let’s assume the delta represents a new instance of r3. Now the whole point of applying the inverse query is to find contexts and roles that are now available to the user having the perspective, but were not so before. In other words: a new path has been formed and we want to travel that to its root. Obviously, the new connection must be part of the path we travel. But then we should start at the new instance of r3! Otherwise, on starting with c3, we would also travel down all paths that begin with siblings of the new instance.

Hence we shorten the query and start at the new role instance.

A similar consideration holds for the inverted query stored in filledInvertedQueries role stored in r1. Instead of applying the full inverted query to an instance of r2, we apply the shorter version to the new filled role of type r1. This is because there can be many filled roles of r2!

For queries stored in fillerInvertedQueries, the same reasoning applies.

Looking back, we see that a query is stored with the node of departure of the first step: is it the context step, we store in the role; is it the role step, we store it in the context. The filler departs from the filled node and so we store such queries there. So why do we not store queries that start on the filled step with the filler node? There are two reasons: