Data that is subject to change has different needs in terms of care than static data. Dynamic aspects in data storage have been dealt with for a long time in active database research. The most basic form of active behaviour is common to most of the present-day databases: triggers. Triggers are simple rules on the (database) programming language and data structure level. The underlying paradigm for such behaviour are ECA rules: On the occurence of an Event, when someConditionis fulfilled, do someAction. In databases, the pattern for trigger definitions is: ONeventIFconditionTHENaction. With triggers, the conditions are given in the database query language and will evaluate to false or true, only in the latter case allowing the trigger to fire and the action part to be evaluated. The action component is given in a simple, operational programming language. The event is a request for the execution of a database operation, e.g. update the number of booked seats of a flight (see Example4.3).
Triggers can be defined to initiate some action before or after the requested database operation is executed, and the action can be supplemental or substi-tutional to the requested operation. Since 1999, triggers are part of the SQL standard. Real-world trigger definitions in SQL are somewhat more complex than the abstract definition above, as they allow for complex, finetuned defini-tion of behaviour that is integrated into the data definidefini-tion and update language.
The purposes of triggers are manifold: they can be used to maintain database integrity and exception handling, to implement business rules, or to fulfill
main-tenance and monitoring tasks within the database itself instead of programmes outside the database.
Trigger implementations differ depending on the database systems in use.
Some make it possible to use embedded procedural languages in the action part of the trigger. That is a very useful feature, because relational algebra, which forms the basis of SQL, is not Turing-complete.
The following example is a typicalafter-trigger, following the SQL standard:
Example 3.20
CREATE TRIGGER f l i g h t a v a i l a b l e c h e c k i n g AFTER INSERT ON F l i g h t b o o k i n g s
REFERENCING NEW AS N
WHEN ( s e l e c t c o u n t (∗) a s b o o k e d s e a t s from F l i g h t b o o k i n g s where f l n u m b e r = n . f l i g h t )
UPDATE b o o k i n g s p e r f l i g h t SET b o o k i n g s = b o o k e d s e a t s WHERE f l i g h t N u m b e r = n . f l i g h t
On the event of an insert on the table Flightbookings the condition of the trigger rule is evaluated (a query that selects the number of booked seats for that flight). Then another table is updated with the result from the query. This is a typical situation where a trigger is used for the update of a materialised view.
The ECA paradigm, which makes it possible to define the behaviour of the database system, can easily be extended. On the one hand, the action part can be, as mentioned before, a fragment of an arbitrary procedural language. On the other hand, the event part can be a composition of many single events com-bined by an event algebra. There has been a lot of research on event algebras for ECA rule systems in the (active) database community [CM94, GJS92] during the ’90s. This branch of research was stimulated again with the advent of the Semantic Web, when again the usage of the ECA paradigm seemed fitting for the description of the dynamic aspects of change in knowledge bases [MAB04].
There have been several examinations on how to develop meta-models, encour-aging the definition of a general semantics for ECA-Rules that covers most of the popular ECA-rule systems from previous research, e.g. [Hin03,ZU99].
The situation in a (distributed) knowledge base is up to a certain extent similar to the one in a database. But the distinction of what an action and what an event is can be different. In the database the point of view is determined by the perception of the process: the event (something changes) is directly connected to the update (which causes the change of state). In a database the action-performing agent and the event-detecting observer are always the same.
In the Semantic Web there are many agents, and events can be about arbitrary changes performed by any agent. If an event is detected it is not necessary to know where it originated or which action was causing it. Without consideration of the agent, we talk about an event (following a common definition given by e.g. [Kem01]). An event is primarily something linguistic or cognitive in nature as the world does not really contain events. But how exactly do actions and events interact? A general representation of actions and events has to be found in order to support reasoning about the dynamic aspects of application domains.
These questions will be examined in more detail in Chapters4and5.
MARS: Modular Active
Rules in the Semantic Web
This chapter explains the design principles of Modular Active Rules (Mars) [BFMS06, BFK+07, BFMS08]. A description of the architecture and the com-ponents of the service infrastructure is provided.
4.1 Overview
As the nameactive rulesindicates, theMarsrule system offers an infrastructure which can be used for the modelling of thedynamic aspects of an application domain. This means that the behaviour of a domain (e.g. a set of services) can be specified by rules which are executed directly by the rule evaluation system of Mars. Consider the following example:
Example 4.1(Travel booking)
The application domain consists of services for travelling. In a flight booking process a travel agency and an airline company are involved. The plot is: a customer wants to book for flight LH458, the travel agency orders the booking at the airline company and the airline has to update its internal database in order to reflect that change on flight LH458. The intended behaviour can be modelled by the use of a simple rule: on the occurence of a flight-booking if there are available seats for that flightthen dobook-seat. This rule is given to Mars and in case of a flight-booking the rule evaluation engine will conclude
thatbook-seathas to be done. 2
The rule formalism that is used in Mars follows the ECA paradigm (see again Section 3.8). ECA rules consist of an event, a condition and an action part. Initially, an event from the application domain (e.g. book-flight) activates the evaluation of the rule. Eventually, if the condition (the query to the airline for available seats) is satisfied, the actionbook-seatis executed.
The execution of such a rule relies on a set of service components which will be described in Section4.2. The components and their interaction are mostly invisible to the user. In this respect, the Mars architecture differs greatly from other architectures like Web Services. The latter demand from the user to
59
address services directly in order to execute programme codeof the service. In Mars, however, it is not necessary to know how the services are implemented, for example how a flight booking has to be done. Instead, the behaviour of the domain is modelled abstractly by rules which in turn can be executed directly.
The only preconditions are knowledge about
• how to define rules using the Marsrule formalism and
• what vocabulary has to be used (e.g.flight-booking,book-seat) in order to achieve the desired behaviour.
Section 4.3presents the concept of ECA rules and how it is used in Mars. This includes a description of the notions of actions and events and how they are conceived in the context of Mars. Domain ontologies provide the vocabulary which is used for the specification of events, actions, and other notions of the rules and the application domain. The concept of domain ontologies, however, is a subject of its own and will be discussed in Chapter5.