The Fact Space model is a coordination model which provides applications with a federated fact space: a distributed knowledge base containing logic facts which are implicitly made available for all devices within reach. Consequently, when an application asserts a fact in the federated fact space, other devices that are within earshot can see the fact and react to its appearance.

To react to the appearance of facts in the federated fact space, applications specify logic rules. These logic rules describe the causal relation between (a combination of) context observations and the application's reaction. Moreover, when the facts that cause a rule to trigger are removed, the application is notified that some of its reactions may need to be reconsidered.

In summary, the Fact Space model combines the notion of a federated fact space with a logic coordination language. In the remainder of this section we will discuss each of these components in slightly more detail.

The Fact Space model equips every application with a private fact space in which application-specific facts can be stored. Additionally, applications may use an arbitrary amount of (named) interface fact spaces. Facts which are asserted in these interface fact spaces are transparently shared by the underlying implementation (Crime) which aggregates all reachable interface fact spaces with the same name into a federated fact space. Hence, when interacting with its own interface fact space, the application can transparently access facts published by other devices in its immediate environment.

In essence, the distribution semantics of the federated fact space in the Fact Space model are largely similar to those of the federated tuple space of Lime. One notable difference is that whereas tuple spaces are based on the notion of a blackboard where messages can be published, read and removed, fact spaces are conceived as knowledge bases. This implies that in the Fact Space model both the assertion and retraction of a fact are meaningful events which may trigger reactions.

The fact that applications can respond to both the assertion and the retraction of facts is of particular importance when devices go in and out of earshot. For instance, when a new device is discovered, its interface fact space will be engaged. This implies that all its facts will be atomically and transparently asserted in the federated fact space. Conversely, when a device goes out of communication range, its interface fact space is said to be disengaged which implies that all facts that it contained are retracted. Since retraction is reified by the Fact Space model, applications which reacted to the appearance of a fact published in the disengaged space (possibly in combination with other facts) are provided with the opportunity to recover from the disappearance of that fact. This mechanism provides the Fact Space model with fine-grained support for the handling of disconnections.

The Fact Space model provides applications with a logic coordination language to cherry pick the relevant context information from the federated fact space. For instance, consider a cellular phone that wants to adapt its sound profile according to its current location. First of all, such an application would contain a set of preferences which detail which sound profile needs to be adopted in various room types. In the example application shown below, these preferences are encoded as facts published in the private fact space.

preference(meetingRoom, silent). 
preference(office, default).

:Switch(?profile) :- 
  location -> detected(myID, ?room), 
  preference(?room, ?profile). 

Subsequently, a Crime rule is defined which has two preconditions. First of all, it requires that there is a detected fact in a public fact space (named location), which denotes that the cellular phone is located in a room of a particular kind. The kind of room will be bound to the logic variable ?room. Additionally, a preference should be defined which determines the sound profile to be adopted for the given kind of room. When both conditions are met, the profile to adopt will be bound to the logic variable ?profile and the rule will be triggered. When the rule is triggered, it will invoke the application-specific action :Switch to ensure the cellular phone adopts the correct sound profile.

Applications can supply application-level actions (such as :Switch) by providing a Java class which implements the Action interface. Such classes need to implement two methods: First of all, the activate method which is invoked whenever a rule is triggered which lists the action in its rule head. Second, the deactivate method which is invoked when one of the facts that caused the rule to trigger is retracted. In the example, the deactivate method can be used to make the cellular adopt a loud sound profile.

S. Mostinckx, C. Scholliers, E. Philips, C. Herzeel, W. De Meuter. Fact Spaces: Coordination in the Face of Disconnection. In Murphy and Vitek (eds.), Proc. of the 9th Int. Conf. on Coordination Models and Languages (COORDINATION). LECT NOTES COMPUT SC 4467, pp. 268–285. Springer Verlag, June 2007. (pdf,bibtex)