InSwan, hybrid reasoning is used only as a supplementary reasoning process that is activated on demand (in contrast to OWL reasoning which is applied continuously). Only when the additional deductive power of F-Logic is needed the additional inference mechanism is used.
Consider a railway company that uses a knowledge base containing a number of interconnected railway stations. Moreover, the fact base defines connections between neighbouring stations (”direct-connections”along with their”distances”
and ”durations”). The rules in the F-Logic programme calculate all possible
”connections”between reachable rail stations.
Note that for ease of reading, the whole example is given in F-Logic. In Swan, usually the facts are given as RDF statements and only the derivation rules are given in F-Logic.
Example 9.18 (Railway facts)
” G o e t t i n g e n ” : ” s t a t i o n ” [ ”name” −>> ” G o e t t i n g e n ” ] .
” Hannover ” : ” s t a t i o n ” [ ”name” −>> ” Hannover ” ] .
” B r a u n s c h w e i g ” : ” s t a t i o n ” [ ”name” −>> ” B r a u n s c h w e i g ” ] .
” Hamburg Hbf ” : ” s t a t i o n ” [ ”name” −>> ” Hamburg Hbf ” ] .
” B e r l i n Z o o l o g i s c h e r G a r t e n ” : ” s t a t i o n ”
[ ”name” −>> ” B e r l i n Z o o l o g i s c h e r G a r t e n ” ] .
” Magdeburg ” : ” s t a t i o n ” [ ”name” −>> ” Magdeburg ” ] .
” G o e t t i n g e n−Hannover ” : ” d i r e c t−c o n n e c t i o n ” .
” G o e t t i n g e n−Hannover ” [ ” d u r a t i o n ”−>54;” d i s t a n c e ”−>100].
” G o e t t i n g e n−Hannover ” [ ” from”−>” G o e t t i n g e n ” ; ” t o ”−>”Hannover ” ] .
” G o e t t i n g e n−B r a u n s c h w e i g ” : ” d i r e c t−c o n n e c t i o n ” .
” G o e t t i n g e n−B r a u n s c h w e i g ” [ ” d u r a t i o n ”−>54;” d i s t a n c e ”−>110].
” G o e t t i n g e n−B r a u n s c h w e i g ”
[ ” from”−>” G o e t t i n g e n ” ; ” t o ”−>”B r a u n s c h w e i g ” ] .
” B e r l i n Z o o l o g i s c h e r G a r t e n−Hamburg Hbf ” : ” d i r e c t−c o n n e c t i o n ” .
” B e r l i n Z o o l o g i s c h e r G a r t e n−Hamburg Hbf ” [ ” d u r a t i o n ”−>96;” d i s t a n c e ”−>175].
” B e r l i n Z o o l o g i s c h e r G a r t e n−Hamburg Hbf ”
[ ” from”−>” B e r l i n Z o o l o g i s c h e r G a r t e n ” ; ” t o ”−>”Hamburg Hbf ” ] .
” Hannover−Hamburg Hbf ” : ” d i r e c t−c o n n e c t i o n ” .
” Hannover−Hamburg Hbf ” [ ” d u r a t i o n ”−>68;” d i s t a n c e ”−>175].
” Hannover−Hamburg Hbf ” [ ” from”−>”Hannover ” ; ” t o ”−>”Hamburg Hbf ” ] .
” B r a u n s c h w e i g−B e r l i n Z o o l o g i s c h e r G a r t e n ” : ” d i r e c t−c o n n e c t i o n ” .
” B r a u n s c h w e i g−B e r l i n Z o o l o g i s c h e r G a r t e n ”
[ ” d u r a t i o n ”−>96;” d i s t a n c e ”−>240].
New connections can be found from the facts by computing the transitive closure using the F-Logic rules from Example9.19. The new resource names are created by a concatenation of the names of the railway stations. Hereby, all newly created connection objects are added to the OWL knowledge base. With little extra effort theFloridrailway example can be extended such that only those connections for pairs of stations are added which have the shortest duration.
Example 9.20(Computing fastest railway connections)
C2 : c o n n e c t i o n [ from−>Y; t o−>Z ; t m p d u r a t i o n−>D2 ; p a t h−>P2 ] ,
These rules create temporaryconnectionobjects for all pairs (A, B) of railway stations whereBis reachable fromAand where the duration of the new connec-tion is shorter than any existing one for the same pair of staconnec-tions. The last rule creates ”connection” objects for all pairs (A, B) choosing from the temporary connectionobjects the one with the shortest duration. Only these”connection”
objects become instances ofurl, therefore they are the only resources that will be added to the OWL knowledge base.
The hybrid reasoning process, which calculates new connections along with their durations has to be performed only once when the knowledge base becomes initialised . The results fromFloridare returned to the hybrid reasoning core where they are translated into RDF statements and added to the knowledge base. A new hybrid reasoning process is only necessary in case that there are changes in the knowledge base that would allow to derive new facts by the hybrid reasoning process (e.g. insertion of new stations). This behaviour can be defined and initiated by the use of triggers:
Example 9.21 (Hybrid reasoning activated by a trigger)
ON CREATION OF INSTANCE OF CLASS
The trigger condition is not intended to bind any values to variables (actually, connectedis adon’t-care variable). Rather it ensures that the trigger fires only in case of the insertion of a new station which is also part of a connection (connected either by thefrom or to property). The action part in the trigger definition (start-flogic-reasoning()) is a domain node action which initiates the hybrid reasoning process.
The last chapters described all features of the SWAN architecture. Know-ledge base triggers, ACA rule wrapping, and hybrid reasoning have been pre-sented. In the concluding chapter about Swan the behaviour of the domain node is given a logical characterisation.
Logical Characterisation of Domain Node Behaviour
10.1 Integration into MARS
Rule formalisms play a central role in both the MARS and the Swan archi-tecture. Hereby,Swandomain nodes can be integrated easily into the MARS architecture. ACA rules enable domain nodes to react on actions of the appli-cation domain (see Chapter8) whereas knowledge base triggers allow to make changes within the domain node visible to other parts of the event-driven net-work (see Chapter 7). Basically, both of these formalisms are ECA rules and specify the behaviour not only of the domain node but also of global issues. In the event-driven architectureMarswhere all behaviour is specified by rules, it is possible to reason about the dynamic aspects of a domain. Such reasoning can be, for example, the testing of the satisfiability of an action or proving of the validity of rules with regard to knowledge base updates. A prerequisite for reasoning tasks like this is the characterisation of the dynamic aspects of the domain node. This characterisation is given in the following forSwan, covering ACA rules and triggers.
10.1.1 Characterisation of Events
The communication between the service components of the Mars framework and the domain nodes is mainly realised by events. Actions are discriminated from events with regard to operational aspects: actions actually are the activities that happen whereas events inform the rest of the application domain about these changes (see Section4.3.4). In this respect it makes sense to speak of a
“signaling of events”.
On a conceptual level, however, the notion of an event is different. Basically, an event does not exist and is never communicated. An event occurs instan-taneously and has no duration. It simply happens and becomesvisible. The visibility depends on the agent. Every agent has different knowledge and there-fore a different point of view. Events are not necessarily visible to all agents but can be distributed globally.
131
Definition 10.1 (Visibility)
Visibility of events is defined by a predicate visible(E,N) where E is a set of
events, which is visible to a set of agentsN. 2
The set of agents defines the range of visibility. Local actions (e.g. updates to the knowledge base) are always visible locally. From the point of view of the agent (the domain node) they are considered at the same time as events, e.g.
when a statement (x, y, z) becomes inserted into the knowledge base then the eventinsertion(x, y, z) becomes visible to the agent itself. The local node is the only agent that is able to see such an event unless it is explicitly made visible to the outside. Knowledge base triggers are ECA rules that are activated upon the detection of events, but as events directly correspond to actions (knowledge base updates) they actually fire upon actions. As a consequence it is possible to use triggers in order to make events visible (as realised by the domain-node actionraise-event).
The operation of raising an event makes the event visible to other nodes, e.g. a domain broker, formally specified by
visible({e},{localhost}), e∈DomainEvents visible({e},{localhost, DomainBroker})
DomainEventsare events that are specified as the consequence of a trigger. If an event is visible locally and is aDomainEvent it becomes visible to the domain, too (here to the domain broker as an intermediate distributor).
Events and the Aspect of Time
Events have no duration, which makes it more difficult to describe ongoing changes. Depending on the domain of interest it might be necessary to con-tinously talk about changes (e.g. a metereological station) or to have events which indicate only starting and ending points of periods of interest. In the latter case intermediate events might be necessary if the changes do not evolve monotonically.
Example 10.1
Again, a flight reservation system is considered. The availability of new flights is announced withnew-flightevents. The end of the reservation period is naturally limited by either the departure of the plain or when it is fully booked. The latter needs to be made visible with afully-bookedevent whereas the first can be derived from the flight schedule. Intermediate events can be used to indicate the booking
status (e.g. half-booked). 2
Events are well suited for the implementation of the notion of time in the MARS framework. Time passes synchronously in discrete steps at all nodes which can be realised by time-events that are globally visible.
visible({time-passes-1sec},{timenode}) visible({time-passes-1sec},{global})
There has to be a coordinating node (named timenode in the definition above) which originates such events. Like any other event, global events are distributed by the domain broker. The term global does not denote a specific node but the set of all known nodes.
10.1.2 Events and Rules
The relationship of events and actions can be expressed by ECA rules. Similarly, ACE rules define, from the point of view of the agent, how actions (that the agent is able to fulfill) correspond to one or more events.
Example 10.2
The booking of a seat for flight LH458 at the airline company is a local action.
The action is, locally, also seen as an insertion event. This event, in turn, can be made visible by a trigger:
ON INSERTION OF
http://www.semwebtech.org/domains/2006/travel#bookedFor DO BEGIN
raise event(
<travel:flightBooked xmlns:travel=
”http://www.semwebtech.org/domains/2006/travel#”>
<travel:flightNo>$flightNo</travel:flightNo>
<travel:date>$date</travel:date>
<travel:passenger>$pas</travel:passenger>
</travel:flightBooked>
);
END;
The following trigger raises, upon the same flight booking, an event in case that half of the seats of the airplane are booked:
ON INSERTION OF
http://www.semwebtech.org/domains/2006/travel#bookedFor WHEN SELECT ?flight WHERE{
<$old.subject>
<http://www.semwebtech.org/domains/2006/travel#hasBookings>
?bookings .
<$old.subject>
<http://www.semwebtech.org/domains/2006/travel#hasFlightNo>
?flight.
<$old.subject>
<http://www.semwebtech.org/domains/2006/travel#hasFlightNo>?con.
?con<http://www.semwebtech.org/domains/2006/travel#withType>
?type .
?type
<http://www.semwebtech.org/domains/2006/travel/iata/meta#capacity>
?cap .
FILTER(?bookings = ?cap/2)} DO BEGIN
raise event(
<travel:halfBooked
xmlns:travel=”http://www.semwebtech.org/domains/2006/travel#”>
<travel:flightNo>$old.subject</travel:flightNo>
</travel:halfBooked>);
END;
2
In fact, local ECA rules can be used as if they were ACE rules for the raising of events to the application domain.
Whereas ECA rules express the relationships between events and actions, ECE rules allow for the definition of the relationship between events (see also Section 5.2.2). In this respect ECE rules can also be regarded as rewriting rules for events. Mostly, the correspondence of events expresses different points of view of agents. For example, the flight-bookingevent with destination New York can also be rewritten as aflight-booking-to-USAevent.
More importantly, with regard to the domain application nodes, are ACA rules which have been presented in Section 8. The following section gives a logical characterisation for ACA rules.