Complex Event Processing (CEP) has emerged as a relevant new field of software engineering and computer science. Many of the current approaches to CEP are declarative and based on rules, and often on logic-programming-like languages and semantics. Some work on CEP is situated within the field of logical agents. Usually, event processing is based upon Event-Condition-Action rules, which are however able to manage only simple events or unstructured sets of events. In this paper, we refine the notion of “complex event”, which is an event that cannot be detected directly, but rather can be identified (not necessarily in a deterministic way) by interrelating sets of simple events. We propose a formalization and a possible implementation of such notion, that we extend to complex actions.
1 Introduction
“Complex Event Processing” (CEP) has emerged as a relevant new field of software
engineering and computer science [
Complex Event Processing is particularly important in software agents. Naturally,
most agent-oriented languages architectures and frameworks are to some extent
eventoriented and are able to perform event-processing. The issue of event processing agents
(EPAs) is of growing importance in the industrial field, since agents and multi-agent
systems are able to manage rapid change and thus to allow for scalability in
applications aimed at supporting the ever-increasing level of interaction. In particular this paper
is concerned with logical agents, i.e., agents whose syntax and semantics is rooted in
Computational Logic. There are several approaches to logical agents (for a recent
survey cf., e.g., [
A recent but well-established and widely used approach to CEP in computational
logic is ETALIS [
In logical agents, some relevant work about CEP is related to DALI, a logic
agentoriented language (first appeared in 1999 [
Teleo-Reactive Computing by Kowalski and Sadri [
The motivation of the present work relies in the observation that a complex event
cannot always be defined and recognized from simple deterministic incremental
aggregation of simple events. Rather, complex events sometimes require a more involved
and not necessarily deterministic description. In fact, in order to be flexible and
versatile instead of brittle and rigid an agent should be able to possibly interpret a set of
simple events in different ways, and to assign/learn the plausibility and reliability of
each interpretation (for a discussion of brittleness w.r.t. versatility in agents, cf. [
In this paper, we propose a novel conceptual view of complex events and a possible formalization of the new concepts. In our view, an agent should be able to possibly interpret a set of simple events in different ways, and to assign/learn a plausibility and reliability of each interpretation. We also consider complex actions, which we consider as agent-generated events. To this aim, we propose to equip agents with specific modules, that we call Event-Action modules, describing complex events and complex actions. Such modules receives as “input” a set of simple events, either perceived by the agent at its present stage of operation (external events), or generated internally by the agent itself. Each module returns: (i) possible interpretations of a set of simple events in terms of complex events; (ii) an ordering of such interpretations (if more than one is possible) in terms of preferences and/or of certainty factors; (iii) detection of anomalies; (iv) (sets of) actions to perform in response. Modules are (automatically) re-evaluated whevener new instances of the “triggering” events become available.
From a practical point of view, for both providing a formal semantics and an
implementation of modules we have presently adopted Answer Set Programming (ASP, cf.,
among many, [
To define Event-Action modules we presently refer to a quite simple logical setting which can be in fact translated into ASP. However, in principle such modules might be based upon more expressive logics (e.g., modal and/or probabilistic logics which would certainly be suitable to express event recognition/aggregation). The structure of our proposal is such that the basic concept, i.e, modules for (non-deterministic, defeasible) reasoning about event aggregation, might be easily rephased upon another logic. Clearly, in such case a suitable semantic and execution model (other than ASP) should then be provided.
The paper is organized as follows. In Section 2 we provide some background about
the building blocks of the proposed apprach. In Section 3 we present the proposal,
and in Sections 4 and 5 its formalization, and some considerations about learning. In
Section 6 we conclude. This paper is the extended version of [
Background In this section, we recall notions that define some basic foundation elements of the proposed approach. 2.1
Evolutionary Semantics of Logical Agent-Oriented Languages
The Evolutionary semantics (introduced in [
We define in fact, in very general terms, an agent as the tuple Ag = < PA, E > where A is the agent name and PA (that we call “agent program”, but can be in turn a tuple) describes the agent according to some agent-oriented formalism L. E is the set of the events that the agent is able to recognize or determine (so, E includes actions that the agent is able to perform), according to the specific agent-oriented framework.
Let H be the history of an agent as recorded by the agent itself (in a form that will depend upon the specific agent-oriented framework), i.e., H includes agent’s perceptions and memories. We assume that events that either happen externally or are generated internally, actions which are performed, and other relevant agent’s activities are recorded in H.
We assume that program PA as written by the programmer is in general transformed into an initial agent program P0 by means of an initialization phase (possibly doing nothing). When agent A is activated P0 will go into execution, and will evolve according to the evolution of H.
Evolution is represented via program-transformation steps, each one transforming Pi into Pi+1 according to Hi, which is the partial history up to stage i. The choice of which elements of Hi do actually trigger an evolution step is part of the definition of a specific agent framework.
Thus, we obtain a Program Evolution Sequence P E = [P0, . . . , Pn, . . .]. The program evolution sequence will imply a corresponding Semantic Evolution Sequence M E = [M0, . . . , Mn, . . .] where Mi is the semantics of Pi according to L. Notice in fact that the approach is parametric w.r.t L.
Definition 1 (Evolutionary semantics). Let Ag be an agent. The evolutionary semantics " Ag of Ag is a tuple hH, P E, M Ei, where H is the history of Ag , and P E and M E are respectively its program and semantic evolution sequences.
The next definition introduces the notion of instant view of " Ag, at a certain stage of the evolution (which is in principle of unlimited length).
Definition 2 (Evolutionary semantics snapshot). Let Ag be an agent, with evolutionary semantics " Ag = hH, P E, M Ei. The snaphot at stage i of " iAg is the tuple hHi, Pi, Mii, where Hi is the history up to the events that have determined the transition from Pi 1 to Pi.
In [
In Section 4.1 we provide an integration of the proposed approach to Complex Event Processing into the Evolutionary semantics, in order to make it applicable to many agent-oriented logic programming languages among which the above-mentioned ones. 2.2
Background on Answer Set Semantics
The answer set semantics is used in this paper to provide both a formal semantics and
an execution model for the proposed modules. In fact, this logic gives rise to answer set
programming (ASP), which is a very well-established and fully logical programming
paradigm. Many efficient solvers have become freely available for ASP, [
In the answer set semantics (originally named “stable model semantics”),
a (logic) program ⇧ (cf., [
The answer sets semantics is a view of a logic program as a set of inference rules (more precisely, default inference rules), or, equivalently, a set of constraints on the solution of a problem: each answer set represents a solution compatible with the constraints expressed by the program. In simple program {q not p p not q}, the first rule is read as “assuming that p is false, we can conclude that q is true.” This program has two answer sets. In the first one, q is true while p is false; in the second one, p is true while q is false. Thus, this program represent choice among two alternatives.
In the ASP (Answer Set Programming) paradigm, each answer set is seen as a
solution of given problem, encoded as an ASP program. An ASP program is basically
composed by program fragments like the above ones that generate the search space by
defining available alternatives, and by constraints which prune the generated space thus
selecting solutions. To find these solutions, one employes one of the several existing
ASP solvers [
Complex Event Processing in Logical Agent Languages In this section we present our approach to advanced Complex Event Processing in logical agents. First, we recall how event processing and aggregation can be performed in most existing frameworks. Then, we argue that new methods and tools would be useful, and introduce our proposal. 3.1
Complex Events Recognition and Evaluation: Simple Event Aggregation Event processing is traditionally based upon Event-Condition-Action (ECA) rules, of the form “IF Event then Reaction” where sometimes reaction is limited to performing a sequence of actions, sometimes is enlarged so as to allow forms of reasoning and various kinds of constraints. Most (virtually all) agent-oriented languages provide ECA rules of some form.
For instance, the following sample ECA rules defined in DALI evaluate medical symptoms, stating that to cope with high temperature one should assume an antipyretic, and to cope with cough one should take a syrup (clearly, we do not aim at medical precision). External events are indicated with postfix E, actions with postfix A, and connective :> indicates reaction. I.e., :> is a specific connective used to define ECA rules. Since DALI is an extension of prolog, the comma represents conjunction. high temperatureE :> take antipyreticA. intense coughE :> take cough syrupA.
Plain ECA rules can hardly provide more than this kind of simple reaction. Agent languages may offer empowering mechanisms that allow for some form of CEP. In DALI for instance, by means of the “internal event” construct evaluation can become more involved. In the example we may, e.g., consider the possibility that a combination of symptoms suggests the occurrence of a more serious illness. For illustration purposes we assume to hypothesize the presence of either pneumonia, or just flu, or both. In DALI external events are, a short while after perception (that may or may not imply reaction), recorded as past events (postfix P ), with a time-stamp. By high temperatureP : [4days] it is intended that at least two past events of the form high temperatureP : T 1 and high temperatureP : T 2 have been recorded, where T 2 T 1 is no less than four days. By default, the most recent records are considered, so the interval refers to the last and to the immediately previous measures of temperature (if the time-stamp of a past event is omitted, the most recent version is implicitly referred to).
The first rule below “reasons” about what has happened: if in fact both high temperature and cough have occurred, and high temperature has lasted for at least four days, one may conclude that occurrence of pneumonia should be suspected. Therefore, from the occurrence of a set of simple events, the occurrence of a complex event is inferred, as an internal event suspect pneumoniaI . Once inferred, such an event can be reacted to exactly like external ones by an ECA rule, the one below stating that the patient shoul take an antibiotic and consult a lung doctor. suspect pneumoniaI :high temperatureP : [4days], intense coughP , compatible(prenumonia, anamnesis). suspect pneumoniaI :> take antibioticA,
consult lung doctorA.
Internal events are periodically re-evaluated at a certain (customizable) frequency. Between one attempt and the next one, the agent’s belief base will evolve as new events will have happened, reacted to and recorded. Thus, at each attempt an internal event can be either generated (and reacted to) or not, according to the agent’s belief state. In the example, the suspect of pneumonia will not raise immediately, but rather after four days of high temperature measurements.
Clarly, the proposed example might be formalized also in ETALIS and in many other agent-oriented frameworks, each one offering its own improvements over simple ECAs in view of CEP. In summary, by means of ECA rules little can be done for CEP. By means of suitable empowring mechanisms such as the internal events, complex events can posibly be generated (ad then reacted to) by reasoning on simple external events.
We believe however that such a simple pattern is often not sufficient, as there are many cases where the interpretation of sets of simple events is not univocal or straightforward. Therefore, different hypotheses about the meaning of a situation at hand should be generated and evaluated. We then propose a novel view and a novel formalization of event aggregation. 3.2
Complex Events Recognition and Evaluation: Event-Action Modules Below we introduce the notion of Event and Action modules. For lack of space we illustrate these modules by means of two examples that we consider as representatives of significant situations. The first example concerns complex event recognition, the second one concerns complex actions generation. We do not intend to propose here a specific syntax for Event and Action modules: rather, we intend to point out what should be the elements and functions of such modules. In the sample syntax, adopted only for illustration purposes, as before postfix ’P’ indicates past events, i.e., events which have occurred (after the ’:’ there is the time-stamp or the interval of occurrence). Postfix ’A’ indicates actions. Connective :> indicated Event-Condition-Action rules, while :- is the usual prolog if.
Event Interpretation
The following example illustrates an Event-Action Module that re-elaborates the previosly-introduced example concerning medical diagnosis. This should allow the reader to appreciate the improvements over the simple formulation.
An Event-Action Module will be (re-)evaluated whenever the triggering events occur within a certain time interval, and according to specific conditions: in the example, the module is evaluated whenever in the last two days both high temperature and intense cough have been recorded.
EVENT-ACTION-MODULE
(high temperatureP AND intense coughP ) : [2days]
suspect flu OR suspect preumonia suspect flu :- high temperatureP . suspect pneumonia :- high temperatureP : [4days], intense coughP .
suspect flu :- patient is healthy . suspect pneumonia :- patient is at risk .
suspect flu :> stay in bedA. suspect flu, high temperatureP : [4days], not suspect pneumonia :> take antibioticA. suspect preumonia :>
take antibioticA, consult lung doctorA.
suspect preumonia :- high temperatureP : [4days], suspect fluP , take antibioticP : [2days].
From given symptoms, either a suspect flu or a suspect pneumonia or both can
be concluded, though for suspecting pneumonia high temperature should have lasted
for at least four days, accompanied by intense cough. This is stated in the
COMPLEX EVENTS section, where each of the listed complex events (in the example,
suspect flu and suspect pneumonia) can be inferred, though according to the specified
conditions. Notice that the whole agent’s belief base (including the history) is implicitly
included in the definition of an Event-Action module. Explicit preferences are expressed
in the PREFERENCES section, here stating that hypothesizing a flu should be preferred
in case the patient is healthy, while pneumonia is more plausible for risky patients. If
either none or both options hold, then they are equally preferred. More involved forms
of preferences might be specified, that for lack of space we do not discuss here (cf.,
e.g., [
Actions will be actually performed depending upon the outcome that the agent will prefer to choose. In particular, if a flu is suspected then the patient should stay in bed, and if the high temperature persists then an antibiotic should also be assumed (even if pneumonia is not suspected). In case of suspect pneumonia, an antibiotic is mandatory, plus a consult with a lung doctor.
The MANDATORY section of the module includes constraints, that may be of various kinds: in this case, it specifies which complex events must be mandatorily inferred in module (re)evaluations if certain conditions occur. Specifically, pneumonia is to be assumed mandatorily whenever flu has been previously assumed, but high temperature persists despite at least two days of antibiotic therapy.
Answer set modules for possibility and necessity (cf. [
We have noted before that event interpretation is not necessarily deterministic and straightforward. The same happens for actions: devising which actions and agent should perform can be highly context-dependent, and can be subjected to various kinds of uncertainty. To avoid brittleness, an agent should in our opinion be able to flexibly choose what to do in specific circumstances, and to dynamically adapt to changes of context/role/situation. This is why we propose to adapt previously introduced modules to action generation.
We illustrate the approach by means of an example related to what happens when two persons meet. The representation is simplicistic and is meant only to illustration purposes. A “real” encoding of the module below might be much more involved, and imply various kinds of knowledge representation methods, possibly including a theory of emotions.
In the sample representation, we assume that the person/agent who first gets sight of a person/agent (s)he knows possibly smiles, and then either simply waves or stops to shake hands. Section RELATED EVENTS specifies, as a boolean combination, events that may occur contextually to the triggering ones. There are some conditions, for instance that one may smil and/or waves if (s)he is neither in a bad temper nor angry at the other. Also, one who is in a hurry just waves, while good friends or people who meet each other in a formal setting should shake hands. Actions simply consist in returning what the other one does, and it is anomalous not doing so (e.g., if one smiles and the other does not smile back). In the formalization below, the expression meet friend (A, F ) means that agent A meets agent F : then, each one possibly makes some actions and the other one will normally respond. This module is totally revertible, in the sense that it manages both the case where “we” meet a friend and the case where vice versa somebody else meets us. This is the reason why in some module sections events have no postfixes. In fact, meet friend(A,F), smile, wave and shake hands are present events if a friend meets “us”, and are actions if “we” meet a friend. Postfixes appear in the ACTIONS and ANOMALY sections, where all elements (whatever their origin) have become past events to be coped with. The PRECONDITIONS section expresses action preconditions, via connective :< . Section MANDATORY defines obligations, here via a rule stating that it is mandatory to shake hands in a formal situation. The anomaly management section (left undefined here) may include counter-measures to be taken in case of unexpected behavior, that in the example may go from asking for explanation to getting angry, etc.
EVENT-ACTION-MODULE TRIGGER meet friend (A, F ), RELATED EVENTS smile(A, F )OR (wave(A, F ) XOR shake hands(A, F ))
smileA(A, F ) :< not angry(A, F ), not bad temper (A). waveA(A, F ) :< not angry(A, F ). shake handsA(A, F ) :< good friends(A, F ), not angry(A, F ), not in a hurry(A), not in a hurry(F ).
shake handsA(A, F ) :- formal situation(A, F ).
ACTIONS smiled (A, F ) :- smileP (A, F ). waved (A, F ) :- waveP (A, F ). shaken hands(A, F ) :> shake handsP (F , A). smiled (A, F ) :> smileA(F, A). waved (A, F ) :> waveA(F, A). shaken hands(A, F ) :> shake handsA(F , A).
ANOMALY anomaly1 (meet friend (A, F )) :
smileP (A, F ), not smileA(F, A). anomaly2 (meet friend (A, F )) :
waveP (A, F ), not waveA(F, A). anomaly3 (meet friend (A, F )) :
shake handsP (A, F ), not shake handsA(F, A).
ANOMALY MANAGEMENT ACTIONS . . . 4 Formalization of Event-Action Modules In this section we provide a formalization of Event-Action modules based upon previously-introduced building blocks. To ensure integration of modules within the most common agent-oriented programming languages, we suitably merge them into the Evolutionary semantics. To provide (as a proof of concept) a formal semantics and an execution model, we define a translation of Event-Action modules into ASP modules. 4.1 Evolutionary Semantics Extended We now briefly illustrate how to refine the Evolutionary semantics so as encompass the proposed approach. The agent program PA becomes now a tuple including at least the “main” agent program PM, and the available Event-Action modules EA1, . . . , EAk. Definition 3 (Evolutionary Semantics). Let Ag be an agent, defined by agent program
PA = hPM, hEA1, . . . , EAki, . . .i where PM is the main agent program, and EA1, . . . , EAk, k Event-Action modules.
0, are the available
Its evolutionary semantics is "Ag = hH, PExt , M Ei. The program evolution sequence, indicated by PExt , stems from an Extended initial program PExt 0 obtained from PM by means of a a suitable initialization phase. In particular, PExt 0 includes the following elements: – Program P0, obtained by adding to given main agent program the rules included in sections ACTIONS, ANOMALY MANAGEMENT ACTIONS and PRECONDITIONS of EA1, . . . , EAk. – Tuple of ASP modules h⇧ 1, . . . , ⇧ ki, where each ⇧ i is obtained by translating Event-Action module EAi into ASP.
At the i-th evolution step, the agent’s history in general evolves, as new events/knowledge items may be recorded/removed. This determines an evolution of both the main agent program Pi and of the ASP modules: in fact, the main program and the modules implicitly encompass the agent’s history as the set of given facts. This implies that both the main program and modules semantics needs to be re-evaluated at each step. Each module will admit none, one or several answer sets, among which just one has to be selected. Such answer set will encompass a number of inferred complex events and actions, as well as possibly a number of anomalies, that have to be added to the agent’s history in order to be respectively reacted to (for events) or executed (for actions) or coped with (for anomalies). Precisely, at each step we have: Definition 4 (Evolutionary Semantics Snapshot). The snaphot at stage i of "iAg is the tuple hHi, PExt i, Mii, where Mi is in turn a tuple, i.e.,
Mi = hFi, S1, . . . , Sri where Fi is the semantics of Pi, and Si (i r k) is the set composed of the answer sets of each ⇧ i which has been (re-)evaluated at stage i. The evolution step to stage i + 1 will imply: (i) the choice of one answer set Ai for each ⇧ i (selected among the elements of Si); (ii) and the addition to Hi+1 of all the complex events and actions and anomalies included in Ai.
Therefore, at step i + 1, complex events, actions and anomalies generated at step i by each ASP module will be coped with as specified in the original corresponding Event-Action module, and then recorded as past events in the agent’s history.
In summary, the integration of Event-Action modules within a logical agent’s basic functioning can be described as follows.
– At every agent’s evolution step, the TRIGGER headline of each Event-Action module has to be checked, in order to state whether the module is to be re-avaluated. We cannot treat here complexity of this check, that will depend upon complexity of expressions involved. – ASP modules corresponding to Event-Action modules that are to be (re-)evaluated will be fed to an answer set solver. A module will admit as a result of evaluation none, one or more answer sets. – If the module admits answer sets, each one will encompass a number of complex events, actions and anomalies. One answer set will be selected, according to preferences (if expressed within the module), or by random choice, or by informed choice deriving from a learning process, as discussed in Section 5. The rules for coping with the inferred complex events, actions and anomalies are defined in sections ACTIONS, ANOMALY MANAGEMENT ACTIONS and PRECONDITIONS, which can be found in the main agent program. 4.2
ASP Representation of Modules Each Event-Action module can be translated in a fully automated way into an ASP module. This except sections ACTIONS, ANOMALY MANAGEMENT ACTIONS and PRECONDITIONS, whose content as seen before has to be added to the main agent program.
The answer set program (module) ⇧ corresponding to a given Event-Action module will be obtained by translating into ASP the contents of sections COMPLEX EVENTS, CHECK, RELATED EVENTS, ANOMALIES and MANDATORY. The translation is straightforward and can be fully automated.
For the sake of simplicity we outline a translation into basic ASP, thus not
considering the various additional useful constructs that have been introduced in the literature
and in the implementations. It can be noted that extensions of ASP oriented to stream
reasoning have been defined (cf., e.g., [
For lack of space we cannot properly describe how to cope with time intervals: however, our method consists in representing time-stamps as additional arguments of ASP predicates representing events. Intervals are then computed by trivial arithmetic constraints.
The translation of (the relevant sections of) an Event-Action module into ASP can be performed by means of the following guidelines (a formal definition of the translation, including the treatment of time intervals, is deferred to an extended version of this paper). conj In ASP, the conjunction among a number of elements a1, . . . , an is simply expressed as conj a1, . . . , an. or-xor Disjunction among two elements a and b is expressed by the cycle a b b a. This disjunction is not exclusive, since either a or b or both might be derived elsewhere in the program. To obtain exclusive disjunction, a constraint a, b must be added. A constraint in ASP can be read as it cannot be that.... In the case of exclusive disjunction, it cannot be that both a and b belong to the same answer set. Disjunction (also exclusive) can be expressed also on several elements. choice Choice, or possibility, or hypothesis, expressing that some element a may or may not be included in an answer set, can be expressed by means of a cycle involving a fresh atom, say na. The cycle is of the form a na na a. Therefore, an answer set will contain either a or na, the latter signifying the absence of a. choyf A choice that can be done (by pattern choice) on element a only if certain conditions Conds are satisfied, is expressed by a choice pattern plus a rule c Conds and a constraint a, not c. The constraint states that a cannot be hypothesized in an answer set if c does not hold, i.e., if Conds are not implied by that answer set. mand Mandatory presence in an answer set of atom a defined by rule a Body whenever Body is implied by that answer set can be obtained as follows. In addition to the defining rule a Body , a constraint must be added of the form not a, Body stating that it cannot be that an answer set implies Body but does not contain a. The constraint is necessary for preventing a to be ruled out by some other condition occurring elsewhere in the program. – Events in the RELATED EVENTS section can be expressed by means of the choice pattern, and their combinations via the conj and or-xor patterns. Constraints in the MANDATORY can be expresses by means of the mand pattern. – Section COMPLEX EVENTS is coped with by the choice and choyf patterns. – Sections CHECK and ANOMALIES can be translated by a plain transposition of their rules into ASP, possibly exploiting the conj and or-xor patterns. 5
Evaluating Outcomes and Reinforcement Learning
Outcomes of an Event-Action Module are often not univocal: thus, at each stage the
agent face a choice among the answer sets of corresponding ASP module ⇧ . As we
have seen in the example, preferences may help the agent in choosing an outcome rather
than another one. However, knowledge can be incomplete or partial about reliability of
such preferences, and in general about plausibility of the choice. This choice is akin to
the “multi-armed bandit problem” [
Therefore, a self-improving process is in order, and for this purpose, an agent can be
endowed with a simple reinforcement learning mechanism [
Qt+1(A) = Qt(A) + ↵. (V t(A)
Qt(A)) where ↵ is the discount rate. Then, an agent draws an answer set A amongst all the possible answer sets A1, . . . , Ak of ⇧ with probability P t(A). This probability can be computed using a Gibbs-Boltzmann distribution:
P t(M ) = eQt(A)/⌧ / X eQt(Ai)/⌧
i where ⌧ is a ‘learning temperature’ to balance the exploitation and the exploration of possible models. 6
Concluding Remarks In summary, in this paper we have introduced kinds of Event-Action modules that allow an agent to: aggregate simple events into complex ones, also according to constraints; check events that occur w.r.t. expectations; cope with events possibly occurring contextually to certain other events; detect anomalies; decide actions to be performed in both normal or anomalous cases, according to a number of issues among which we may include context, role, circumstances, past experience, etc.
In future work, other event aggregation and recognition patterns might be introduced. The approach might be extended to a more involved definition of complex actions, and to the choice among possible action patterns. The proposed simple learning mechanism might be refined based on experimentations on suitable test cases. We may notice that the approach is basically independent of the underlying logic, so that more expressive (e.g., modal) logic might be employed in future extensions. Clearly, a semantics and execution model going beyond ASP should then be provided.
We intend to introduce forms of ’deep’ learning of Event-Action modules. In our
intention, an Event-Action Modules might be initially defined in a tentative or
embryonic form: then, module elements might be learnt via a training phase, and refined via
reinforcement learning during the agent’s ’life’ thus adding to agent’s flexibility and
adaptability. To this aim, we have been developing suitable argomentation-based
learning techniques [
We do not intend to claim that all events can be recognized and reacted to, and all actions generated, only in a logic-based way. Nevertheless, also based upon relevant literature, we claim that event/actions recognition, generation and management oftens require forms of (even non-trivial) reasoning. Overall, any really “intelligent” agent capable of flexible interaction with complex real-world environment will presumably result from a graceful integration of several kind of components, possibly based upon different approaches.