Rule Responder is a rule-based multi-agent framework in which agents run platform-speci c rule engines as distributed inference services. They communicate with each other using Reaction RuleML as the common rule interchange format, e.g. for question answering or execution of mobile rule code in distributed problem solving, concurrent processing work ows and distributed event/action processing. In this paper we demonstrate the new capabilities of Reaction RuleML 1.0 for supporting the functionalities of Rule Responder such as knowledge interface declarations with signatures, modes, and scopes; distributed knowledge modules with static and dynamic scopes enabling imports and scoped reasoning within metadata-based scopes (closed constructive views) on the knowledge base; messaging reaction rules enabling conversation-scope based interactions between agents interchanging queries, answers, and rulebases; and evaluation and testing of interchanged knowledge bases with intended semantic pro les and self-validating test suites. We demonstrate these Reaction RuleML 1.0 capabilities with our proofof-concept implementation Rule Responder agent architecture and Prova 3.0 rule engine.
Rule Responder1 [
RuleML is a knowledge representation language designed for the interchange of the
major kinds of Web rules in an XML format that is uniform across various rule logics
and platforms. It has broad coverage and is de ned as an extensible family of
sublanguages, whose modular system of schemas permits rule interchange with high precision.
RuleML 1.0 encompasses both Deliberation RuleML 1.0 and Reaction RuleML 1.02 [
Reaction RuleML is a standardized rule markup language and semantic
interchange format for reaction rules and rule-based event processing. Reaction rules include
distributed Complex Event Processing (CEP), Knowledge Representation (KR) calculi,
as well as Event-Condition-Action (ECA) rules, Production (CA) rules, and Trigger
(EA) rules [
In this paper, we demonstrate the features of Reaction RuleML 1.0 for Rule
Responder. Reaction RuleML de nes a generic rule syntax distinguishing between metadata,
interface, and implementation, enabling distributed and modularized rulebases and
rules. It supports both programming-in-the-large with compositional import and
message interchange mechanisms and programming-in-the-small with abstraction and
scoping mechanisms. Semantic Pro les attach meaning to interchanged Reaction RuleML
rulebases and messages and enable their semantic interpretation and interchange, e.g. in
distributed rule-based agent system and rule-based Complex Event Processing (CEP)
agent architectures [
As demonstration scenario we use a typical Semantic CEP scenario, namely the
real-time monitoring of stock market events[
In contrast to standard CEP agents which apply syntactic event patterns, the Rule Responder agents support more expressive semantic event queries, such as "stocks of companies, which have production facilities in Europe and produce products out of metal and have more than 10,000 employees " and which require additional background knowledge bases (such as DBPedia), e.g., (OPEL, is_a, car_manufacturer), (car_manufacturer, build, Cars), (Cars, are_build_from, Metall), (OPEL, has_production_facilities_in, Germany), (Germany, is_in, Europe) (OPEL, is_a, Major_corporation), (Major_corporation, have, over_10,000_employees)
The paper is organizes as follows: Section 2 introduces semantic pro les which allow de ning the intended evaluation semantics of Reaction RuleML knowledge. Section 3 distinguishes the knowledge interface from the knowledge implementation, which is the basis for describing the interfaces of distributed Rule Responder agents. Section 4 explains how Reaction RuleML supports modularization and distribution of knowledge locally, externally, and by import. Section 5 broadens the concept of scopes to the construction of dynamic views on the knowledge base by metadata based scopes and scoped reasoning. Section 6 uses this scoping mechanism for conversation based scopes which allow to maintain local (reasoning) context in messaging reaction rules with send and receive actions for interchanging Reaction RuleML based knowledge actions between Rule Responder agents. Finally, section 7 summaries the contribution of Reaction RuleML 1.0 for Rule Responder and their implementation in Prova 33. 3 http://prova.ws
Dialects in Reaction RuleML provide a layer of general representation expressiveness
by de ning a dialect language, typically for a particular sort of reaction rules or a
combination of di erent sorts. The main Reaction RuleML dialects with their core
elements are:
{ Derivation Reaction RuleML (if-then) - Time, Spatial, Interval, Situation (+
algebra operators)
{ KR Reaction RuleML (if-then or on-if-do) - Happens(@type), Initiates,
Terminates, Holds, uent
{ Production Reaction RuleML (if-do) - Assert, Retract, Update, Action
{ ECA Reaction RuleML (on-if-do) - Event, Action, (+ event / action algebra
operators)
{ CEP Reaction RuleML (arbitrary combination of on, if, do) - Receive, Send,
Message
Combinations of dialects are also possible, e.g., DR-PR Reaction RuleML, which
combines derivation and production rules, or KR-CEP Reaction RuleML, which combines
KR calculi with CEP reaction rules, enabling e.g. pro les with an interval-based Event
Calculus semantics for complex (event/action) algebra operators [
Semantic pro les in Reaction RuleML are used to de ne the intended semantics for knowledge interpretation (typically a model-theoretic semantics), reasoning (e.g., entailment regimes and proof-theoretic semantics), and for execution (e.g., operational semantics such as selection and consumption policies and windowing techniques in complex event processing). That is, they further detail the syntax and semantics of a dialect and provide necessary information about the intended semantics for Reaction RuleML knowledge representations as required for interchange, translation, inference, and veri cation and validation.
A dialect has a default semantic pro le de ning the default semantics, i.e., the semantics which by default is used for interpretation. Deviating semantic pro les (<Profile>) can be speci ed (<evaluation>) on all formulas and terms in Reaction RuleML giving them an interpretation and execution di erent from the default semantics.
De nition 1. (Semantic Pro le) A semantic pro le, SP = hSSP ; SP ; ISP ; SP ; SP i, (partially) de nes a pro le signature SSP , a language SP , an interpretation ISP , a domain-independent theory SP , and a semantics-preserving translation function SP ( ) which translates from Reaction RuleML to the pro le's language / signature (and vice versa, with the inverse function SP1).
Semantic Pro les can be de ned internally within a Reaction RuleML document (<Profile>) or externally. External semantic pro les can be referenced by their pro le name (@type) and imported by their resource identi er (@iri). Their speci cation can be given in any XML format (<content>), including RuleML formulas (<formula>), as well as other formal and textual languages (which need not be directly machine processable). For non-Reaction RuleML pro les a semantics-preserving translation function needs be de ned in order to allow interpretations of Reaction RuleML knowledge bases with the pro le's semantics.
Multiple alternative semantic pro les are allowed with or without a priority ordering and their scope can be speci ed. For instance the following XML snippet uses two alternative pro les and gives the rst pro le preference by ordering them (@index). <evaluation index="1"> <!-- WFS semantic profile -->
<Profile type="ruleml:Well-Founded-Semantics" direction="backward"/> </evaluation> <evaluation index="2"> <!-- alternative ASS semantic profile -->
<Profile type="ruleml:Answer-Set-Semantics"/> </evaluation>
Semantic pro les might de ne further specialized or deviating structures (e.g., module composition with modular join semantics etc.), intended models (e.g., in terms of entailment regimes) and axioms and propositions (e.g., domain independent meta axioms of a theory, e.g. for calculi such as event calculus, situation calculus), as well as proof-theories and properties of operational semantics (e.g., process semantics and protocols, windowing techniques, selection and consumption policies in complex event processing and actions), etc. Also, they might specialize the language of a dialect, e.g., by limiting the dialect's signature to subsignatures.
De nition 2. (Subsignature) A signature S1 is a subsignature of S2, i.e., S1 S2 i S1 is a signature which consist only of symbols from S2 without changing their sort and arity.
For instance, the following example de nes the signature of a global predicate \planned " as subsignature of the already existing <Happens> predicate in the KR dialect of Reaction RuleML, which takes an event as rst argument and a time as second argument, with the mode attribute de ning it as input predicate. <signature> <Atom type="ruleml:Happens" arity="2" mode="+"> <Rel scope="global">planned</Rel> <Var type="ruleml:Event" mode="+" scope="local"/> <Var type="ruleml:Time" mode="+" scope="local"/> </Atom> </signature>
These explicitly de ned signatures are introduced as further specialized sorts into
the multi-sorted signature of a Reaction RuleML dialect and they are interpreted by
the intended semantic pro le, which de nes a multi-sorted interpretation for the sort
symbols. For further details about the core multi-sorted signatures and structures of
Reaction RuleML see [
The following example (in Prova 3 syntax) lters received stock market ticks and sends the ltered events as new happens facts to another event processing agent, called "epa1".
Filter for stocks starting with "A" and price > 100 rcvMult(SID,stream,"S&P500", inform, tick(S,P,T)) :
filter(S,P), sendMsg(SID2,esb,"epa1", inform, happens(tick(S,P),T). filter(Symbol,Price) :Price > 100, Symbol = "A.*".
The transformed happens facts are interchanged to agent "epa1" as Reaction RuleML messages, e.g., specifying a rei ed event calculus pro le as intended semantics. <evaluation index="1"> <!-- Event Calculus semantic profile -->
<Profile type="ruleml:ReifiedClassicalEventCalculus"/> </evaluation>
A knowledge representation element in Reaction RuleML consists of the representational knowledge object, such as rulebases, rules, facts, queries, events, etc., and optional additional meta knowledge.
The meta knowledge comprises descriptive metadata (<meta>) and the knowledge interface, which contains information about the knowledge scope (<scope>), guard constraints (<guard>), intended semantics (<evaluation>), explicit signatures (<signature>), qualifying metadata (<qualification>), and quanti ers (<quantification>).
Moreover, several knowledge formulas can have further specialized meta knowledge, such as a truth/uncertainty degree (<degree>) for atomic formulas (<Atom>) and equations (<Equal>), conversation identi ers (<cid>), protocols (<protocol>), sender/recevier agents (<sender>, <receiver>) for messages (<Message>), etc. Several meta knowledge attributes specify additional information, e.g. about sort (@type), arity (@arity), cardinality of set values (@card, @maxCard, @minCard), relative weight (@weight), default quanti cation closure (@closure), inference direction (@direction), ordering (@index), internationalized (remote) resource locator (@iri), global node identi er (@node), internal key and key reference (@key, @keyref), input-output mode declaration (@mode), material implication (@material), equality orientation (@oriented), interpretation semantics of relations and functions (@per), pre x and vocabulary definition for "webized" IRI mappings (@prefix, @vocab), processing/execution safety (@safety), reasoning and execution style (@style), and indeterminism/determinism of functions and operators (@val).
The knowledge implementation is an instance (a knowledge object) of the knowledge interface, i.e. it needs to be well-formed according to the signature and it needs to be interpreted with the intended structures (Semantic Pro les) in the scope (quanti cation and quali cation scope) de ned by the interface.
The following example shows this distinction into metadata, interface, and implementation for a rule. <Rule @key @keyref @style> <!-- descriptive rule metadata --> <meta> <!- descriptive metadata of the rule --> </meta> <!-- rule interface --> <scope> <!- scope of the rule e.g. a rule module --> </scope> <evaluation> <!-- intended semantics --> </evaluation> <signature> <! rule signature --> </signature> <qualification> <!- e.g. qualifying rule metadata, e.g.
priorities, validity, strategy --> <quantification> <!-- quantifying rule declarations, e.g. variable bindings --> </quantification> </qualification> <!-- rule implementation --> <oid> <! object identifier --> </oid> <on> <!- event part --> </on> <if> <!- condition part --> </if> <then> <!- (logical) conclusion part --> </then> <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> { The <meta> roles, contain the descriptive metadata, which is used for annotations describing the knowledge object. By default all knowledge is contextually annotated by metadata about their source (@src([Locator])) and their name (@label([OID])), with Locator being the module's source location in which the knowledge object is implemented/de ned and OID being the implicitly (i.e., automatically created) or explicitly de ned object identi er. { The <scope> role de nes subsets of the universe as domain of discourse in which interpretation takes place. That is, from an operational point of view they de ne a static or dynamic constructive view on the knowledge base in which scoped reasoning takes place. The Reaction RuleML vocabulary prede nes the scopes \global" (globally visible) \local" (visible with local interpretation) and \private" (hidden and not visible outside of the module). Reaction RuleML dialects might introduce further scopes, such as, e.g., \supremum" and \inf imum", which expand the scope of nested submodules to its least upper bound or greatest lower bound. Further, named metadata scopes can be de ned (in the scope role) and used as scoped submodule in scoped reasoning. { The <evaluation> roles are used to specify semantic pro les, which de ne the intended semantics for knowledge interpretation (typically a model-theoretic semantics), reasoning (typically entailment regimes and proof-theoretic semantics), and for execution (e.g., operational semantics such as selection and consumption policies and windowing techniques in complex event processing). This includes, e.g., semantic properties and assumptions such as closed world, open world, closed (positively, negatively closed), etc. { The <signature> role explicitly de nes signatures, i.e., it introduces (specialized) signature de nitions in the core multi-sorted signature of the used Reaction RuleML dialect. With the @type attribute locally de ned signature sorts (e.g. frame types, event patterns etc.) as well as externally de ned sorts from external (possibly order-sorted) type systems can be introduced as new sorts in the multi-sorted signature. Modes (@mode) further partition the universe into subsets having a different mode. Reaction RuleML prede nes the modes (@mode) "+" (input mode), " " (output mode) and "?" (open mode, i.e., input or output). { The <qualification> role de nes qualifying metadata. In contrast to descriptive metadata (meta), qualifying metadata has an impact on the interpretation, e.g. it is used for knowledge prioritization (e.g., con ict resolution strategies, defeasible reasoning etc.), or for de ning validity times (e.g., for windowing techniques in event processing etc.). { The <quantification> role explicitly de nes the quanti ers. Note, there is a default quanti er scope assumed in a dialect; typically a universal closure, so that formulas are universally closed by default.
While these optional meta roles allow explicit de nitions of meta knowledge, corresponding attributes on the knowledge formulas can point to these de nitions. For instance, the @scope attribute can use the prede ned terms4 \global ", \local " and \private", as well as scope names de ned in the <scope> role. In following example (in Prova 3 syntax) the rst public rule receives stock market ticks from the event stream "S&P500" and the second private selection rule compares the price with ticker information from other streams in the same event group in order to detect suspicious price information. % Select stock ticker events from stream "S&P500" 4 by using @vocab, an automated mapping of terms into IRIs is performed, i.e., the prede ned terms are mapped into IRIs of the Reaction RuleML vocabulary. % Each received event starts a new subconversation (CID) which further processes the selected % event (select) @group(g1) rcvMult(CID,stream,"S&P500", inform, tick(S,P,T)) :@scope(private) select(CID,tick(S,P,T)). % Indefinitely (count=-1) receive further ticker events from other streams that follow the % previous selected event in event processing group (group=g1). If the price differs for % the same stock at the same time [T1=T2, P1!=P2] then ... @scope(private) select(CID,tick(S,P1,T1)) :@group(g1) @count(-1) rcvMsg(CID,stream, StreamID ,inform, tick(S,P2,T2)) [T1=T2, P1!=P2]
println (["Suspicious:",StreamID, tick(S,P2,T2)]," "). 4
Reaction RuleML supports knowledge modularization and distribution. A syntactic way to distribute knowledge locally within a KB is by separating the representation of a knowledge formula into several syntactic parts and connecting and conjoining them syntactically by key-keyref pairs (@key, @keyref). A key is a local (\webized" by using @prefix and @vocab) identi er, with a unique name assumption (UNA), which can be de ned as meta knowledge on any Reaction RuleML language element. A key reference is a syntactic local reference (within a KB) using the key as locator to connect and conjoin the key element with the key reference element. Multiple references to a key element are possible (1 : m as well as n : m by de ning both key and keyref on pairwise conjoined elements). The resulting combined syntax elements need to be well-formed (according to their signature de nitions) to allow meaningful interpretations, i.e. keykeyref pairs need to be on similar syntactic elements and for each key reference a matching unique key needs to be de ned in a KB. A typical application of the keykeyref mechanism is the separation of the knowledge interface with signatures from the knowledge implementation, so that both can be represented and reused independently. For instance, the following example shows the separated implementation of a rule "ruleimpl1" which is referencing the rule interface "ruleinterf ace1". <Rule key="ruleinterface1"> <evaluation><Profile> ... </Profile></evaluation> <signature> ... </signature> ... </Rule> ... <Rule keyref="rulreinterface1" key="ruleimpl1 "> <if> ... </if> <do> ... </do> </Rule>
This enables, e.g., template de nitions (e.g., abstracted signature patterns, knowledge templates, event pattern de nitions, etc.), modularization and information hiding, e.g. by publishing the interface in a document distributed from the document with the (possibly private) implementation5.
Furthermore, with the @iri attribute also remote resources can be referenced. For instance, in the following example an RDFS entailment regime is referenced as intended semantic pro le for the order-sorted interpretation of external sorts de ned in external RDFS ontologies (taxonomies). 5 With XML Inclusion (XInclude) such distributed documents can be syntactically included into one KB enabling local key intra-references within it. <evaluation><Profile type="rif:RDFS iri="http://www.w3.org/ns/entailment/RDFS"/></evaluation>
This pro le can be used, e.g. for the type reasoning in the following example rule (in Prova syntax), which de nes a semantic event query with variables typed by background knowledge bases (ontologies)6. rcvMult(SID,stream,S&P500, inform, tick(Name^^car:Major_corporation,P^^currency:Dollar,T^^time:Timepoint)) :- ...
Rule-based Data Access (RBDA) with optimizing techniques, such as enrichment, can be used for e cient processing. For instance, the following example de nes a rulebased data access rule which selects with the SPARQL query built-in of Prova 7 all luxury car manufacturers from DBPedia. luxuryCar(Manufacturer,Name,Car) :Query="SELECT ?manufacturer ?name ?car % SPARQL RDF Query WHERE {?car <http://purl.org/dc/terms/subject>
<http://dbpedia.org/resource/Category:Luxury_vehicles> . ?car foaf:name ?name . ?car dbo:manufacturer ?man .
?man foaf:name ?manufacturer. } ORDER by ?manufacturer ?name, sparql_select(Query,manufacturer(Manufacturer),name(Name),car(Car)).
Rulebase formulas (<Rulebase>) introduce a (possibly nested) structuring of groups of knowledge formulas, called modules. External (<RuleML>) documents and messages (<Message>) can be consulted/imported (<Consult>) or received (<Receive>). They are treated as submodules in the importing KB.
De nition 3. (Import) A document KB0 is said to be an import to a document KB, if it is directly imported into KB (or it is imported into another document, which is directly imported into KB). An imported document KB0 becomes a module of the KB.
For instance, the following example consults (imports) the rule interface which has been published in a separated Reaction RuleML document. <Consult iri="http://reaction.ruleml.org/1.0/exa/dr/DistributedDerivationRuleInterface.rrml"/>
The importing Reaction RuleML KB (i.e., <RuleML> document) is the super module of all modules. All asserted, imported, and received rulebases are submodules of this KB module.
De nition 4. (Module and Submodule) A module is a tuple h@ ; i, where is an ordered or unordered nite set of knowledge formulas i 2 (without or with duplicates) and @ is an ordered or unordered nite set of meta knowledge formulas @ i 2 @ , called the module interface. A module is a submodule of if .
Modes partition the symbols in the universe used for formulas (predicates,
functions, and terms) into input, output, and open symbols. Also, scopes partition formulas
(and terms) into global, local, and private symbols. The set of input formulas In and
the set of output formulas Out are visible and can be imported and accessed by other
6 RuleML and Prova support external types, such as object-oriented Java class
hierarchies and ontologies [
De nition 5. (Modes and Scopes) Let M be a module consisting of a tuple hF; I; O; G; L; P i, where F is a nite set of all knowledge formulas in M ; I, O are pairwise disjoint sets of input and output formulas, i.e., formulas with input or output mode; G, L, and P are disjoint sets of formulas with global, local, and private scope. The function signature(F ) gives the signature of F , mode(F ) gives the mode, and scope(F ) gives the scope. Let R be the set of rules in M , then signatureatom(R) gives the atoms (atomic formulas) of a rule R, where { signatureatom(on), signatureatom(if ), signatureatom(af ter) are in I, i.e. the parts of R which consist of input atoms { signatureatom(then), signatureatom(else), signatureatom(do) and signatureatom(elseDo) are in O, i.e. output atoms which are not in I.
Semantic pro les can de ne the composition semantics of modules.
The composition semantics must respect the declared modes and scopes. While global and local scopes are visible and hence can be used in input and output modes, a private scope is only visible within the module in which it is de ned. For instance, the composition of imported modules removes the output atoms from the set of input atoms and enforces that KB0 and KB are mutual independent and that private atoms from one module are not part of the signature of the other module in which they are not visible. Private and local symbols might be de ned and interpreted di erently in two imported modules, but their interpretation must coincide for global symbols. De nition 6. (Module Composition) Let KB0 and KB be two modules; their composition is the union KB0 t KB = hFKB0 [ FKB; (IKB0 [ IKB) (OKB0 [ OKB); OKB0 [ OKB; GKB0 [ GKB; LKB0 [ LKB; PKB0 [ PKBi, where signature(KB0) \ P1 = ; and signature(KB)\P2 = ; and there are no (positive) cyclic dependencies8 in FKB0 [FKB through loops between input and output atoms.
That is, semantic pro les de ne the intended interpretations for composed multimodule KBs. Semantic pro les might also specify syntactic translation and transformation mapping, e.g., to consistently map all imported local symbols into the local symbols of the importing KB or to do program transform such as renaming output formulas to guarantee compositionality. Furthermore, they can de ne concrete module composition semantics, e.g. as semantic join of models, as well as a mechanism to avoid cyclic imports9.
De nition 7. (Modular Semantic Multi-Structure) A modular semantic multistructure M = hMKB0 ; MKB1 ; MKB2 ; ::i is a set of semantic structures such that MKB is the semantic structure of the importing KB and MKBk is a set of semantic structures 8 One approach to detect mutual positive or negative dependencies is by adding extra meta information in the models. 9 see the Semantic Pro les for modular Reaction RuleML knowledge bases and the OntoMaven/RuleMaven dependency analysis and importation resolution algorithm for imports from distributed KB repositories. of the imported modules. The semantic structures MKB and all structures MKBk are required to coincide in the mappings of global symbols in all semantic structures. But they might di er for local and private symbols in their interpretation using the module scope to constrain and close the domain of discourse for deviating local interpretations in each MKBk .
A semantic pro le can specify how to do the expansion of the modular semantic multi-structure. The default is that the semantics of imported modules expands to the semantics of the importing KB. But, other semantics can be de ne in a pro le, e.g. as a conservative composition using renaming output transformations on the output formulas in the module composition and a semantic outer join operator for the joint interpretation.
De nition 8. (Join) Let KB0 and KB be two modules and I0 and I be their sets of interpretations; then the natural outer join I0 ./ I = fI0 \ signature(KB) = I \ signature(KB0)andI [ I0g, where I0 2 I0 and I 2 I.
The following example (in Prova) shows the rule of a manager agent which reads a Prova script from a le and uploads it to a contractor agent. The contractor consults and evaluates the receive mobile code. % Manager upload_mobile_code(Remote,File) :
Writer = java.io.StringWriter(), fopen(File,Reader), copy(Reader,Writer), Text = Writer.toString(), SB = StringBuffer(Text), sendMsg(XID,esb,Remote,eval,consult(SB)). % Service (Contractor) rcvMsg(XID,esb,Sender,eval,[Predicate|Args]):- derive([Predicate|Args]). 5
A particular important feature of Reaction RuleML 1.0 feature for Rule Responder
agents is that it allows constructing views dynamically on the KB. These views are
de ned by metadata scopes [
Scoped reasoning can be performed on such metadata scopes (aka constructive views on the KB) by de ning scoped literals in conditions, queries, and event patterns. Scope literals are interpreted in the scoped domain of discourse and by default have the scopes' closure10. The scope de nition of a scope literal might contain variables. In addition to scopes, Reaction RuleML supports guards which act as additional 10 like for module imports in the large semantic pro les can de ne di erent closure semantics pre-conditional constraints on the literal. The following example de nes a scoring rule which selects ticker events with a score value (scope) over 2 (guard). Accordingly, only the second ticker event with a score value over 2 is further analyzed. happens(tick(S,P),T):@score(Value) tick(S,P,T) [Value>2].
By default, the scope of relations and functions is global and their arguments' scope is local. A global scope corresponds to a metadata scope de ned over all knowledge quali ed with the source of the KB (@source([Locator])), and the local scope corresponds to the metadata scope de ned over all knowledge quali ed with the name of the module (@label([OID])). The mode of formulas when used as conditions, constraints, queries, and event patterns is "+" (input), and the mode of conclusions, answers, and active actions is " " (output); with a corresponding mode for their constant arguments, and by default for variables, the mode is "?" (open). The default quanti cation scope is universal (<Forall>). There is a nested submodule inheritance, i.e., meta knowledge de ned on outer modules is automatically inherited to the inner modules.
In the following example de nes a rating of events from only trusted sources. :-solve(ratedEvent(X)). % => X=e1 (but not e2) 6
Reaction RuleML supports actions for sending (<Send>) and receiving (<Receive>) knowledge via messages (<Message>) in messaging reaction rules (rule @style="messaging"). Messages interchange Reaction RuleML documents as their payload between agents (<Agent>), which are rule-based agents (aka inference services). A Message element that provides the syntax for inbound and outbound messages / noti cations. Besides having the typical meta knowledge, a message consists of { an <oid> (message object identi er) and a <cid> which is the conversation identier (enabling also long-running asynchronous conversations and sub-conversations with new conversation identi ers), { an optional <protocol>: protocol de nition (e.g. high-level negotiation and coordination protocols, agent protocols and operational transport protocols) { an optional <sender> and <receiver>: denotes the sender and the target of the message, { a directive: pragmatic context de ning the pragmatic interaction and interpretation context for the message payload, e.g. FIPA Agent Communication Language primitives such as "acl:query-ref", { an optional @type de nes the type of the message and an optional @mode attribute distinguishes "inbound" from "outbound" communication, { a payload transporting any valid <RuleML> knowledge document (enclosing, e.g., queries (<Query>), answers (<Answer>), imports, and updates (<Consult>, <Assert>, <Retract>, <Update>), as well as general actions (<Action>)) or arbitrary XML <content>.
The following example shows the typical template of a message: <Message> <oid> <!-- message ID--> </oid> <cid> <!-- conversation ID--> </cid> <protocol> <!-- transport protocol --> </protocol> <directive> <!-- pragmatic context --> </directive> <sender> <!-- sender agent/service --> </sender> <receiver> <!-- receiver agent/service --> </receiver> <payload> <!-- message payload --> </payload> </Message>
The knowledge of received RuleML documents can be used in the messaging reaction rules of the receiving agent. An important di erence to \standard" imports, as described in the previous section, is that these knowledge updates are private to the conversation scope of the message interaction which takes place in the execution scope of the messaging reaction rules. A typical application of this conversation-based interactions is distributed question-answering (Q&A) between distributed agents (i.e., agents providing query interfaces to their KBs), where the send and receive actions in messaging reaction rules act as queries and answers to the external agents' KBs. For instance, the following messaging reaction rule starts two conversations, \xid1" and \xid2", sending two queries. The serial execution initially waits for the answers from the second conversation and then, after proving some conditions (e.g., conditions de ned on the bound variables of the received answers), the execution waits for the answers to the rst query in the rst conversation.
Answers are given in terms of solved formulas, e.g. as a rulebase (<Rulebase>) that contains `solved' equations with the variable bindings.
<Rulebase> <Equal><Var>x</Var><Ind>a</Ind></Equal> <Equal><Var>y</Var><Ind>b</Ind></Equal> <Equal><Var>z</Var><Ind>c</Ind></Equal> </Rulebase> <Atom> <Rel>p</Rel> <Ind>a</Ind> <Ind>b</Ind> <Ind>c</Ind> </Atom>
Alternatively, they are given one by one as ground literals (<Atom>) matching the sent query.
The semantics of sent queries interprets them as (sub-)goals which are proven by the external agent's knowledge and the variable bindings from the received answers are used to continue the local proof logic in the serial execution of the messaging reaction rule.
The following Prova example de nes an event composition work ow, where rst an event "A" is received which forks the process into two alternative branches for event "B" and "C". rcvMsg(XID,Process,From,event,["A"]) :
fork_b_c(XID, Process). fork_b_c(XID, Process) :@group(p1) rcvMsg(XID,Process,From,event,["B"]), . fork_b_c(XID, Process) :@group(p1) rcvMsg(XID,Process,From,event,["C"]), . 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,_).
Such reaction groups establish an additional event processing scope which is used to manage the event processing ow. This can be used, for instance, to de ne relative timer events in a reaction group within a time window, e.g., for the accumulation of events over a time window as in the following Prova example. % This reaction operates indefinitely. When the timer elapses (after 25 ms), % the group by map Counter is sent as part of the aggregation event and consumed in an % or group, and the timer is reset back to the second argument of @timer. groupby_rate() :
Counter = ws.prova.eventing.MapCounter(), % Aggr. Obj. @group(g1) @timer(25,25,Counter), % timer every 25 ms rcvMsg(XID,stream,From,inform,tick(S,P,T)) % event [IM=T,Counter.incrementAt(IM)]. % aggr. operation groupby_rate() :% receive the aggregation counter in the or reaction @or(g1) rcvMsg(XID,self,From,or,[Counter]), ... % consume the Counter aggreation object.
Another important aspect in this distributed interaction is the interface declaration of knowledge base, in particular the signatures and their scope visibility which de ne which knowledge can be queried from external agents. Furthermore, the agent conversations might follow certain de ned protocols (<Protocol>) and the knowledge interpretation might be given an additional pragmatic context (<directive>).
For the correct semantic interpretation, the intended semantic pro les can be
interchanged together with test suites, which are special knowledge bases (<TestSuite>)
with a test assertion base (typically ground facts), and test items (<TestItem>),
consisting of test queries and prede ned expected answers. [
In this paper we have described and exempli ed several important features of Reaction RuleML 1.0 which provide support for Rule Responder.
{ Knowledge interface declarations can be used to de ne signatures/patterns,
intended semantic pro les, scopes, quali cations and quanti cations of knowledge
implementations with possible separation and distribution of the interface from its
implementations by key-keyref references.
{ Modules with declarations of scopes, modes, and pro les distinguish global,
local, and private knowledge with possibly varying interpretations and visibility
for external agents.
{ Knowledge imports allow consultation of external knowledge as modules of the
importing KB with module composition and interpreting (join) semantics de ned
by semantic pro les.
{ Scoped reasoning can be used to close o the domain of discourse to a
particular scope, including dynamic metadata-based scopes which act as constructive
views on the (modular) knowledge base. [
The implementation of these advanced features of Reaction RuleML 1.0 and Rule
Responder is demonstrated in the Prova 3.0 rule engine with use cases for Q&A
answering on top of rule-based data access to Linked Open Data (LOD) knowledge
bases such as DBPedia and design pattern implementations for Semantic Complex
Event Processing (SCEP) functionalities [