6.2.1. Inverting queries
Imagine a query as a piping system, fanning out from some context with a user for whom actions are carried ot automatically. Call this context an automatic user context. Role instances and property values ‘flow’ to it from source contexts through the pipes. It is as if the automatic user context ‘pulls’ items towards it.
In general, queries are computed roles or computed properties. The condition of a state is a computed property with a Boolean value.
Now switch your point of view and ‘look through’ the same pipes from the other end. Looking from some source context, we see automatic user contexts at the other end. In other words, invert the queries. As contexts and roles form a graph constructed from fill relations that fan out (or fans in if you look from the other direction), the inverse queries again travel over a subnetworks that are trees. But this time these queries will pull in automatic user contexts to a source context.
This solves the sleeping context problem. A change to a context or role or property can only be realised when that context is in memory. If the Perspectives distributed runtime (PDR) receives a delta (the unit of description of change) from some other PDR, it will first retrieve the affected context or role into the computer memory. Now, if it is a source with respect to the condition (query) of a state of some other context, it will have inverted queries. The PDR runs these queries and thereby retrieves all automatic user contexts that depend on it, fetching them from disk if necessary. In the process, it fetches all roles and contexts on the path between them. It then runs the rules in those contexts. The conditions of those rules will pull in further role instances and values. The changed or new item will be one of them (or it will be missing if it was removed), possibly leading to a different Boolean result from before the change.