• Keine Ergebnisse gefunden

7.3 Formal Specification of Triggers

7.3.2 Trigger Evaluation

The general structure of a trigger is

onu when γ dou

where γ is a conditional expression, and u is a set of updates. Note thatu, γ may contain variables. A trigger is activated if a substitutionσexists such that σ(ui) =ui for aui∈U.

First, a general definition for the evaluation of triggers will be given. Later, this definition will be specified for pre-reasoning and post-reasoning triggers. The overall process of trigger evaluation is described schematically in Figure7.1.

T R

ωT

∆6= 0 True post False

U

T R

ωT

pre

M0:=M(G0) G0

M1:=M(G1) G1

Figure 7.1: Evaluation of Triggers and Updates

Triggers are evaluated using the trigger evaluation operatorT R. The signature ofT RT ,G is:

T RT ,G : 2U→2U

Definition 7.2 (T RT ,G)

For a setT of triggers and a graphG, an updateU is complemented byT RT ,G

such that

T RT ,G(U) = U∪ S

t∈T

( σ(ut) | t= (onut whenγ dout) and σis a substitution such thatσ(ut)∈U and

ut∈U and M(G)|=OW L σ(γ)) The fixpoint ofT RωT ,G is defined as follows:

T RT ,G0 (U) = T RT ,G(U)

T RT ,Gi (U) = T RT ,G(T Ri−1T ,G(U)) fori≥1 T RT ,Gω (U) = lim

i→∞T RiT ,G(U)

T RωT ,G is well-defined if the iteration ends in a finite number of steps:

T RT ,G(T RimaxT ,G (U)) =T RT ,Gimax(U) 2 Pre-reasoning triggers. Pre-reasoning triggersTpreare intended for the com-pletion of an initial set of updates such that consistency of the specialised theory M is guaranteed after all updates are applied. It is necessary to compute a fix-point, because the updates by the triggers again have to be completed . The operatorT RωTpre,G is used for that fixpoint computation, resulting in the com-pleted set of updatesUcomp.

Ucomp = T RωTpre,G(Ubase)

ApplyingUcomp to Gresults in G for which a specialiced theory M exists. δ computes the set ofchanges ∆ fromM,M andUcomp.

M = M(Apply(Ucomp, G)

| {z }

=:G

)

∆ = ∆(M, M, Ucomp)

Post-reasoning triggers. Post-reasoning triggers Tpost are evaluated using the operatorT RTpost,G, reacting on the changes ∆:

Ubase = T RTpost,G(∆)

The resulting updatesUbaseare the consequences of the post-reasoning triggers.

Raising of Events. The consequence of a post-reasoning trigger can be either an update or the raising of an event. As events shall be raised only in case of a successful update, the raising of events has to be delayed until the update processT Uis finished and no further updates are triggered. All events that have been accumulated up to this point are then risen simultaneously. The raising of

events is realised by applying theT Roperator for sets of event-raising triggers Tevt. The signature is the following:

T RTevt,G: 2U → (2U,2E) U 7→ (U,E)

whereEis the set of events that are delayed until the end of the update process.

WhenT RTpost,G is evaluated on a set of changes ∆ also T RTevt,G is evaluated on the same ∆.

Note that this division of post-reasoning triggers into event raising triggers and others causing further updates is only theoretical. In the implementation, both kinds of post-reasoning triggers are evaluated at the same time. With regard to the formal definition, however, this assumption can be made without loss of generality as the event triggers have no side effect on the update process at all.

Definition 7.3 (Update executionT U)

The execution of updates is defined by the operatorT U as follows:

T U : M×2U →(M,∆)

The application of a set of completed updatesU (pre-reasoning triggers already fired once) is defined as:

For an initial updateuthe set of induced updatesU has to be calculated:

U :=Ucomp:=T RωTpre,G(u)

T Uωcan be expressed with regard to the the initial updateuas

∆ = δ(M(G)

This formal specification completes the considerations about knowledge base triggers inSwan. In the following chapter, ACA rule processing is described as another central aspect of theSwanarchitecture.

The ACA-Rule-Aware Application Node

The infrastructure of the Mars architecture is orchestrated by the exchange of events, which are distributed by a domain broker. The integration of the application domain nodes, however, depends on the actions that they receive from the domain broker. The abstract actions from the application domain are translated into knowledge base updates by the use of ACA rules (see Section 5.2.3). In the scope of this thesis an ACA rule mapping mechanism was inte-grated into theSwanarchitecture. The following chapter gives a description of this component.

8.1 Wrapper Components

The translation of abstract actions is realised by a wrapper around the know-ledge base. Abstract actions are translated by the help of XQuery scripts into knowledge base updates, given as XML fragments as presented in Section6.1.2.

These fragments are passed to the knowledge base for execution. Hence, the ACA rule mapper consists mainly of an XQuery engine.

Moreover, a set of built-in XQuery functions is available. These functions create proper XML fragments for update operations. For example, the following XQuery function returns an XML fragment for anrdfu:insertoperation:

Example 8.1(rdfu-Action insert)

d e c l a r e f u n c t i o n r d f u : i n s e r t ($sub , $p r e , $o b j ) { i f ( e x i s t s ($o b j ) ) t h e n

(

<r d f u : i n s e r t>

<r d f : s u b j e c t r d f : a b o u t =”{s t r i n g ($s u b )}” />

<r d f : p r e d i c a t e r d f : a b o u t =”{s t r i n g ($p r e )}” />

{ i f ( r d f u : i s L i t e r a l ($o b j ) )

t h e n <r d f : o b j e c t>{s t r i n g ($o b j )}</ r d f : o b j e c t>

e l s e <r d f : o b j e c t r d f : a b o u t =”{s t r i n g ($o b j )}” />

}

</ r d f u : i n s e r t>

) e l s e ( ) };

103

Domain Broker

Actions

Domain

Node ACA Wrapper

Interface

Opaque Actions

= Native Knowledge Base Updates

Abstract Actions Events

OWL Knowledge Base

Answers

Figure 8.1: Architecture of the Domain Application Node

Instead of giving the whole XML fragment, the following XQuery function call is sufficient:

r d f u : i n s e r t ( : Susan , f a m i l y : h a s C h i l d , : P e t e r ) .

This is useful for better readability and also for the ease of writing of ACA rules.

ACA rules are added to or removed from the domain node by the use of the application-node actionsapplnode:register-aca-mappingand applnode:delete-aca-mapping.

In the following, an example of a simple application domain is given, which is used for illustrating the handling of abstract actions inSwan.