CRIME (Consistent Reasoning in a Mobile Environment) is a logic-based coordination language, which was developed by Christophe Scholliers and Eline Philips during their master thesis. CRIME implements the Fact Space Model, which was designed by Christophe and Eline in collaboration with their supervisors Stijn Mostinckx and Charlotte Herzeel.
CRIME allows applications to specify logic rules which specify how the applications should respond to changes in its immediate environment. Such changes are modelled by the addition or removal of facts which contain context information.
A key feature of CRIME is that applications can explicitly respond to the removal of information. This gives fine-grained control over how an application should respond to disconnection, which implicitly removes information from the system.
The CRIME Engine that was developed by Christophe and Eline in the context of their master thesis is available for download here.
The Fact Space Model
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
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.
Logic Coordination Language
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.
location -> detected(myID, ?room),
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.
The CRIME distribution comes with a suite of example applications, most of which are implemented in Java. This page describes the provided applications, how to deploy them, describes the rules they use internally and provides pointers on how to extend them.
The IN/OUT Board is a classic context-aware application proposed by [Dey et al.] during their seminal work on the context toolkit. The IN/OUT Board implemented using CRIME is used to visualise the current location of a user. The said location is expected to be published as a fact to allow applications to adapt their behaviour accordingly. When users are out of reach, the application keeps a record of when the user was last seen by the system.
Deploying the application
The CRIME distribution contains a script file server.sh, which starts a host-level CRIME Fact Space. It is important to start this server prior to running any CRIME application. After all, it is only through the mediation of the host-level Fact Space that different CRIME applications discover one another both locally and remotely. To start the IN/OUT Board, run the included script file inout.sh. The CRIME engine will evaluate the rules specified below.
The IN/OUT Board consists of an application class which manages the information on which users are located where which is coupled to simple user interface class written in Java. The application also offers a few classes which subclass from the Action class offered by the CRIME engine. These classes can be used in the CRIME rules which specify when the application will be notified of changes in its environment.
The Action class is an abstract class which expects its subclasses to implement two methods: The method activated is invoked whenever a CRIME rule can be derived which triggers the action. The method deactivated is invoked when the supporting evidence that allowed this rule to fire is dropped (due to a retract or a disconnection of a provider).
The rule below triggers the SetBoard action whenever it detects that a particular person (?name) is detected within a particular ?room. The activated method is invoked and will display the said information in its GUI. When the person leaves the room, the deactivated method of SetBoard is triggered which adds a history fact (used in the next rule), containing the persons last known whereabouts and a timestamp of when the deactivated method was invoked.
:edu.vub.crime.examples.board.SetBoard(?name, ?room, ?number) :-
person(?id, ?name, student),
As described in the original paper by [Dey et al.], variations in the functionality of the IN/OUT Board can be conceived where some versions may also display the last known whereabouts of a particular user on the screen. This can be achieved using the history fact which is published when the SetBoard action is deactived. When using the rule given below, the appearance of such a fact will trigger the HistoryBoard action which updates the GUI with the required information.
?name, ?room, ?phone, ?time) :-
history(?name, ?room, ?phone, ?time).
CRIME is a research artifact developed at the Software Languages Lab which can be best described as ‘a coordination language for mobile devices’. The language has been designed as a declarative medium to describe how applications should adapt to changes in its immediate environment. The language is used as a research artifact to study optimization techniques and coordination using temporal logics, yet it is also used to develop realistic scenarios.
CRIME has been designed to co-exist with available Java programs. It offers Java programs a way to enrich the vocabulary of the coordination language by defining custom actions which correspond loosely to method invocations on the Java program. Similarly programs can explicitly add facts to signal detected changes in the environment. This makes CRIME an ideal language to write ‘context-aware glue code’ to make isolated Java programs aware of one another’s presence and ‘state’.
Download the CRIME engine Christophe Scholliers and Eline Philips developed for their master thesis.
This build contains:
The CRIME interpreter is written in pure Java and requires a regular J2SE Java Virtual Machine supporting version 1.4 or higher.