agents. He can ask the agent to perform a certain ac-
tion, assign some declarative goal to it, or can query
the agent’s local knowledge base.
The ISReal agent architecture is based on the
Belief, Desire, Intension (BDI) architecture (Rao95)
which is well suited for dynamic and real-time envi-
ronments. Figure 3 depicts an overview of the ISReal
agent architecture. We distinguish between the agent
core, which encompasses the core functionality pro-
vided by an agent execution platform, and the Local
Semantic Environment (LocalSE), which extends the
core with (i) an OWL-based KB (referred to as KB
a
),
(ii) a reasoner, and (iii) a Service Composition Plan-
ner (SCP). An agent directly controls its avatar (vir-
tual body of an agent) which is situated in the virtual
world. The interface of the agent to its virtual envi-
ronment is realized by sensors and actuators. Sensors
generate perceptions that contain information about
semantic objects. Actuators are realized as semantic
services that are offered by the agent itself or by the
semantic objects the agent can interact with. The per-
ception component is introduced in Section 2.3.1, the
information component in Section 2.3.2, and the be-
havior component in Section 2.3.3.
2.3.1 Perception Component
Sensors provide an agent with perceptions from its
current environment. The perceptions in the ISReal
platform are caused by the RTSGE which manages
the X3D-based scene graph. Since the X3D standard
does not specify the kind of sensor that is required by
ISReal agents, it is necessary to extend RTSGE with
the required functionality. Agents connected to the
ISReal platform perceive only semantic objects (see
Section 2.1). A perception event contains following
information: (i) the object’s ID in the scene graph,
(ii) the object’s individual URI, (iii), the object’s con-
cept URI, (iv) the URIs to the object services, and
(v) the URIs to the context rules assigned to the ob-
ject. The perception handling of the agent is done in
the following order: (i) receive the perception event
coming from the environment, (ii) use the individual
URI to get the corresponding ontological facts from
the GlobalSE, and (iii) add these facts to the KB
a
of
the agent’s LocalSE (see Figure 3). Additionally, add
the URIs of the object services to the respective lists
S
a
in the LocalSE.
2.3.2 Information Component
To enable agents to process OWL-based information
we extended the agent core with the LocalSE. Equiva-
lent to the GlobalSE the LocalSE consists of an OMS
that can be queried in the same three ways. Initializ-
ing an agent (and with it its LocalSE) the LocalSE has
only a partial description of the world representing the
knowledge KB
a
the agent has in this scenario. The
main difficulty is to integrate the LocalSE in a trans-
parent way, so that the agent’s internal mechanisms
do not break. The information component provides
a transparent layer between the agent and its KB
a
. It
provides functionality for (i) updating and inserting
facts into the KB
a
, and (ii) reasoning about informa-
tion in the KB
a
. This functionality is used by the be-
havior component to access the KB
a
. For example,
we use SPARQL queries in the context condition of
BDI plans.
2.3.3 Behavior Component
Classical first-principles planning starts from a given
world state and tries to reach an also given goal state
by the application of a set of operators. The whole
planning process is done off-line, meaning no changes
are incorporated during the planning process. BDI-
based planners rely on a plan library that provides the
agent with plan templates that guide its execution in
certain situations (usually defined by relevance con-
ditions and context condition). Because of the plan
library, BDI systems are more efficient than classical
planners. Their drawback is that they fail as soon as
no plan is applicable in the current situations, even if
there exists a combination of their plans that achieves
a given goal. A further difference is that BDI agents
directly execute the actions of a chosen plan tem-
plate and incorporate incoming events, while classical
planners finish the complete planning process before
the plan can be executed. One important distinction
is the difference between declarative goals (state de-
scriptions) like they are used in traditional planning
problems and procedural goals (goal events) of BDI
systems that are used to trigger actions (Win02).
The ISReal agent architecture combines the effi-
ciency of BDI-planners and the flexibility of classi-
cal planners. An agent’s core functionality is imple-
mented as BDI plans and (goal) events. We consider
two situations in which a BDI agent benefits from the
invocation of a classical planner. The first case occurs
when there is no applicable plan in the agent’s plan li-
brary for the current situation. The agent invokes the
classical planner to explore new plans that have not
been defined at design-time. The second case occurs
when the user assigns a declarative goal to the agent
to reach a certain state. The agent can pass this goal to
its SCP and gets back a plan consisting of a sequence
of services. The agent can either map these services
to existing BDI plans or invoke the corresponding ob-
ject services directly.
INTELLIGENT AGENTS FOR SEMANTIC SIMULATED REALITIES - The ISReal Platform
75