The differences between implicit and explicit updates have already been men-tioned in Section10.2. As the consequences of an insert operation are different from those of an assert operation the guarantees have to be different likewise.
Inserting knowledge is an explicit operation which gives the guarantee that the knowledge base indeed contains the statement afterwards.
Consider the following insert operation:
i n s e r t ( h t t p : / / example . o r g#Katrin , h t t p : / / f a m i l y . o r g#marriedTo , h t t p : / / example . o r g#John ) .
The knowledge base now contains the resources :Katrin and :John plus the pred-icate family:marriedTo which connects both other resources. Therefore it is pos-sible to guarantee at the same time that, after the insert operation, the deletion of the same statement would succeed.
The situation is different if an assert operation with the same statement was executed instead of the insert operation. Although both operations ensure that the knowledge base will entail the given statement afterwards only the insert ensures that the statement is actually contained. Consider a situation where the knowledge base already contains the same statement through entailment:
: John f a m i l y : marriedTo : K a t r i n .
f a m i l y : marriedTo a o w l : S y m m e t r i c P r o p e r t y .
Because family:marriedTo is a symmetric property it can be derived that also :Katrin is married to :John. The insert operation from above would nevertheless add the (now redundant) statement and so it could also be deleted again.
In contrast, the assert operation would cause no changes in the knowledge base (though committing successfully) as the intention of the update is already
fulfilled. A consecutive delete operation on the same statement, however, would fail because a non-existent statement cannot be deleted.
From this considerations follows that the consequences of an assert operation depend heavily on the existing data (both assertional and terminological) and the inference mechanism. As the reasoning process itself is treated as a black box it cannot be told alone from the success of an assert operation what actually happened within the knowledge base. Hence, the only guarantee towards the assert operation can be given with regard to the entailment of the statement by the model.
A similar situation can be found with the relationship of the delete and the retract operations. Both operations ensure that the statement, as specified with the operation, cannot be entailed afterwards. But it cannot be told whether the retract operation performed any changes to the knowledge base at all. Other than with insert and assert, here is no difference with regard to future operations because both delete and retract lead to a situation where the statement is not contained in the knowledge base.
The logical characterisations that have been presented, complete the main part of this work. In the next part, the results are discussed.
Results
143
Applicability
This chapter gives a motivating example scenario by which the capabilities of the Swan architecture are demonstrated. The scenario consists of an applica-tion domain with two domain applicaapplica-tion nodes. These domain nodes use the components of an existing Mars implementation for ECA rule evaluation. The description of the scenario involves
- concepts of the application domain defined in the domain ontology, - ECA rule definitions for event processing,
- ACA rules for a mapping of domain actions to knowledge base updates, - local ECE rules in form of knowledge base triggers for the raising of events, - local ECA rules, again as knowledge base triggers, for the completion of
knowledge base updates,
- F-Logic programmes for hybrid reasoning,
- event definitions which initiate activities in the domain (simulating user interaction).
The chapter comprises a short description of the technical details, the rule specifications, and some conclusions.
11.1 Technical Details
Two domain nodes are integrated into a Mars infrastructure using virtual ma-chines (VM). Each node runs in its own VM with the same technical setup.
By the use of a VM for hosting a domain application node the scenario can be extended easily by an arbitrary number of additional nodes that are completely independent. The nodes differ only in the way that they become initialised by a startup script. This script loads all ontological data (the contents of the know-ledge base), triggers, and ACA rules. Furthermore, the application domain node registers at the domain broker in order to receive actions. ECA rule definitions are sent to the ECA engine. Each node can be administrated seperately by its own frontend which is accessible via a web browser. Additionally, there is a do-main frontend, which allows for the sending of commands to one or more nodes
145
plus the sending of pre-defined domain actions (see the screenshot in Figure 11.1).
Figure 11.1: Domain Frontend (Screenshot of the Browser Interface)
The application domain nodes make use of an implementation of the Mars framework, which resides on a separate machine (note that the place where the components are located is not important, all services can be distributed amongst many different servers). The Mars framework can be administrated via a browser interface that offers several options for managing the Mars in-frastructure: rule (de-)registration, event raising (also by choosing from a set of pre-defined events), and framework logging facilities.
For the demonstration of the interaction of the components, an example scenario about travel planning and booking is presented.