Context is the knowledge “surrounding” knowledge of interest, the background knowledge needed to give meaning.
A context is a structure that compartmentalizes knowledge into consistent units. Contexts can be used for many different purposes, some of which are [Sow92]:
Given a domain D, containing items d and item names t, a context maps item names to items within the domain. So domains and contexts are, in a sense, interchangeable.
The elements of D might be procedures which are carried out by other elements of D, but not procedures that act on elements of D.
There are many different contexts in a typical design environment.
Maintaining certain distinctions between different contexts allows reflexivity and its problems to be controlled.
One context is that of the product itself (e.g. a car). This includes functions of a car, its parts, etc. This D constitutes the product model.
Another context is that of manufacturing (the car), and contains the equipment, jigs, workers, actual process plans, etc. that act on the raw materials and which result in product formation.
Does this mean that the product D must include the raw materials? It would appear so since the manufacturing context includes actions on those materials.
There is a context for the designers and manufacturing engineers (the engineering context). It contains them, and the things they use (including processes) to develop the product and manufacturing contexts. Actions in this context act on elements of the product and manufacturing contexts.
Finally there is a management context, which acts on the engineering context.
Note this fits exactly with product centred modelling.
These contexts do not share information via lifting; they are abstractions that are considered disjoint.
Additionally, there is a second kind of abstraction, though, through which lifting can occur.
In this case, contexts can be regarded as interrelated systems, where information that can be lifted represents interfaces between them.
From an email by Terry Love, 7 Feb 2006:
I've found the body of work round Constituent Orientation useful. Constituent = anyone who is affected by or affects a situation. I've found the direct and indirect stakeholder model gets messy as situations get complex because some individuals/groups are direct in some respects and indirect in others. Also the stakeholder literature is primarily financial (stake = 'investment') and substantially tied to a business-like model that requires some of the people involved to be seen as 'customers'.
There are two other benefits of the constituent-based approach. There is a strong literature and solid body of research/theory; and Constituent research identifies and resolves many of the problems with stakeholder-based approaches. These steakholder problems are particularly evident in situations that involve public good, such as developing a new approach to designing transportation systems, or improving quality in university doctoral education.
Can context logic capture the nature of this? It sounds like it could.