ArticlePDF Available

Rule Responder: Rule-Based Agents for the Semantic-Pragmatic Web.

December 2011
International Journal of Artificial Intelligence Tools 20(6):1043-1081

December 2011
20(6):1043-1081

DOI:10.1142/S0218213011000528

Source
DBLP

Authors:

Adrian Paschke

Freie Universität Berlin

Rule Responder is a Pragmatic Web infrastructure for distributed rule-based event processing multi-agent eco-systems. This allows specifying virtual organizations -- with their shared and individual (semantic and pragmatic) contexts, decisions, and actions/events for rule-based collaboration between the distributed members. The (semi-)autonomous agents use rule engines and Semantic Web rules to describe and execute derivation and reaction logic which declaratively implements the organizational semiotics and the different distributed system/agent topologies with their negotiation/coordination mechanisms. They employ ontologies in their knowledge bases to represent semantic domain vocabularies, normative pragmatics and pragmatic context of event-based conversations and actions.

…

Figures - uploaded by Adrian Paschke

Content may be subject to copyright.

Content uploaded by Adrian Paschke

Content may be subject to copyright.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Electronic version of an article published as International Journal on Artiﬁcial Intelligence Tools,

20, 6, 2011, 1043-1081 DOI: 10.1142/S0218213011000528

copyright World Scientiﬁc Publishing Company

http://www.worldscientiﬁc.com/doi/abs/10.1142/S0218213011000528

Rule Responder: Rule-based Agents for the Semantic-Pragmatic Web

Adrian Paschke

AG Corporate Semantic, Department of Computer Science, Freie Universitaet Berlin, Germany

paschke AT inf.fu-berlin.de

Harold Boley

Institute for Information Technology, National Research Council Canada

Fredericton, NB, Canada

harold.boley AT nrc.gc.ca

Rule Responder is a Pragmatic Web infrastructure for distributed rule-based event pro-

cessing multi-agent eco-systems. This allows specifying virtual organizations – with their

shared and individual (semantic and pragmatic) contexts, decisions, and actions/events

for rule-based collaboration between the distributed members. The (semi-)autonomous

agents use rule engines and Semantic Web rules to describe and execute derivation and

reaction logic which declaratively implements the organizational semiotics and the dif-

ferent distributed system/agent topologies with their negotiation/coordination mecha-

nisms. They employ ontologies in their knowledge bases to represent semantic domain

vocabularies, normative pragmatics and pragmatic context of event-based conversations

and actions.

Keywords: Pragmatic Web; Semantic Web; Multi Agent System.

1. Introduction

Rule Responderaextends the Semantic Web towards a Pragmatic Web infrastruc-

ture for collaborative rule-based agent networks realizing distributed rule inference

services, where independent agents engage in conversations by exchanging event

messages and cooperate to achieve (collaborative) goals.

Rule Responder agents communicate in conversations that allow implementing

diﬀerent agent coordination and negotiation protocols. By means of pragmatic prim-

itives, such as speech acts, deontic norms, etc., which are represented as ontologies,

Rule Responder attaches the semantic and pragmatic context, e.g. organizational

norms, purposes or goals and values, to the interchanged messages. In its multi-

agent architecture Rule Responder utilizes messaging reaction rules from Reaction

RuleMLbfor communication between the distributed agent inference services. The

ahttp://responder.ruleml.org

bhttp://reaction.ruleml.org

December 16, 2011 17:17 Postprint Version RuleResponderReaction

2Adrian Paschke and Harold Boley

Rule Responder middleware is based on modern enterprise service technologies and

Semantic Web technologies for implementing intelligent agent services that access

data and ontologies, receive and detect events (e.g., for complex event processing

in event processing agent networks), and make rule-based inferences and (semi-

)autonomous pro-active decisions for reactions based on these representations.

The core of a Rule Responder agent is a rule engine, such as Provac, OO jDREW,

DR-Device (initially in Emerald), Euler, or Drools, which implements the decision

and behavioral reaction logic of the agents’ roles. An agent can employ vocabularies

deﬁned as Semantic Web ontologies (e.g., based on RDFS or OWL) to give its rules

a domain-speciﬁc meaning. The vocabularies can be used within the conversation

with other agents to enable a semantic and pragmatic interpretation of the messages.

For the deployment of agents on the Web and for the communication in agent

networks, Rule Responder uses an enterprise service bus middleware, which supports

a multitude of synchronous and asynchronous transport protocols (>40) – such as

SMTP, JDBC, TCP, HTTP, XMPP – to transport rulebases, queries and answers

between the agents. The de facto standard Reaction RuleML is used as a platform-

independent rule interchange format for agent conversation.

In summary, Rule Responder can be seen to support a digital agent ecosystem,

evolving from the Semantic Web to the Pragmatic Web d. Such an ecosystem con-

sists of all the semantic agents in one or more virtual organizations, as well as all

the other components of this environment with which the agents interact, such as

other services, tools, the ESB middleware, etc.

The rest of the article is organized as follows. Section 2 explains a typical dis-

tributed agent topology for virtual organizations and the types of agents used to

implement it. Section 3 discusses the components and used technologies of the Rule

Responder framework. Section 4 focuses on interchange between the semantic agents

which communicate by using (Reaction) RuleML as common rule interchange for-

mat. Section 5 describe how Rule Responder agents are implemented using the ex-

pressive Semantic Web rule engine Prova. Section 6 demonstrates some application

use cases of Rule Responder by means of selected Rule Responder instantiations.

Section 7 discusses related work and section 8 concludes the paper.

2. Rule Responder Multi Agent Architecture

Rule Responder supports the implementation of various distributed agent coordi-

nation topologies, from centralized orchestration, executed in star-like agent nodes,

to decentralized ad-hoc choreography within the Rule Responder agent network. In

the following, we describe a common hierarchical agent topology which represents a

chttp://prova.ws

dhttp://www.pragmaticweb.info/

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 3

centralized star-like structure for virtual organizations (and many orchestrated dis-

tributed systems). Organizational Agents (OAs) act as central orchestration nodes

which control and disseminate the information ﬂow from and to their internal Per-

sonal Agents (PAs), and the External Agents/Services (EAs) and internal Compu-

tational Agents/Services (CAs).

2.1. Organizational Agent

An Organizational Agent (OA) represents a virtual organization (respectively net-

work of agents) as a whole. An OA manages its local Personal Agents (PAs), pro-

viding control of their life cycle and ensuring overall goals and policies of the or-

ganization and its semiotic structures. OAs can act as a single point of entry to

the managed sets of local PAs to which requests by EAs are disseminated. This

allows for eﬃcient implementation of various mechanisms of making sure the PAs

functionalities are not abused (security mechanisms) and making sure privacy of

entities, personal data, and computation resources is respected (privacy & informa-

tion hiding mechanisms). For instance, an OA can disclose information about the

organization to authorized external parties without revealing private information

and local data of the PAs, although this data might have been used in the PAs to

compute the resulting answers to the external requester.

2.2. Personal Agents

Personal Agents (PAs) assist the local entities of a virtual organization (respective

network). Often these are human roles in the organization. But, it might be also ser-

vices or applications in, e.g. a service oriented architecture. A PA runs a rule engine

which accesses diﬀerent sources of local data and computes answers according to the

local rule-based decision logic of the PA. Depending on the required expressiveness

to represent the PAs rule logic arbitrary rule engines can be used as long as they

provide an interface to ask queries and receive answers which are translated into

the common Reaction RuleML interchange format in order to communicate with

other agents.

Importantly, the PAs might have local autonomy and might support privacy

and security implementations. In particular, local information used in the PA rules

becomes only accessible by authorized access of the OA via the public interfaces

of the PA which act as an abstraction layer supporting security and information

hiding. A typical coordination protocol is that all communication to EAs is via the

OA, but the OA might also reveal the direct contact address of a PA to authorized

external agents which can then start an ad-hoc conversation directly with the PA

BP 07 . A PA itself might act as a nested suborganization, i.e. containing itself an

OA providing access to a suborganization within the main virtual organization. For

instance, this can be useful to represent nested organizational structures such as

departments, project teams, service networks, where e.g., the department chair is

December 16, 2011 17:17 Postprint Version RuleResponderReaction

4Adrian Paschke and Harold Boley

a personal agent within the organization and at the same time an organizational

chair for the department, managing the personal agents of the department.

2.3. Internal Computational Agents

Computational Agents (CAs) act as wrappers around internal computational ser-

vices and data which is used by the PAs. They fulﬁll computational tasks such as

collecting, transforming and aggregating data from internal data sources or com-

putational functions. The PAs can communicate with the CAs decoupled via inter-

changing event messages or loosely coupled via the built-ins and service interfaces

of the rule engines in the PAs.

2.4. External Agents

External Agents (EAs) constitute the points-of-contact that allow an external user

or service to query the Organizational Agent (OA) of a virtual organization. An

EA is based, e.g., on a Web (HTTP) interface that allows such an enquiry user to

pose queries, employing a menu-based Web form, which gets translated to equiv-

alent RuleML/XML message that is sent to the OA via HTTP Post or Get. An

external agent – from the point of view of a Rule Responder agent organization –

can be an external human agent, a service/tool, or another external Rule Responder

organization, i.e. leading to cross-organizational Rule Responder communications.

3. The Rule Responder Framework

Three interconnected architectural layers constitute the Rule Responder framework,

listed here from top to bottom:

•Computationally independent user interfaces such as template-based Web

forms or controlled English rule interfaces.

•Reaction RuleML as the common platform-independent rule interchange

format to interchange rules, events, actions, queries, and data between Rule

Responder agents and other agents (e.g., Semantic Web services or humans

via Web forms).

•A highly scalable and eﬃcient enterprise service bus (ESB) as agent/service-

broker and communication middleware on which platform-speciﬁc rule en-

gines are deployed as distributed agent nodes (respective semantic infer-

ence Web services). These engines manage and execute the logic of Rule

Responder’s semantic agents in terms of declarative rules which have access

to semantic ontologies.

In the following, the Rule Responder framework will be explained from bottom

to top.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 5

3.1. Enterprise Service Bus Communication Middleware

To seamlessly handle message-based interactions between the Rule Responder

agents/services and other agents/services using disparate complex event process-

ing (CEP) technologies, transports, and protocols, an enterprise service bus (ESB)

– the Mule open-source ESB e– is used in Rule Responder as the communica-

tion middleware. This ESB allows deploying the rule-based agents (see Figure 1)

as distributed rule inference services installed as Web service-based endpoints on

the Mule object broker and supports the communication in this rule-based agent

processing network via a multitude of transport protocols. That is, the ESB pro-

vides a highly scalable and ﬂexible application messaging framework to commu-

nicate synchronously or asynchronously amongst the ESB-local agents and with

agents/services on the Web.

Fig. 1. Distributed Rule Responder Agent Services

The agent object broker follows the Staged Event Driven Architecture (SEDA)

pattern W CB 01. The basic approach of SEDA is to decompose a complex, event-

driven application into a set of stages connected by queues. This design decouples

event and thread scheduling from application logic and avoids the high overhead

associated with thread-based concurrency models. That is, SEDA supports high con-

currency demands on Web-based services and provides a highly scalable approach

for asynchronous communication.

Figure 2 shows a simpliﬁed breakdown of the integration of Mule into the Rule

Responder framework.

Distributed agent services (see Figure 1), which at their core run a platform

speciﬁc rule engine, are deployed as Mule components which listen at conﬁgured

endpoints, e.g., JMS message endpoints, HTTP ports, SOAP server/client addresses

or JDBC database interfaces, etc. Reaction RuleML is used as a common platform-

independent rule interchange format between the agents (and possible other rule

ewww.mulesoft.org

December 16, 2011 17:17 Postprint Version RuleResponderReaction

6Adrian Paschke and Harold Boley

Fig. 2. Layering of Rule Responder on Mule ESB

execution / inference services). Translator services are used to translate inbound

and outbound (event) messages from platform-independent Reaction RuleML into

the platform-speciﬁc execution syntaxes of rule engines, and vice versa.

The large variety of transport protocols provided by Mule can be used to trans-

port the messages to the registered endpoints or external applications / tools. Usu-

ally, JMS is used for the internal communication between distributed Prova rule

agent instances, while HTTP and SOAP is used to access external Web services.

The usual processing style is asynchronous using SEDA event queues. However,

sometimes synchronous communication is needed. For instance, to handle com-

munication with external synchronous HTTP clients such as Web browsers where

requests, e.g. by a Web from, are sent through a synchronous HTTP channel. In

this case, a synchronous bridge component (see Figure 1) dispatches the requests

into the asynchronous messaging framework and collects all answers from the inter-

nal service nodes, while keeping the synchronous channel with the external service

open. After all asynchronous answers have been collected, they are sent back to the

still connected external service via the HTTP-synchronous channel.

3.2. Platform-Speciﬁc Rule Engines for Rule Responder Agents

The core of a Rule Responder agent, which is deployed as a service component on

the Rule Responder ESB, is a platform-speciﬁc rule engine. These engines might

diﬀer, e.g., in their supported rule types, state representation, rule evaluation mech-

anism, conﬂict resolution and truth maintenance. Hence, depending on their ex-

pressiveness and functionalities, these rule engines might be capable of implement-

ing agents in the strong sense of cognitive architectures for intelligent agents with

goal/task-based, utility-based and learning-based functionalities, or in the weak

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 7

sense of inference agent services with simple reﬂexive functionalities for, e.g., de-

ductive query-answering capabilities. Following the general consensus deﬁned by

the strong notion of agency in W oo01, a Rule Responder agent, in addition to being

(semi-)autonomous, should be capable of reactive, proactive, and communicative

behavior. Additionally, it is often important that certain mentalistic notionsfcan

be used in the rule language for describing the agent behavior in an abstract and in-

tuitive way, e.g. in the interactions between agents to communicate the pragmatics

of the interchanged information.

Fig. 3. Rule Responder Agent

Figure 3 shows the architecture of an intelligent cognitive Rule Responder agent

as it is implemented in the Prova. Provagis an enterprise-strength, highly expressive

distributed Semantic Web logic programming (LP) rule engine.

3.3. Conversations Between Rule Responder Agents

Rule Responder permits agents to use local platform speciﬁc languages and engines,

only requiring that all rulebases, (event) messages, queries, and answers will be

translated to Reaction RuleML as standard rule and event (message) interchange

format for transmitting them to other agents.

fThe term mentalistic notions aka mental attitudes refers to human properties such as beliefs,

goals, etc. when transferred to describing machine agents.

ghttp://prova.ws

December 16, 2011 17:17 Postprint Version RuleResponderReaction

8Adrian Paschke and Harold Boley

Reaction RuleML provides a translator service framework with Web form in-

terfaces accepting controlled natural language input or predeﬁned selection-based

rule templates for the communication with external (human) agents on the com-

putational independent level, as well as HTTP interfaces, and Web service SOAP

interfaces, which can be used for translation into and from platform-speciﬁc rule

languages such as Prova.

On the platform-independent and platform-speciﬁc level, the translator services

are using diﬀerent translation technologies such as XSLT stylesheet, JAXB, etc. to

translate from and to Reaction RuleML as a general rule interchange format. The

Reaction RuleML translator services are conﬁgured in the transport channels of the

inbound and outbound links of the deployed rule engines on the ESB. Incoming

Reaction RuleML messages (receive) are translated into platform-speciﬁc rulebases

which can be executed by the rule engine, e.g. Prova, and outgoing rulebases (send)

are translated into Reaction RuleML in the outbound channels before they are

transferred via a selected transport protocol such as HTTP or JMS.

On the computation-independent level, online user interfaces allow external hu-

man agents issuing queries to Rule Responder agents (typically the OA) in a con-

trolled natural language or with template-driven Web forms and receive answers.

The translation between the used controlled English rule language (Attempto Con-

trolled English SG06 ) and Reaction RuleML is based on domain-speciﬁc language

translation rules in combination with a controlled English translator service.

Fig. 4. ACE2RuleML Translator Web Service

Figure 4 shows the architecture of the ACE-to-Reaction RuleML translator Web

service of the Rule Responder infrastructure. Queries to Rule Responder are for-

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 9

mulated in Attempto Controlled English. The ACE2RML translator forwards the

text to the Attempto Parsing Engine (APE), which translates the text into a dis-

course representation structure (DRS) and/or advices to correct malformed input.

The DRS gives a logical/structural representation of the text. It is fed into an XML

parser which translates it into a domain-speciﬁc Reaction RuleML representation of

the query. Besides parsing and processing the elements of the DRS, the parser addi-

tionally employs domain-speciﬁc transformation rules and vocabularies to correctly

translate the query into a public interface call of a Rule Responder OA.

4. Reaction RuleML as Standard Semantic Rule and Event

Interchange Format

Reaction RuleML is used in Rule Responder as standardized rule and event in-

terchange format between the (diﬀerent) rule engines used for implementing the

agents. Reaction RuleML incorporates various kinds of production, action, reac-

tion, and KR temporal/event/action logic rules as well as (complex) event/action

messages into the native RuleML syntax. The Reaction RuleML subfamily addresses

the four major reaction rule types:

•Production Rules (Condition-Action rules) in the Production RuleML sub-

family

•Event-Condition-Action (ECA) rules in the ECA RuleML subfamily

•Rule-based Complex Event Processing (complex event processing reaction

rules, (distributed) event messaging reaction rules, query reaction rules etc.)

in the CEP RuleML subfamily

•Knowledge Representation Event/Action/Situation Transition/Process

Logics and Calculi in the KR Reaction RuleML subfamily

The general syntax of reaction rules is as follows:

<qualification> <!-- e.g. qualifying rule declarations, e.g.

priorities, validity, strategy --> </qualification>

<after> <!-- postcondition part after action,

e.g. to check effects of execution --> </after>

<elsedo> <!-- alternative/else action,

e.g. for default handling --> </elsedo>

</Rule>

Depending on which parts of this general rule syntax are used diﬀerent types

of reaction rules can be expressed, e.g. if-then (derivation rules), if-do (production

December 16, 2011 17:17 Postprint Version RuleResponderReaction

10 Adrian Paschke and Harold Boley

rules), on-do (trigger rules), on-if-do (ECA rules).

Derivation Rule:

</Rule>

Production Rule:

</Reaction>

ECA Rule:

</Reaction>

CEP Rule:

<on> event 1 </on>

<do> action </do>

<on> event 2 </on>

<if> condition</if>

<do> action </do>

...

</Rule>

Reaction RuleML provides several layers of expressiveness for adequately repre-

senting the agents’ logic and for interchanging events (queries, actions, event data)

and rules. In the following some of the needed Rule Responder expressiveness con-

structs of Reaction RuleML 1.0 are described.

4.1. Reaction RuleML Messaging for Distributed Agent

Conversation

For communication between distributed rule-based (agent) systems Reaction

RuleML provides a general message syntax:

</Message>

In the context of these Reaction RuleML messages agents can interchange events

(e.g., queries and answers) as well as complete rule bases (rule set modules), e.g.

for remote parallel task processing. Agents can be engaged in long running possibly

asynchronous conversations and nested sub-conversations using the conversation id

to manage the conversation state. The protocol is used to deﬁne the message passing

and coordination protocol. The directive attribute corresponds to the pragmatic

instruction, e.g. a FIPA ACL primitive, i.e. the pragmatic characterization of the

message context broadly characterizing the meaning of the message.

For sending and receiving (event) messages Reaction RuleML 1.0 supports serial

messaging CEP reaction rules which receive and send events in arbitrary combi-

nations. A serial (messaging) reaction rule starts with a receiving event on followed

by an arbitrary combination of conditions if, events receive and actions send in

the body of the rule for expressing complex event processing logic. This ﬂexibility

with support for modularization and aspect-oriented weaving of reactive rule code

is in particular useful in distributed systems where event processing agents com-

municate and form a distributed event processing network, as e.g. in the following

example:

<on><Receive> receive event from agent 1 </Receive></on>

<do><Send> query agent 2 for regular products in a new sub-conversation </Send></do>

<on><Receive> receive results from sub conversation with agent 2 </Receive></on>

<if> prove some conditions, e.g. make decisions on the received data </if>

<do><Send> reply to agent 1 by sending results received from agent 2 </Send></do>

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 11

</Rule>

For better modularization the sub-conversation logic can be also written with

an inlined reaction rule as follows:

<on><Receive> receive event from agent 1 </Receive></on>

<Atom><Rel>regular</Rel><Var>prod</Var></Atom>

</if>

<do><Send> reply to agent 1 by sending results received from agent 2 </Send></do>

</Rule>

<then>

<Atom><Rel>regular</Rel><Var>prod</Var></Atom>

</then>

<do><Send> query agent 2 for regular products in a new sub-conversation </Send></do>

<on><Receive> receive results from sub conversation with agent 2 </Receive></on>

</Rule>

Reaction RuleML messaging reaction rules can be translated, e.g., into serial

messaging Horn rules and executed in the Prova rule engine, so that incoming event

queries can be processed by the Prova agents and derived answers can be send back

as event messages.

4.2. Event/Action/Situation Processing in Reaction RuleML

Events, actions and situations states play a central role in the reactive (behavioral)

logic of Rule Responder agents. Reaction RuleML deﬁnes a standard library of

typical event and action algebra operator constructs to deﬁne complex event and

actions:

Event Algebra:

Sequence (Ordered), Disjunction (Or) , Xor (Mutal Exclusive),

Conjunction (And), Concurrent, Not, Any, Aperiodic, Periodic

Action Algebra:

Succession (Ordered Succession of Actions), Choice

(Non-Deterministic Choice), Flow (Parallel Flow),

Loop (Loops)

Complex Sequence (A;(B;C))

<on>

</on>

Furthermore, Reaction RuleML provides support for (re)using external

event/action ontologies and metamodels which can be applied in generic operator

deﬁnitions Operator for deﬁning semantic (complex) event/action types and in the

events to deﬁne speciﬁc event types. Diﬀerent selection, consumption, and (trans-

actional) execution policies for events and actions can be speciﬁed in the evaluation

semantics for the complex event/action descriptions. This allows for a highly exten-

sible and ﬂexible Semantic CEP (SCEP) approach which (re-)uses external semantic

models.

Reaction RuleML also deﬁnes syntax and semantics for knowledge representa-

tion event/action calculi such as Situation Calculus M H 69, Event Calculus KS 86

December 16, 2011 17:17 Postprint Version RuleResponderReaction

12 Adrian Paschke and Harold Boley

and Temporal Action Languages DGKK 98 etc. Speciﬁcally the notion of an explicit

state (a.k.a. as state or ﬂuent in Event Calculus) is introduced in the KR Reaction

RuleML layer. An event/action initiates or terminates a state. That is, a state ex-

plicitly represents the abstract eﬀect of occurred events and executed actions. Such

states can be e.g. used for situation reasoning in the condition part of reaction rules.

<on> <Receive> ... event message ... </Receive> </on>

<if> <HoldsState> ... state individual ... </HoldsState> </if>

<do> <Send> ... action message ... </Send></do>

</Rule>

4.3. Agent Interface Descriptions with Reaction RuleML

Signatures

Information hiding is another important concept for virtual collaboration of in-

dependent agents. In particular, local information used in the PAs becomes only

accessible by authorized access via the public interfaces of the OAs which act as an

abstraction layer supporting security and information hiding. To achieve this, Re-

action RuleML provides an interface deﬁnition language which allows descriptions

of the signatures of publicly accessibly rule functions together with their mode and

type declarations. Modes are states of instantiation of the predicate described by

mode declarations, i.e. declarations of the intended input-output constellations of

the predicate terms with the following semantics:

•”+” The term is intended to be input

•”−” The term is intended to be output

•”?” The term is undeﬁned/arbitrary (input or output)

For instance, the interface deﬁnition for the function add(Result, Arg1, Arg 2) is

add(−,+,+), i.e. the function predicate add returns one output argument followed

by two input arguments. Serialized in Reaction RuleML this would be:

<Atom>

</Atom>

</signature>

External agents can access the virtual organization only via these public inter-

faces, which often only reveal abstracted information to authorized users and hence

hide local information of the organization and its PAs. That is, e.g. add(X, 1,1)?

would be a valid query to this public signature function of an agent.

Other expressive constructs of Reaction RuleML needed for adequate implemen-

tations of Rule Responder agents will be discussed on the platform speciﬁc level in

the next section.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 13

5. Prova Semantic Rule Engine for Rule Responder Agents

On the platform-speciﬁc level Rule Responder allows arbitrary rule engines to be

deployed as inference and execution environments for the agents as long as they

provide a translator into the standard Reaction RuleML and as long as they support

the required expressiveness to represent the respective agent’s logic. In the following

we describe the implementation of Rule Responder agents using Provah, which is a

highly expressive Semantic Web rule engine.

The Prova rule engine supports diﬀerent rule types:

•Derivation rules to describe the agent’s decision logic

•Integrity rules to describe constraints and potential conﬂicts

•Normative rules to represent the agent’s permissions, prohibitions and obli-

gation policies

•Defeasible rules to prioritize rules for, e.g. handling conﬂicts between agent’s

goals and modularization of the agent’s KB to support multiple roles of an

agent

•Global ECA-style reaction rules to deﬁne global reaction logic which are

triggered on the basis of detected (complex) events

•Messaging reaction rules to deﬁne the agents conversation-based workﬂow

reactions and behavioral logics based on complex event processing

In the following subsections several extra logical expressiveness features of Prova

will be describe, which are useful for implementing the logic of Rule Responder

agents.

5.1. Access to External Data, Type Systems and Procedural

Attachments

Prova follows the spirit and design of the W3C Semantic Web initiative and com-

bines declarative rules, ontologies and inference with dynamic object-oriented pro-

gramming and access to external data sources and type systems. Therefore, Prova

assumes not just a single universe of discourse, but several domains, so called sorts

(types) which are interpreted in a multi-sorted logic. The extension of the signature

and the typed variables of the language alphabet with sorts (aka types) is deﬁned

as follows.

Deﬁnition 5.1. (Multi-sorted Signature) The multi-sorted signature Sof Prova

is deﬁned as a tuple hT , P ,F , arity, c, sortiwhere T={T1, .., Tn}is a set of

sort/type symbols called sorts. The function sort associates with each predicate,

function or constant its sorts:

•if cis a constant, then sort(c) returns the type Tof c.

hhttp://prova.ws

December 16, 2011 17:17 Postprint Version RuleResponderReaction

14 Adrian Paschke and Harold Boley

•if pis a predicate of arity k, then sort(p) is a k-tuple of sorts sort(p) =

(T1, .., Tk) where each term tiof pis of some type Tj, i.e., ti:Tj.

•if fis a function of arity k, then sort(f) is a k+ 1-tuple of sorts sort(f) =

(T1, .., Tk, Tk+1) where (T1, .., Tk) deﬁnes the sorts of the domain of fand

Tk+1 deﬁnes the sorts of the range of f

Prova supports the following three basic types of sorts

(1) primitive sorts are given as a ﬁxed set of primitive data types such as integer,

string, etc.

(2) function sorts are complex sorts constructed from primitive sorts T1×...×Tn→

Tn+1 or other complex sorts deﬁned in the external type alphabet

(3) Boolean sorts are (predicate) statement of the form T1×... ×Tn

Deﬁnition 5.2. (Multi-sorted Logic) Prova’s multi-sorted logic associates which

each term, predicate and function a particular sort:

(1) Any constant or variable tis a term and its sort Tis given by sort(t)

(2) Let f(t1, .., tn) be a function then it is a term of sort Tn+1 if sort(f) =

hT1, .., Tn, Tn+1i, i.e., ftakes argument of sort T1, .., Tnand returns arguments

in sort Tn+1.

The intuitive meaning is that a predicate or function holds only if each of its

terms is of the respective sort given by sort.

The alphabet of the Prova language builds on top of the standard ISO Prolog

syntax standard, but further extends it. For typing each variable Xjin the multi-

sorted alphabet of the Prova language is associated with a speciﬁc sort sort(Xj) =

Ti, written as Xj:Ti, where Xjis a variable and Tiis a type sort associated with

the variable. That is, the extended Prova language considers external sort/type

alphabets. The combined signatures of the Prova rule language and the external type

languages form the basis for combined hybrid knowledge bases and the integration

of external type systems into the rule system.

Deﬁnition 5.3. (Type alphabet) An external type alphabet Tis a ﬁnite set of

monomorphic sort/type symbols built over the distinct set of terminological class

concepts of a (external type) language.

Deﬁnition 5.4. (Combined Signature) A combined signature Sis the union of

all its constituent ﬁnite signatures: S=hS1∪.. ∪Sni

The type systems considered in Prova are order-sorted (i.e., with sub-type rela-

tions):

Deﬁnition 5.5. (Order-sorted Type System) A ﬁnite order-sorted type system

T S comes with a partial order ≤, i.e., T S under ≤has a greatest lower bound

glb(T1, T2) for any two types T1and T2having a lower bound at all. Since T S is

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 15

ﬁnite also a least upper bound lub(T1, T2) exists for any two types T1and T2having

an upper bound at all.

Deﬁnition 5.6. (Combined Knowledge Base) The combined knowledge base

of a typed Prova K B =hΦ,Ψiconsists of a ﬁnite set of (order-sorted) type systems

/ type knowledge bases Ψ = {Ψ1∩.. ∩Ψn}and a typed Prova KB Φ.

The combined signature is the union of all constituent signatures, i.e., each

interpretation of a Prova rule program has the set of ground terms of the combined

signature as its ﬁxed universe.

Deﬁnition 5.7. (Extended Herbrand Base) Let KB =hΦ,Ψibe a typed com-

bined Prova KB P. The extended Herbrand base of P, denoted B(P), is the set

of all ground literals which can be formed by using the predicate/function symbols

in the combined signature with the ground typed terms in the combined universe

U(P), which is the set of all ground typed terms which can be formed out of the

constants, type and function symbols of the combined signature.

The grounding of the combined KB is computed wrt the composite signature.

Deﬁnition 5.8. (Grounding) Let Pbe a typed (combined) Prova KB and cits set

of constant symbols in the combined signature. The grounding ground(P) consists

of all ground instances of all rules in Pw.r.t to the combined multi-sorted signature

which can be obtained as follows:

•The ground instantiation of a rule ris the collection of all formulae r[X1:

T1/t1, .., Xn:Tn/tn] with X1, .., Xndenoting the variables and T1, .., Tnthe

types of the variables (which must not necessarily be disjoint) which occur in r

and t1, .., tnranging over all constants in cwrt to their types.

•For every explicit query/goal Q[X1:T1, .., Xm:Tm] to the type system, being

either a fact with one or more free typed variables X1:T1, .., Xm:Tmor a

special built-in Prova query literal rdf(...) with variables as arguments in the

triple-like query, the grounding ground(Q) is an instantiation of all variables

with constants (individuals) in caccording to their types.

Using equalities Prova assumes a notion of default inequality for the combined

set of individuals/constants which leads to a default unique name assumption:

Deﬁnition 5.9. (Default Unique Name Assumption) Two ground terms are

assumed to be unequal, unless equality between the terms can be derived.

The interpretation Iof a typed Prova program Pthen is a subset of the extended

Herbrand base B(P).

Deﬁnition 5.10. (Multi-sorted Interpretation) Let KB =hΦ,Ψibe a com-

bined KB and cits set of constant symbols. An interpretation Ifor a multi-sorted

combined signature Sconsists of

December 16, 2011 17:17 Postprint Version RuleResponderReaction

16 Adrian Paschke and Harold Boley

(1) a universe |M|=TI

1∪TI

2∪.. ∪TI

n, which is the union of the types (sorts), and

(2) the predicates, function symbols and constansts/individuals cin the combined

signature, which are interpreted in accordance with their types.

The assignment function σfrom the set of variable Xof Pinto the combined

universe U(P) must respect the sorts/types of the variables (in order-sorted type

systems also subtypes). That is, if Xiis a variable of type T, then σ(X)∈TI.

In general, if φis a typed predicate or function in Φ and σan assignment to the

interpretation I, then I|=φ[σ], i.e., φis true in Iwhen each variable Xof φis

substituted by the values σ(X) wrt to its type. Since the assignment to constant

and function symbols is ﬁxed and the domain of discourse corresponds one-to-one

with the constants cin the combined signature U(P), it is possible to identify an

interpretation Iwith a subset of the extended Herbrand base: I⊆B(P).

The assignment function in Prova is given as a query from the rule component

to the type system, so that there is a separation between the inferences in a type

system and the rule component. Moreover, explicit queries to a type system (Java

or Semantic Web) deﬁned in the body of a rule, e.g., procedural attachments, built-

ins or ontology queries (special rdf query or free DL-typed facts) are based on this

hybrid query mechanism.

Deﬁnition 5.11. (Semantic Multi-Structure Model) Let K B =hΦ,Ψibe a

combined KB of a typed Prova program P.

An interpretation Iis a model of an untyped ground atom A∈KB or Isatisﬁes

A, denoted I|=Aiﬀ A∈I.

Iis a model for a ground typed atom A:T∈KB, or Isatisﬁes A:T, denoted

I|=A:T, iﬀ A:T∈Iand for every typed term ti:Tjin Athe type query

Tj=sort(ti), denoting the type check ”is tiof type Ti”, is entailed in KB, i.e.,

KB |=Ti=sort(ti) (note, in an order sorted type system subtypes are considered,

i.e., tiis of the same or a subtype of Tj).

Iis an interpretation of an ground explicit query/goal Qto the type system Ψ if

Ψ|=Q.

Iis a model of a ground rule r:H←Biﬀ I|=H(r) whenever I|=B(r). Iis a

model a typed program P(respective a combined knowledge base KB), denoted by

I|=P, if I|=rfor all r∈ground(P).

Informally, a typed Prova knowledge base consists of rules with logic program-

ming literals which have typed terms and a set of external (order-sorted) type

systems in which the types (sorts) are deﬁned over their type alphabets. An exter-

nal type system might possibly deﬁne a complete knowledge base with types/sorts

(Java classes or T-Box in DL) and individuals associated with these types (Java

object instances of the classes or A-box in DL). Restricted built-in and procedural

attachment predicates or functions which construct or return individuals of a cer-

tain type (boolean or object-valued) are also considered to be part of the external

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 17

type system(s), i.e., part of the external signature. The combined signature is then

the union of the two (or more) signatures, i.e., the combination of the signature

of the rule component and the signatures of the external type systems / knowl-

edge bases combining their type alphabets, their functions and predicates and their

individuals.

The operational semantics of typed Prova is implemented as hybrid polymor-

phic order-sorted uniﬁcation. P as06bIn contrast to other hybrid (DL-typing) ap-

proaches which apply additional constraint literals as type guards in the rule body

and leave the usual machinery of resolution and uniﬁcation unchanged, the oper-

ational semantics for prescriptive types in Prova’s typed logic is implemented by

an order-sorted uniﬁcation. Here the speciﬁc computations that are performed in

the typed language are intimately related to the types attached to the atomic term

symbols. The order-sorted uniﬁcation yields the term of the two sorts (types) in

the given sort hierarchy. This ensures that type checks apply directly during typed

uniﬁcation of terms at runtime enabling ad-hoc polymorphism of variables leading

e.g., to diﬀerent optimized rule variants and early constrained search trees. Thus,

the order-sorted mechanism provides higher level of abstraction, providing more

compact and complete solutions and avoiding possibly expensive backtracking.

Prova provides support for two external order-sorted type systems, namely Java

class hierarchies and ontological type systems (e.g. OWL or RDFS ontologies) re-

spectively Description Logic knowledge bases.

5.1.1. Description Logic Type Systems / Ontologies

External type systems supported by Prova are Semantic Web ontologies (Descrip-

tion Logic KBs) represented, e.g., in RDFS or OWL. That is, the combined signa-

ture SDL consisting of the ﬁnite signature Sof the rule component and the ﬁnite

signature(s) Siof the ontology language(s).

The type alphabet T S is a ﬁnite set of monomorphic type symbols built over

the distinct set of terminological atomic concepts Tin a Semantic Web ontology

language ΣDL, i.e., deﬁned by the atomic classes in the T-Box model.

Note, that restricting types to atomic concepts is not a real restriction, because

for any complex concept such as (T1uT2) or (T1tT2) one may introduce an atomic

concept T3in the T-Box and use T3as atomic type instead of the complex concept.

This approach is also reasonable from a practical point of view since dynamic type

checking must be computationally eﬃcient in order to be usable in an order-sorted

typed logic with possible very large rule derivation trees and many typed uniﬁcation

steps, i.e., fast type checks are crucial during typed term uniﬁcation. We assume

that the type alphabet is ﬁxed (but arbitrary), i.e., no new terminological concepts

can be introduced in the T-Box by the rules at runtime. This ensure completeness

of the domain and enables static type checking on the used DL-types in Prova

programs at compile time (during parsing the Prova script).

The set of constants/individuals cis built over the set of individual names in

December 16, 2011 17:17 Postprint Version RuleResponderReaction

18 Adrian Paschke and Harold Boley

ΣDL, but we do not ﬁx the constant names and allow arbitrary fresh constants

(individuals) (under default UNA) to be introduced in the head of rules and facts

of the rule base. However, new individuals which are introduced in rules or facts

apply locally within the scope of the rules in which they are deﬁned, i.e., within a

local reasoning chain; in contrast to the individuals deﬁned in the A-box model of

the type system which apply globally as individuals of a class. DL-typed terms in

Prova are deﬁned as follows:

Deﬁnition 5.12. (DL-typed Terms) A DL-type is a terminological concept/class

deﬁned in the DL-type system (T-Box model). A typed DL-typed Prova term is

denoted by the relation t:Twhere tis the term and Tis the DL-type of term.

The type ontologies are typically provided as Web ontologies (RDFS or OWL)

where types and individuals are represented as resources having an webized URI.

Namespaces can be used to avoid name conﬂicts and namespace abbreviations fa-

cilitate a more readable language.

% A customer gets 10 percent discount, if the customer is a gold customer

discount(X^^business:Customer, 10^^math:Percentage) :-

gold(X^^business:Customer).

% fact with free typed variable acts as instance query on the ontology A-box

gold(X^^business:Customer).

Free DL-typed variables are allowed in facts. They act as free instance queries

on the ontology layer, i.e., they query all individuals of the given type and bind

them to the typed variable.

5.1.2. Java Type System, Procedural Attachments and Built-Ins

For external Java type systems, the combined multi-sorted signature SJ ava uses the

fully qualiﬁed order-sorted Java class hierarchy as type symbols. In order to type

a variable with a Java type the fully qualiﬁed name of the Java class to which the

variable should belong must be speciﬁed as a preﬁx separated from the variable by

a dot ”.”.

java.lang.Integer.X variable X is of type Integer

java.util.Calendar.T variable T is of type Calendar

java.sql.Types.STRUCT.S variable S is of SQL type Struct

To sense the environment and trigger actions, query data from external sources

such as databases, call external procedural code such as Enterprise Java Beans, and

receive / send messages from / to other agents or external services, Prova provides

a set of built-in functions and additionally can dynamically instantiate any Java

object and call its API methods at runtime.

Java objects, as instances of Java classes, can be dynamically constructed by

calling their constructors or static methods using extra logical procedural attach-

ments. The returned objects, might then be used as individuals/constants that are

bound by an equality relation (denoting typed uniﬁcation equality) to appropriate

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 19

variables, i.e., the variables must be of the same type or of a super type of the Java

object.

A procedural attachment is a function that is implemented by an external pro-

cedure (i.e., a Java method). They are used in Prova to dynamically call external

procedural methods during runtime, i.e., they enable the (re)use of procedural code

and allow dynamic access to external data sources and tools using their program-

ming interfaces (APIs). Hence, in particular for Rule Responder agents, they are a

crucial extension to traditional logic programming, combining the beneﬁts of object-

oriented languages (Java) with declarative rule based programming, e.g., in order

to externalize mathematical computations such as aggregations to highly optimized

procedural code in Java or use query languages such as SQL by JDBC to select and

aggregate facts from external data sources.

Deﬁnition 5.13. (Procedural Attachments) A procedural attachment is a func-

tion or predicate whose implementation is given by an external procedure. Two types

of procedural attachments are distinguished:

•Boolean-valued attachments (or predicate attachments) which call

methods which return a Boolean value, i.e., which are of Boolean sort (type).

•Object-valued attachments (or functional attachments) which are

treated as functions that take arguments and return one or more objects, i.e.,

which are of a function sort.

Functional Java attachments have a left-hand side with which the results (the

returned object(s)) of the call are uniﬁed by a uniﬁcation equality relation =, e.g.,

C=java.util.Calendar.getI nstance(). If the left-hand side is a free (unassigned)

variable the latter stores the result of the invocation. If the left-hand side is a

bound variable or a list pattern the uniﬁcation can succeed or fail according to the

typed uniﬁcation and consequently the call itself can succeed or fail. List structures

are used on the left-hand side to allow matching of sets of constructed/returned

objects to speciﬁed list patterns. A predicate attachment is assumed to be a test

in such a way that the call succeeds only if a true Boolean variable is returned.

Static, instance and constructor calls are supported in both predicate and func-

tional attachments depending on their return type. Constructor calls follow the

Java syntax with the fully qualiﬁed name of the class and the constructor argu-

ments, e.g., X=java.lang.Long(123). Static method calls require fully qualiﬁed

class names to appear before the name of the static method followed by arguments,

e.g., Z=java.lang.M ath.min(X, Y ). Instance methods are mapped to concrete

classes dynamically based on the type of the variable, i.e., the method of a previ-

ously bound Java object is called. They require a variable before the name of an

instance method followed by the arguments, e.g., S=X.toString().

add(java.lang.Integer.In1,java.lang.Integer.In2,Result):-

Result = java.lang.Integer.In1 + java.lang.Integer.In2.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

20 Adrian Paschke and Harold Boley

The rule takes two Integer variables In1 and I n2 as input and returns the

result which is bound to the untyped variable Result. Accordingly, a query

add(1,1, Result)? succeeds with an Integer object 2 bound to the Result variable,

while a query add(”abc”,”def”, Result)? will fail.

It is important to note, that Java objects can be bound to variables and their

methods can be dynamically used as procedural attachment functions anywhere

during the reasoning process, i.e., in other rules. This enables a tight and highly

expressive integration of external object oriented functions into declarative agent’s

rules’ execution.

Deﬁnition 5.14. (Built-in Predicates or Functions) Built-in predicates or

functions (built-ins) are special restricted procedural attachment predicate respec-

tive function symbols in the Prova language for concrete domains, e.g., integers or

strings, that may occur in the body of a rules.

Examples are +, =, assert,bound,f ree etc. For instance, Prova provides a rich

library of built-ins for query languages such as SQL, SPARQL, and XQuery:

File Input / Output

..., fopen(File,Reader), ...

XML (DOM)

document(DomTree,DocumentReader) :- XML(DocumenReader),...

SQL

... ,sql_select(DB,cla,[pdb_id,"1alx"],[px,Domain]).

RDF

...,rdf(http://...,"rdfs",Subject,"rdf_type","gene1_Gene"),...

XQuery

..., XQuery = ’for $name in StatisticsURL//Author[0]/@name/text()

return $name’, xquery_select(XQuery,name(ExpertName)),...

SPARQL

...,sparql_select(SparqlQuery,...

The following rule uses a SPARQL query built-in to access an RDF Friend-of-

a-Friend (FOAF) proﬁle published on the Web. The selected data is assigned to

variables which can be used within an agent’s rule logic, e.g. to expose the agent’s

contact data.

exampleSPARQLQuery(URL,Type) :-

QueryString = ’ PREFIX foaf:

PREFIX rdf:

SELECT ?contributor ?url ?type

FROM

WHERE {

?contributor foaf:name "Bob DuCharme" .

?contributor foaf:weblog ?url .

?contributor rdf:type ?type . } ’,

sparql_select(QueryString,url(URL),type(Type)).

Note, that the structures in Java type systems are usually not considered as in-

terpretations in the strict model-theoretic deﬁnition, but are composite structures

involving several diﬀerent structures whose elements have a certain inner compo-

sition. However, transformations of composite structures into their ﬂat model the-

oretic presentations is in the majority of cases possible. From a practical point of

view, it is convenient to neglect the inner composition of the elements of the uni-

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 21

verse of a structure. These elements are just considered as ”abstract” points devoid

of any inherent meaning. This structural mapping between objects from their inter-

pretations in the Java universe to their interpretation in the rule system ignoring

ﬁner-grained diﬀerences that might arise from the respective deﬁnitions is given by

the following isomorphism.

Deﬁnition 5.15. (Isomorphism) Let I1,I2be two interpretations of the combined

signature S={T1, .., Tn}, then f∼

=:|M1| → |M2|is an isomorphism of I1and I2if

f∼

=is a one-to-one mapping from the universe |M1|of I1onto the universe |M2|of

I2such that:

(1) For every type Ti,t∈TI1

i, iﬀ f∼

=(t)∈TI2

(2) For every constant c,f∼

=(cI1)∼

=cI2

(3) For every n-ary predicate symbol pwith n-tuple t1, .., tn∈ |M1|,ht1, .., tni ∈ pI1

iﬀ hf∼

=(t1), .., f∼

=(tn)i ∈ pI2

(4) For every n-ary function symbol fwith n-tuple t1, .., tn,∈ |M1|,

f∼

=(fI1(t1, .., tn)) ∼

=fI2(f∼

=(t1), .., f∼

=(tn))

For instance, in Prova an isomorphism between Boolean Java objects and their

model-theoretic truth value is deﬁned, which makes it possible to treat boolean-

valued procedural attachments as conditional body literals in rules and establish

a model-theoretic interpretation as deﬁned above between the Java type system

and the model-theoretic semantics of the typed logic of the rule component. Other

examples are String objects which are treated as standard constants in rules, i.e., the

Java String object maps with the untyped theory of logic programming. Primitive

datatype values, from the ontology respective XML domain (XSD datatypes) can

be mapped similarly.

5.1.3. Example - Responsibility Assignment Matrix Ontology for Agent

Coordination

As one possible way for coordination in a virtual organization the Rule Responder

framework uses a ‘pluggable’ Responsibility Assignment Matrix (RAM) ontology

to support the OA in its selection of a PA and its optional participating proﬁles

underneath. A RAM describes the responsibility of agent roles in completing certain

tasks or deliverables in a virtual organization. A standard RAM is a RACI matrix

(Responsible, Accountable, Consulted, and Informed), with

•Responsible – agents who do the work to achieve the task. There is typically one

role with a participation type of Responsible, although others can be delegated

to assist in the work required. Typically, the PAs are the responsible roles.

•Accountable (also Approver or ﬁnal Approving authority) – agent who is ulti-

mately accountable for the correct and thorough completion of the deliverable

or task, and the one to whom Responsible is accountable. Typically, this is

December 16, 2011 17:17 Postprint Version RuleResponderReaction

22 Adrian Paschke and Harold Boley

the OA which receives the answer from the PA and further processes it before

forwarding it to the EA.

•Informed – the agent who is kept up-to-date on progress, often only on com-

pletion of the task or deliverable; and with whom there is just one-way com-

munication. Typically, this is the EA who is informed about the result by the

OA.

In a simple star-like Rule Responder agent topology, a single RAI matrix can

be used in the OA to map an incoming query to the PA whose local knowledge

base is deemed to be best suited for answering it. The RAI matrix is represented

as an OWL ontology (OWL Lite) and can be used by a Rule Responder agent via

querying it with the Semantic Web built-ins of Prova, binding the respective roles

and their responsibilities to typed variables in the agent’s rule logic. For instance,

the following returns an agent’s responsibility and role in a virtual organization by

querying the concrete values from the imported RAM matrix (an OWL document)

using the special Prova RDF query built-in (a simple RDF triple query instead of

the more complex Prova SPARQL query built-in).

assigned(Agent,Responsibility,Role) :-

rdf("http://www.csw.inf.fu-berlin.de/agents/ram.owl","owl",Agent,Role,Responsibility).

Many variants of the RAM with diﬀerent role distinctions are possible such as

RACI (with Consulted agents), RASCI (with Supporting agents) etc. - see, e.g.,

table 1.

Table 1. Responsibility Assignment Matrix

General Chair Program Chair Publicity Chair

Symposium responsible consulted supportive

Website accountable responsible

Sponsoring informed, signs veriﬁes responsible

Submission informed responsible

... ... ... ...

While RAMs (RACI matrix, Linear Responsibility Charts, etc.) are often used

to represent stable semiotic structures of virtual organizations, where responsibil-

ities are clearly deﬁned for each role, it should be noted that Prova OAs can also

implement other well-known agent coordination and negotiation mechanisms.

5.2. Modularization, Scopes and Guards

Modularization is another important concept for a virtual collaboration of indepen-

dent agents, since each agents might play multiple roles in the same organization.

Prova supports modularization of the agents knowledge base in order to implement

the several diﬀerent roles an agent might play in the same agent instance. Each role

has its own set of reaction rules to autonomously react (potentially proactive) on

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 23

detected situations (complex events) and its own set of decision rules to interpret

goals and derive decisions according to conditional proofs. Moreover, modularization

of the agent’s KB makes it easier to maintain.

5.2.1. Metadata Based Modularization and Module Imports/Updates

Prova has a ﬂexible approach towards modularization of the knowledge base which

allows constructing metadata based views on the knowledge base, so called scopes.

Therefore, Prova extends the rule language to a labelled logic programming rule

language (LLP) with metadata annotations such as rule labels, module (rule sets

in rule bases) labels and arbitrary other (Semantic Web) annotations (e.g., Dublin

Core author, date etc). These metadata annotations are used to manage the rules

and facts in the knowledge base.

In analogy to the multi-sorted extension for types, the meta-data extension of

the Prova language is deﬁned over a combined signature Swhich is the union of the

signature of the rule language and the signatures of the used metadata vocabularies

(e.g. Dublin Core).

Deﬁnition 5.16. (Combined Signature with Metadata Annotations) The

combined metadata annotated signature Sis deﬁned as a tuple hT , P ,F , arity , c,

sort, metaiwhere Pis the union of the predicate symbols deﬁned in the signature

of the core Prova rule language and the metadata predicate symbols (denoting

metadata key properties) deﬁned in the signature(s) of the metadata vocabularie(s)

and cis the union of constant symbols deﬁned in the rule signature and in the

metadata signature(s) (denoting metadata values). meta is a special unary function

which returns the assigned metadata.

To explicitly annotate clauses in a Prova program Pwith an additional set

of metadata labels a general 1-ary built-in function @ is introduced in the Prova

language.

Deﬁnition 5.17. (Metadata Annotation Labels) The special 1-ary built-in

function @ is a partial injective labelling function that assigns a set of metadata

annotations m(property-value pairs) to a clause cl in P, e.g.

@(L1), .., @(Ln)H:−B

where Liare a ﬁnite set of unary positive literals (positive metadata literals)

which denote an arbitrary metadata property(value) pair, e.g., @label(rule1).

The implicit form @(L1), .., @(Ln)H:−Bof the metadata function expresses

that @(H:−B) = L1, .., Ln. The explicit @() annotation is optional, i.e., a Prova

program Pwithout metadata annotated clauses coincides with a standard unla-

belled logic program.

Clauses in Prova are treated as objects in KB having an unique object id (oid )

which might be user-deﬁned, i.e., explicitly deﬁned by a metadata annotation

@label(oid)H:−Bor system-deﬁned i.e., all rules are automatically ”labelled”

December 16, 2011 17:17 Postprint Version RuleResponderReaction

24 Adrian Paschke and Harold Boley

with an auto-incremented oid (an increasing natural number) provided by the sys-

tem at compile time. Rules and facts might be bundled to clause sets, so called

modules, which also have an object id, the module oid. By default the module oid

is the URI or full document name of the Prova script which deﬁnes the module.

But the module oid might also be user-deﬁned @src(moduleoid). All clauses (rules

and facts) deﬁned in a module are automatically annotated with the module oid

@src(moduleoid)H:−B. The oids are used to manage the knowledge in the (dis-

tributed) knowledge base, e.g., to import a rule set from an URI which is then used

as the module oid or remove a module from the KB by its oid. Beside oids arbitrary

other semantic annotations such as Dublin Core data might be speciﬁed in the @

annotation function.

@label(r1) @dc:author("Adrian") @dc:date(2006-11-12)

p(X):-q(X).

@label(f1)

q(1).

The example shows a rule with rule label r1 and two additional Dublin Core

annotations dc :author(”Adrian”) and dc :date(2006−11−12) and a fact with fact

label f1. Since there is no explicitly user-deﬁned module oid in the meta-data labels,

the default module oid for both clauses is the URI or document name of the Prova

script in which they are deﬁned, e.g. @src(”http ://prova.ws/example1.prova”).

In Prova it is possible to consult (import/load) distributed rulebases from local

ﬁles, a Web address, or from incoming messages transporting a rulebase. Further-

more, Prova supports update built-ins such as assert and retract.

%load from a local file

:- eval(consult("organization2009.prova")).

% import from a Web address

:- eval(consult("http://ruleml.org/organization2010.prova")).

The imported rulebases are managed as modules in the knowledge base, which

are uniquely identiﬁed by their source object id src(moduleOI D). Since multiple

nested imports are possible, modules might be nested, i.e. a module denoting a rule

base (e.g. a Prova script) might consist of several nested submodules (e.g. sets of

rules and facts).

Similar to imports of external type systems and built-ins (procedural attach-

ments) which query and compute external data, the semantics for modules in Prova

is deﬁned over the combined knowledge base of the modules, an extended state

based Herbrand Base and semantic multi-structures.

Deﬁnition 5.18. (Combined Knowledge Base) The combined knowledge base

of a modular Prova KB =hΦ,Ψiconsists of a ﬁnite set of modules Ψ = {Ψ1∩..∩Ψn}

and an initial primary Prova KB Φ.

Prova supports knowledge updates which import modules (consult) and add or

remove clauses (assert,retract). Each update leads to a new knowledge state of the

combined KB.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 25

Deﬁnition 5.19. (Knowledge State) A knowledge state represents the combined

knowledge base KBkat this particular state, where k∈ ℵ.

Note that according to the modularized logic in Prova a state, i.e., a combined

knowledge base KBk, might consist of nested submodules, each having an unique

ID (the module oid). Intuitively, a state represents the union of all clauses stored

in all modules in the combined knowledge base.

An update is then a transition which adds or removes facts and/or rules and

changes the knowledge base. That is, the KB transits from the initial state KB1

to a new state KB2. We deﬁne the following notion of positive (assert) and nega-

tive(retract) transition:

Deﬁnition 5.20. (Positive Update Transition) A positive update transition,

or simply positive update, to a knowledge state KBkis deﬁned as a ﬁnite set

Upos

oid := {rN:H:−B, f actM:A}with Aan atom denoting a fact, H:−Ba

rule, N= 0, .., n and M= 0, ..m and oid being the update oid which is also used as

module oid to manage the knowledge as a new module in the KB. Applying Upos

oid to

KBkleads to the extended state K Bk+1 ={K Bk∪Upos

oid }. Applying several positive

updates as an increasing ﬁnite sequence Upos

oidjwith j= 0, .., k and Upos

oid0:= ∅to

KB0leads to a state K Bk={K B0∪Upos

oid0∪Upos

oid1∪... ∪Upos

oidk}.

That is a state KBkis decomposable in the previous knowledge state k−1

plus the update: KBk={KBk−1∪Upos

k}. We deﬁne K B0={∅ ∪ Upos

oid0}and

Upos

oid0={KB : the set of rules and facts deﬁned in the program P}, i.e., importing

the initial Prova program Pfrom a Prova script document is the ﬁrst update leading

to the knowledge state KB1.

Likewise, We deﬁne a negative update transition as follows:

Deﬁnition 5.21. (Negative Update Transition) A negative update transition,

or for short a negative update, to a knowledge state KBkis a ﬁnite set Uneg

oid :=

{rN:H:−B, f actM:A}with A∈KBk,H:−B∈P,N= 0, .., n and M= 0, ..m,

which is removed from K Bk, leading to the reduced program KBk+1 ={KBk\

Uneg

oid }.

Applying arbitrary sequences of positive and negative updates leads to a se-

quence of KB states KB0, .., K Bkwhere each state KBiis deﬁned by either

KBi=K Bi−1∪Upos

oidior KBi=K Bi−1\Uneg

oidi. In other words, KBi, i.e., the

set of all clauses in the KB at a particular knowledge state i, is decomposable in the

previous knowledge state plus/minus an update, whereas the previous state consists

of the state i−2 plus/minus an update and so on. Hence, each particular knowl-

edge state can be decomposed in the initial state K B0and a sequence of updates.

Although an update might insert more than one rule or fact, i.e., insert or remove

a complete module, it is nevertheless treated as an elementary update, a so called

bulk update, which transits the current knowledge state to the next state in an

elementary transition: hKBi, U pos/neg

oid , KBk+1 i. Intuitively, one might think of it

December 16, 2011 17:17 Postprint Version RuleResponderReaction

26 Adrian Paschke and Harold Boley

as a complex atomic update action which performs all knowledge inserts respective

removes simultaneously.

Elementary updates have both a truth value, i.e. they may succeed or fail, and

a side eﬀect on the knowledge base leading to the transition of the knowledge state.

The extended Herbrand Base is deﬁned on the notion of knowledge states and

transitions from one state to another.

Deﬁnition 5.22. (Extended State-Based Herbrand Base) Let Pbe the com-

bined KB at a particular knowledge state KBk. The extended Herbrand base of P,

denoted B(P), is the set of all ground literals which can be formed by using the

predicate/function symbols in the combined signature with the ground typed terms

in the combined universe U(P), which is the set of all ground typed terms which

can be formed out of the constants, type and function symbols of the combined

signature of KBk.

Deﬁnition 5.23. (Modular semantic multi-structure) A modular multi-

structure Iis the model of a modular program P(respective the knowledge state

KBkof the combined knowledge base KB), denoted by I|=P, if I|=cfor all

clauses c∈ground(P), where I|=cis a usual multi-sorted model for providing the

interpretation of Prova clauses.

Accordingly, all queries to a Prova program apply on the extended respective

reduced transition knowledge state of the program, i.e., the truth valuation of a

goal Gdepends on its model at the current knowledge state KBk, denoted by

T V alKBk|=G(G).

Based on this modular knowledge state transition semantics and the metadata

based control of the knowledge state updates which are treated as modules in the

combined KB, Prova provides supports for transactional updates, where failing se-

quences of knowledge updates can be rolled back by removing the associated mod-

ules from the combined Prova KB. P as06aIn the non-transactional style update

action within (serial) Prova rules are not rolled-back to the original state if the

derivation fails and the system backtracks. Typically this ”weak” non-transactional

semantics is intended when external Prova scripts are imported (consult) or new

rule sets are added (assert) as modules. That is, independently, of whether the

particular derivation in which the update is performed fails from some reason the

update transition to the next knowledge state subsists and is not rolled back in case

of failures.

5.2.2. Scoped Reasoning

The metadata annotation of rules/facts and rule sets (modules) enables scoped

(meta) reasoning with the semantic annotations. The metadata can act as an explicit

scope for constructive queries (creating a view) on the knowledge base. For instance,

the metadata annotations might be used to constrain the level of generality of a

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 27

scoped goal literal to a particular module, i.e., to consider only the set of rules and

facts which belong to the speciﬁed module.

Deﬁnition 5.24. (Scoped Literal) A scoped literal is of the form @C L where

Lis a positive or negative literal and @Cis the scope deﬁnition which is a set of

one or more metadata constraints. Scoped literals are only allowed in the body of

a rule.

Informally, the semantics of scoped literals allows to explicitly close the domain

of discourse to certain parts of the KB.

Deﬁnition 5.25. (Metadata-based Scope) Let KB be a combined KB consist-

ing of a set of submodules KB ={KB1∪.. ∪KBk}. The scope KB0of a scoped

literal @C L is the set of clauses K B0={m0

1cl1, .., m0

ncln} ∈ KB, where for all

clauses cli(m0

i)∈KB0its set of metadata annotations m0

isatisfy the scope con-

straints Cof the scoped literal L, i.e., m0

i|=C.

Accordingly, a scope (aka constructive view) is constructed by one or more

metadata constraints, e.g., the module oid @src(U RI /F ilename) or Dublin Core

values @dc :author(...).

Deﬁnition 5.26. (Closure) Let K B be a combined KB. The closure of KB,

denoted Cl(KB), is deﬁned by KB plus all modules KBkwhich are in the scope

of any scoped literal in KB.

A scoped literal @C L is closed if each rule in KB which uniﬁes with the literal

Lis also closed, i.e., its body literals are closed in Cl(K B).

Intuitively, this means that the closure of a Prova program depends on the scopes

of the literals in the bodies of its rules. Obviously, if one of the subsequently used

goal literals in a proof attempt is open, i.e., without a scope, the closure expands

to the open KB.

Deﬁnition 5.27. (Scoped Semantics) Given a scoped KB0, where all literals

are scoped with closure Cl(KB0), the truth value of a scoped literal @C L de-

pends on the partial model of the clauses of K B0wrt the scope deﬁnition C, i.e.,

IpartialC(KB0)|=L.

Syntactically the scope deﬁnitions use the syntax of Prova metadata annotations.

@label(rule1) r1(X):-q(X).

@label(rule2) r1(X):-q(X).

@label(rule3) p1(X):-

@label(rule1) r1(X). % scoped goal literal

q(1).

:-solve(p1(Y)).

The example shows three metadata annotated rules. They query p1(Y) will

return only one solution with Y= 1, since the subgoal r1(X) of rule3 applies only

December 16, 2011 17:17 Postprint Version RuleResponderReaction

28 Adrian Paschke and Harold Boley

in the scope of the rule with label rule1, but not on rule1 and rule2, which would

be the case if there would be no scope constraint deﬁned for the subgoal.

Prova allows variables in the scope deﬁnitions which are bound to the annotated

metadata values. The following example shows the deﬁnition of a scope, that con-

straints the application of the subgoal r2(X) on the rule with label rule3 and on

the module with source name AgentRole1.prova.

% get module label

r1(X,Y):-

@src(Y) @label(rule3)

r2(X).

:-solve(r1(X,"AgentRole1.prova")).

5.2.3. Guards

In addition to scopes Prova supports literal guards which act as additional pre-

condition constraints.

Guards in Prova are syntactically speciﬁed in the Prova rule language using

brackets after the goal literal. The model-theoretic semantics of guards is like for

goal literals, however in the proof-theoretic semantics guards act like pre-conditions

before the proofs of the standard goal literals starts.

For instance, the following rule makes decisions on the basis of rules which

haven been authored by diﬀerent persons and only applies those rules from trusted

authors.

%simplified decision rules of an agent

@author(dev22) r2(X):-q(X).

@author(dev32) r2(X):-s(X).

q(2).

s(-2).

% for simplicity this is a fact, but could be also a complex rule

% which computes the trust value from the reputation value of dev22

trusted(dev22).

% Author dev22 is trusted but dev32 is not, so one solution is found: X=2

p1(X):-

@author(A)

r2(X) [trusted(A)].

% for all query

:-solve(p1(X1)).

This example uses metadata annotations on rules for the head literals r2 and a

scope on the literal r2(X) in the body of the rule for p1(X). Since variable Ain

@author(A) is initially free, it gets instantiated from the matching target rule(s).

Once Ais instantiated to the target rule’s @author annotation’s value (dev22,

for the ﬁrst r2 rule), the body of the target rule is dynamically non-destructively

modiﬁed to include all the literals in the additional guard trusted(A) before the

body start, after which the processing continues. Since trusted(dev22) is true but

trusted(dev32) is not, only the ﬁrst rule for predicate r2 is used and so one solution

X1 = 2 is returned by solve(p1(X1)).

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 29

5.3. Prova Serial Horn Rules for Messaging

For communication between distributed agents Prova supports special built-ins for

asynchronously sending and receiving event messages within serial Horn rules. The

main language constructs of messaging reaction rules are: sendMsg predicates to

send messages, reaction rcvMsg rules which react to inbound messages, and rcvMsg

or rcvMult inline reactions in the body of messaging reaction rules to receive one

or more context-dependent multiple inbound event messages:

sendMsg(XID,Protocol,Agent,Performative,Payload |Context)

rcvMsg(XID,Protocol,From,Performative,Paylod|Context)

rcvMult(XID,Protocol,From,Performative,Paylod|Context)

Here, XID is the conversation identiﬁer (conversation-id) of the conversation

to which the message will belong. Protocol deﬁnes the transport protocol. Agent

denotes the target party of the message. Performative describes the pragmatic en-

velope for the message content. A standard nomenclature of performatives is, e.g.,

the FIPA Agents Communication Language (ACL). Payload represents the mes-

sage content sent in the message envelope. It can be a speciﬁc query or answer or a

complex interchanged rule base (set of rules and facts). For instance, the following

rule snippet shows how a query is sent to an agent via the ESB and then an answer

is received from this agent.

...

sendMsg(Sub_CID,esb,Agent,acl:query-ref, Query),

rcvMsg(Sub_CID,esb,Agent,acl:inform-ref, Answer),

...

Prova does not deﬁne a speciﬁc set of mentalistic notions as ﬁrst-class pro-

gramming constructs. Instead, interchanged messages besides the conversation’s

metadata and payload also carry the pragmatic context of the conversation such

as communicative situations / acts, mentalistic notions, organizational and indi-

vidual norms, purposes or individual goals and values. The payload of incoming

event messages is interpreted with respect to the local conversation state, which

is denoted by the conversation id, and the pragmatic context, which is given by a

pragmatic performative. For instance, a standard nomenclature of pragmatic per-

formatives, which can be integrated as external (semantic) vocabulary/ontology, is

e.g., deﬁned by the Knowledge Query Manipulation Language (KQML) F LM 97, by

the FIPA Agent Communication Language (ACL) i, which gives several speech act

theory-based communicative acts, or by the Deontic Logic with its normative con-

cepts for obligations, permissions, and prohibitions. Depending on the pragmatic

context, the message payload is used, e.g. to update the internal knowledge of the

agent (e.g., add new facts or rulebases), add new tasks (goals), or detect a complex

event pattern (from the internal event instance sequence). For instance, the follow-

ing example shows a reaction rule that sends a complete rule base, which is loaded

from a local File to an agent service Remote using JMS as transport protocol.

ihttp://www.ﬁpa.org/repository/aclspecs.html

December 16, 2011 17:17 Postprint Version RuleResponderReaction

30 Adrian Paschke and Harold Boley

Example 5.1.

% Upload a rule base read from File to the host

% at address Remote via JMS

upload_mobile_code(Remote,File) :-

% Opening a file returns an instance

% of java.io.BufferedReader in Reader

fopen(File,Reader),

Writer = java.io.StringWriter(),

copy(Reader,Writer),

Text = Writer.toString(),

% variable SB will encapsulate the whole content of File

SB = StringBuffer(Text),

% send the complete rule base to the receiver agent "Remote"

sendMsg(XID,jms,Remote,acl:inform,consult(SB)).

The corresponding receiving reaction rule of the remote agent is:

% wait for incoming messages with pragmatic context $acl:inform$

rcvMsg(XID,jms,Sender,acl:inform,[Predicate|Args]):-

% derive the message payload, i.e. consult the received rule set to the internal KB

derive([Predicate|Args]).

This rule receives incoming JMS-based messages with the pragmatic context

acl :inform and derives the message content, i.e. consults the received rule base

to the local knowledge base of the remote agent. It is important to note that via

the conversation id several reaction rule reasoning processes might run in parallel,

local to their conversation ﬂows. Inactive reactions (conversation partitions) are

removed from the system, e.g. by timeouts. Self-activations by sending a message

to the receiver ”self” are possible. With the pragmatic performatives it is possible

to implement diﬀerent coordination and negotiation protocols. For instance, if an

agent does not understand the semantics of the interchanged message payload, it can

inform the sender about this, using, e.g., the acl :not −understood performative,

so that the sender can additionally send the semantic information, e.g. a pointer to

the ontology that deﬁnes the concepts of the payload, and the receiving agent can

import this ontology to its internal knowledge base.

For implementing the Rule Responder communication ﬂows in the OAs, Prova

messaging reaction rules are used. A typical coordination pattern implemented in a

Rule Responder OA is the following messaging reaction rule (Prova variables start

with an upper-case letter), which waits for an incoming query from an EA and

delegates this query to an internal responsible PA.

% receive query and delegate it to another party

rcvMsg(CID,esb, Requester, acl:query-ref, Query) :-

responsibleRole(Agent, Query),

sendMsg(Sub-CID,esb,Agent,acl:query-ref, Query),

rcvMsg(Sub-CID,esb,Agent,acl:inform-ref, Answer),

... (other goals)...

sendMsg(CID,esb,Requester,acl:inform-ref,Answer).

When activated by an incoming request from an EA, e.g. an HTTP request

coming from a Web form, this messaging reaction rule ﬁrst selects the responsible

role for the query. Then the rule sends the query in a new sub-conversation to the

selected party and waits for the answer to the query. That is, the rule execution waits

until an answer event message is received in the inlined sub-conversation, which

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 31

activates the process ﬂow again, e.g. to prove further ‘standard’ goals, e.g. with

information from the received answer, which is uniﬁed with variables in the normal

logic programming way, including also backtracking to other variable assignments.

Finally, in this example, the rule sends back the answer to the original requesting

EA.

Remarkably, Prova’s messaging reaction rules do not require separate threads for

handling multiple conversation situations simultaneously. Hence, new subconversa-

tions can be started with other PAs in parallel. This can be used for implementing,

e.g., a Contract Net coordination protocol, where PAs bid for the task oﬀered by

the OA and the OA selects the best PA according to the received bids, or a publish-

subscribe protocol, where PAs are selected according to their subscriptions with the

OA.

By using messaging reaction rules Prova can be deployed as a distributed rule

inference service in a Rule Responder agent, or e.g. as an OSGi jcomponent enabling

massive parallelization of Prova agent nodes in grid/cloud environments and (smart)

devices (e.g. RFID networks) which communicate via event messages.

Several other expressive logic formalisms are supported by Prova P as07, e.g., for

updating the knowledge base (transactional update logic), deﬁning and detecting

complex events (complex event algebra), handling situations/states (event calculus),

as well as for reasoning (e.g., deontic logic for normative reasoning on permissions,

prohibitions, obligations) and planning (abductive reasoning on plans and goals).

In summary, Prova agents can interchange event information, rules (tasks), and

queries/answers in agent conversations, including information about the semantics

and pragmatics of the interchanged information.

6. Recent Rule Responder Instantiations

Early instantiations of Rule Responder include the Health Care and Life Sciences

eScience infrastructure P as08, the Rule-based IT Service Level Managment, and

Semantic BPM system P B08,P K08 . Recent instantiations include multiple versions

of the deployed SymposiumPlanner system CB08 , two versions of the WellnessRules

prototype BOC 09, and PatientSupporter. We will here highlight the principles of

Rule Responder instantiations with an emphasis on the recent ones.

6.1. SymposiumPlanner

SymposiumPlanner is a series of deployed applications created with Rule Responder

for the Q&A parts of the oﬃcial websites of the RuleML Symposia.

Rule Responder started to support the organizing committee of the RuleML-

2007 Symposium Cra07 and was further developed to assist the yearly RuleML

Symposia since. These applications embody responsibility assignment, automated

jOpen Services Gateway initiative standard

December 16, 2011 17:17 Postprint Version RuleResponderReaction

32 Adrian Paschke and Harold Boley

ﬁrst-level contacts for information regarding the symposium, helping the publicity

chair with sponsoring correspondence, helping the panel chair with managing panel

participants, and the liason chair with coordinating organization partners.

SymposiumPlanner utilizes a single organizational agent to handle the ﬁltering

and delegation of incoming queries. Each committee chair has a personal agent that

acts in a rule-governed manner on behalf of the committee member. Each agent

manages personal information, such as a FOAF-like proﬁle containing a layer of

facts about the committee member as well as FOAF-extending rules. These rules

allow the PA to automatically respond to requests concerning the RuleML Sym-

posium. Task responsibility for the organization is currently managed through a

responsibility matrix, which deﬁnes the tasks committee members are responsible

for. The matrix and the roles assigned within the virtual organization are deﬁned

by an OWL (Ontology Web Language) Lite Ontology.

External agents and the RuleML-2008 agents can communicate by sending mes-

sages that transport queries, answers, or complete rulebases through the public

interface of the OA (e.g., an EA can use an HTTP port to which post and get

requests can be sent from a Web form).

The Rule Responder instantation to SymposiumPlanner is further described and

demonstrated online.k

6.2. WellnessRules

WellnessRules is a system supporting the management of wellness practices within

a community based on rules plus ontologies. The idea is the following. As in Friend

of a Friend (FOAF)l, people can choose a (community-unique) nickname and create

semantic proﬁles about themselves, here about their wellness practices, for their own

planning and to network with other people supported by a system that ‘understands’

those proﬁles. As in FindXpRT LB BM 06 , such FOAF-like fact-only proﬁles are ex-

tended with rules to capture conditional person-centered knowledge such as each

person’s wellness activity depending on the season, the time-of-day, the weather,

etc. People can use rules of various reﬁnement levels and rule languages ranging

from pure Prolog to N3, which will be interoperated through RuleML/XML Bol07 .

Interoperating with translators, WellnessRules thus frees participants from using

any single rule language. In particular, it bridges between Prolog as the main Logic

Programming rule paradigm and N3 as the main Semantic Web rule paradigm. The

distributed nature of Rule Responder proﬁles, each queried by its own (copy of an)

engine, permits scalable knowledge representation and processing.

WellnessRules has recently been developed to WellnessRules2, using a new kind

of agents, a Service Agent (SA), for accessing Google weather data. From the point

khttp://ruleml.org/SymposiumPlanner

lhttp://www.foaf-project.org/

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 33

of the OA, an SA can be queried similarly to a PA. However, while a PA is a personal

assistant to a human owner, an SA is just a machine agent, in WellnessRules2 acting

as a wrapper for a (Web) service.

The Rule Responder instantations to WellnessRules are further described and

demoed online.m

6.3. PatientSupporter

Patients are increasingly seeking interaction in support groups, which provide shared

information and experience about diagnoses, treatment, etc. We present a Social Se-

mantic Web prototype, PatientSupporter, that will enable such networking between

patients within a virtual organization. PatientSupporter is an instantiation of Rule

Responder that permits each patient to query other patients’ proﬁles for ﬁnding or

initiating a matching group.

Rule Responder’s External Agent (EA) is a Web-based patient-organization in-

terface that passes queries to the Organizational Agent (OA). The OA represents

the common knowledge of the virtual patient organization, delegates queries to rele-

vant Personal Agents (PAs), and hands validated PA answers back to the EA. Each

PA represents the medical subarea of primary interest to a corresponding patient

group. The PA assists its patients by advertising their interest proﬁles employing

rules about diagnoses and treatments as well as interaction constraints such as time,

location, age range, gender, and number of participants.

PAs can be distributed across diﬀerent rule engines using diﬀerent rule lan-

guages (e.g., Prolog and N3), where rules, queries, and answers are interchanged

via translation to and from RuleML/XML. We discuss the implementation of Pa-

tientSupporter in a use case where the PA’s medical subareas are deﬁned through

sports injuries structured by a partonomy of aﬀected body parts.

PatientSupporter uses ontologies and rules for organizing geographically dis-

tributed patients – here, suﬀering from sports injuries – into virtual support groups

around classes of an ontology of injuries – here, a sports-injury partonomy. The

prototype is designed to help patients with a similar sports injury to interact with

a virtual support group having that common interest. Patients in an online Pa-

tientSupporter virtual organization create their semantic proﬁle referring to classes

in a disease ontology – here a partonomy of body parts aﬀected by sports injuries.

Proﬁles contain rules about diagnoses and treatments as well as interaction con-

straints such as time, location, age range, gender, and number of participants. A

patient can pose queries against the semantic proﬁles of other patients in his or her

virtual organization to ﬁnd or initiate a matching group.

PatientSupporter allows patients to have their proﬁles expressed in either Pure

Prolog (Logic Programming rules) or N3 (Semantic Web rules). Providing these

mhttp://ruleml.org/WellnessRules and http://ruleml.org/WellnessRules2

December 16, 2011 17:17 Postprint Version RuleResponderReaction

34 Adrian Paschke and Harold Boley

quite diﬀerent rule language paradigms permit patients to choose the language

that best suits them. Rule Responder handles the interoperation between the rule

languages of diﬀerent patients using translators to and from RuleML/XML as the

interchange format BT W 01,Bol07.

Patients using the PatientSupporter Social Semantic Web portal are able to

initiate the virtual support group about their sports injury on a global scale. They

also beneﬁt from PatientSupporter’s interoperation facility in the background – to

transform patient proﬁles between Pure Prolog and N3 through RuleML/XML.

The system employs a partonomy of sports-injury-aﬀected body parts (a ‘body

partonomy’), which makes it easy for patients to navigate hierarchically up or down

to increase recall or precision, respectively. A patient’s queries invoke other patients’

interaction rules, allowing him or her to narrow down the search in a step-wise

fashion. All of this saves a patient from browsing through a large set of irrelevant

patient proﬁles and permits him or her to eﬃciently converge on a ﬁrst Skype call.

The Rule Responder instantation to PatientSupporter is further described and

demoed online.n

6.4. Reputation Management System

The Rule Responder reputation management system AP M 10 is based on distributed

Rule Responder rule agents, which use rules for implementing the reputation man-

agement functionalities as rule agents, and which use Semantic Web ontologies for

representing simple or complex multi-dimensional reputation objects. This Semantic

Web reputation ontology model enables reputation portability, eases the manage-

ment of reputation data, mitigates risks in open environments, and enhances the

decision making process in the reputation processing agents. The reputation man-

agement system computes, manages, and provides reputation about entities which

act on the Web. It is implemented as a Reputation Processing Network (RPN) con-

sisting of Reputation Processing Agents (RPAs) that have two diﬀerent roles:

(1) Reputation Authority Agents (RAAs): Act as reputation scoring services for

the reputee entities whose Reputation Objects (ROs) are being considered or

calculated in the agents’ rule-based Reputation Computation Services (RCSs).

An RCS runs a rule engine which accesses diﬀerent sources of reputation (in-

put) data from the reputors about an entity and evaluates an RO based on

its declarative rule-based computational algorithms and contextual information

available at the time of computation.

(2) Reputation Management Agents (RMAs): Act as a reputation trust center oﬀer-

ing reputation management functionalities. An RMA manages the local RAAs

providing control of their life-cycle in particular, and also ensuring goals such as

fairness. It might act as a Reputation Service Provider (RSP) which aggregates

nhttp://ruleml.org/PatientSupporter

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 35

reputations from the reputation scores of local RAAs. Based on the ﬁnal calcu-

lated reputation, it might also perform actions, e.g. compute trust-worthiness,

make automated decisions, or trigger reactions. It also manages the communi-

cation with the reputors, collecting data about entities from them, generates

reputation data inputs for the reputation scoring, and distributes the data to the

RAAs. It might also act as central point of communication for the real reputee

entities (e.g., persons) giving them legitimate control over their reputation and

allowing entities the governance of their reputations.

The agent-based approach for an online reputation management ensures eﬃ-

cient automation, semantic interpretability and interaction, openness in ownership,

ﬁne-grained privacy and security protection, and easy management of semantic rep-

utation data on the Web.

6.5. Semantic Complex Event Processing Agent Network

The Event Processing Network (EPN) K JP 09 consists of Semantic Event Process-

ing Agents (EPA) implemented as distributed Prova inference services which de-

tect complex events using Prova’s rule-based Semantic Complex Event Process-

ing (SCEP) logic. T P 09. The multi-agent approach allows for a highly-available

distributed implementation with redundant Event-Calculus based state processing

where events are processed concurrently in the EPN.

7. Related Work

Closely related to Rule Responder are agent architectures which directly use ex-

pressive rule languages and rule engines as basis for the agent behavior control.

Using this kind of architecture basically requires that the rule base is properly con-

nected with the agent’s sensors and eﬀectors in order to allow an agent to receive

percepts and execute actions. To be able to exhibit reactive behavior and process

incoming messages it is necessary that 1) incoming messages will trigger the exe-

cution of processing rules and 2) the external knowledge representation ﬁts to the

internal one or is mapped accordingly. Examples of this domain are e.g. JADE/Jess

agent Car07 , Vivid Agents SW 00, OPAL Agents WPN05, Jason BW H07 , and Emer-

ald KKB10. In JADE/Jess an agent is constructed in a way that allows access to

the production rule engine (JESS). Vivid agents are controlled systems whose state

comprises the mental components of knowledge, perceptions, tasks, and intentions.

Their behavior is represented by means of action and reaction rules, which follow

the event-condition-action (ECA) paradigm and are underpinned by formal tran-

sition semantics for concurrent action planning. In Emerald reasoning engines are

employed as reasoning services that are implemented as reasoner agents, which

intercommunicate via FIPA-based communication protocols. In the OPAL agents

various reasoning engines are employed as plug-in components of the agents which

are deployed on the OPAL platform and intercommunicate via FIPA-based com-

December 16, 2011 17:17 Postprint Version RuleResponderReaction

36 Adrian Paschke and Harold Boley

munication protocols. Jason is an extension of the AgentSpeak agent-oriented pro-

gramming language used for rule-based programming of the behaviour of individual

agents.

Another related category contains specialized rule engine based agent architec-

tures, which have specialized rule engines for executing the agent logic. Nonetheless,

the oﬀered programming concepts have not been changed, i.e. the agent behavior

speciﬁcation is mainly done by programming traditional rules. Two typical repre-

sentatives for this category are RC++ W M 03 and SOAR LLR96. The motivations

behind those approaches are quite diﬀerent. RC++ is an extension to the C++

programming language, which incorporates rules directly into the base language.

It therefore realizes a conservative extension approach, which aims at a tight in-

tegration with the underlying procedural core language. The RC++ language is

a general purpose language, but has been designed with a clear application focus

in mind. It should facilitate the programming of game AI for the game console.

In contrast, SOAR has been developed to be a general problem solver for arbi-

trary complex problems. Hence, the SOAR architecture has primarily been used for

knowledge-rich intelligent agent applications. Examples include intelligent control,

natural language understanding, human behavior experiments and simulation WJ 05.

A third category of related rule-based agent architectures encompasses ap-

proaches that aim at introducing abstract mentalistic notions as agent program-

ming language constructs. Each of these approaches proposes a speciﬁc concerted

set of mental state components and introduces a language with speciﬁc types of

rules to operate on these components (e.g. commitment rules, which operate on

commitments). As a natural way of controlling the relation between diﬀerent types

of mental components and rules respectively, these approaches are not implemented

as a general rule base, but use the speciﬁc rules only as part of an extended in-

terpreter architecture. All approaches in this category are intended to be speciﬁc

agent programming languages. Due to the rules operating directly on the mental

state of the agent, these approaches are best suited for agents operating in dynamic

environments, where quick reactions to environmental changes are advantageous.

Such environments are common, e.g. for agents operating on mobile devices such as

PDAs or cell phones and for controlling autonomous robots. Prominent representa-

tives of this category are the AOP (AOP, cf. Sho93)and the 3APL/2APL language

families. 3APL (”An Abstract Agent Programming Language”) and its successor

2APL (”A Practical Agent Programming Language”) are developed at the Univer-

sity of Utrecht H DBV DHC M99. In addition to implementing agent applications, these

languages are also used for teaching purposes. In contrast to 3APL/2APL, AOP lan-

guages are developed by diﬀerent groups for diﬀerent purposes including academic

and commercial projects. Agent-0 Sho93 and other AOP languages introduce addi-

tional constructs for making agent oriented programming more convenient. In the

second generation of AOP, PLACA T ho95 extends Agent-0 with planning features,

while Agent-K DE94 supports the KQML as a standardized agent communication

language. Agent-K has been further extended to GOAL BE96 , which incorporates

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 37

planning similar to PLACA, but also on a multi-agent level (e.g. group goals, which

comprise commitments of several agents). Successors of PLACA are RADL, which

is the language of the commercial AgentBuilder toolkit oand AF-APL, belonging

to the open source AgentFactory framework RCO05. Both languages try to advance

the practical usability of the language, e.g., by providing convenient mechanisms

for integration with Java.

8. Conclusion

Rule Responder is a framework for specifying virtual organizations as semantic

multi-agent systems. The software is available open source in Sourceforgep. Char-

acteristics of Rule Responder include

•the coverage of the distributed processing spectrum from Web Services to agents

in one framework

•the recursive (holonic) modeling of a virtual organization of services and agents

as a single agent,

•the use of ESBs, especially Mule, as a Semantic and Pragmatic Web infrastruc-

ture,

•the use of Semantic-Pragmatic Web rules as the main knowledge representation,

complemented by ontologies,

•the introduction of PAs as human-assisting agents within a virtual organization,

complementing the usual self-contained CAs,

•the design of a ‘pluggable’ agent-ﬁnding mechanism from role assignment to

Semantic Service discovery.

The Rule Responder framework, with its increasing number of users and engines

(Prova, OO jDREW, DR-Device, Euler, and Drools), is thus being proposed as

a reference architecture for distributed rule-based knowledge representation and

processing on the Semantic-Pragmatic Web.

9. Acknowledgement

Electronic version of an article published as International Journal on Artiﬁcial In-

telligence Tools, 20, 6, 2011, 1043-1081

DOI: 10.1142/S0218213011000528 copyright World Scientiﬁc Publishing Company

http://www.worldscientiﬁc.com/doi/abs/10.1142/S0218213011000528

References

APM10. Rehab Alnemr, Adrian Paschke, and Christoph Meinel. Enabling rep-

utation interoperability through semantic technologies. In ACM Inter-

national Conference on Semantic Systems. ACM, 2010.

ohttp://www.agentbuilder.com/

phttp://mandarax.svn.sourceforge.net/viewvc/mandarax/PragmaticAgentWeb

December 16, 2011 17:17 Postprint Version RuleResponderReaction

38 Adrian Paschke and Harold Boley

BE96. Ciara Byrne and Peter Edwards. Reﬁnement in agent groups. In Pro-

ceedings of the Workshop on Adaption and Learning in Multi-Agent Sys-

tems, IJCAI ’95, pages 22–39, London, UK, 1996. Springer-Verlag.

BOC09. Harold Boley, Taylor Michael Osmun, and Benjamin Larry Craig. So-

cial Semantic Rule Sharing and Querying in Wellness Communities.

In Asunci´on G´omez-P´erez, Yong Yu, and Ying Ding, editors, ASWC,

volume 5926 of Lecture Notes in Computer Science, pages 347–361.

Springer, 2009.

Bol07. Harold Boley. Are Your Rules Online? Four Web Rule Essentials. In

A. Paschke and Y. Biletskiy, editors, Proc. Advances in Rule Interchange

and Applications, International Symposium (RuleML-2007), Orlando,

Florida, volume 4824 of LNCS, pages 7–24. Springer, 2007.

BP07. Harold Boley and Adrian Paschke. Expert Querying and Redirection

with Rule Responder. In Anna V. Zhdanova, Lyndon J. B. Nixon, Mal-

gorzata Mochol, and John G. Breslin, editors, FEWS, volume 290 of

CEUR Workshop Proceedings, pages 9–22. CEUR-WS.org, 2007.

BTW01. Harold Boley, Said Tabet, and Gerd Wagner. Design Rationale of

RuleML: A Markup Language for Semantic Web Rules. In Proc. Se-

mantic Web Working Symposium (SWWS’01), pages 381–401. Stanford

University, July/August 2001.

BWH07. Rafael H. Bordini, Michael Wooldridge, and Jomi Fred H¨ubner. Pro-

gramming Multi-Agent Systems in AgentSpeak using Jason (Wiley Se-

ries in Agent Technology). John Wiley & Sons, 2007.

Car07. H. L. Cardoso. Integrating jade and jess, 2007.

CB08. Benjamin Larry Craig and Harold Boley. Personal Agents in the Rule

Responder Architecture. In Nick Bassiliades, Guido Governatori, and

Adrian Paschke, editors, RuleML, volume 5321 of Lecture Notes in Com-

puter Science, pages 150–165. Springer, 2008.

Cra07. Benjamin Craig. The OO jDREW Engine of Rule Responder: Naf Horn-

log RuleML Query Answering. In Adrian Paschke and Yevgen Biletskiy,

editors, RuleML-2007, volume 4824 of Lecture Notes in Computer Sci-

ence. Springer, 2007.

DE94. W. H. E. Davies and P. Edwards. Agent-K: An Integration of AOP and

KQML. In T. Finin and Y. Labrou, editors, Proceedings of the CIKM’94

Workshop on Intelligent Agents, 1994.

DGKK98. P. Doherty, J. Gustafsson, L. Karlsson, and J. Kvarnstroem. Tal: Tem-

poral action logics language speciﬁcation and tutorial. Linkoeping Elec-

tronic Articles in Computer and Information Science, 3(015), 1998.

FLM97. Tim Finin, Yanis Labrou, and James Mayﬁeld. KQML as an agent com-

munication language. MIT Press, Cambridge, MA, USA, 1997.

HDBVDHCM99. Koen V. Hindriks, Frank S. De Boer, Wiebe Van Der Hoek, and John-

Jules Ch. Meyer. Agent programming in 3apl. Autonomous Agents and

Multi-Agent Systems, 2:357–401, November 1999.

KJP09. Alexander Kozlenkov, David Jeﬀery, and Adrian Paschke. State man-

agement and concurrency in event processing. In DEBS, 2009.

KKB10. Kalliopi Kravari, Efstratios Kontopoulos, and Nick Bassiliades. Emer-

ald: A multi-agent system for knowledge-based reasoning interoperabil-

ity in the semantic web. In SETN, pages 173–182, 2010.

KS86. R. A. Kowalski and M. J. Sergot. A logic-based calculus of events. New

Generation Computing, 4:67–95, 1986.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

Rule Responder Agents 39

LBBM06. Jie Li, Harold Boley, Virendrakumar C. Bhavsar, and Jing Mei. Ex-

pert Finding for eCollaboration Using FOAF with RuleML Rules. In

Montreal Conference of eTechnologies 2006, pages 53–65, 2006.

LLR96. Jill Fain Lehman, John Laird, and Paul Rosenbloom. A gentle intro-

duction to soar, an architecture for human cognition. In In S. Sternberg

& D. Scarborough (Eds), Invitation to Cognitive Science. MIT Press,

1996.

MH69. J. McCarthy and P. Hayes. Some philosophical problems from the stand-

point of artiﬁcial intelligence. Machine Intelligence, 4:463–502, 1969.

Pas06a. Adrian Paschke. Eca-lp / eca-ruleml: A homogeneous event-condition-

action logic programming language. CoRR, abs/cs/0609143, 2006.

Pas06b. Adrian Paschke. A typed hybrid description logic programming lan-

guage with polymorphic order-sorted dl-typed uniﬁcation for semantic

web type systems. CoRR, abs/cs/0610006, 2006.

Pas07. A. Paschke. Rule-Based Service Level Agreements - Knowledge Repre-

sentation for Automated e-Contract, SLA and Policy Management. Idea

Verlag GmbH, Munich, 2007.

Pas08. Adrian Paschke. Rule responder hcls escience infrastructure. In ICPW

’08: Proceedings of the 3rd International Conference on the Pragmatic

Web, pages 59–67, New York, NY, USA, 2008. ACM.

PB08. Adrian Paschke and Martin Bichler. Knowledge representation concepts

for automated sla management. Decis. Support Syst., 46(1):187–205,

2008.

PK08. Adrian Paschke and Alexander Kozlenkov. A rule-based middleware

for business process execution. In Multikonferenz Wirtschaftsinformatik,

2008.

RCO05. Robert Ross, Rem Collier, and G. OHare. Af-apl bridging principles

and practice in agent oriented languages. In Rafael Bordini, Mehdi Das-

tani, Jrgen Dix, and Amal El Fallah Seghrouchni, editors, Programming

Multi-Agent Systems, volume 3346 of Lecture Notes in Computer Sci-

ence, pages 66–88. Springer Berlin / Heidelberg, 2005.

SG06. Geoﬀ Sutcliﬀe and Randy Goebel, editors. Proceedings of the Nineteenth

International Florida Artiﬁcial Intelligence Research Society Confer-

ence, Melbourne Beach, Florida, USA, May 11-13, 2006. AAAI Press,

2006.

Sho93. Yoav Shoham. Agent-oriented programming. Artif. Intell., 60(1):51–92,

1993.

SW00. Michael Schroeder and Gerd Wagner. Vivid agents: Theory, architec-

ture, and applications. Applied Artiﬁcial Intelligence, 14(7):645–675,

2000.

Tho95. S. Thomas. The PLACA agent programming language. In Intelligent

Agents, pages 355–370. 1995.

TP09. Kia Teymourian and Adrian Paschke. Towards semantic event process-

ing. In DEBS, 2009.

WCB01. M. Welsh, D. Culler, and E. Brewer. SEDA: An Architecture for Well

Conditioned, Scalable Internet Services. In Proceedings of Eighteeth

Symposium on Operating Systems (SOSP-18), Chateau Lake Louise,

Canada, 2001.

WJ05. R. E. Wray and R. M. Jones. Considering Soar as an Agent Architecture.

In Ron Sun, editor, Cognition and Multi-agent Interaction, pages 53–78.

December 16, 2011 17:17 Postprint Version RuleResponderReaction

40 Adrian Paschke and Harold Boley

Cambridge University Press, 2005.

WM03. I. Wright and J. Marshall. The execution kernel of rc++: Rete*, a faster

rete with treat as a special case. International Journal of Intelligent

Games and Simulation, 2, 2003.

Woo01. M. Wooldridge. An Introduction to MultiAgent Systems. John Wiley &

Sons, 2001.

WPN05. Mengqiu Wang, Martin Purvis, and Mariusz Nowostawski. An in-

ternal agent architecture incorporating standard reasoning compo-

nents and standards-based agent communication. In Proceedings of the

IEEE/WIC/ACM International Conference on Intelligent Agent Tech-

nology, IAT ’05, pages 58–64, Washington, DC, USA, 2005. IEEE Com-

puter Society.

Provalets: Component-Based Mobile Agents as Microservices for Rule-Based Data Access, Processing and Analytics

Article

Full-text available

Oct 2016
BUS INFORM SYST ENG+

Adrian Paschke

Provalets are mobile rule agents for rule-based data access, semantic processing, and inference analytics. They can be dynamically deployed as microservices from Maven repositories into standardized container environments such as OSGi, where they can be used via simple REST calls. The programming model supports rapid prototyping and reuse of Provalets components to build Linked Enterprise Data applications where the sensible corporate data is not transmitted outside the enterprise, but instead the Provalets providing data processing and knowledge inference capabilities are moved closer to the data.

Web Stream Reasoning: From Data Streams to Actionable Knowledge

Chapter

Full-text available

Jul 2015

Alessandra Mileo

A fast growing torrent of data is being created by companies, social networks, mobile phones, smart homes, public transport vehicles, healthcare devices, and other modern infrastructures. Being able to unlock the potential hidden in this torrent of data would open unprecedented opportunities to improve our daily lives that were not possible before. Advances in the Internet of Things (IoT), Semantic Web and Linked Data research and standardization have already established formats and technologies for representing, sharing and re-using (dynamic) knowledge on the Web. However, transforming data into actionable knowledge requires to cater for (i) automatic mechanisms to discover and integrate heterogeneous data streams on the fly and extract patterns for applications to use, (ii) concepts and algorithms for context and quality-aware integration of semantic data streams, and (iii) the ability to synthesize domain-driven commonsense knowledge (and answers derived from it) with expressive inference that can capture decision analytics in a scalable way. In the first part of this lecture we will characterize the main approaches to stream processing for the Web of Data, showing how data quality and context can guide semantic integration. In the second part of this lecture we will focus on rule-based Web Stream Reasoning and illustrate how scalability and uncertainty issues can be addressed in a rule-based approach. We will discuss new challenges and opportunities in Web Stream Reasoning, briefly considering economical and societal impact in real application scenarios in a smart city context, and we will conclude by providing a brief overview of ongoing research and standardization activities in this area.

Emotional dialog generation via multiple classifiers based on a generative adversarial network

Article

Full-text available

Feb 2021

Background Human-machine dialog generation is an essential topic of research in the field of natural language processing. Generating high-quality, diverse, fluent, and emotional conversation is a challenging task. Based on continuing advancements in artificial intelligence and deep learning, new methods have come to the forefront in recent times. In particular, the end-to-end neural network model provides an extensible conversation generation framework that has the potential to enable machines to understand semantics and automatically generate responses. However, neural network models come with their own set of questions and challenges. The basic conversational model framework tends to produce universal, meaningless, and relatively "safe" answers. Methods Based on generative adversarial networks (GANs), a new emotional dialog generation framework called EMC-GAN is proposed in this study to address the task of emotional dialog generation. The proposed model comprises a generative and three discriminative models. The generator is based on the basic sequence-to-sequence (Seq2Seq) dialog generation model, and the aggregate discriminative model for the overall framework consists of a basic discriminative model, an emotion discriminative model, and a fluency discriminative model. The basic discriminative model distinguishes generated fake sentences from real sentences in the training corpus. The emotion discriminative model evaluates whether the emotion conveyed via the generated dialog agrees with a pre-specified emotion, and directs the generative model to generate dialogs that correspond to the category of the pre-specified emotion. Finally, the fluency discriminative model assigns a score to the fluency of the generated dialog and guides the generator to produce more fluent sentences. Results Based on the experimental results, this study confirms the superiority of the proposed model over similar existing models with respect to emotional accuracy, fluency, and consistency. Conclusions The proposed EMC-GAN model is capable of generating consistent, smooth, and fluent dialog that conveys pre-specified emotions, and exhibits better performance with respect to emotional accuracy, consistency, and fluency compared to its competitors.

A FIPA-Compliant Framework for Integrating Rule Engines into Software Agents for Supporting Communication and Collaboration in a Multiagent Platform

Chapter

Full-text available

Apr 2019

Production rules have been traditionally considered a good knowledge representation formalism for creating expert systems, and also as a good mechanism for building intelligence within software agents due to the flexibility of their declarative knowledge representation. But the use of rules and rule engines for implementing behaviors inside agents in the context of a multiagent environment has a number of challenges if one wants to adhere and preserve the defining characteristics of agency and support the kind of communication and collaboration mechanisms needed by multiagent systems. This paper describes a framework, and its implementation, for the integration of production rules reasoning mechanisms inside software agents in the context of a multiagent platform, preserving the defining characteristics of agency and accomplishing the well-established FIPA standards for agent interaction.

Emotional Human-Machine Conversation Generation Based on Long Short-Term Memory

Article

Full-text available

Jun 2018

With the rise in popularity of artificial intelligence, the technology of verbal communication between man and machine has received an increasing amount of attention, but generating a good conversation remains a difficult task. The key factor in human-machine conversation is whether the machine can give good responses that are appropriate not only at the content level (relevant and grammatical) but also at the emotion level (consistent emotional expression). In our paper, we propose a new model based on long short-term memory, which is used to achieve an encoder-decoder framework, and we address the emotional factor of conversation generation by changing the model’s input using a series of input transformations: a sequence without an emotional category, a sequence with an emotional category for the input sentence, and a sequence with an emotional category for the output responses. We perform a comparison between our work and related work and find that we can obtain slightly better results with respect to emotion consistency. Although in terms of content coherence our result is lower than those of related work, in the present stage of research, our method can generally generate emotional responses in order to control and improve the user’s emotion. Our experiment shows that through the introduction of emotional intelligence, our model can generate responses appropriate not only in content but also in emotion.

OntoMaven - Maven-Based Ontology Development and Management of Distributed Ontology Repositories

Chapter

Sep 2018

In collaborative agile ontology development projects support for modular reuse of ontologies from large existing remote repositories, ontology project life cycle management, and transitive dependency management are important needs. The Apache Maven approach has proven its success in distributed collaborative Software Engineering by its widespread adoption. The contribution of this paper is a new design artifact called OntoMaven. OntoMaven adopts the Maven-based development methodology and adapts its concepts to knowledge engineering for Maven-based ontology development and management of ontology artifacts in distributed ontology repositories.

A Dialogue between a Lawyer and Computer Scientist: The Evaluation of Knowledge Transformation from Legal Text to Computer-Readable Format

Article

Apr 2016
APPL ARTIF INTELL

Involvement of a domain expert in domain knowledge modeling, for its use in an automated decision support system, has been a subject of interest in the last few decades. The process of knowledge creation and its transformation for further reasoning requires verification and validation. In this article, we provide details of the first approaches to a process that uses the well-known CQ-based evaluation methodology to identify and evaluate the process of legal-knowledge creation using SBVR-SE and its transformation to OWL 2. Thereby, it increases the legal practitioner’s confidence in using the created and transformed knowledge within a decision support system for deriving inferences for an in-court argumentation.

Ganzheitliches ontologiebasiertes Wissensmanagement im Umfeld der industriellen Produktion

Thesis

Full-text available

Jan 2020

Markus Brandmeier

Die heutige Zeit unterliegt mehr denn je einem strukturellen Wandel, im Zuge dessen Wissen zunehmend an Bedeutung gewinnt. Während in den 1990er Jahren noch Produktionsfaktoren wie Arbeit, Standort und vor allem Kapital von Relevanz sind, ist das Wissen eines Unternehmens heute ein wettbewerbsentscheidender strategischer Faktor. Durch die Konzentration der unternehmerischen Aufgaben auf diese entscheidende Ressource muss sichergestellt werden, dass das für den Geschäftserfolg notwendige Wissen marktorientiert aufgebaut, abgesichert und optimal genutzt wird. Bestehende Ansätze des Wissens¬managements vernachlässigen jedoch die Herausforderungen der produzierenden Industrie, berücksichtigen die menschliche Kommunikation nicht ausreichend und bilden Wissen nicht ganzheitlich ab. Ziel der Arbeit ist es, die spezifischen Anforderungen der produzierenden Industrie für den Wandel hin zu Wissensunternehmen zu analysieren und in einem ganzheitlichen Wissens-managementkonzept abzubilden. Die systematische Analyse der Einflüsse auf das Wissensmanagement, wie Hindernisse, Erfolgsfaktoren, Methoden und Systeme, schafft ein Verständnis darüber, wie Wissen in der produzierenden Industrie optimal genutzt werden kann. Durch die Abbildung von Wissen, dessen Beziehungen sowie der darin enthaltenen Logik in einem ontologiebasiertes Wissensmanagement-Framework werden Unternehmen in der formalen Erfassung der erfolgskritischen Ressource unterstützt. Die adäquate Integration der Technologie der künstlichen Intelligenz und des maschinellen Lernens ermöglicht es Mitarbeitern zudem, mit Ontologien als Wissensrepräsentationsform aufwandsarm zu interagieren. Darüber hinaus zeigt die Arbeit auf, wie das ontologiebasiertes Wissensmanagement-Framework in einer realen Fertigung angewendet und dadurch eine optimale Ausgestaltung des gegenwärtigen und zukünftigen Ressourceneinsatzes gewährleistet werden kann.

Emotional Human Machine Conversation Generation Based on SeqGAN

Conference Paper

May 2018

Provalets

Conference Paper

Oct 2015

Adrian Paschke

Rule-based Data Access (RBDA) has become an active R&D topic in the recent years. In this paper we propose an easy to use agent-based rule programming model and a general component architecture for RBDA. The programming model supports rapid prototyping and reuse of existing Prova rule agents/components which are published and managed in OntoMaven repositories. We name these components Provalets. We propose a declarative component description language that is powerful enough to represent different types of Provalets, including the representation of their functional interfaces and their semantics as well as their non-functional collaboration aspects and quality of service attributes.

A gentle introduction to Soar, an architecture for human cognition

Article

Full-text available

Jan 1996

Many intellectual disciplines contribute to the field of cognitive science: psychology, linguistics, anthropology, and artificial intelligence, to name just a few. Cognitive science itself originated in the desire to integrate expertise in these traditionally separate disciplines in order to advance our insight into cognitive phenomena, phenom ena like problem solving, decision making, language, memory, and learning. Each discipline has a history of asking certain types of questions and accepting certain types of answers. And that, according to Allen Newell, a founder of the field of artificial intelligence, is both an advantage and a problem.

A logic-based calculus of events

Article

Full-text available

Jan 1985

We outline an approach for reasoning about events and time within a logic programming framework. The notion of event is taken to be more primitive than that of time and both are represented explicitly by means of Horn clauses augmented with negation by failure. The main intended applications are the updating of databases and narrative understanding. In contrast with conventional databases which assume that updates are made in the same order as the corresponding events occur in the real world, the explicit treatment of events allows us to deal with updates which provide new information about the past. Default reasoning on the basis of incomplete information is obtained as a consequence of using negation by failure. Default conclusions are automatically withdrawn if the addition of new information renders them inconsistent. Because events are differentiated from times, we can represent events with unknown times, as well as events which are partially ordered and concurrent.

Agent programming in 3APL

Article

Full-text available

Nov 1999

An intriguing and relatively new metaphor in the programming community is that of an intelligent agent. The idea is to view programs as intelligent agents acting on our behalf. By using the metaphor of intelligent agents the programmer views programs as entities which have a mental state consisting of beliefs and goals. The computational behaviour of an agent is explained in terms of the decisions the agent makes on the basis of its mental state. It is assumed that this way of looking at programs may enhance the design and development of complex computational systems. To support this new style of programming, we propose the agent programming language 3APL. 3APL has a clear and formally defined semantics. The operational semantics of the language is defined by means of transition systems. 3APL is a combination of imperative and logic programming. From imperative programming the language inherits the full range of regular programming constructs, including recursive procedures, and a notion of state-based computation. States of agents, however, are belief or knowledge bases, which are different from the usual variable assignments of imperative programming. From logic programming, the language inherits the proof as computation model as a basic means of computation for querying the belief base of an agent. These features are well-understood and provide a solid basis for a structured agent programming language. Moreover, on top of that 3APL agents use so-called practical reasoning rules which extend the familiar recursive rules of imperative programming in several ways. Practical reasoning rules can be used to monitor and revise the goals of an agent, and provide an agent with reflective capabilities. Applying the metaphor of intelligent agents means taking a design stance. From this perspective, a program is taken as an entity with a mental state, which acts pro-actively and reactively, and has reflective capabilities. We illustrate how the metaphor of intelligent agents is supported by the programming language. We also discuss the design of control structures for rule-based agent languages. A control structure provides a solution to the problem of which goals and which rules an agent should select. We provide a concrete and intuitive ordering on the practical reasoning rules on which such a selection mechanism can be based. The ordering is based on the metaphor of intelligent agents. Furthermore, we provide a language with a formal semantics for programming control structures. The main idea is not to integrate this language into the agent language itself, but to provide the facilities for programming control structures at a meta level. The operational semantics is accordingly specified at the meta level, by means of a meta transition system.

Agent-Oriented Programming

Article

Full-text available

Mar 1993
ARTIF INTELL

Yoav Shoham

A new computational framework is presented, called agent-oriented programming (AOP), which can be viewed as a specialization of object-oriented programming. The state of an agent consists of components such as beliefs, decisions, capabilities, and obligations; for this reason the state of an agent is called its mental state. The mental state of agents is described formally in an extension of standard epistemic logics: beside temporalizing the knowledge and belief operators, AOP introduces operators for obligation, decision, and capability. Agents are controlled by agent programs, which include primitives for communicating with other agents. In the spirit of speech act theory, each communication primitive is of a certain type: informing, requesting, offering, and so on. This article presents the concept of AOP, discusses the concept of mental state and its formal underpinning, defines a class of agent interpreters, and then describes in detail a specific interpreter that has been implemented.

A Rule-based Middleware for Business Process Execution.

Conference Paper

Full-text available

Jan 2008

Considering Soar As An Agent Architecture

Article

Dec 2005

INTRODUCTION The Soar architecture was created to explore the requirements for general intelligence and to demonstrate general intelligent behavior (Laird, Newell, & Rosenbloom, 1987; Laird & Rosenbloom, 1995; Newell, 1990). As a platform for developing intelligent systems, Soar has been used across a wide spectrum of domains and applications, including expert systems (Rosenbloom, Laird, McDermott, Newell, & Orciuch, 1985;Washington & Rosenbloom, 1993), intelligent control (Laird, Yager, Hucka, & Tuck, 1991; Pearson, Huffman, Willis, Laird,& Jones, 1993), natural language (Lehman, Dyke, & Rubinoff, 1995; Lehman, Lewis, & Newell, 1998), and executable models of human behavior for simulation systems (Jones et al., 1999;Wray, Laird, Nuxoll, Stokes, & Kerfoot, 2004). Soar is also used to explore the integration of learning and performance, including concept learning in conjunction with performance (Chong & Wray, to appear; Miller & Laird, 1996), learning by instruction (Huffman & Laird, 1995), learning to correct errors in performance knowledge (Pearson & Laird, 1998), and episodic learning (Altmann & John, 1999; Nuxoll & Laird, 2004). This chapter will introduce Soar as a platform for the development of intelligent systems (see also Chapters 2 and 4). Soar can be viewed as a theory of general intelligence, as a theory of human cognition, as an agent architecture, and as a programming language. This chapter reviews the theory underlying Soar but considers Soar primarily as an agent architecture. The architecture point-of-view is useful because Soar integrates a number of different algorithms common in artificial intelligence, demonstrating how they can be used together to achieve general intelligent behaviour. © Cambridge University Press 2006 and Cambridge University Press, 2009.

Programming Multi-Agent Systems in AgentSpeak Using Jason

Book

Oct 2007

Jason is an Open Source interpreter for an extended version of AgentSpeak - a logic-based agent-oriented programming language - written in Java™. It enables users to build complex multi-agent systems that are capable of operating in environments previously considered too unpredictable for computers to handle. Jason is easily customisable and is suitable for the implementation of reactive planning systems according to the Belief-Desire-Intention (BDI) architecture. Programming Multi-Agent Systems in AgentSpeak using Jason provides a brief introduction to multi-agent systems and the BDI agent architecture on which AgentSpeak is based. The authors explain Jason's AgentSpeak variant and provide a comprehensive, practical guide to using Jason to program multi-agent systems. Some of the examples include diagrams generated using an agent-oriented software engineering methodology particularly suited for implementation using BDI-based programming languages. The authors also give guidance on good programming style with AgentSpeak. Programming Multi-Agent Systems in AgentSpeak using Jason. Describes and explains in detail the AgentSpeak extension interpreted by Jason and shows how to create multi-agent systems using the Jason platform. Reinforces learning with examples, problems, and illustrations. Includes two case studies which demonstrate the use of Jason in practice. Features an accompanying website that provides further learning resources including sample code, exercises, and slides. This essential guide to AgentSpeak and Jason will be invaluable to senior undergraduate and postgraduate students studying multi-agent systems. The book will also be of interest to software engineers, designers, developers, and programmers interested in multi-agent systems.

Rule-Based Service Level Agreements - Knowledge Representation for Automated e-Contract, SLA and Policy Management

Book

Jan 2007

Adrian Paschke

Automated management and monitoring of IT service contracts, like Service Level Agreements (SLAs) and higher-level policies, is essential for efficient and reliable IT Service Supply Chains / Enterprise Service Networks with high Quality of Service levels (QoS). This typically faces rapidly changing highly distributed business and system environments, huge amounts of scattered contracts and data managed in distributed sources, and a great variety of more or less cooperative roles involved in the contract life cycles. The complexity of contractual logic requires new forms of knowledge representation for SLAs and new technical solutions with a high degree of agility and flexibility in order to efficiently engineer, manage and continuously monitor and enforce large amounts of complex, distributed IT service contracts. This book presents the implemented Rule-Based Service Level Agreement (RBSLA) approach (http://rbsla.ruleml.org) which is based on a new knowledge representation to describe and execute SLAs in a formal, rule-based way. The research and development draws on logic programming techniques as well as on new standards in the areas of Enterprise Services Computing, Complex Event Processing and the Semantic Web. A particular focus is on the hybrid application of enterprise service technologies in combination with expressive logic programming techniques and logical formalisms such as defeasible logic, deontic logic, temporal event/action logics, transaction and update logics, and description logics as a means of deriving formal declarative contract specifications that reason about ideal and actual behaviours relating to agreed contract norms and their violations and exceptions.

Some Philosophical Problems from the Standpoint of Artificial Intelligence

Article

Jan 1969

A computer program capable of acting intelligently in the world must have a general representation of the world in terms of which its inputs are interpreted. Designing such a program requires commitments about what knowledge is and how it is obtained. Thus, some of the major traditional problems of philosophy arise in artificial intelligence.

Knowledge Representation Concepts for Automated SLA Management

Article

Nov 2006
DECIS SUPPORT SYST

Outsourcing of complex IT infrastructure to IT service providers has increased substantially during the past years. IT service providers must be able to fulfil their service-quality commitments based upon predefined Service Level Agreements (SLAs) with the service customer. They need to manage, execute and maintain thousands of SLAs for different customers and different types of services, which needs new levels of flexibility and automation not available with the current technology. The complexity of contractual logic in SLAs requires new forms of knowledge representation to automatically draw inferences and execute contractual agreemen ts. A logic-based approach provides several advantages including automated rule chaining allowing for compact knowledge representation as well as flexibility to adapt to rapidly changing business requirements. We suggest logical formalisms for the representation and enforcement of SLA rules and describe a proof-of-concept implementation. The article describes selected formalisms of the ContractLog KR and their adequacy for automated SLA management and presents results of experiments and examples from common industry use cases to demonstrate the expressiveness of the language and the scalability of the approach.

Rule Responder: Rule-Based Agents for the Semantic-Pragmatic Web.

Abstract and Figures

Recommended publications

A Reputation Multi-agent System in Semantic Web

A multi-agent architecture for a driver model for autonomous road vehicles

Twin-subset semantic model for intention

Submitted to Autonomous Agents and Multi Agent Systems 2003