15.4.2. Making sense of this situation
We should consider the property Price as added to one role, Present Mother, to be different from the property Price as added to another (Present Father). Think of them as templates, where their incorporation into other role types stamps them into something new. Price as used in Present Father is a different property from Price as used in Present Mother. Changing either of these different properties should not be mixed up with changing the other.
A similar thing holds for role Aspects. In fact, at the type level, we should identify roles with the combination of a context- and a role type: RoleInContext.
This is important when we analyze and use paths through type space. A query, and consequently an inverted query, is such a path. We should describe such paths in terms of Context types and RoleInContexts, rather than Context types and EnumeratedRoleTypes.
When a user makes a change to the structure of roles and contexts, she adds or removes a role to a context or fills (or clears) a role. We describe such a change in terms of a Delta that identifies either a context- and role instance, or two role instances. As a role instance representation contains a direct reference to a context instance, we can immediately derive a RoleInContext type combination from a role instance. Hence, we can identify with certainty two points of a path through type space. With those points in hand, we can find inverted queries that run through them and use those to find the peers that need to be informed.
We really should use two points rather than one. The Delta describes a path of length two; we want to make sure we only follow (inverted) queries that incorporate that entire segment. Were we to use just one of the two points, we would include all relevant queries, but would err on the other side by including paths we don’t want to follow.