From the existing direct flight connections (which are given as facts to the know-ledge base) all possible connected flights between the airports are calculated in a hybrid reasoning process using an F-Logic programme (see Example 11.15).
Now the node can be queried for connections between arbitrary cities which are served by the airline company. The connection which is returned is always the fastest (the calculation of the duration of a flight includes the waiting time be-tween two flights at an airport). In case that a flight is fully booked, information about alternative flights is also available.
In the following the rules of the application domain are described. Figure 11.3gives an overview on how these rules interact by use of actions and events.
The booking of a flight can be achieved by sending an action (travel:flight-booking) to the domain node which becomes mapped by the following ACA rule to a knowledge base update:
ECA Engine
Figure 11.3: Interaction of Rules, Actions and Events in the Travel Scenario
? con r d f : t y p e t r a v e l : F l i g h t .
The condition of this ACA rule evaluates a test whether the requested flight still has available seats (by comparing the amount of bookings so far to the capacity of the airplane that is used for that flight). If there are any spare seats atravel:hasBookingstatement is inserted for the combination of that flight and
passenger.
In addition to that ACA rule there are two triggers which react on insertions of travel:hasBooking(theinsertoperation is seen as an event on the level of the application). The first trigger (Example 11.5) refreshes the travel:hasBookings counter for each flight that received a new booking:
Example 11.5 (Trigger: add-booking)
The second trigger (Example11.6) raises an event for every single booked flight:
Example 11.6 (Trigger: raise booked-seat event)
In order to allow for the booking of a flight between two airports an ECA rule is registered at the ECA engine:
Example 11.7(ECA-rule: book flight)
<t r a v e l : p a s s e n g e r>{$P e r s o n}</ t r a v e l : p a s s e n g e r>
This rule fires upon receiving an event of the following kind:
Example 11.8 (book-flight event)
The condition part of the ECA rule sends a query to the airline domain node asking for a travel:ConnectedFlightbetween the two airports that are given in the event. If there is such a flight connection, the domain node will return a result tuple for each necessary flight (from San Francisco to Frankfurt, there are two flights necessary: San Francisco-Denver, Denver-Frankfurt). The action part of the ECA rule sends a travel:flight-bookingaction to the airline domain node for every result tuple.
The ACA rule in Example11.4translates thetravel:flight-bookingaction into a knowledge base update: a seat for the flight is booked, causing the trigger from Example11.6to raise atravel:flightBookedevent.
There is another ECA rule which serves the purpose of a car pre-reservation:
Example 11.9 (ECA-rule: car pre-reservation)
<e c a : has−i n p u t−v a r i a b l e name=”To” u s e=”$To”/>
As soon as the ECA engine receives a travel:flightBookedevent the second domain node is needed: the car-rental domain node. This domain node repre-sents a car-rental company with several branches at selected airports or nearby cities. Each branch has a set of available cars at specific prices. The purpose of this node is, similar as with the airline domain node, to demonstrate the
capabilities of the rule driven architecture of Swanand Marsrather than to implement a real-world business application (although it can easily be extended for such a purpose). The domain node does not store information about single cars that are being booked or pre-reserved. Instead, all reservations are realised by adding a statement for thetypesof cars being reserved for a certain contract number. As there is no limit to such statements about a car type, there is also no limit to the availability of cars. In a more sophisticated application, there would be a booking object with information about contract, car-number, price, and date.
The car-rental company shares part of the domain knowledge with the air-line domain node as both make use of the travel ontology. The domain node also knows about existing airports and where they are located at. Hereby corre-sponding branch offices of the OntoRent company and airports can be matched (e.g. the airport in Frankfurt and the car-rental branch in Wiesbaden).
Once the ECA engine receives atravel:flightBookedevent, the car-rental do-main node is queried for suitable cars. In this scenario the car rental dodo-main node has access to details about registered customers with regard to their prefer-ences. It is known, for example thatJohn Doeowns avw:Golf and avw:Passat.
It is assumed that a customer wants to rent a car of the same kind that he owns. Therefore, the query asks for cars belonging to the same class as the one that the customer owns, available in the car-rental branch of the city that is next to the destination airport1. IfJohn Doe travels to Frankfurt there would be two types of cars suitable for him: a VW Golf and an Audi A4. For both of them a pre-reservation would be made from which he can choose. These pre-reservations are, again, realised by an ACA rule:
Example 11.10 (ACA-rule: Car pre-reservation)
1Actually, the carpre-reservation is done for every intermediate airport on a connected flight, but only at the destination airport there will be a confirmation of a pre-reservation.
}}”>
This ACA rule has two actions as consequences: firstly, the pre-reservation is inserted into the knowledge base. Secondly, a travel:car prereservation event is raised. Besides the raising of the event by the ACA rule there is another reaction in the knowledge base: a trigger fires upon the event of an insertion of a statement with the predicateontorent:prereserved for:
Example 11.11(Trigger: Car pre-reservation)
As it was shown with the rules above, a car-pre-reservation has, as a con-sequence, two events: thetravel:car prereservationevent and the travel:decision-Requiredevent. This ECA rule causes all pre-reservations to be cancelled after a specified time (here 24h):
<e c a : has−i n p u t−v a r i a b l e name=”Cn” />
All pre-reservations that have not been confirmed before the timeout will be cancelled by a travel:cancel-car-prereservation action that is sent to the domain node. This ECA rule is registered at the ECA engine by the car-rental domain-node itself. Additionally, there is another ECA rule, which becomes registered by the customer:
<t r a v e l : l o c a t i o n>{$c i t y}</ t r a v e l : l o c a t i o n>
This rule automises the decision procedure and should be registered by the customer before sending thetravel:book-flightevent at the beginning of the book-ing process. The rule is triggered by a travel:flightBooking event where name and destination match the values given in the initialisation variables of the rule.
The action part consists of a CCS process which collects, after the detection of the travel:flightBooked event, for the duration of one hour (specified with the ccs:wait attribute) alltravel:car prereservation events and chooses that one with the lowest price. Finally atravel:confirm-car-prereservationaction is sent to the car-rental domain-node, which is mapped by the following ACA rule to a knowledge base update:
This ACA rule simply updates the predicate of the pre-reservation-statement such that it is now a reservation statement.
F-Logic Programme
The domain node representing the airline company uses a flight plan in which direct flight connections between airports are defined, e.g.San Francisco
→ Denver. By use of hybrid reasoning all possible connections between pairs of airports can be calculated, e.g.San Francisco →Denver →Frankfurt. The F-Logic programme creates connected flight objects by concatenating the names of the departure and destination airports of two flights (either simple or con-nected flights). By appending further simple flights to a concon-nected flight, longer connected flights are created until eventually all possible connections between airports are constructed. If two airports are to be connected by more than one connected flight only the one with the shorter flight duration is chosen. The du-ration of a connected flight is calculated by adding the time of the constituting flights plus the waiting time at the intermediate airports.
Note that this construction of new flights (or new objects in general) would not be possible in OWL or by the use of the built-in rule engines of Jena. Although theowl:transitivePropertyallows to deduce that San Franciscois con-nected with Frankfurt it is not possible to assign properties to such connec-tions. Furthermore, F-Logic reasoning allows for stratification. For operations on cyclic graphs a fixpoint computation is necessary. This, however, is not pos-sible with the in-built rule engines that come with the programming framework Jena. Hence, the built-in reasoning engines of Jena would fail because of the cycles in the flight plan (see Figure11.2).
Example 11.15 (F-Logic: connected flights)
p a u s e (X, Y,DP) ,
” h t t p : / /www . s e m w e b t e c h . o r g / domains /2006/ t r a v e l#t o”−>>T
HH = ( YDH− XAH + 24 ) ∗ 60 + MM .
The hybrid reasoning process has to be run only once during the initialisation of the domain node. Florid then delivers instances of the newly introduced concepttravel:ConnectedFlight(which is also created and added to the concept definitions in the DL TBox). Only in case that, at a later stage, new flight connections are added to the knowledge base (which can be assumed to happen very seldom) the hybrid reasoning process has to be started again. This can be realised by use of a trigger like
ON CREATION OF INSTANCE OF CLASS t r a v e l : F l i g h t DO BEGIN s t a r t−f l o g i c−r e a s o n i n g ( ) ;
END;