Tutorial:
Deliberation RuleML, Reaction RuleML, and LegalRuleML:
Specification and Application
Harold Boley, Adrian Paschke, Tara Athan,
Monica Palmirani, and Guido Governatori
Part 2 - Reaction RuleML
Adrian Paschke, Harold Boley and Tara Athan
(RuleML Initiative)
The 6th International Symposium on Rules:
Research Based and Industry Focused (RuleML-2012)
Aug. 27-29, 2012, Montpellier, France 0

The RuleML Family
Reaction
Harold Boley, Adrian Paschke and Omair Shafiq: RuleML 1.0: The
Overarching Specification of Web Rules , in Semantic Web Rules,
Proceedings of RuleML-2010, Lecture Notes in Computer Science, 2010,
Volume 6403/2010, 162-178. 1

Reaction Rules: Four Sub-branches
• PR RuleML: Production Rules
(Condition-Action rules)
• ECA RuleML: Event-Condition-Action (ECA) rules
• CEP RuleML: Rule-based Complex Event Processing
(complex event processing reaction rules,
(distributed) event messaging reaction rules, query
reaction rules, etc.)
• DR and KR RuleML: Knowledge Representation AI
Reasoning withTemporal/Event/Action/Situation/
Transition/Process Logics and Calculi
Adrian Paschke, Harold Boley, Zhili Zhao, Kia Teymourian and Tara Athan. Reaction RuleML 1.0: Standardized Semantic
Reaction Rules, 6th International Conference on Rules (RuleML 2012), Montpellier, France, August 27-31, 2012 2

Reaction Rules: Specializable Syntax
<Rule @key @keyref @style>
Info, Life <meta> <!-– descriptive metadata of the rule --> </meta>
Cycle Mgt. <scope> <!–- scope of the rule e.g. a rule module --> </scope>
<evaluation> <!-- intended semantics --> </evaluation>
Interface <signature> <!– rule signature --> </signature>
<qualification> <!–- e.g. qualifying rule metadata, e.g.
priorities, validity, strategy --> </qualification>
<quantification> <!-- quantifying rule declarations,
e.g. variable bindings --> </quantification>
<oid> <!– object identifier --> </oid>
<on> <!–- event part --> </on>
<if> <!–- condition part --> </if>
Imple- <then> <!-– (logical) conclusion part --> </then>
mentation <do> <!-- action part --> </do>
<after> <!–- postcondition part after action,
e.g. to check effects of execution --> </after>
<else> <!–- (logical) else conclusion --> </else>
<elsedo> <!-- alternative/else action,
e.g. for default handling --> </elsedo>
</Rule>
3

Reaction RuleML – Example Rule Types
• Derivation Rule: <Rule style="reasoning">
(temporal/event/action/situation <if>...</if>
reasoning) <then>...</then>
</Rule>
• Production Rule: <Rule style="active">
<if>...</if>
<do>...</do>
</Rule>
• Trigger Rule: <Rule style="active"> >
<on>...</on>
<do>...</do>
</Rule>
• ECA Rule: <Rule style="active">
<on>...</on>
<if>...</if>
<do>...</do>
</Rule> 4

Rule Interface and Rule Implementation
<Rule style="active">
<evaluation>
<Profile type="&ruleml;DefiniteProductionRule" direction="forward" style="active"/>
</evaluation>
<signature> Interface with
<Atom> evaluation
<op><Rel>likes</Rel></op>
<arg><Var mode="+"/></arg> <!-- mode=+ i.e. input argument -->
semantics and
<arg><Var mode="?"/> </arg><!-- mode=- i.e. input or output argument --> rule signature
</Atom> declaration
</signature>
<if>
<Atom>
<op><Rel>likes</Rel></op>
<arg><Var>X</Var></arg>
<arg><Ind>wine</Ind></arg>
</Atom>
</if>
<do> Implementation
<Assert> <formula>
<Atom>
<op><Rel>likes</Rel></op>
<arg><Ind>John</Ind></arg>
<arg><Var>X</Var></arg>
</Atom>
</formula> </Assert> </do>Paschke, A., Boley, H., Kozlenkov. A., Craig, B.: Rule Responder: RuleML-Based Agents for Distributed Collaboration
5
</Rule> on the Pragmatic Web, 2nd International Conference on the Pragmatic Web, Tilburg, Netherlands, 2007.

Separation of Interface and Implementation
(Distributed Knowledge)
<Rule key="ruleinterface1">
<evaluation><Profile> ...p1… </Profile><evaluation>
<evaluation><Profile> …p2 …</Profile></evaluation> Interface 1
(@key=ruleinterface1)
<signature>…s1…</signature>
</Rule>
<Rule key="ruleinterface2">
<evaluation><Profile> ...p3… </Profile><evaluation> Interface 2
<signature>…s2…</signature> (@key=ruleinterface2)
</Rule>
…
<Rule keyref=“ruleinterface2" key=" ruleimpl2 ">
<if> … </if> Implementation 2
<do> </do> (@keyref=ruleinterface2)
</Rule>
<Rule keyref="rulreinterface1" key="ruleimpl1 ">
<if> … </if>
<do> </do> Implementation 1
(@keyref=ruleinterface1)
</Rule>
A. Paschke, H. Boley, P. Vincent, D. Sottara, T. Athan: Reaction RuleML for Loosley-Coupled and Event-Messaged KBs, OMG API4KB 6
Technical Meeting, Ontology PSIG, Cambridge, MA, 21 June 2012, http://www.cs.unb.ca/~boley/talks/ReactionRuleML-OMG.pdf

Example: Distributed Rule Interface and Implementation
<-- rule interface with two alternative interpretation semantics and a signature.
The interface references the implementation identified by the corresponding key -->
<Rule keyref=“#r1"> Interface
<evaluation index="1">
<!-- WFS semantic profile define in the metamodel -->
with
<Profile type="&ruleml;Well-Founded-Semantics" direction="backward"/> evaluation
</evaluation> semantics
<evaluation index="2"> and
<!-- alternative ASS semantic profile define in the metamodel -->
<Profile type="&ruleml;Answer-Set-Semantics" direction="backward"/> public rule
</evaluation> signature
<!-- the signature defines the queryable head of the backward-reasoning rule -->
<signature>
<Atom><Rel>getPapers</Rel><Var mode="+"/><Var mode="+"/><Var mode="-"/></Atom>
</signature>
</Rule>
<!-- implementation of rule 1 which is interpreted either by WFS or by ASS semantics
and onyl allows queries according to it's signature definition. -->
Implemen
<Rule key=“#r1" style="reasoning">
<if>... </if> tation
<then>
<Atom><Rel>getPapers</Rel><Var>Type</Var><Var>Status</Var><Var>Papers</Var></Atom>
</then>
</Rule>
Zhili Zhao, Kia Teymourian, Adrian Paschke, Harold Boley and Tara Athan: Loosely-Coupled and Event-Messaged Interactions with
7
Reaction RuleML 1.0 in Rule Responder, 6th International Rule Challenge at RuleML 2012, Montpellier, France, August 27-29, 2012

Descriptive and Qualifying Metadata
<Assert key="#module1”>
<meta> <!-- descriptive metadata -->
<Atom><Rel iri="dc:creator"/><Ind>Adrian Paschke</Ind></arg></Atom>
</meta>
<meta> Descriptive
<Time type="&ruleml;TimeInstant"><Data xsi:type="xs:date">2011-01-01</Data></Time> Metadata
</meta>
<meta>
<Atom><Rel>source</Rel><Ind>./module1.prova</Ind></Atom>
</meta>
<qualification> <!-- qualifying metadata -->
<Atom> <!-- the module is valid for one year from 2011 to 2012 -->
<Rel>valid</Rel>
<Interval type="&ruleml;TimeInstant"> Qualifying
<Time type="&ruleml;TimeInstant"><Data xsi:type="xs:date">2011-01-01</Data></Time> Metadata
<Time type="&ruleml;TimeInstant"><Data xsi:type="xs:date">2012-01-01</Data></Time>
</Interval>
</Atom>
</qualification>
<Rulebase key="#innermodule1.1">
<meta>…</meta> <qualification> … </qualification>
<Rule key=“#rule1”>
<meta>…<meta> <qualification> … </qualification>
</Rule>
<Rule key=“#rule2”>
<meta>…<meta> <qualification> … </qualification>
</Rule>
</Rulebase>
</Assert> 8

Dynamic Views with Scopes and Guards
<Assert key="#module1”>
<meta> <!-- descriptive metadata -->
<Atom><Rel iri="dc:creator"/><Ind>Adrian Paschke</Ind></arg></Atom>
</meta>
<qualification> <!-- qualifying metadata -->
<Atom> <!-- the module is valid for one year from 2011 to 2012 -->
<Rel>valid</Rel>
<Interval type="&ruleml;TimeInstant">
<Time type="&ruleml;TimeInstant"><Data xsi:type="xs:date">2011-01-01</Data></Time>
<Time type="&ruleml;TimeInstant"><Data xsi:type="xs:date">2012-01-01</Data></Time>
</Interval>
</Atom>
</qualification>
<Rulebase key="#innermodule1.1">
<!– the rule base scopes apply to all knowledge in the rule base -->
<scope> <!– scope : only knowledge authored by „Adrian Paschke“ -->
<Atom><Rel iri="dc:creator"/><Ind>Adrian Paschke</Ind></arg></Atom>
Outer
</scope>
Scope
<scope> <!– scope : only valid knowledge; validity value will be bound to variable -->
<Atom><Rel>valid</Rel><Var>Validity</Var></Atom>
</scope>
<Rule key=“#rule1”> Inner
<scope> <Atom><Rel>source</Rel><Ind>./module1.prova</Ind></Atom></scope> Scope
<guard> <!-- guard on the validity: “current date during validity of module1” +
<Operator type="&ruleml;During"><Expr iri="…getDate()“/><Var>Validity</Var></Operator> Guard
</guard>
<if> … </if> <then> </then>
</Rule>
</Rulebase> Adrian Paschke and Harold Boley: Rule Responder: Rule-Based Agents for the Semantic-Pragmatic Web, in Special 9
</Assert> Issue on Intelligent Distributed Computing in International Journal on Artificial Intelligence Tools (IJAIT), V0l. 20,6, 2011

Quick Overview: Reaction RuleML Dialects
*+ variants and alternatives
• Derivation RuleML (if-then)*
– Time, Spatial, Interval, Situation (+ algebra operators)
• KR RuleML (if-then or on-if-do) *
– Happens(@type), Initiates, Terminates, Holds, fluent
• Production RuleML (if-do) *
– Assert, Retract, Update, Action
• ECA RuleML (on-if-do) *
– Event, Action, + (event / action algebra operators)
• CEP RuleML: (arbitrary combination of on, if, do)
– Receive, Send, Message
Adrian Paschke, Harold Boley, Zhili Zhao, Kia Teymourian and Tara Athan. Reaction RuleML 1.0: Standardized Semantic
10
Reaction Rules, 6th International Conference on Rules (RuleML 2012), Montpellier, France, August 27-31, 2012

Example: Interval-based Processing and Reasoning
– Interval-based Event Calculus semantics (model-theory + proof theory) based on
time intervals modeled as fluents
I: Tinterval x Fl  {true, false}
– Example: D = A;(B;C) (consolidation: derive event D from sequence composition)
T1 T2 T3 T4
A B C
Composition
[A,A] [B,C]
[[A,A],[B,C]]
Consolidation
D = [A,C]
– Example: derived situation from complex event detection (consolidation: initiate situation1 by event D)
initiates(D,situation1,T).
holdsAt(situation1, t5)? => yes
Paschke,A.:ECA-LP/ECA-RuleML:A Homogeneous Event-Condition-Action Logic Programming Language CoRR abs/cs/0609143:(2006)
Adrian Paschke, Alexander Kozlenkov, Harold Boley: A Homogeneous Reaction Rule Language for Complex Event Processing, In Proc. 2nd International Workshop on
Event Drive Architecture and Event Processing Systems (EDA-PS 2007) at VLDB 2007 11
Kia Teymourian, Adrian Paschke: Semantic Rule-Based Complex Event Processing. RuleML 2009: 82-92
Paschke, A., Bichler, M.: SLA Representation, Management and Enforcement - Combining Event Calculus, Deontic Logic, Horn Logic and Event Condition Action
Rules, E-Technology, E-Commerce, E-Service Conference (EEE05), Hong Kong, 2005.

Example: KR RuleML – AI Event / Action Reasoning
<Rule style="active">
<on> <Event> <Ind> d </Ind> </Event></on>
<do>
<Initiates >
<fluent>
<Situation> initiates(d,s1,T).
<Ind> s1 </Ind>
</Situation>
</fluent>
</Initiates>
</do>
</Rule>
<Rule style="reasoning" >
<if> <And>
<Holds>
<fluent>
<Situation><Var >s1</Var><Situation> holdsAt(s1,t5).
</fluent>
<at>< Time ><Var>t5</Var></Time></at>
</Holds>
</And> </if>
<then> … </then>
</Rules>
12

Selected Reaction RuleML Algebra Operators
• Action Algebra
Succession (Ordered Succession of Actions), Choice (Non-Determenistic
Choice), Flow (Parallel Flow), Loop (Loops), Operator (generic Operator)
• Event Algebra
Sequence (Ordered), Disjunction (Or) , Xor (Mutal Exclusive), Conjunction
(And), Concurrent , Not, Any, Aperiodic, Periodic, AtLeast, ATMost,
Operator (generic Operator)
• Interval Algebra (Time/Spatio/Event/Action/… Intervals)
During, Overlaps, Starts, Precedes, Meets, Equals, Finishes,
Operator (generic Operator)
• Counting Algebra
Counter, AtLeast, AtMost, Nth, Operator (generic Operator)
• Temporal operators
Timer, Every, After, Any, Operator (generic Operator)
• Negation operators
Adrian Paschke, Harold Boley, Zhili Zhao, Kia Teymourian and Tara Athan. Reaction RuleML 1.0: Standardized Semantic
13
Reaction Rules, 6th International Conference on Rules (RuleML 2012), Montpellier, France, August 27-31, 2012

Reaction RuleML Metamodel and External
Ontologies + Data - Examples
<Quantifier type="&ruleml;Forall"> == <Forall>
<Operator type="&ruleml;And"> == <And>
<Operator type="&ruleml;Conjunction"> == <Conjunction>
<Negation type="&ruleml;InflationaryNegation"> == <Naf>
<Action type="&ruleml;Assert"> == <Assert>
<Action type="&ruleml;Retract"> == <Retract>
<Event type="&ruleml;SimpleEvent"> == <Atom> …
</Atom>
<Event type="ibm:CommonBaseEvent"> == IBM CBE
<Operator type="snoop:Squence"> == Snoop Algebra
== <Operator type="&ruleml;Sequence"> == <Sequence>
<Ind iri="person.xml#xpointer(//Person/LastName[1]/text())"/>
<Action iri="BPEL.xml#xpointer(//invoke[@name=checkHotel])"> 14

Reaction RuleML Metamodel
Top Level Ontologies
General concepts such as space, time, event, action and their properties and relations
Spatio Action
Ontology Ontology Situation Process Agent
Temporal Event Ontology Ontology Ontology
Ontology Ontology
Vocabularies related Vocabularies related
to specific domains to generic tasks or
by specializing the Task activities by
Domain
concepts introduced Activities specializing the
Ontologies
in the top-level Ontologies concepts introduced in
ontology the top-level ontology
Specific Application E.g. ontologies describing roles
user/application played by domain entities while
Ontologies perfoming application activities
ontologies
Teymourian, K., Coskun, G., and Paschke, A. 2010. Modular Upper-Level Ontologies for Semantic Complex Event Processing. In
Proceeding of the 2010 Conference on Modular ontologies: Proceedings of the Fourth international Workshop (WoMO 2010) O. Kutz, J. Hois, 15
J. Bao, and B. Cuenca Grau, Eds. Frontiers in Artificial Intelligence and Applications. IOS Press, Amsterdam, The Netherlands, 81-93.

Time Top Ontology Metamodel
Time Time Types
Time Instant Time Interval
16

Interval Top Ontology Metamodel
Interval
Interval Types
Empty Degene Left Closed Left Open Left Left Right Right
Interval rated Right Open Right Closed Open Closed Closed Open
Interval Interval Interval Interval Interva Interva Interva
l l l
17

Event Top Ontology Metamodel
Event Event
Types
Simple Event Complex Event
18

Action Top Ontology Metamodel
Action Action
Types
Atomic Action Complex Action
19

Situation Top Ontology Metamodel
Situation Situation
Types
Heterogeneous Fluent Homogenous
Situation Situation
Domain ontologies
Dynamic Time Frequency State Process Iterative Habitual
Change Frame Situation Situation Situation Situation Situation
Situation Situation
20

Example: Situation Top Ontology Metamodel
Metadata Pattern
Properties Properties
hasValue
Situation Situation Situation
Properties Content Descriptions
(time, location, participants, …)
use the other hasProperties hasContent
top ontologies
Situation Situation
Types
Heterogeneous Homogenous
Situation Situation
Domain ontologies
Dynamic Time Frequency State Process Iterative Habitual
Change Frame Situation Situation Situation Situation Situation
Situation Situation
TrafficLight Within5 Rings3 LaysOn He He He Situation
Changes Minutes Times TheFloor Runs Coughs Smokes Individuals
21

Example - Event Metamodel
(for defining Event Types as Instances of the Metamodel Event Class)
Defined
Event
Types
Event Class
Definition
22

Extended Event Metamodel Ontology
(with computational properties and complex value definitions)
23

The Generic Syntax Pattern of An Event
references to external
ontologies
<Event @key @keyref @iri @type>
<!-- event info and life cycle management, modularization -->
<meta> <!-- R: (semantic) metadata of the event --> </meta>
<scope> <!-- R: scope of the event --> </scope>
<!-- event pattern description -->
<evaluation><!-- R: semantics, e.g. selection, consumption-->
</evaluation>
<signature> <!-- R: event pattern declaration --> </signature>
<!-- event instance -->
<qualification> <!-- R: e.g. qualifying event declarations, e.g.
priorities, validity, strategy --> </qualification>
<quantification> <!-- R: quantifying rule declarations --> </quantification>
<oid> <!-- R: object identifier --> </oid>
<content> <!-- R: event instance content --> </content>
</Event>
24

Complex Event Pattern Definition
<Event key=“#ce2" type="&ruleml;ComplexEvent">
<signature> <!-- pattern signature definition -->
<Sequence>
<signature>
<Event type="&ruleml;SimpleEvent">
<signature><Event>...event_A...</Event></signature>
</Event>
</signature>
<signature><Event type="&ruleml;ComplexEvent" keyref="ce1"/></signature> Event
<signature> Pattern
<Event type="cbe:CommonBaseEvent" iri="cbe.xml#xpointer(//CommonBaseEvent)"/>
</signature> defining
</Sequence> Event
</signature> Templates
</Event>
signature
<Event key=“#ce1">
<signature> <!-- event pattern signature -->
<Concurrent>
<Event><meta><Time>...t3</Time></meta><signature>...event_B</signature></Event>
<Event><meta><Time>...t3</Time></meta><signature>...event_C</signature></Event>
</Concurrent>
</signature>
</Event>
Event
<Event key=“#e1” keyref=“#ce2”><content>…</content></Event>
Instance
25

Rule Interface and Rule Implementation
<Rule style="active">
<evaluation>
<Profile> e.g. selection and consumptions policies </Profile>
</evaluation>
<signature> Interface
<Event key="#ce2">
(Note in reaction
… see example from the previous slide
rules the signature
</Event>
is the event pattern
</signature>
which detects the
event instances)
<on>
<Event keyref="#ce2"/> <!– use defined event pattern for detecting events -->
</on>
<do>
<Assert safety="transactional"> <!-- transactional update -->
<formula>
<Atom>
<op><Rel>likes</Rel></op> Implementation
<arg><Ind>John</Ind></arg>
<arg><Var>X</Var></arg>
</Atom>
</formula>
</Assert>
</do>
</Rule>
26

Execution Semantics
(can be defined in the <evaluation> semantics element)
1. Definition
– Definition of event/action pattern e.g. by event algebra
– Based on declarative formalization or procedural implementation
– Defined over an atomic instant or an interval of time, events/actions, situation, transition
etc.
2. Selection
– Defines selection function to select one event from several occurred events
(stored in an event instance sequence e.g. in memory, database/KB) of a particular type,
e.g. “first”, “last”
– Crucial for the outcome of a reaction rule, since the events may contain different
(context) information, e.g. different message payloads or sensing information
3. Consumption
– Defines which events are consumed after the detection of a complex event
– An event may contribute to the detection of several complex events, if it is not consumed
– Distinction in event messaging between “multiple receive” and “single receive”
– Events which can no longer contribute, e.g. are outdated, should be removed
4. Execution
– Actions might have an internal effect i.e. change the knowledge state leading to state
transition from (pre-)condition state to post-condition state
– The effect might be hypothetical (e.g. a hypothetical state via a computation) or
persistent (update of the knowledge base),
– Actions might have an external side effect
Adrian Paschke: The Reaction RuleML Classification of the Event / Action /
27
State Processing and Reasoning Space CoRR abs/cs/0611047: (2006) 27

EPTS - Reference Architecture: Functional View
Definition, Modeling, (continuous) Improvement
Event Reaction
Assessment, Routing, Prediction,
Discovery, Learning
(Pattern, Control, Rule, Query, RegEx.etc)
Event Process Monitoring, Control
0..*
State Management
Complex Event Detection
Event and Complex Event
Consolidation, Composition,
Aggregation
0..*
Event Analysis
Analytics, Transforms, Tracking,
Scoring, Rating, Classification
0..*
Event Preparation
Identification, Selection, Filtering,
Monitoring, Enrichment
0..*
Event Production Event Consumption
Publication, Dashboard, Apps,
Retrieval External Reaction
Design time Run time Administration
Adrian Paschke, Paul Vincent, Alexandre Alves, Catherine Moxey: Tutorial on advanced design patterns in event processing. 28
DEBS 2012: 324-334; http://www.slideshare.net/isvana/epts-debs2012-event-processing-reference-architecture-design-patterns-v204b

Coupling Approaches for
(Distributed) Reaction RuleML Bases
• Strong coupling direct
implementation
– Interaction through a stable interface KB
– API call is hard coded Computer
• Loose coupling
– Resilient relationship between two or
Agent / Service Interface
more systems or organizations with Reaction RuleML
Message Interchange
some kind of exchange relationship
Rule KB1
– Each end of the transaction makes its Request
requirements explicit, e.g. as an Rule Service 0.0000 …
Consumer
interface description, and makes few Response
assumptions about the other end 0.0000
Rule KBn
• Decoupled
– de-coupled in time using (event)
messages (e.g. via Message-oriented Event Streams
(ordered events)
Middleware (MoM)) new auto pay account login
logout
– Often asynchronous stateless deposit withdrawalnew auto pay
communication (e.g. publish- deposit
transfer
Event
book logoutaccount login
enquiry
subscribe or CEP event detection) account balance Cloud
incident request
new auto pay account login
enquiry
enquiry
(unordered events)
depositwithdrawalnew auto pay
transfer account login
enquiry deposit logout 29
activity history

Reaction RuleML Rule interchange
(on the PIM level)
Rules
Reaction
RuleML
serialize de-serial.
Rules doc Rules
Ontologies
Rule (ODM, OWL, Rule
system 1 RDF-S, CL) system 2
<XML doc>
Data serialize
(or others) de-serial. Data
Application A data Application B
30

Send and Receive Messaging
• Send a message
• Send @directive (oid,protocol,agent,content)
• Receive a message
• Receive @directive (oid,protocol,agent,content)
–oid is the conversation identifier (enabling also subconverstations)
–protocol: protocol definition (high-level protocols and transport prot.)
–agent: denotes the target or sender of the message
–@directive: pragmatic context, e.g. FIPA
Agent Communication Language (ACL) primitives
–content: Message payload 31

Messaging Reaction Rules
<Rule>
…
<do><Send><oid>xid1</oid> …query1 </Send></do>
<do><Send><oid>xid2</oid> …query2 </Send></do>
<on><Receive><oid>xid2</oid> …response2 </Receive></on>
<if> prove some conditions, e.g. make decisions on the received
answers </if>
<on><Receive><oid>xid1</oid> …response1 </Receive></on>
….
</Rule>
Note: The „on“, „do“, „if“ parts can be in
arbitrary combinations to allow for a flexible
see Prova rule engine workflow-style logic with subconversations
www.prova.ws
and parallel branching logic 32

Reaction - Routing
Prova: Example with Agent (Sub-) Conversations
rcvMsg(XID,esb,From,query-ref,buy(Product) :-
routeTo(Agent,Product), % derive processing agent
% send order to Agent in new subconversation SID2
sendMsg(SID2,esb,Agent,query-ref,order(From, Product)),
% receive confirmation from Agent for Product order
rcvMsg(SID2,esb,Agent,inform-ref,oder(From, Product)).
% route to event processing agent 1 if Product is luxury
routeTo(epa1,Product) :- luxury(Product).
% route to epa 2 if Product is regular
routeTo(epa2,Product) :- regular(Product).
% a Product is luxury if the Product has a value over …
luxury(Product) :- price(Product,Value), Value >= 10000.
% a Product is regular if the Product ha a value below …
regular(Product) :- price(Product,Value), Value < 10000.
corresponding serialization with Reaction
Prova3, http://prova.ws
RuleML <Send> and <Receive>
33
Slides: http://www.slideshare.net/isvana/epts-debs2012-event-processing-reference-architecture-design-patterns-v204b

Reaction RuleML Messaging
•<Message directive="<!-- pragmatic context -->" >
• <oid> <!-- conversation ID--> </oid>
• <protocol> <!-- transport protocol --> </protocol>
• <sender> <!-- sender agent/service --> </sender>
• <receiver> <!-- receiver agent/service --> </receiver>
• <content> <!-- message payload --> </content>
•</Message>
• oid is the conversation identifier (enabling also subconverstations)
• protocol: protocol definition (high-level protocols and transport prot.)
• agent (send, receiver): denotes the target or sender of the message
• @directive: pragmatic context, e.g. FIPA ACL primitives
• content: Message payload
Adrian Paschke and Harold Boley: Rule Responder: Rule-Based Agents for the Semantic-Pragmatic Web, in Special
Issue on Intelligent Distributed Computing in International Journal on Artificial Intelligence Tools (IJAIT), V0l. 20,6, 2011 34

Loosley-Coupled Communication via
Messages to Agent Interface
FIPA ACL directive
<Message directive="acl:query-ref">
<oid> <Ind>conversation1</Ind> </oid>
<protocol> <Ind>esb</Ind> </protocol>
<sender> <Ind>Agent1</Ind> </sender>
<receiver> <Ind>Agent2</Ind> </receiver>
<content>
<Atom> Interpreted by Agent 2 as
<Rel>likes</Rel> query according to
<Ind>John</Ind> ACL:query-ref
<Ind>Mary</Ind>
</Atom> Note: the receiver „Agent2“
needs to specify an
</content>
appropriate <signature> for
</Message> „likes“
• Event Message is local to the conversation state (oid)
and pragmatic context (directive) 35

Message Driven Routing
Prova : Event Routing in Event-Driven Workflows
rcvMsg(XID,Process,From,event,["A"]) :- Task1
fork_b_c(XID, Process). B D
A C
Task2
fork_b_c(XID, Process) :- E
@group(p1) rcvMsg(XID,Process,From,event,["B"]),
execute(Task1), sendMsg(XID,self,0,event,["D"]).
fork_b_c(XID, Process) :-
@group(p1) rcvMsg(XID,Process,From,event,["C"]),
execute(Task2), sendMsg(XID,self,0,event,["E"]).
fork_b_c(XID, Process) :-
% OR reaction group "p1" waits for either of the two
event message handlers "B" or "C" and terminates the
alternative reaction if one arrives
@or(p1) rcvMsg(XID,Process,From,or,_). Prova3, http://prova.ws 36
Slides: http://www.slideshare.net/isvana/epts-debs2012-event-processing-reference-architecture-design-patterns-v204b

Coupling Approaches for
(Distributed) Reaction RuleML Bases
• Strong coupling direct
implementation
– Interaction through a stable interface KB
– API call is hard coded Computer
• Loose coupling
– Resilient relationship between two or
Agent / Service Interface
more systems or organizations with Reaction RuleML
Message Interchange
some kind of exchange relationship
Rule KB1
– Each end of the transaction makes its Request
requirements explicit, e.g. as an Rule Service 0.0000 …
Consumer
interface description, and makes few Response
assumptions about the other end 0.0000
Rule KBn
• Decoupled
– de-coupled in time using (event)
messages (e.g. via Message-oriented Event Streams
(ordered events)
Middleware (MoM)) new auto pay account login
logout
– Often asynchronous stateless deposit withdrawalnew auto pay
communication (e.g. publish- deposit
transfer
Event
book logoutaccount login
enquiry
subscribe or CEP event detection) account balance Cloud
incident request
new auto pay account login
enquiry
enquiry
(unordered events)
depositwithdrawalnew auto pay
transfer account login
enquiry deposit logout 37
activity history

Decoupled Interaction: Event Messaging Reaction Rule
… sendMsg(SID,stream,“S&P500“, inform, tick((name,
N),(price, P), (time, T)) …
publish
Event Stream
decoupled {(Name, “OPEL”)(Price, 45)(Volume, 2000)(Time, 1) }
{(Name, “SAP”)(Price, 65)(Volume, 1000) (Time, 2)}
consum / subscribe
rcvMult(SID,stream,“S&P500“, inform,
tick(Name^^car:Major_corporation,P^^currency:Dollar,
T^^time:Timepoint)) :- …<further processing of semantic event>.
{(OPEL, is_a, car_manufacturer),
(car_manufacturer, build, Cars),
(Cars, are_build_from, Metall),
Semantic (OPEL, hat_production_facilities_in, Germany),
Knowledge Base (Germany, is_in, Europe)
(OPEL, is_a, Major_corporation),
(Major_corporation, have, over_10,000_employees)}
Prova3, http://prova.ws 38
Slides: http://www.slideshare.net/isvana/epts-debs2012-event-processing-reference-architecture-design-patterns-v204b

Example: Semantic BPM and
BAM with Rule Responder
Adrian Paschke: A Semantic Rule and Event Driven
Approach for Agile Decision-Centric Business
Process Management . ServiceWave 2011: 254-267
Business Process
39

Highly Modular Relax NG for Reaction RuleML
• Reaction RuleML is a monotonic language extension of
Deliberation RuleML
– Every valid Deliberation RuleML document is a valid Reaction RuleML
document
• Deliberation RuleML 1.0 is specified by a modular, monotonic
Relax NG schema, released 2012-04-03
– Reaction RuleML 1.0 can be specified by new Relax NG modules that
may be freely-combined with (some or all) Deliberation RuleML
modules
– E.g.: modules/Rule.rnc, modules/scope.rnc, modules/event.rnc,
modules/action.rnc, …
• MYNG (http://ruleml.org/1.0/myng) provides a GUI for
building a customized Deliberation RuleML Relax NG schema
from these modules
– MYNG can be extended to the Reaction RuleML schema modules
40

Summary of Selected Reaction RuleML Features
• Different Rule Families and Types (DR, KR, PR, ECA, CEP)
• Support for Event/Action/Situation… Reasoning and Processing
• Rule Interface and Implementation for Distributed Knowledge
• Knowledege Life Cycle Management, Modularization and Dynamic
Views (metadata, scopes, guards, situations/fluents, update actions)
• Decoupled event messaging and loosley-coupled send/receive
interaction against rule (KB) interface within conversations,
coordination/negotiation protocols and pragmatic directives
• Different detection, selection and consumption semantics (profiles)
• Different algebras (Event, Action, Temporal,…)
• Specialized Language Constructs
– Intervals (Time, Event), situations (States, Fluents)
• Top Level Meta Model for semantic Type Definitions and predefined
Types in Top-Level Ontologies
• External (event) query languages, external data and ontology models
• ...
41

Selected References
• Adrian Paschke, Harold Boley, Zhili Zhao, Kia Teymourian and Tara Athan. Reaction RuleML 1.0: Standardized Semantic
Reaction Rules, 6th International Conference on Rules (RuleML 2012), Montpellier, France, August 27-31, 2012
• Harold Boley, Adrian Paschke and Omair Shafiq: RuleML 1.0: The Overarching Specification of Web Rules , in Semantic
Web Rules, Proceedings of RuleML-2010, Lecture Notes in Computer Science, 2010, Volume 6403/2010, 162-178.
• Paschke, A., Boley, H., Kozlenkov. A., Craig, B.: Rule Responder: RuleML-Based Agents for Distributed Collaboration on
the Pragmatic Web, 2nd International Conference on the Pragmatic Web, Tilburg, Netherlands, 2007.
• Adrian Paschke and Harold Boley: Rule Responder: Rule-Based Agents for the Semantic-Pragmatic Web, in Special
Issue on Intelligent Distributed Computing in International Journal on Artificial Intelligence Tools (IJAIT), V0l. 20,6, 2011
• Adrian Paschke, Paul Vincent, Alexandre Alves, Catherine Moxey: Advanced design patterns in event processing. DEBS
2012: 324-334; http://www.slideshare.net/isvana/epts-debs2012-event-processing-reference-architecture-design-
patterns-v204b
• Adrian Paschke, Alexander Kozlenkov: Rule-Based Event Processing and Reaction Rules. RuleML 2009: 53-66
• Adrian Paschke, Paul Vincent, Florian Springer: Standards for Complex Event Processing and Reaction Rules. RuleML
America 2011: 128-139; http://www.slideshare.net/isvana/ruleml2011-cep-standards-reference-model
• Teymourian, K., Coskun, G., and Paschke, A. 2010. Modular Upper-Level Ontologies for Semantic Complex Event
Processing. In Proceeding of the 2010 Conference on Modular ontologies: Proceedings of the Fourth international
Workshop (WoMO 2010) O. Kutz, J. Hois, J. Bao, and B. Cuenca Grau, Eds. Frontiers in Artificial Intelligence and
Applications. IOS Press, Amsterdam, The Netherlands, 81-93.
• Kia Teymourian, Adrian Paschke: Semantic Rule-Based Complex Event Processing. RuleML 2009: 82-92
• Adrian Paschke, Alexander Kozlenkov, Harold Boley: A Homogeneous Reaction Rule Language for Complex Event
Processing, In Proc. 2nd International Workshop on Event Drive Architecture and Event Processing Systems (EDA-PS
2007) at VLDB 2007; http://arxiv.org/pdf/1008.0823v1.pdf
• Adrian Paschke: ECA-LP / ECA-RuleML: A Homogeneous Event-Condition-Action Logic Programming Language CoRR
abs/cs/0609143: (2006); http://arxiv.org/ftp/cs/papers/0609/0609143.pdf
• Adrian Paschke: ECA-RuleML: An Approach combining ECA Rules with temporal interval-based KR Event/Action Logics
and Transactional Update Logics CoRR abs/cs/0610167: (2006); http://arxiv.org/ftp/cs/papers/0610/0610167.pdf
• Paschke, A., Bichler, M.: SLA Representation, Management and Enforcement - Combining Event Calculus, Deontic
Logic, Horn Logic and Event Condition Action Rules, E-Technology, E-Commerce, E-Service Conference (EEE05), Hong
Kong, 2005.
• Adrian Paschke, Martin Bichler: Knowledge representation concepts for automated SLA management. Decision
Support Systems 46(1): 187-205 (2008)
• Adrian Paschke: RBSLA A declarative Rule-based Service Level Agreement Language based on RuleML. CIMCA/IAWTIC 42
2005: 308-314

Thank you !
Questions?
43
43