Artem Katasonov University of Jyvskyl 31.10.2007 - PowerPoint PPT Presentation


PPT – Artem Katasonov University of Jyvskyl 31.10.2007 PowerPoint presentation | free to download - id: 114128-OTk4M


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Artem Katasonov University of Jyvskyl 31.10.2007


2. Ontological approaches to inter-agent coordination ... An ontological framework for dynamic coordination. In Proc. ... Motivation: APL for ontological modeling ... – PowerPoint PPT presentation

Number of Views:151
Avg rating:3.0/5.0
Slides: 38
Provided by: kson2
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Artem Katasonov University of Jyvskyl 31.10.2007

Artem KatasonovUniversity of Jyväskylä31.10.200
Semantic Approach to Engineering Agent-Based
  • Benefits and drawbacks of Agent-Oriented Software
    Engineering (AOSE)
  • Motivation for our approach
  • SmartResource / Ubiware platform
  • Semantic Agent Programming Language (S-APL)

Roots of the agent technology
Artificial Intelligence
Structured Programming
Client Server Architectures
Distributed AI
OO Programming
Peer to Peer Architectures
Agent Technology
Communication Philosophy
Speech Acts
Social Sciences
Agent-Oriented Software Engineering (AOSE)
  • From the implementation point of view, agents are
    a next step in the evolution of software
    engineering approaches and programming languages.
  • It is a step following the trend towards
    increasing degrees of localization and
    encapsulation in the basic building blocks of the
    programming models
  • Structures (e.g., in C) localizing data
  • Objects (e.g., in C and Java) localizing, in
    addition, code, i.e. an entitys behavior
  • Agents localizing, in addition, the purpose of
    existence, the thread of control and logic of
    action selection.
  • An agent is a programming entity that is
    autonomous in run-time, does not need to be
    directly controlled.
  • When we apply AOSE, not only the system as a
    whole, but also its components are autonomous,
    i.e. agents.

  • OOSE
  • Stakeholders, their goals, knowledge, intentions,
    collaboration, etc.
  • Components, objects, their services, invocations,
    dependencies, etc

AOSE Stakeholders, their goals, knowledge,
intentions, collaboration, etc. Agents, their
goals, beliefs, intentions, communication, etc.
Drawback of AOSE
  • Although the flexibility of agent interactions
    has many advantages when it comes to engineering
    complex systems, the downside is that it leads to
    unpredictability in the run time system as
    agents are autonomous, the patterns and the
    effects of their interactions are uncertain.
  • It is common in specific systems and applications
    to circumvent these difficulties, i.e. to reduce
    the systems unpredictability,
  • By using interaction protocols whose properties
    can be formally analyzed
  • By adopting rigid and preset organizational
  • By limiting the nature and the scope of the agent
  • These restrictions also limit the power of the
    agent-based approach thus, in order to realize
    its full potential some longer term solutions are
  • Emergence of a solution that would allow flexible
    yet predictable operation of agent systems seems
    to be a prerequisite for wide-scale adoption of

N.R. Jennings. On agent-based software
engineering. Artificial Intelligence,
117(2)277296, 2000.
Direction towards solution 1
  • 1. Social level characterization of agent systems
  • The need for a better understanding of the impact
    of sociality and organizational context on an
    individuals behavior and of the symbiotic link
    between the behavior of the individual agents and
    that of the overall system (Jennings, 2000).
  • Modeling agent organizations in a way similar to
    human organizations
  • Researchers in multi-agent systems have
    contributed with, among others, various
    methodologies for designing MAS, such as Gaia,
    TROPOS, and OMNI.
  • Such methodologies normally focus on the notion
    of an organizational role
  • Organizational policies, norms

N.R. Jennings. On agent-based software
engineering. Artificial Intelligence,
117(2)277296, 2000.
  • Organizational Model for Normative Institutions
    (OMNI) allows the balance of global
    organizational requirements with the autonomy of
    individual agents.
  • OMNI
  • elaborates on the organizational context of a
  • defines the relationship between organizational
    roles and agents enacting those roles,
  • discusses how organizational norms, values and
    rules are supposed to govern the organizations
    behavior and thus to put restrictions on
    individual agents behaviors,
  • defines abstract languages for specification of
    norms, values and rules.

J. Vazquez-Salceda, V. Dignum, and F. Dignum.
Organizing multiagent systems. Autonomous Agents
and Multi-Agent Systems, 11(3)307360, 2005.
OMNI (2)
  • OMNI touches only on a very abstract level the
    question about how the individual agents will be
    implemented or even function the agents are
    treated as rather atoms.
  • One reason is that it is (reasonably) assumed
    that the agent organizations designer may have
    no direct control over the design of individual
  • The organization designer develops the rules to
    be followed and enforcing policies and entities,
    such as police agents, while development of
    other agents is done by external people or
  • One of few concrete implementation requirements
    mentioned in OMNI is that a rule interpreter must
    be created that any agent entering the
    organization will incorporate, somehow.
  • OMNI framework also includes explicitly the
    ontological dimension, which is restricted,
    however, to a domain ontology only.

Direction towards solution 2
  • 2. Ontological approaches to inter-agent
  • To enable agents to communicate their intentions
    with respect to future activities, and reason
    about them in real time (Tamma et al.,2005).
  • To enable individual agents to represent and
    reason about the actions, plans, and knowledge of
    other agents to coordinate with them (Jennings et
    al., 1998).
  • Is not yet studied much by the scientific
    community. Tamma et al.,2005 is one of the first
    endeavors into this direction, which however only
    introduced and analyzed some of the relevant
    concepts, such as resource, activity, etc.

V.A.M. Tamma, C. Aart, T. Moyaux, S. Paurobally,
B. Lithgow-Smith, and M. Wooldridge. An
ontological framework for dynamic coordination.
In Proc. 4th International Semantic Web
Conference05, LNCS vol. 3729, pages 638652.
Springer, 2005. N.R. Jennings, Sycara K. P., and
M. Wooldridge. A roadmap of agent research and
development. Autonomous Agents and Multi-Agent
Systems, 1(1)738, 1998.
Ontologies that need to be shared
  • ExtOnt(A) - properties of the external world
  • MentOnt(A) - internal mental properties of the
  • BodyOnt(A) - properties of the agent's (physical)
  • InOnt(A)
  • - properties of the sensory input
  • - properties of the communication input
  • OutOnt(A)
  • - properties of the action output
  • - properties of the communication output
  • Domain ontology
  • E.g. BDI model
  • Available sensors and actuators
  • Sensing vocabulary
  • E.g. FIPAs ACL
  • Acting vocabulary
  • E.g. FIPAs ACL

Are not really treated
Motivation APL for ontological modeling
  • Conclusion from the previous slide Need to be
    able to ontologically describe not only the
    domain, but the agents themselves.
  • How to model agents? Agent Programming Languages
    (APLs) are an obvious and already elaborated
  • Normally, APL code is assumed to be written by
    the developer of an agent and either compiled
    into an executable program or interpreted in
    run-time but remaining an agents intrinsic and
    static property.
  • Normally, APL code is not assumed to ever come
    from outside of the agent in run-time, neither
    shared with other agents in any way (except
    approaches where the agents are able to
    communicate their plans encoded in an APL).

Motivation Externalization of APL code
  • Methodologies like OMNI describe a role with a
    set of rules, and APLs are rule-based languages.
    So, using an APL for specifying a role is
  • Then, APL code corresponding to a role should
    naturally be a property of and controlled by the
    organization, and accessed by the agents enacting
    the role potentially even in the run-time.
  • This would also enable the organization to modify
    the role code if needed.
  • Additionally, the agents may access a roles APL
    code not only in order to enact that role, but
    also in order to coordinate with the agents
    playing that role
  • An agent can send to another agent a part of its
    APL code to communicate its intentions with
    respect to future activities.
  • If a roles code is made public inside the
    organization, the agents may access it in order
    to understand how to interact with, or what to
    expect from, an agent playing that role.

Motivation Semantic APL
  • In other words, why normally the role of APL code
    is not considered beyond the development stage,
    we propose to do exactly that to extend the
    role of APL into the run-time stage.
  • Problems, if to consider existing APLs
  • Semantics of n-ary predicates is difficult to
    explicitly define, e.g. SendMessage (A, B, C)
    who sends what to who?
  • Code in existing APLs is, roughly speaking, a
    text. A database-based solution would be better
  • To manage huge amounts of data (beliefs, rules)
  • To be able to easily access a part of the code,
    not the whole document
  • Solution RDF-based APL
  • RDF data model, i.e. set of subject-predicate-obje
    ct triples, allows explicit definition of
    semantics. Languages for that exist, such as OWL.
  • Triples can be stored in a database. Can be
    Oracle or free ones Sesame, Joseki.

Motivation Summary
  • In a nutshell
  • Lets start treating agents programs as data
  • If it is data, lets use the semantic approach
    (advantages are well-known)

SmartResource Platform
  • Ongoing effort at the University of Jyväskylä.
  • One of the results of the SmartResource project
    2004-2007. Is further developed in the follow-up
    UBIWARE project 2007-2010.
  • May be seen as extension of JADE with a cognitive
    agent architecture.
  • Major distinctive features
  • Utilization of the RDF-based Semantic Agent
    Programming Language (S-APL), instead of common
    Prolog-like languages.
  • S-APL programs are one per organizational role,
    not one per agent.
  • Externalization of behavior prescriptions, i.e.
    agents access S-APL documents from organizational
  • Perceptors and actuators (called reusable atomic
    behaviors) are dynamically managed and can also
    be accessed from organizational repositories.

3-Layer Agent Architecture
Ubiware Agent
Behavior Models
Assign Role
Beliefs storage
Reusable atomic behaviors (RABs)
Layer 1 Reusable atomic behaviors (RABs)
  • A piece of JAVA code, implementing a reasonably
    atomic function (action or data adaptation)
    perceptors, actuators, and reasoners.
  • Reusable across scenarios, agents and roles.
  • Examples of RABs in the current version
  • Shared
  • Request Sender Request Receiver
  • Data Sender Data Receiver
  • Http Data Fetcher
  • Email Sender
  • External Application Starter
  • Directory Lookup (for agents playing a role)
  • Simple Select
  • Create Agent
  • E.g. ABB-prototype specific ones (mainly
  • Generating KML data for Google Earth
  • Processing weather information

Layer 2 Behavior models
  • An RDF-based encoding of the behavior model
    corresponding to an agent role
  • In Semantic Agent Programming Language (S-APL).
  • One per defined role.
  • Specifies initial beliefs (including knowledge,
    goals, commitments, and behavioral rules) of the
    agent in the role.
  • Commitments and behavioral rules normally lead to
    adding/removing beliefs and executing various
  • Examples of roles operators agent, feeder
    agent, agent of feeder N3056, fault localization
    service agent, ABB fault localization service
    agent, etc.
  • A general role can be played by several agents.
  • One agent can (and usually does) play several
  • Recommendation other agents, with who there is a
    need of communication, are to be identified by
    their roles not by their unique names.

Layer 3 Behavior engine
  • The same for all agents (each has a copy of it).
  • The main shell class
  • Core of a SmartResource agent for the JADE
    middleware framework.
  • Assign Role activity
  • Parses an S-APL document and loads it into the
    beliefs storage
  • Registers the new role with the system Directory
    Facilitator agent.
  • Live activity
  • Iterates through all the behavior rules, checks
    them against existing beliefs and goals, and
    executes the appropriate ones.
  • Fulfills the commitments adds/removes beliefs,
    executes RABs

Externalization of behavior models
Ubiware Agent
Behavior Models
Assign Role
Beliefs storage
  • Advantages include
  • Flexibility for control and coordination
  • Remote control
  • Up-to-date behavior models
  • An agent may learn how to play a new role in
  • Inter-agent behavior awareness
  • To understand how to interact with another agent
  • To coordinate behavior of several agents

On-demand access of RABs
Ubiware Agent
Behavior Models
Assign Role
Beliefs storage
  • Added advantages
  • Ability to learn new behaviors
  • Light start with on-demand extension of

Starting SmartResource agents
  • Following the JADE convention ltnamegtubiware.core
  • ltscriptsgt is the star() separated list of the
    initial behavior models
  • ltrolesgt is plus() separated list of the roles.
  • Platform provides the behavior model
    startup.sapl, which has to be loaded by an agent
    at startup in order to enable it to remotely
    access behavior models from an OntologyAgent.
  • Parameter ltrolesgt is needed only in startup.sapl
    is one of the scripts
  • Includes also the rule for engaging
  • Platform provides also the behavior model
    RABLoader.sapl, which has to be loaded by an
    agent in order to enable it to remotely access
    atomic behaviors from an OntologyAgent.
  • It includes rules for requesting, receiving, and
    (if needed) unzipping the behavior files.

Interaction scenario Agent creation
6. Load received scripts
1. Load
4. Give scripts for the roles FeederAgent,
Feeder1 and RABLoader
3. Agent named Ontology
2. Who plays the role OntologyAgent?
In run.bat Feeder1ubiware.core.
UbiwareAgent(DB/startup.sapl, FeederAgentFeeder1
Scenario Auction for service selection
7a. I have that role already
7b. Operator has right of doing such requests.
I need to load that role
10. LS1 and LS2 make offers 11. Operator selects,
say, LS1 12. Operators makes service transaction
with LS1
5. Load Role Auction Seller
6. Make Offer on Price
3. What is the rule for resolving this?
2. Agents LS1 and LS2
1. Who plays the role LocalizationService?
4. Starting Auction
Semantic Agent Programming Language (S-APL)
  • Everything is a belief. All other mental
    attitudes such as desires, goals, commitments,
    behavioral rules are just complex beliefs.
  • Every belief is either a semantic statement
    (subject-predicate-object triple, e.g. John
    Loves Mary) or a linked set of such statements.
  • Every belief belongs to a context container that
    restricts the scope of validity of that belief.
    Beliefs have any meaning only inside their
    respective contexts (this convention goes beyond
    normal RDF where everything is global truth).
  • Statements can be made about contexts, i.e.
    contexts may appear as subjects or/and objects of
    triples. Such statements give meaning to
    contexts. This also leads to a hierarchy of
    contexts (not necessarily a tree structure
  • There is the General Context G, which is the root
    of the hierarchy. G is the context for global
    beliefs of the agent (what it believes to be true
    here and now ). Nevertheless, every local belief,
    through the hierarchical chain of its contexts,
    is linked to G.

S-APL notation (subset of Notation3)
  • A statement is a white-space-separated sequence
    of subject, predicate and object, i.e. S P O
  • Dot ( . ), followed by a white space, separates
    statements of the same level, i.e. S P O . S P O
  • Semicolon ( ) , followed by a white space,
    allows making several statements about the same
    subject, i.e. S P O P O
  • Comma ( , ) , followed by a white space, allows
    making several statements having common subject
    and predicate, i.e. S P O , O
  • denotes reification, it may appear as the
    subject or the object of a statement and has to
    include inside itself one or more other
    statements, e.g. S P S P O or S P O P S
    P O . Reification always implies a context
    however, the relation is not necessarily 1-to-1.
    E.g. S P O P O P O implies that the statement
    in is linked to two different contexts defined
    as given.
  • Colon ( ) is used to specify an URI as a
    combination of the namespace and the local name,
    i.e. nslocalname There can be default namespace,
    the colon is used anyway, i.e. localname
  • _at_prefix prefix namespace links a prefix to a
  • URIs given directly are to be inside lt gt, i.e.
  • Literals containing whitespaces are to be inside
    , i.e. some literal
  • Comments are java-style, i.e. / /

S-APL simple beliefs
  • Simple belief (two below are equivalent)
  • John Loves Mary
  • John Loves Mary gbis gbtruth
  • Complex belief
  • John Loves Mary accordingTo Bill
  • Goal / desire
  • gbI gbwant John Loves Mary
  • The prefix gb is used here to denote the
    ontology of S-APL
  • In S-APL, making a statement has the meaning of
    adding it to the agents beliefs.

S-APL commitments
  • Unconditional commitment to an action
  • gbI gbdo javaubiware.shared.RequestSenderBehav
  • gbconfiguredAs
  • xreceiver gbis John .
  • xcontent gbis bla bla .
  • gbSuccess gbadd John was notified
  • Special statements to add or remove beliefs the
    subject can be gbStart, gbEnd, gbSuccess, and
    gbFail. The predicate is either gbadd or
  • Sequential plan
  • gbI gbdo ... gbconfiguredAs
  • ... gbSuccess gbadd gbI gbdo ...

S-APL commitments (2)
  • Unconditional commitment to removing a belief
  • gbI gbremove John Loves Mary
  • Conditional commitment
  • John Loves Mary gt
  • gbI state busy .
  • gbI gbdo aSendMail gbconfiguredAs
  • gt is the shorthand for gbimplies. If the left
    side of gt is truth (beliefs are connected with
    AND), the right side is copied into G. The
    commitment is removed after that.
  • Conditional commitment that creates another
    conditional commitment
  • ... gt ... gt ...

S-APL additional conditions
  • Exclusive condition
  • John Loves Mary .
  • gbI gbdoNotBelieve John was notified
  • gt ...
  • If the object of gbdoNotBelieve matches G, the
    left side of gt is false. If there are several
    gbdoNotBelieve, they are connected with OR)
  • Commitment with a guard condition
  • ... gt ... gbis gbtruth
  • gbexistsWhile ...
  • If the object of gbexistsWhile is false, its
    subject is removed in this case, the commitment
    is dropped.

S-APL additional conditions (2)
  • Prerequisites
  • ... gt ... gbrequires ...
  • If the left side of gt is truth but some of the
    conditions in the object of gbrequires are
    false, those are wrapped as gbI gbwant .. (i.e.
    as goals) and added to G
  • Action that attempts achieving a goal
  • gbI gbwant John Loves Mary gtgt ...
  • gtgt is the shorthand for gbachievedBy. It works
    similar to gt but, in addition, the goal is
    removed (technically, it is moved to context for
    goals under work).
  • Persistent behavior rule (not removed upon
  • ... gt ... gbis gbRule

S-APL querying constructs
  • Matching with variables
  • John Loves ?x accordingTo ?y. ?x gbis
    Girl gt
  • gbI gbdo aSendMail gbconfiguredAs
  • xreceiver gbis ?x...
  • If there can be found some values of ?x and ?y so
    that the beliefs are present in G, the rule will
    be executed. The variables will be bind to the
    first found matching values, and those will be
    used in the right side of gt
  • In future, we plan to introduce gbAll ?x so
    the rule will be executed for all matching values
    of a variable.
  • Matching with (gbAnything)
  • John Loves gt
  • Filtering predicates (evaluated by the agents
    engine rather than matched against G)
  • ?x gt 5. ?y gbregex S.h (lt ,lt , gt)

(No Transcript)
Inter-agent communication
  • Uses S-APL as well
  • E.g. request
  • gbI gbwant gbYou gbanswer
  • ?x Loves ?y gbAll ?x
  • Response is one of
  • John Loves Mary
  • gbI gbdoNotBelieve ?x Loves ?y
  • Request for action
  • gbI gbwant gbYou gbdo ...
  • gbconfiguredAs ...

Advantages of S-APL
  • Simple model (triples in hierarchical contexts)
    that allows implementing any feature found in
    existing APLs.
  • Expressive power is even greater than in existing
    APLs, because of full symmetry (everything is a
    belief) e.g. rules upon execution can add other
    rules of any complexity.
  • Behavior specification is done using semantic
    predicates (e.g. implies, existsWhile)
  • Formally defined in an ontology.
  • Language is extensible with other such
  • Reusable Atomic Behaviors and their parameters
    are also resources that can (and should) be
    ontologically modeled.
  • So, there is a basis for sharing all 5 ontologies
    (Ext, Ment, Body, In and Out), and thus for
    better understanding among agents.

SmartResource Platform Future work
  • What mechanisms are needed for flexibly treating
    the potential (and likely) conflicts among the
    roles played by one agent?
  • How to implement the separation between a roles
    capabilities (individual functionality), and the
    business processes in which this role can be
    involved (complex functionality)?
  • What would be concrete benefits of and what
    mechanisms are needed for accessing and using a
    roles script by agents who are not playing that
    role but wish to coordinate or interact with an
    agent that does?
  • How to realize an agents roles as higher-level
    commitments of the agent that restrict its
    behavior, still leaving freedom for learning and
    adaptation on lower-levels, instead of totally
    and rigidly prescribing the behavior?