Date post: | 10-May-2015 |
Category: |
Education |
Upload: | easss-2012 |
View: | 542 times |
Download: | 4 times |
Organisation and Environment
Oriented Programming
Olivier Boissier1, Rafael H. Bordini2,Jomi F. Hubner3, Alessandro Ricci4
1EMSE, [email protected]
2PUC-RS, [email protected]
3DAS-UFSC, [email protected]
4University of Bologna, [email protected]
European Agent Systems Summer SchoolMay, 2012 — Valencia, Spain
Outline of the course
Introduction
EOP
About Environment Oriented ProgrammingA&A and CArtAgO
OOP
About Organisation Oriented ProgrammingMoise
Conclusions
Practical Exercise: a hands-on lab session!
Introduction
Introduction EOP OOP Conclusion
Abstractions in Multi-Agent Systems
roleorgmission
schema
ORGAMISATIONLEVEL
AGENTLEVEL
ENDOGENOUSENVIRONMENTLEVELwsp
artifact
network node
EXOGENOUS ENVIRONMENT
agent
4 / 165
Introduction EOP OOP Conclusion
Abstractions in Multi-Agent Systems
Individual Agent Level: autonomy, situatedness
Cognitive Concepts: beliefs, desires, goals, intentions, plansReasoning Cycle: sense/reason/act, reactive/pro-activebehaviour
Environment Level: resources and services that agents canaccess and control; sensing and acting in an environment
Social and Organisation Level: cooperation, coordination,regulation patterns
Roles: rights, responsibilities, ...Organisational Rules: constraints on roles and theirinteractions, norms, deadlines, ...Organisational Structures: topology of interaction patternsand relations over activity control
5 / 165
Introduction EOP OOP Conclusion
Agent Oriented Programming
Proposed by Shoham [Shoham, 1993]
Use of mentalistic notions and a societal view ofcomputation (anthropomorphism)
Levels of abstraction: Agents – Organisations – Environment
Programming languages for agents have developed a lotsince then, but still not a mature paradigm
Programming languages/platforms for organisation andenvironment are also being developed
Some agent development platforms have a formal basis
Many influenced by the BDI agent architecture
6 / 165
Introduction EOP OOP Conclusion
BDI Architecture
Intentional Stance (Dennett)
Practical Reasoning (Bratman)
IRMA (Bratman, Isreal, Pollack)
PRS (George↵, Lansky)
dMARS (Kinny)
BDI Logics and Agent Architecture (Rao, George↵)
Wooldridge, Singh, ...
7 / 165
Introduction EOP OOP Conclusion
Programming Languages for Cognitive Agents
Programming Languages for Multi-Agent SystemsE.g., Jason, Jadex, JACK, 2APL, GOAL, Brahms, JIAC, Agent
Factory, MetateM, Golog variants, ...
Architecture to represent an agent mental state:
Beliefs: information available to agent (e.g., about theenvironment or other agents)Goals: states of a↵airs that the agent wants to achieveEvents: changes in agents beliefs or goalsCapabilities: reusable modules of activities that the agentcan performPlans: reasoning about courses of action to achieve goalsRules: reasoning about beliefs
8 / 165
Introduction EOP OOP Conclusion
Programming Languages for Cognitive Agents
Some steps of a Reasoning Cycle:
Determining Relevant Plans for Handling EventsSelect a Plan for ExecutionExecute Part of an Intended PlansHandle Plan Failures
Agent Interpreter is an infinite loop of such reasoning cycles.The architecture and reasoning cycle together with the agentprogram (specially plans) determine the behaviour of the agent.
9 / 165
Introduction EOP OOP Conclusion
Programming Languages/Platforms for Organisations
Concepts used to specify the state of an organisation:
Agents, Roles, GroupsNorms, Obligations, Prohibitions, Permissions, ViolationsDependency, Power, Delegation, Information flow relationsDeadlines, Sanctions, Rewards
Management Infrastructure to control and coordinateagent behaviour at run-time:
Endogenous: The control is a part of the agent programExogenous: The control is performed by an external system
Monitoring Agent BehaviourEnforcing Organisational RulesRegimenting Organisational Rules
10 / 165
Introduction EOP OOP Conclusion
Programming Languages/Platforms for Environments
Artifacts to represent the state of the environment
Access to Databases/Services/etc., Coordination, InteractionEnvironment “objects”, i.e., non-proactive entities
Processing Operations on Artifacts
Realising the e↵ects of environments actionsProviding events related to sensing the environmentSynchronising agent actions
At the right level of abstraction for a multi-agent system
11 / 165
Introduction EOP OOP Conclusion
Hands-on Part of this Course
We will use JaCaMo
First fully operational, unified platform covering the 3 mainlevels of abstractions for multi-agent oriented programming
JaCaMo = Jason + CArtAgO + Moise
http://jacamo.sourceforge.net
http://jason.sourceforge.net
http://cartago.sourceforge.net
http://moise.sourceforge.net
More than the sum of 3 successful platforms
Revealing the full potential of Multi-Agent OrientedProgramming
12 / 165
Environment OrientedProgramming— EOP —
Outline
2 Environment ProgrammingWhy Environment Programming in MASBasic LevelAdvanced LevelA&A and CArtAgOConclusions and Wrap-up
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Back to the Notion of Environment in MAS
The notion of environment is intrinsically related to thenotion of agent and multi-agent system
“An agent is a computer system that is situated in some
environment and that is capable of autonomous action in
this environment in order to meet its design
objective” [Wooldridge, 2002]“An agent is anything that can be viewed as perceiving
its environment through sensors and acting upon the
environment through e↵ectors.
” [Russell and Norvig, 2003]
Including both physical and software environments
15 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Single Agent Perspective
ENVIRONMENT
feedback
actions
percepts
effectors / actuators
sensors
action to
do
PERCEPTION
DECISION
ACTION
Perception
process inside agent inside of attaining awareness orunderstanding sensory information, creating perceptsperceived form of external stimuli or their absence
Actions
the means to a↵ect, change or inspect the environment
16 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Multi-Agent Perspective
In evidence
overlapping spheres of visibility and influence..which means: interaction
17 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Why Environment Programming
Basic level
to create testbeds for real/external environmentsto ease the interface/interaction with existing softwareenvironments
Advanced levelto uniformly encapsulate and modularise functionalities ofthe MAS out of the agents
typically related to interaction, coordination, organisation,securityexternalisation
this implies changing the perspective on the environment
environment as a first-class abstraction of the MASendogenous environments (vs. exogenous ones)programmable environments
18 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Environment Programming: General Issues
Defining the interface
actions, perceptionsdata-model
Defining the environment computational model &architecture
how the environment worksstructure, behaviour, topologycore aspects to face: concurrency, distribution
Defining the environment programming model
how to program the environment
19 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Basic Level Overview
actions
percepts
SIMULATED
WORLD
OR
INTERFACE
OR
WRAPPER TO
EXISTING
TECHNOLOGY
EXTERNAL
WORLD(PHYSICAL OR
COMPUTATIONAL)
MAS ENVIRONMENT
REAL WORLD(PHYSICAL OR
COMPUTATIONAL)
mimicking
Example:
JAVA
PLATFORMAGENTS
MAS
20 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Basic Level: Features
Environment conceptually conceived as a single monoliticblock
providing actions, generating percepts
Environment APIto define the set of actions and program actionscomputational behaviour
which include the generation of percepts
typically implemented using as single object/class in OO suchas Java
method to execute actionsfields to store the environment state
available in many agent programming languages/frameworks
e.g., Jason, 2APL, GOAL, JADEX
21 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
An Example: Jason [Bordini et al., 2007]
Flexible Java-based Environment APIEnvironment base class to be specialised
executeAction method to specify action semanticsaddPercept to generate percepts
UserEnvironment
AgentArchitecture
getPercepts
changepercepts
executeAction
+init(String[] args)+stop()
+getPercepts(String agName): List<Literal>+executeAction(String agName, Structure action): boolean
+addPercept(String agName, Literal p)+removePercept(String agName, Literal p)...
-globalPercepts: List<Literal>-agPercepts: Map<String,List<Literal>>
Environment
+init(String[] args)+executeAction(String agName, Structure action): boolean
UserEnvironment
22 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
MARS Environment in Jason
public class MarsEnv extends Environment { private MarsModel model; private MarsView view; public void init(String[] args) { model = new MarsModel(); view = new MarsView(model); model.setView(view); updatePercepts(); } public boolean executeAction(String ag, Structure action) { String func = action.getFunctor(); if (func.equals("next")) { model.nextSlot(); } else if (func.equals("move_towards")) { int x = (int)((NumberTerm)action.getTerm(0)).solve(); int y = (int)((NumberTerm)action.getTerm(1)).solve(); model.moveTowards(x,y); } else if (func.equals("pick")) { model.pickGarb(); } else if (func.equals("drop")) { model.dropGarb(); } else if (func.equals("burn")) { model.burnGarb(); } else { return false; } updatePercepts(); return true; } ...
...
/* creates the agents perception * based on the MarsModel */ void updatePercepts() {
clearPercepts(); Location r1Loc = model.getAgPos(0); Location r2Loc = model.getAgPos(1); Literal pos1 = Literal.parseLiteral ("pos(r1," + r1Loc.x + "," + r1Loc.y + ")"); Literal pos2 = Literal.parseLiteral ("pos(r2," + r2Loc.x + "," + r2Loc.y + ")");
addPercept(pos1); addPercept(pos2);
if (model.hasGarbage(r1Loc)) { addPercept(Literal.parseLiteral("garbage(r1)")); }
if (model.hasGarbage(r2Loc)) { addPercept(Literal.parseLiteral("garbage(r2)")); } }
class MarsModel extends GridWorldModel { ... } class MarsView extends GridWorldView { ... } }
23 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Jason Agents Playing on Mars
// mars robot 1
/* Initial beliefs */
at(P) :- pos(P,X,Y) & pos(r1,X,Y).
/* Initial goal */
!check(slots).
/* Plans */
+!check(slots) : not garbage(r1) <- next(slot); !!check(slots).+!check(slots).
+garbage(r1) : not .desire(carry_to(r2)) <- !carry_to(r2). +!carry_to(R) <- // remember where to go back ?pos(r1,X,Y); -+pos(last,X,Y); // carry garbage to r2 !take(garb,R); // goes back and continue to check !at(last); !!check(slots)....
...
+!take(S,L) : true <- !ensure_pick(S); !at(L); drop(S).
+!ensure_pick(S) : garbage(r1) <- pick(garb); !ensure_pick(S).+!ensure_pick(_).
+!at(L) : at(L).+!at(L) <- ?pos(L,X,Y); move_towards(X,Y); !at(L).
24 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Another Example: 2APL [Dastani, 2008]
2APL
BDI-based agent-oriented programming language integratingdeclarative programming constructs (beliefs, goals) andimperative style programming constructs (events, plans)
Java-based Environment API
Environment base classimplementing actions as methods
inside action methods external events can be generated to beperceived by agents as percepts
25 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example: Block-world Environment in 2APL
package blockworld;
public class Env extends apapl.Environment {
public void enter(String agent, Term x, Term y, Term c){...}
public Term sensePosition(String agent){...}
public Term pickup(String agent){...}
public void north(String agent){...}
...
}
26 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
2APL Agents in the block-world
BeliefUpdates: { bomb(X,Y) } RemoveBomb(X,Y){ not bomb(X,Y) } { true } AddBomb(X,Y) { bomb(X,Y) } { carry(bomb) } Drop( ) { not carry(bomb)} { not carry(bomb) } PickUp( ) { carry(bomb) }
Beliefs: start(0,1). bomb(3,3). clean( blockWorld ) :- not bomb(X,Y) , not carry(bomb).
Plans: B(start(X,Y)) ; @blockworld( enter( X, Y, blue ), L )
Goals: clean( blockWorld )
PG-rules: clean( blockWorld ) <- bomb( X, Y ) | { goto( X, Y ); @blockworld( pickup( ), L1 ); PickUp( ); RemoveBomb( X, Y ); goto( 0, 0 ); @blockworld( drop( ), L2 ); Drop( ) }...
...
PC-rules: goto( X, Y ) <- true | { @blockworld( sensePosition(), POS ); B(POS = [A,B]); if B(A > X) then { @blockworld( west(), L ); goto( X, Y ) } else if B(A < X) then { @blockworld( east(), L ); goto( X, Y ) } else if B(B > Y) then { @blockworld( north(), L ); goto( X, Y ) } else if B(B < Y) then { @blockworld( south(), L ); goto( X, Y ) } }
...
27 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Environment Interface Stardard – EIS Initiative
Recent initiative supported by main APL researchgroups [Behrens et al., 2010]
GOAL, 2APL, GOAL, JADEX, JASON
Goal of the initiativedesign and develop a generic environment interface standard
a standard to connect agents to environments... environments such as agent testbeds, commercialapplications, video games..
Principles
wrapping already existing environmentscreating new environments by connecting already existingappscreating new environments from scratch
Requirements
genericreuse
28 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
EIS Meta-Model
By means of the Env. Interface agents perform actions andcollect percepts
actually actions/percepts are issued to controllable entities inenvironment modelrepresent the agent bodies, with e↵ectors and sensors
29 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Environment Interface Features
Interface functions
attaching, detaching, and notifying observers (software designpattern);registering and unregistering agents;adding and removing entities;managing the agents-entities-relation;performing actions and retrieving percepts;managing the environment
Interface Intermediate language
to facilitate data-exchangeencoding percepts, actions, events
30 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Advanced Level Overview
Vision: environment as a first-class abstraction inMAS [Weyns et al., 2007, Ricci et al., 2010b]
application or endogenous environments, i.e. thatenvironment which is an explicit part of the MASproviding an exploitable design & programming abstractionto build MAS applications
Outcomedistinguishing clearly between the responsibilities of agent andenvironment
separation of concerns
improving the engineering practice
31 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Three Support Levels [Weyns et al., 2007]
Basic interface support
Abstraction support level
Interaction-mediation support level
32 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Basic Interface Support
The environment enables agents to access the deploymentcontext
i.e. the hardware and software and external resources withwhich the MAS interacts
33 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Abstraction Support
Bridges the conceptual gap between the agent abstractionand low-level details of the deployment context
shields low-level details of the deployment context
34 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Interaction-Mediation Support
Regulate the access to shared resources
Mediate interaction between agents
35 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Environment Definition Revised
Environment definition revised [Weyns et al., 2007]
The environment is a first-class abstraction that provides thesurrounding conditions for agents to exist and that mediates boththe interaction among agents and the access to resources
36 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Research on Environments for MAS
Environments for Multi-Agent Systems research field /E4MAS workshop series [Weyns et al., 2005]
di↵erent themes and issues (see JAAMAS SpecialIssue [Weyns and Parunak, 2007] for a good survey)
mechanisms, architectures, infrastructures,applications [Platon et al., 2007, Weyns and Holvoet, 2007,Weyns and Holvoet, 2004, Viroli et al., 2007]
the main perspective is (agent-oriented) software engineering
Focus of this tutorial: the role of the environmentabstraction in MAS programming
environment programming
37 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Environment Programming
Environment as first-class programmingabstraction [Ricci et al., 2010b]
software designers and engineers perspectiveendogenous environments (vs. exogenous one)programming MAS =programming Agents + programming Environment
..but this will be extended to include OOP in next part
Environment as first-class runtime abstraction for agents
agent perspectiveto be observed, used, adapted, constructed, ...
Defining computational and programmingframeworks/models also for the environment part
38 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Computational Frameworks for EnvironmentProgramming: Issues
Defining the environment interface
actions, percepts, data modelcontract concept, as defined in software engineering contexts(Design by Contract)
Defining the environment computational model
environment structure, behaviour
Defining the environment distribution model
topology
39 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Programming Models for the Environment: Desiderata
Abstraction
keeping the agent abstraction level e.g. no agents sharing andcalling OO objectse↵ective programming models for controllable and observablecomputational entities
Modularity
away from the monolithic and centralised view
Orthogonality
wrt agent models, architectures, platformssupport for heterogeneous systems
40 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Programming Models for the Environment: Desiderata
Dynamic extensibility
dynamic construction, replacement, extension of environmentpartssupport for open systems
Reusability
reuse of environment parts for di↵erent kinds of applications
41 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Existing Computational Frameworks
AGRE / AGREEN / MASQ [Stratulat et al., 2009]AGRE – integrating the AGR (Agent-Group-Role)organisation model with a notion of environment
Environment used to represent both the physical and socialpart of interaction
AGREEN / MASQ – extending AGRE towards a unifiedrepresentation for physical, social and institutionalenvironmentsBased on MadKit platform [Gutknecht and Ferber, 2000a]
GOLEM [Bromuri and Stathis, 2008]Logic-based framework to represent environments for situatedcognitive agentscomposite structure containing the interaction betweencognitive agents and objects
A&A and CArtAgO [Ricci et al., 2010b]introducing a computational notion of artifact to design andimplement agent environments
42 / 165
A&A and CArtAgO
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Agents and Artifacts (A&A) Conceptual Model:Background Human Metaphor
WHITEBOARDartifact
ARCHIVEartifact
COM. CHANNELartifact
TASK SCHEDULERartifact
RESOURCE artifact
CLOCKartifact
BAKERY
workspace
agents can joindynamically the workspace
44 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A&A Basic Concepts [Omicini et al., 2008]
Agents
autonomous, goal-oriented pro-active entitiescreate and co-use artifacts for supporting their activities
besides direct communication
Artifactsnon-autonomous, function-oriented, stateful entities
controllable and observable
modelling the tools and resources used by agents
designed by MAS programmers
Workspaces
grouping agents & artifactsdefining the topology of the computational environment
45 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A&A Programming Model Features [Ricci et al., 2007b]
Abstraction
artifacts as first-class resources and tools for agents
Modularisation
artifacts as modules encapsulating functionalities, organizedin workspaces
Extensibility and openness
artifacts can be created and destroyed at runtime by agents
Reusability
artifacts (types) as reusable entities, for setting up di↵erentkinds of environments
46 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A&A Meta-Model in More Detail [Ricci et al., 2010b]
Artifact
Operation
Observable Event
generate
Agentuse
perceive
Workspace
Environment
ObservableProperty
update
perceive
observe
Manual
has
consult
link
create
dispose
link
join
quit
47 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Artifact Abstract Representation
OperationX(Params)
...
ObsPropName(Args)
...
SIGNALS
USAGE
INTERFACE
OBSERVABLE
PROPERTIES
OperationY(Params)
...
LINK
INTERFACE
OPERATIONS
48 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A World of Artifacts
put
n_items 0
max_items 100
get
a bounded buffer
inc
count 5
reset
a counter
switch
state true
a flag
setTodo
last_todo ...
cancelTodo
next_todo check_plant
an agenda
...
GetLastTradePrice
a Stock Quote Web Service
availablestate
...wsdl
postEvent
registerForEvs
clearEvents
an event service
query
createTable
addRecord
a data-base
...
1001n_records
table_names ...
... ...
in
rd
out
a tuple space
49 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A Simple Taxonomy
Individual or personal artifactsdesigned to provide functionalities for a single agent use
e.g. an agenda for managing deadlines, a library...
Social artifacts
designed to provide functionalities for structuring andmanaging the interaction in a MAScoordination artifacts [Omicini et al., 2004], organisationartifacts, ...
e.g. a blackboard, a game-board,...
Boundary artifactsto represent external resources/services
e.g. a printer, a Web Service
to represent devices enabling I/O with users
e.g GUI, console, etc.
50 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Actions and Percepts in Artifact-Based Environments
Explicit semantics defined by the (endogenous)environment [Ricci et al., 2010c]
success/failure semantics, execution semanticsdefining the contract (in the SE acceptation) provided by theenvironment
actions ! artifacts’ operationthe action repertoire is given by the dynamic set of operationsprovided by the overall set of artifacts available in the workspacecan be changed by creating/disposing artifacts
action success/failure semantics is defined by operationsemantics
percepts ! artifacts’ observable properties + signalsproperties represent percepts about the state of the environmentsignals represent percepts concerning events signalled by theenvironment
51 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Interaction Model: Use
op(Params)
ValuePropName
ValuePropName...
...
AGENT
op(parms)action
Performing an action corresponds to triggering the executionof an operation
acting on artifact’s usage interface
52 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Interaction Model: Operation execution
OPERATION EXECUTIONop(Params)
ValuePropNameValue...
...
SIGNALS OBS PROPERTIESCHANGE
AGENT
op(parms)action
action completion- with success or failure -
a process structured in one or multiple transactional steps
asynchronous with respect to agent...which can proceed possibly reacting to percepts and
executing actions of other plans/activities
operation completion causes action completionaction completion events with success or failure, possibly withaction feedbacks
53 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Interaction Model: Observation
Belief base(or alike)
PropName(Value).PropName(Value).... ValuePropName
ValuePropName...
focus
AGENTOBSERVER
Agents can dynamically select which artifacts to observe
predefined focus/stopFocus actions
54 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Interaction Model: Observation
AGENTOBSERVER
Belief base(or alike)
PropName(Value).PropName(Value).... ValuePropName
ValuePropName...
use
By focussing an artifactobservable properties are mapped into agent dynamicknowledge about the state of the world, as percepts
e.g. belief base
signals are mapped as percepts related to observable events
55 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Artifact Linkability
WSP-X WSP-Y
linkedOp
Basic mechanism to enable inter-artifact interactionlinking artifacts through interfaces (link interfaces)
operations triggered by an artifact over an other artifact
Useful to design & program distributed environments
realised by set of artifacts linked togetherpossibly hosted in di↵erent workspaces
56 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Artifact Manual
Agent-readable description of artifact’s......functionality
what functions/services artifacts of that type provide
...operating instructions
how to use artifacts of that type
Towards advanced use of artifacts by intelligentagents [Piunti et al., 2008]
dynamically choosing which artifacts to use to accomplishtheir tasks and how to use themstrong link with Semantic Web research issues
Work in progress
defining ontologies and languages for describing the manuals
57 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
CArtAgO
Common ARtifact infrastructure for AGent Openenvironment (CArtAgO) [Ricci et al., 2009b]
Computational framework / infrastructure to implement andrun artifact-based environment [Ricci et al., 2007c]
Java-based programming model for defining artifactsset of basic API for agent platforms to work withinartifact-based environment
Distributed and open MASworkspaces distributed on Internet nodes
agents can join and work in multiple workspace at a time
Role-Based Access Control (RBAC) security model
Open-source technology
available at http://cartago.sourceforge.net
58 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Integration with Agent Languages and Platforms
Integration with existing agent platforms [Ricci et al., 2008]
by means of bridges creating an action/perception interfaceand doing data binding
Outcome
developing open and heterogenous MASintroducing a further perspective on interoperability besidesthe ACL’s one
sharing and working in a common work environmentcommon object-oriented data-model
59 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
JaCa Platform
Integration of CArtAgO with Jason language/platform
a JaCa program is a dynamic set of Jason agents workingtogether in one or multiple CArtAgO workspaces
Mappingactions
Jason agent external actions are mapped onto artifacts’operations
percepts
artifacts’ observable properties are mapped onto agent beliefsartifacts’ signals are mapped as percepts related toobservable events
data-model
Jason data-model is extended to manage also (Java) objects
60 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 1: A Simple Counter Artifact
class Counter extends Artifact { void init(){ defineObsProp("count",0); } @OPERATION void inc(){ ObsProperty p = getObsProperty("count"); p.updateValue(p.intValue() + 1); signal("tick"); }}
inc
count 5
Some API spots
Artifact base class@OPERATION annotation to mark artifact?s operationsset of primitives to work define/update/.. observablepropertiessignal primitive to generate signals
61 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 1: User and Observer Agents
!create_and_use.
+!create_and_use : true <- !setupTool(Id); // use inc; // second use specifying the Id inc [artifact_id(Id)].
// create the tool+!setupTool(C): true <- makeArtifact("c0","Counter",C).
!observe.
+!observe : true <- ?myTool(C); // discover the tool focus(C).
+count(V) <- println(“observed new value: “,V).
+tick [artifact_name(Id,”c0”)] <- println(“perceived a tick”).
+?myTool(CounterId): true <- lookupArtifact(“c0”,CounterId).
-?myTool(CounterId): true <- .wait(10); ?myTool(CounterId).
OBSERVER(S)USER(S)
Working with the shared counter
62 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Pre-defined Artifacts
Each workspace contains by default a predefined set ofartifacts
providing core and auxiliary functionalitiesi.e. a pre-defined repertoire of actions available to agents...
Among the othersworkspace, type: cartago.WorkspaceArtifact
functionalities to manage the workspace, including securityoperations: makeArtifact, lookupArtifact, focus,...
node, type: cartago.NodeArtifact
core functionalities related to a nodeoperations: createWorkspace, joinWorkspace, ...
console, type cartago.tools.Console
operations: println,...
blackboard, type cartago.tools.TupleSpace
operations: out, in, rd, ...
....
63 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 2: Coordination Artifacts – A Bounded Bu↵er
public class BoundedBuffer extends Artifact { private LinkedList<Item> items; private int nmax; void init(int nmax){ items = new LinkedList<Item>(); defineObsProperty("n_items",0); this.nmax = nmax; }
@OPERATION void put(Item obj){ await("bufferNotFull"); items.add(obj);
getObsProperty("n_items").updateValue(items.size()); }
@OPERATION void get(OpFeedbackParam<Item> res) { await("itemAvailable"); Item item = items.removeFirst();
res.set(item);getObsProperty("n_items").updateValue(items.size());
}
@GUARD boolean itemAvailable(){ return items.size() > 0; }
@GUARD boolean bufferNotFull(Item obj){ return items.size() < nmax; }}
put
n_items 5
get
Basic operation featuresoutput parameters to represent action feedbackslong-term operations, with a high-level support forsynchronization (await primitive, guards)
64 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 2: Producers and Consumers
item_to_produce(0).!produce.
+!produce: true <- !setupTools(Buffer); !produceItems.
+!produceItems : true <- ?nextItemToProduce(Item); put(Item); !!produceItems.
+?nextItemToProduce(N) : true <- -item_to_produce(N); +item_to_produce(N+1).
+!setupTools(Buffer) : true <- makeArtifact("myBuffer","BoundedBuffer", [10],Buffer).
-!setupTools(Buffer) : true <- lookupArtifact("myBuffer",Buffer).
!consume.
+!consume: true <- ?bufferReady; !consumeItems. +!consumeItems: true <- get(Item); !consumeItem(Item); !!consumeItems.
+!consumeItem(Item) : true <- .my_name(Me); println(Me,": ",Item). +?bufferReady : true <- lookupArtifact("myBuffer",_). -?bufferReady : true <-.wait(50); ?bufferReady.
PRODUCERS CONSUMERS
65 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Remarks
Process-based operation execution semantics
action/operation execution can be long-termaction/operation execution can overlapkey feature for implementing coordination functionalities
Operation with output parameters as action feedbacks
66 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Action Execution & Blocking Behaviour
Given the action/operation map, by executing an action theintention/activity is suspended until the correspondingoperation has completed or failed
action completion events generated by the environment andautomatically processed by the agent/environment platformbridgeno need of explicit observation and reasoning by agents toknow if an action succeeded
However the agent execution cycle is not blocked!
the agent can continue to process percepts and possiblyexecute actions of other intentions
67 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 3: Internal Processes – A Clock
public class Clock extends Artifact {
boolean working; final static long TICK_TIME = 100;
void init(){ working = false; }
@OPERATION void start(){ if (!working){ working = true; execInternalOp("work"); } else { failed("already_working"); } }
@OPERATION void stop(){ working = false; }
@INTERNAL_OPERATION void work(){ while (working){ signal("tick"); await_time(TICK_TIME); } }}
!test_clock.
+!test_clock <- makeArtifac("myClock","Clock",[],Id); focus(Id); +n_ticks(0); start; println("clock started.").
@plan1+tick: n_ticks(10) <- stop; println("clock stopped.").
@plan2 [atomic]+tick: n_ticks(N) <- -+n_ticks(N+1); println("tick perceived!").
CLOCK CLOCK USER AGENT
Internal operationsexecution of operations triggered by other operationsimplementing controllable processes
68 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 4: Artifacts for User I/O – GUI Artifacts
setValue
value 16.0
user
ok
closed
agent
Exploiting artifacts to enable interaction between humanusers and agents
69 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Example 4: Agent and User Interaction
public class MySimpleGUI extends GUIArtifact { private MyFrame frame; public void setup() { frame = new MyFrame(); linkActionEventToOp(frame.okButton,"ok"); linkKeyStrokeToOp(frame.text,"ENTER","updateText"); linkWindowClosingEventToOp(frame, "closed"); defineObsProperty("value",getValue()); frame.setVisible(true); }
@INTERNAL_OPERATION void ok(ActionEvent ev){ signal("ok"); }
@OPERATION void setValue(double value){ frame.setText(""+value); updateObsProperty("value",value); } ... @INTERNAL_OPERATION void updateText(ActionEvent ev){ updateObsProperty("value",getValue()); }
private int getValue(){ return Integer.parseInt(frame.getText()); }
class MyFrame extends JFrame {...}}
!test_gui.
+!test_gui <- makeArtifact("gui","MySimpleGUI",Id); focus(Id).
+value(V) <- println("Value updated: ",V). +ok : value(V) <- setValue(V+1).
+closed <- .my_name(Me); .kill_agent(Me).
GUI ARTIFACT USER ASSISTANT AGENT
70 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Other Features
Other CArtAgO features not discussed in this lecturelinkability
executing chains of operations across multiple artifacts
multiple workspaces
agents can join and work in multiple workspaces, concurrentlyincluding remote workspaces
RBAC security model
workspace artifact provides operations to set/change theaccess control policies of the workspace, depending on theagent roleruling agents’ access and use of artifacts of the workspace
...
See CArtAgO papers and manuals for more information
71 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
A&A and CArtAgO: Some Research Explorations
Designing and implementing artifact-based organisationInfrastructures
JaCaMo model and platform (which is the evolution of theORA4MAS infrastructure [Hubner et al., 2009c])
Cognitive stigmergy based on artifactenvironments [Ricci et al., 2007a]
cognitive artifacts for knowledge representation andcoordination [Piunti and Ricci, 2009]
Artifact-based environments forargumentation [Oliva et al., 2010]
Including A&A in AOSE methodology [Molesini et al., 2005]
Defining a Semantic (OWL-based) description of artifactenvironments ( CArtAgO-DL)
JaSa project = JASDL + CArtAgO-DL
...
72 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Applying CArtAgO and JaCa
Using CArtAgO/JaCa for building real-world applications andinfrastructures
Some examplesJaCa-Android
implementing mobile computing applications on top of theAndroid platform using JaCa [Santi et al., 2011]http://jaca-android.sourceforge.net
JaCa-WS / CArtAgO-WS
building SOA/Web Services applications usingJaCa [Ricci et al., 2010a]http://cartagows.sourceforge.net
JaCa-Web
implementing Web 2.0 applications using JaCahttp://jaca-web.sourceforge.net
73 / 165
Introduction EOP OOP Conclusion Introduction Basic Advanced CArtAgO Wrap-up
Wrap-up
Environment programming
environment as a programmable part of the MASencapsulating and modularising functionalities useful foragents’ work
Artifact-based environmentsartifacts as first-class abstraction to design and programcomplex software environments
usage interface, observable properties / events, linkability
artifacts as first-order entities for agents
interaction based on use and observationagents dynamically co-constructing, evolving, adapting theirworld
CArtAgO computational framework
programming and executing artifact-based environmentsintegration with heterogeneous agent platformsJaCa case
74 / 165
Organisation OrientedProgramming— OOP —
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Abstractions in Multi-Agent Systems
roleorgmission
schema
ORGAMISATIONLEVEL
AGENTLEVEL
ENDOGENOUSENVIRONMENTLEVELwsp
artifact
network node
EXOGENOUS ENVIRONMENT
agent
76 / 165
Outline
3 Organisation Oriented Programming (OOP)FundamentalsMotivationsSome OOP approachesFocus on theMoise frameworkMoise Organisation Modelling Language (OML)Moise Organisation Management Infrastructure (OMI)Moise integration with agents & environment
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation in MAS – a definition
What is an organisation?
Pattern of agent cooperation
with a purposesupra-agentemergent orpredefined (by designer or agents)
78 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation in MAS – a definition
What is an organisation?
Pattern of agent cooperation
with a purposesupra-agentemergent orpredefined (by designer or agents)
78 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Introduction: Some definitions
Organisations are structured, patterned systems of activity,knowledge, culture, memory, history, and capabilities that aredistinct from any single agent [Gasser, 2001] Organisations are supra-individual phenomenaA decision and communication schema which is applied to a set ofactors that together fulfill a set of tasks in order to satisfy goalswhile guarantying a global coherent state [Malone, 1999] definition by the designer, or by actors, to achieve a purposeAn organisation is characterised by: a division of tasks, adistribution of roles, authority systems, communication systems,contribution-retribution systems [Bernoux, 1985] pattern of predefined cooperationAn arrangement of relationships between components, whichresults into an entity, a system, that has unknown skills at the levelof the individuals [Morin, 1977] pattern of emergent cooperation
79 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Perspective on organisations from EASSS’05 Tutorial (Sichman, Boissier)
Agents know about organisation
Agents don’t know about organisation
���������� ������Organisation Specification Observed Organisation
Designer / Observer Bottom-up Top-down Organisation Entity
Agent Centred
Organisation Centred
80 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Perspective on organisations from EASSS’05 Tutorial (Sichman, Boissier)
Agents know about organisation
Agents don’t know about organisation
Agent Centred Swarms, AMAS, SASO Self-organisations …
Organisation is observed. Implicitly programmed in Agents, Interactions, Environment.
Social Reasoning Coalition formation Contract Net Protocol … Organisation is observed. Coalition formation mechanisms programmed in Agents.
AOSE MASE, GAIA, MESSAGE, …
Organisation is a design model. It is hard-coded in Agents
TAEMS, STEAM, AGR MOISE+, OPERA, …
Organisation-Oriented Programming of MAS
Organisation Centred ���������� ������Organisation Specification Observed Organisation
Designer / Observer Bottom-up Top-down Organisation Entity
81 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Oriented Programming (OOP)
Organisation Entity
OrganisationSpecification
Agent
Agent
Agent
Programming outsidethe agents
Using organisationalconcepts
To define a cooperativepattern
Program = Specification
By changing thespecification, we canchange the MAS overallbehaviour
82 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Oriented Programming (OOP)
Organisation Entity
OrganisationSpecification
Agent
Agent
Agent First approach
Agents read the programand follow it
82 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Oriented Programming (OOP)
Organisation Entity
OrganisationSpecification
Agent
Agent
Agent
Second approach
Agents are forced tofollow the program
Agents are rewarded ifthey follow the program
...
82 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Oriented Programming (OOP)
Organisation Entity
OrganisationSpecification
Agent
Agent
Agent
Second approach
Agents are forced tofollow the program
Agents are rewarded ifthey follow the program
...
82 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Oriented Programming (OOP)
Organisation Entity
OrganisationSpecification
Agent
Agent
Agent
Components
Programming language(OML)
Platform (OMI)
Integration to agentarchitectures andenvironment
82 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Components of OOP:Organisation Modelling Language (OML)
Declarative specification of the organisation(s)
Specific constraints, norms and cooperation patternsimposed on the agents
Based on an organisational model
e.g. AGR [Ferber and Gutknecht, 1998],TeamCore [Tambe, 1997],Islander [Esteva et al., 2001],Moise+ [Hubner et al., 2002],Opera [Dignum and Aldewereld, 2010],2OPL [Dastani et al., 2009a],...
83 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Components of OOP:Organisation Management Infrastructure (OMI)
Coordination mechanisms, i.e. support infrastructure
e.g. MadKit [Gutknecht and Ferber, 2000b],Karma [Pynadath and Tambe, 2003],...
Regulation mechanisms, i.e. governance infrastructure
e.g. Ameli [Esteva et al., 2004],S-Moise+ [Hubner et al., 2006],ORA4MAS [Hubner et al., 2009b],...
Adaptation mechanisms, i.e. reorganisation infrastructure
84 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Components of OOP:Integration mechanisms
Agent integration mechanismsallow agents to be aware of and to deliberate on:
entering/exiting the organisationmodification of the organisationobedience/violation of normssanctioning/rewarding other agents
e.g. J -Moise+ [Hubner et al., 2007], Autonomy basedreasoning [Carabelea, 2007], ProsA2 Agent-based reasoningon norms [Ossowski, 1999], ...
Environment integration mechanismstransform organisation into embodied organisation so that:
organisation may act on the environment (e.g. enact rules,regimentation)environment may act on the organisation (e.g. count-as rules)
e.g [Piunti et al., 2009b], [Okuyama et al., 2008]
85 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Motivations for OOP:Applications point of view
Current applications show an increase in
Number of agentsDuration and repetitiveness of agent activitiesHeterogeneity of the agentsNumber of designers of agentsAgent ability to act and decideOpenness, scalability, dynamism
More and more applications require the integration of humancommunities and technological communities (ubiquitous andpervasive computing), building connected communities(ICities) in which agents act on behalf of users
Trust, security, ..., flexibility, adaptation
86 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Motivations for OOP:Constitutive point of view
Organisation helps the agents to cooperate with otheragents by defining common cooperation schemes
global tasksprotocolsgroups, responsibilities
e.g. ‘to bid’ for a product on eBay is an institutional action onlypossible because eBay defines rules for that very action
the bid protocol is a constraint but it also creates the action
e.g. when a soccer team wants to play match, the organisationhelps the members of the team to synchronise actions, toshare information, etc
87 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Motivations for OOP:Normative point of view
MAS have two properties which seem contradictory:
a global purposeautonomous agents
While the autonomy of the agents is essential, it may causeloss in the global coherence of the system and achievement ofthe global purpose
Embedding norms within the organisation of an MAS is away to constrain the agents’ behaviour towards the globalpurposes of the organisation, while explicitly addressing theautonomy of the agents within the organisation
Normative organisatione.g. when an agent adopts a role, it adopts a set of behavioural
constraints that support the global purpose of theorganisation.It may decide to obey or disobey these constraints
88 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Motivations for OOP:Agents point of view
An organisational specification is required to enable agents to“reason” about the organisation:
to decide to enter into/leave from the organisation duringexecution
Organisation is no more closed
to change/adapt the current organisation
Organisation is no more static
to obey/disobey the organisation
Organisation is no more a regimentation
89 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Motivations for OOP:Organisation point of view
An organisational specification is required to enable theorganisation to “reason” about itself and about the agents inorder to ensure the achievement of its global purpose:
to decide to let agents enter into/leave from theorganisation during execution
Organisation is no more closed
to decide to let agents change/adapt the currentorganisation
Organisation is no more static and blind
to govern agents behaviour in the organisation (i.e. monitor,enforce, regiment)
Organisation is no more a regimentation
90 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Some OOP approaches
AGR/Madkit [Ferber and Gutknecht, 1998]
STEAM/Teamcore [Tambe, 1997]
ISLANDER/AMELI [Esteva et al., 2004]
Opera/Operetta [Dignum and Aldewereld, 2010]
PopOrg [Rocha Costa and Dimuro, 2009]
2OPL [Dastani et al., 2009a]
...
91 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
AGR [Ferber and Gutknecht, 1998]
Agent Group Role (previously known as AALAADIN)
Agent: Active entity that plays roles within groups. An agentmay have several roles and may belong to several groupsGroup: set of agents sharing common characteristics, i.e.context for a set of activities. Two agents cant communicatewith each other if they dont belong to the same groupRole: Abstract representation of the status, position,function of an agent within a group
OMI: the Madkit platform
92 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
AGR OML
Interaction protocol
Group structure Role 1..* 1
contains
source
participant
1
*
1..*
* Role dependency Role properties *
1
1 1
target
Agent
Group
*
1..*
*
1..*
is member of
plays
1
described by 1 1
initiator 1
Agent level
Organization level
93 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
AGR OML Modelling Dimensions
P E
Environment
B
B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible behaviors structurally constrained by the organization
OS
Structural Specification
94 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
STEAM [Tambe, 1997]
Shell for TEAMwork is a general framework to enable agentsto participate in teamwork
Di↵erent applications: Attack, Transport, Robocup soccerBased on an enhanced SOAR architecture and 300 domainindependent SOAR rules
Principles:
Team synchronisation: Establish joint intentions, Monitorteam progress and repair, Individual may fail or succeed inown roleReorganise if there is a critical role failureReassign critical roles based on joint intentionsDecision theoretic communication
Supported by the TEAMCORE OMI
95 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
STEAM OML [Tambe, 1997]
TASK FORCE
ORDERS OBTAINER
SAFETY INFO OBTAINER
FLIGHT TEAM
ROUTE PLANNER
ESCORT TRANSPORT
HELO1 HELO2 HELO1 HELO2
Organization: hierarchy of roles that may be filled by agents or groups of agents.
[TASK FORCE]
[TASK FORCE] [TASK FORCE] [TASK FORCE]
[ORDERS OBTAINER]
[TASK FORCE] [ESCORT] [TRANSPORT]
[TASK FORCE]
EVACUATE
PROCESS ORDERS
EXECUTE MISSION
LANDING ZONE MANEUVERS
OBTAIN ORDERS
FLY-FLIGHT PLAN
MASK OBSERVE PICKUP
FLY-CONTROL ROUTE
Team Plan: • initial conditions, • term. cond. : achievability, irrelevance, unachievability • team-level actions.
96 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
STEAM OML Modelling Dimensions
E
Environment
P
Structural Specification
OF Functional Specification
OS
B
B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible behaviors structurally constrained by the organization OF: agents’ possible behaviors functionally constrained by the organization
97 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ISLANDER
Based on di↵erent influences: economics, norms, dialogues,coordination
electronic institutions
Combining di↵erent alternative views: dialogical, normative,coordination
Institution Description Language:
Performative structure (Network of protocols)Scene (multi-agent protocol)RolesNorms
Ameli as OMI
98 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ISLANDER OML: IDL [Esteva et al., 2001]
Performative Structure
(define-institution soccer-server as dialogic-framework = soccer-df performative-structure = soccer-pf norms = ( free-kick coach-messages … )
)
99 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ISLANDER OML Modelling Dimensions
E
Environment
P
B
B: agents’ possible behaviors P: agents’ behaviors that lead to global purpose E: agents’ possible behaviors constrained by the environment OS: agents’ possible/permitted/obliged behaviors structurally constrained by the organisation OI: agents’ possible/permitted/obliged behaviors interactionally constrained by the organisation
OI Structural Specification
OS
Dialogical Specification
100 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
2OPL slides from Dastani
The aim is to design and develop a programming language tosupport the implementation of coordination mechanisms in termsof normative concepts.
An organisation
determines e↵ect of external actions
normatively assesses e↵ect of agents’ actions (monitoring)
sanctions agents’ wrongdoings (enforcement)
prevents ending up in really bad states (regimentation)
101 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Programming Language for Organisations
Example (Train Station)
Facts:
– -at˙platform , -in˙train , -ticket ˝
Effects:
– -at˙platform ˝ enter – at˙platform ˝,
– -ticket ˝ buy˙ticket – ticket ˝,
– at˙platform , -in˙train ˝
embark
– -at˙platform, in˙train ˝
Counts˙as rules:
– at˙platform , -ticket ˝ =¿ – viol˙ticket ˝,
– in˙train , -ticket ˝ =¿ – viol˙—˙ ˝
Sanction˙rules:
– viol˙ticket ˝ =¿ – fined˙10 ˝
102 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
2OPL Modelling Dimension
103 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Summary
Several models
Several dimensions on modelling organisation
Structural (roles, groups, ...)Functional (global plans, ....)Dialogical (scenes, protocols, ...)Normative (norms)
104 / 165
TheMoise Framework
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise Framework
OML (language)
Tag-based language(issued fromMoise [Hannoun et al., 2000],Moise+ [Hubner et al., 2002],MoiseInst [Gateau et al., 2005])
OMI (infrastructure)
developed as an artifact-based working environment(ORA4MAS [Hubner et al., 2009b] based on CArtAgOnodes, refactoring of S-Moise+ [Hubner et al., 2006] andSynai [Gateau et al., 2005])
Integrations
Agents and Environment (c4Jason, c4Jadex[Ricci et al., 2009c])Environment and Organisation ([Piunti et al., 2009a])Agents and Organisation (J -Moise+ [Hubner et al., 2007])
106 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise Modelling Dimensions
E
Environment
P
OF Functional Specification
Global goals, plans, Missions, schemas, preferences
B Structural Specification
Groups, links, roles Compatibilities, multiplicities inheritance
OS
Normative Specification Permissions, Obligations Allows agents autonomy!
107 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise OML meta-model (partial view)
Agent Goal
MissionRole
Group
Social Scheme
createdelete
adoptleave
createdelete
agent's actionscompositionassociation
Cardinalities are not represented
concept mapping
Norm
Goal
commit leave
achieve
StructuralSpecification
NormativeSpecification
FunctionalSpecification
108 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise OML
OML for defining organisation specification and organisationentity
Three independent dimensions [Hubner et al., 2007]( well adapted for the reorganisation concerns):
Structural: Roles, GroupsFunctional: Goals, Missions, SchemesNormative: Norms (obligations, permissions, interdictions)
Abstract description of the organisation for
the designersthe agents
J -Moise+ [Hubner et al., 2007]the Organisation Management Infrastructure
ORA4MAS [Hubner et al., 2009b]
109 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise OML Structural Specification
Specifies the structure of an MAS along three levels:
Individual with RoleSocial with LinkCollective with Group
Components:
Role: label used to assign rights and constraints on thebehavior of agents playing itLink: relation between roles that directly constrains theagents in their interaction with the other agents playing thecorresponding rolesGroup: set of links, roles, compatibility relations used todefine a shared context for agents playing roles in it
110 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Structural Specification Example
Graphical representation of structural specification of 3-5-2 Joj Team
111 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise OML Functional Specification
Specifies the expected behaviour of an MAS in terms ofgoals along two levels:
Collective with SchemeIndividual with Mission
Components:Goals:
Achievement goal (default type). Goals of this type shouldbe declared as satisfied by the agents committed to them,when achievedMaintenance goal. Goals of this type are not satisfied at aprecise moment but are pursued while the scheme is running.The agents committed to them do not need to declare thatthey are satisfied
Scheme: global goal decomposition tree assigned to a group
Any scheme has a root goal that is decomposed into subgoals
Missions: set of coherent goals assigned to roles withinnorms
112 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Functional Specification Example
score a goal
m1
go towards the opponent field
m1, m2, m3
get the ball
be placed in the middle field
be placed in the opponent goal area kick the ball to (agent committed to m2)
go to the opponent back line
kick the ball to the goal area
shot at the opponent’s goal
m1
m1
m2 m2
m2
m3
m3
Key
goalmissions
success rate parallelismchoicesequence
Scheme
Organizational EntityLucio
Cafu
Rivaldo
m1
m2
m3
Graphical representation of social scheme “side attack” for joj team
113 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Goal States
waiting
satisfiedimpossible
enabled
waiting initial state
enabled goal pre-conditions are satisfied &scheme is well-formed
satisfied agents committed to the goal have achieved it
impossible the goal is impossible to be satisfied
114 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Moise OML Normative Specification
Explicit relation between the functional and structuralspecifications
Permissions and obligations to commit to missions in thecontext of a role
Makes explicit the normative dimension of a role
115 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Norm Specification – example
role deontic mission TTF
back obliged m1 get the ball, go ... 1 minuteleft obliged m2 be placed at ..., kick ... 3 minuteright obliged m2 1 dayattacker obliged m3 kick to the goal, ... 30 seconds
116 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational Entity
norrmative groups
roles
structural
schemas
missions
functional
group instances role
player
schema instances
mission player
agents
purpose
Organisation specification
Organisation Entity
links norms
117 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation Entity Dynamics
1 Organisation is created (by the agents)
instances of groupsinstances of schemes
2 Agents enter into groups adopting roles3 Groups become responsible for schemes
Agents from the group are then obliged to commit tomissions in the scheme
4 Agents commit to missions
5 Agents fulfil mission’s goals
6 Agents leave schemes and groups
7 Schemes and groups instances are destroyed
118 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisation management infrastructure (OMI)
Responsibility
Managing – coordination, regulation – the agents’ executionwithin organisation defined in an organisational specification
OrganisationSpecification OMI
AgentAgentAgentAgent
(e.g. MadKit, AMELI, S-Moise+, ...)
119 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational artifacts in ORA4MAS
System
Agent
GroupArtifact
SchemeArtifact
SchemeArtifact
Agent
Agent
Agent
Agent
Agent
based on A&A andMoiseagents create and handleorganisational artifacts
artifacts in charge ofregimentations,detection and evaluationof norms compliance
agents are in charge ofdecisions aboutsanctions
distributed solution
120 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ORA4MAS – GroupBoard artifact
GroupBoard
Specification
Players
Schemes
adoptRole
leaveRole
addScheme
removeScheme
Formation status
Observable Properties:
specification: thespecification of the group inthe OS (an object of classmoise.os.ss.Group)
players: a list of agentsplaying roles in the group.Each element of the list is apair (agent x role)
schemes: a list of schemeidentifiers that the group isresponsible for
121 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ORA4MAS – GroupBoard artifact
GroupBoard
Specification
Players
Schemes
adoptRole
leaveRole
addScheme
removeScheme
Formation status
Operations:
adoptRole(role): the agentexecuting this operationtries to adopt a role in thegroup
leaveRole(role)
addScheme(schid): thegroup starts to beresponsible for the schememanaged by theSchemeBoard schId
removeScheme(schid)
122 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ORA4MAS – SchemeBoard artifact
SchemeBoard
Specification
Players
Goals
Obligations
commitMission
leaveMission
goalAchieved
setGoalArgument
Groups
Observable Properties:
specification: thespecification of the schemein the OS
groups: a list of groupsresponsible for the scheme
players: a list of agentscommitted to the scheme.Each element of the list is apair (agent, mission)
goals: a list with thecurrent state of the goals
obligations: list ofobligations currently activein the scheme
123 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
ORA4MAS – SchemeBoard artifact
SchemeBoard
Specification
Players
Goals
Obligations
commitMission
leaveMission
goalAchieved
setGoalArgument
Groups
Operations:
commitMission(mission)and leaveMission:operations to “enter” and“leave” the scheme
goalAchieved(goal): definesthat some goal is achievedby the agent performing theoperation
setGoalArgument(goal,argument, value): definesthe value of some goal’sargument
124 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational Artifact Architecture
OrganisationArtifact
NPL Interpreter
NOPLProgram
GroupState
NPLEngine
ObligationsState
Organisation Specificatoin
translates
Signals (o = obligation(to whom, reason, what, deadline)):
obl created(o): the obligation o is created
obl fulfilled(o): the obligation o is fulfilled
obl unfulfilled(o): the obligation o is unfulfilled
obl inactive(o): the obligation o is inactive
norm failure(f ): the failure f has happened125 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Environment integration
Organisational Artifacts enable organisation and environmentintegration
Embodied organisation [Piunti et al., 2009a]
Env. Artifact Org. Artifactcount-as
enact
count-as
status: ongoing work
126 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Environment integration: constitutive rules
Count-As rule
An event occurring on an artifact, in a particular context, maycount-as an institutional event
transforms the events created in the working environmentinto activation of an organisational operation
indirect automatic updating of the organisation
Enact rule
An event produced on an organisational artifact, in a specificinstitutional context, may “enact” change and updating of theworking environment (i.e., to promote equilibrium, avoidundesiderable states)
Installing automated control on the working environment
Even without the intervention of organisational/sta↵ agents(regimenting actions on physical artifacts, enforcingsanctions, ...) 127 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Agent integration
Agents can interact with organisational artifacts as withordinary artifacts by perception and action
Any Agent Programming Language integrated withCArtAgO can use organisational artifacts
Agent integration provides some “internal” tools for the agentsto simplify their interaction with the organisation:
maintenance of a local copy of the organisational state
production of organisational events
provision of organisational actions
128 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
J -Moise: Jason +Moise
Agents are programmed with Jason
BDI agents (reactive planning) – suitable abstraction level
The programmer has the possibility to express sophisticatedrecipes for adopting roles, committing to missions,fulfilling/violating norms, ...
Organisational information is made accessible in the mentalstate of the agent as beliefs
Integration is totally independent of thedistribution/communication layer
129 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
J -Moise: Jason +Moise– General view
Jason-CArtAgo Agent
Plan Library
Belief Base
Organisational Workspace (CArtAgO)
Intentions
J-Moise+����� ��������������������
130 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational actions in Jason I
Example (GroupBoard)...
joinWorkspace(”ora4mas”,O4MWsp);
makeArtifact(
”auction”,
”ora4mas.nopl.GroupBoard”,
[”auction-os.xml”, auctionGroup, false, true ],
GrArtId);
adoptRole(auctioneer);
focus(GrArtId);
...
131 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational actions in Jason II
Example (SchemeBoard)...
makeArtifact(
”sch1”,
”ora4mas.nopl.SchemeBoard”,
[”auction-os.xml”, doAuction, false, true ],
SchArtId);
focus(SchArtId);
addScheme(Sch);
commitMission(mAuctioneer)[artifact˙id(SchArtId)];
...
132 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational perception
When an agent focus on an Organisational Artifact, theobservable properties (Java objects) are translated to beliefs withthe following predicates:
specification
play(agent, role, group)
commitment(agent, mission, scheme)
goalState(scheme, goal, list of committed agents, list ofagent that achieved the goal, state of the goal)
obligation(agent,norm,goal,dead line)
....
133 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Organisational perception – example
134 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Handling organisational events in Jason
Whenever something changes in the organisation, the agentarchitecture updates the agent belief base accordingly producingevents (belief update from perception)
Example (new agent entered the group)
+play(Ag,boss,GId) ¡- .send(Ag,tell,hello).
Example (change in goal state)
+goalState(Scheme,wsecs,˙,˙,satisfied)
: .my˙name(Me) & commitment(Me,mCol,Scheme)
¡- leaveMission(mColaborator,Scheme).
Example (signals)
+normFailure(N) ¡- .print(”norm failure event: ”, N).
135 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Typical plans for obligations
Example
+obligation(Ag,Norm,committed(Ag,Mission,Scheme),DeadLine)
: .my˙name(Ag)
¡- .print(”I am obliged to commit to ”,Mission);
commit˙mission(Mission,Scheme).
+obligation(Ag,Norm,achieved(Sch,Goal,Ag),DeadLine)
: .my˙name(Ag)
¡- .print(”I am obliged to achieve goal ”,Goal);
!Goal[scheme(Sch)];
goal˙achieved(Goal,Sch).
+obligation(Ag,Norm,What,DeadLine)
: .my˙name(Ag)
¡- .print(”I am obliged to ”,What,
”, but I don’t know what to do!”).
136 / 165
Introduction EOP OOP Conclusion Introduction Motivations OOP Moise
Summary –Moise
Ensures that the agents follow some of the constraintsspecified for the organisation
Helps the agents to work together
The organisation is interpreted at runtime, it is nothardwired in the agents code
The agents ‘handle’ the organisation (i.e. their artifacts)
It is suitable for open systems as no specific agentarchitecture is required
All available as open source at
http://moise.souceforge.net
137 / 165
Conclusions
Introduction EOP OOP Conclusion
Putting the Pieces Together
BELIEFSGOALSPLANS
INTERNALEVENTS
ACTIONSPERCEPTIONS
AGENTS
MISSIONS
ROLES
DEONTIC RELATIONS
GROUPS
NORMS
SANCTIONSREWARDS
ORGANISATIONS
RESOURCES
LEGACY
SERVICES OBJECTS
ENVIRONMENTS
COMMUNICATIONLANGUAGES
INTERACTIONPROCOLS
SPEECH ACTS
INTERACTIONS
MOISE Framework
JASON Agent Prog. Language
JADE Platform
CarTaGO Platform?
139 / 165
Introduction EOP OOP Conclusion
Exploiting Orthogonality
Treating AOP & EOP & OOP as orthogonal dimensionsimproving separation of concerns
using the best abstraction level and tools to tackle thespecific dimensions, avoiding design pitfalls, such as usingagents to implement either non-autonomous entities (e.g., ablackboard agent) or a collection of autonomous entities(group agent)
promoting openness and heterogeneity
E.g., heterogeneous agents working in the same organisation,heterogeneous agents working in the same environment, thesame agent working in di↵erent and heterogeneousorganisations, the same agent working in di↵erentheterogeneous environments
Outcome from a programming point of view
code more clean and understandableimproving modularity, extensibility, reusability
140 / 165
Introduction EOP OOP Conclusion
Beyond Orthogonality: Synergetic Integration
Exploiting one dimension to e↵ectively design and programalso aspects related to the other dimensions
for instance, using the environment to design, implement andrepresent at runtime the organisation infrastructure
Designing and implementing MAS behaviours that are basedon explicit bindings between the di↵erent dimensions
for instance, exploiting events occurring in the environment torepresent events that have an e↵ect at the institutional orsocial level
141 / 165
Introduction EOP OOP Conclusion
Exploiting Synergy between the A/E Dimensions
Mapping
agent actions into environment operations (e.g. CArtAgO)environment observable state/events into agent beliefs
Outcome
agents with dynamic action repertoireuniformly implementing any mechanisms (e.g. coordinationmechanism) in terms of actions/percepts
no need to extend agents with special purpose primitives
exploiting a new type of agent modularity, based onexternalization [Ricci et al., 2009a]
142 / 165
Introduction EOP OOP Conclusion
Exploiting Synergy on A/O Integration
Normative deliberative agents
possibility to define mechanisms for agents to evolve withinan organisation/several organisationspossibility to define proper mechanisms for deliberating on theinternalisation/adoption/violation of norms
Reorganisation, adaptation of the organisation
possibility to define proper mechanisms fordiagnosing/evaluating/refining/defining organisations
“Deliberative” Organisations
possibility to define dedicated organisational strategies for theregulation/adaptation of the organisation behaviour(organisational agents)
143 / 165
Introduction EOP OOP Conclusion
Exploiting Synergy between the E/O Dimensions
Grounding the organisation infrastructure
implemented using environment abstractions... that agents perceive then as first-class entities of theirworld
Mapping
organisational state reified by the environment computationalstateorganisational actions/perceptions reified by actions/perceptson the environment stateorganisational functionalities encapsulated by suitablydesigned environment abstractions
Outcome
“the power is back to agents” [Hubner et al., 2009c]by perceiving and acting upon that environment, agents canreason and dynamically adapt the organisation infrastructure
144 / 165
Introduction EOP OOP Conclusion
E/O Synergy Example: Implementing Regimentation
Exploiting the environment role of enabler and mediator ofagent interaction
by providing actions and generating percepts
�! natural place where to embed and enforceorganisational rules and norms
a↵ecting action execution behaviour and percepts generation
Examplessimple: a game-board artifact in an artifact-basedenvironment
providing agents actions to make movesencapsulating and enforcing the rules of the game
complex: fully-fledged institutions
reified into properly programmed environments
145 / 165
Introduction EOP OOP Conclusion
E/O Synergy Example: Implementing Constitutive Rules
Exploiting the environment to create, represent, and managedependencies and rules that are meaningful at theorganisational level
A main example: implementing constitutiverules [Searle, 1997]
events occurring in concrete environments conveyed as socialand institutional eventstypically represented in the form X counts as Y in Can example: reaching the environment state S counts asachieving the organisational goal G
The integration E/O allows for naturally design andimplementation of these kinds of rules
without adding any further concepts wrt the ones belongingto the E/O dimensions
146 / 165
Introduction EOP OOP Conclusion
A proposal: JaCaMo
Artifact
Operation Agent
Workspace
Work Environment
Manual
has
use
generateupdate
createdispose
link
consult
joinquit
Belief
Goal
Plan
External Action Internal Action
MissionRole
GroupSocial Scheme
createdelete
adoptleave
createdelete
commit leave
perceive
Trigger eventObservable Property
Norm
Goal
Action
Observable Event
Agentdimension
Environmentdimension
Organisationdimension
agent's actionscompositionassociationdependency concept mapping
dimension border
Lege
nd
147 / 165
Introduction EOP OOP Conclusion
Ongoing and Related Research
Unifying agents, environments and organisation perspectives
Volcano platform [Ricordel and Demazeau, 2002]MASK platform [Occello et al., 2004]MASQ [Stratulat et al., 2009], extending AGRE andAGREENEmbodied organisations [Piunti, 2010]Situated E-Institutions [Campos et al., 2009]
Normative programming andinfrastructures [Hubner et al., 2009a,Tinnemeier et al., 2009, Dastani et al., 2009b]
148 / 165
References[Behrens et al., 2010] Behrens, T., Bordini, R., Braubach, L., Dastani, M.,
Dix, J., Hindriks, K., Hbner, J., and Pokahr, A. (2010). An interface
for agent-environment interaction. In In Proceedings of InternationalWorkshop on Programming Multi-Agent Systems (ProMAS-8).
[Bernoux, 1985] Bernoux, P. (1985). La sociologie des organisations.Seuil, 3eme edition.
[Bordini et al., 2007] Bordini, R., Hubner, J., and Wooldridge, M. (2007).
Programming Multi-Agent Systems in AgentSpeak Using Jason. Wiley-
Interscience.
[Bromuri and Stathis, 2008] Bromuri, S. and Stathis, K. (2008). Situating
Cognitive Agents in GOLEM. In Weyns, D., Brueckner, S., and De-
mazeau, Y., editors, Engineering Environment-Mediated Multi-AgentSystems, volume 5049 of LNCS, pages 115–134. Springer Berlin / Hei-
delberg.
[Campos et al., 2009] Campos, J., Lopez-Sanchez, M., Rodriguez-Aguilar,
J. A., and Esteva, M. (2009). Formalising situatedness and adaptation
in electronic institutions. In Coordination, Organizations, Institutionsand Norms in Agent Systems IV, volume 5428/2009 of LNCS. SpringerBerlin / Heidelberg.
[Carabelea, 2007] Carabelea, C. (2007). Reasoning about autonomy inopen multi-agent systems - an approach based on the social power the-ory. in french, ENS Mines Saint-Etienne.
[Dastani, 2008] Dastani, M. (2008). 2APL: a practical agent programming
language. Autonomous Agent and Multi-Agent Systems, 16(3):214–248.
[Dastani et al., 2009] Dastani, M., Tinnemeier, N., and Meyer, J.-J. C.
(2009). A programming language for normative multi-agent systems.
In Multi-Agent Systems: Semantics and Dynamics of OrganizationalModels. IGI-Global.
[Dignum and Aldewereld, 2010] Dignum, V. and Aldewereld, H. (2010).
Operetta: Organization-oriented development environment. In Proceed-ings of LADS @ MALLOW 2010, pages 14–20.
[Esteva et al., 2001] Esteva, M., Rodriguez-Aguiar, J. A., Sierra, C., Gar-
cia, P., and Arcos, J. L. (2001). On the formal specification of elec-
tronic institutions. In Dignum, F. and Sierra, C., editors, Proceedingsof the Agent-mediated Electronic Commerce, LNAI 1191, pages 126–
147, Berlin. Springer.
[Esteva et al., 2004] Esteva, M., Rodrıguez-Aguilar, J. A., Rosell, B., and
L., J. (2004). AMELI: An agent-based middleware for electronic insti-
tutions. In Jennings, N. R., Sierra, C., Sonenberg, L., and Tambe, M.,
editors, Proc. of the 3rd Int. Joint Conf. on Autonomous Agents andMulti-Agent Systems (AAMAS’04), pages 236–243, New York, USA.
ACM.
[Ferber and Gutknecht, 1998] Ferber, J. and Gutknecht, O. (1998). A
meta-model for the analysis and design of organizations in multi-agents
systems. In Demazeau, Y., editor, Proceedings of the 3rd Interna-tional Conference on Multi-Agent Systems (ICMAS’98), pages 128–
135. IEEE Press.
[Gasser, 2001] Gasser, L. (2001). Organizations in multi-agent systems.
In Pre-Proceeding of the 10th European Worshop on Modeling Au-tonomous Agents in a Multi-Agent World (MAAMAW’2001), Annecy.
[Gateau et al., 2005] Gateau, B., Boissier, O., Khadraoui, D., and Dubois,
E. (2005). Moiseinst: An organizational model for specifying rights and
duties of autonomous agents. In Third European Workshop on Multi-Agent Systems (EUMAS 2005), pages 484–485, Brussels Belgium.
[Gutknecht and Ferber, 2000a] Gutknecht, O. and Ferber, J. (2000a). The
MADKIT agent platform architecture. In Agents Workshop on Infras-tructure for Multi-Agent Systems, pages 48–55.
[Gutknecht and Ferber, 2000b] Gutknecht, O. and Ferber, J. (2000b). The
MadKit agent platform architecture. In Agents Workshop on Infras-tructure for Multi-Agent Systems, pages 48–55.
[Hannoun et al., 2000] Hannoun, M., Boissier, O., Sichman, J. S., and
Sayettat, C. (2000). Moise: An organizational model for multi-agent
systems. In Monard, M. C. and Sichman, J. S., editors, Proceedings ofthe International Joint Conference, 7th Ibero-American Conference onAI, 15th Brazilian Symposium on AI (IBERAMIA/SBIA’2000), At-ibaia, SP, Brazil, November 2000, LNAI 1952, pages 152–161, Berlin.
Springer.
[Hubner et al., 2009a] Hubner, J. F., Boissier, O., and Bordini, R. H.
(2009a). Normative programming for organisation management infras-
tructures. In MALLOW Workshop on Coordination, Organization,Institutions and Norms in Agent Systems in Online Communities(COIN-MALLOW 2009).
[Hubner et al., 2009b] Hubner, J. F., Boissier, O., Kitio, R., and Ricci, A.
(2009b). Instrumenting multi-agent organisations with organisational
artifacts and agents: “Giving the organisational power back to the
agents”. Autonomous Agents and Multi-Agent Systems. DOI-URL:
http://dx.doi.org/10.1007/s10458-009-9084-y.
[Hubner et al., 2009c] Hubner, J. F., Boissier, O., Kitio, R., and Ricci, A.
(2009c). Instrumenting Multi-Agent Organisations with Organisational
Artifacts and Agents. Journal of Autonomous Agents and Multi-AgentSystems.
[Hubner et al., 2002] Hubner, J. F., Sichman, J. S., and Boissier, O.
(2002). A model for the structural, functional, and deontic specifica-
tion of organizations in multiagent systems. In Bittencourt, G. and Ra-
malho, G. L., editors, Proceedings of the 16th Brazilian Symposium onArtificial Intelligence (SBIA’02), volume 2507 of LNAI, pages 118–128,
Berlin. Springer.
[Hubner et al., 2006] Hubner, J. F., Sichman, J. S., and Boissier, O.
(2006). S-MOISE+: A middleware for developing organised multi-agent
systems. In Boissier, O., Dignum, V., Matson, E., and Sichman, J. S., ed-
itors, Coordination, Organizations, Institutions, and Norms in Multi-Agent Systems, volume 3913 of LNCS, pages 64–78. Springer.
[Hubner et al., 2007] Hubner, J. F., Sichman, J. S., and Boissier, O.
(2007). Developing Organised Multi-Agent Systems Using the MOISE+
Model: Programming Issues at the System and Agent Levels. Agent-Oriented Software Engineering, 1(3/4):370–395.
[Malone, 1999] Malone, T. W. (1999). Tools for inventing organizations:
Toward a handbook of organizational process. Management Science,45(3):425–443.
[Molesini et al., 2005] Molesini, A., Omicini, A., Denti, E., and Ricci, A.
(2005). SODA: A roadmap to artefacts. In Dikenelli, O., Gleizes, M.-
P., and Ricci, A., editors, 6th International Workshop “EngineeringSocieties in the Agents World” (ESAW’05), pages 239–252, Kusadası,
Aydın, Turkey. Ege University.
[Morin, 1977] Morin, E. (1977). La methode (1) : la nature de la nature.Points Seuil.
[Occello et al., 2004] Occello, M., Baeijs, C., Demazeau, Y., and Koning,
J.-L. (2004). MASK: An AEIO toolbox to design and build multi-agent
systems. In et al., C., editor, Knowledge Engineering and Agent Tech-nology, IOS Series on Frontiers in AI and Applications. IOS press, Am-
sterdam.
[Okuyama et al., 2008] Okuyama, F. Y., Bordini, R. H., and
da Rocha Costa, A. C. (2008). A distributed normative infras-
tructure for situated multi-agent organisations. In Baldoni, M., Son,
T. C., van Riemsdijk, M. B., and Winiko�, M., editors, DALT, volume
5397 of Lecture Notes in Computer Science, pages 29–46. Springer.
[Oliva et al., 2010] Oliva, E., McBurney, P., Omicini, A., and Viroli, M.
(2010). Argumentation and artifacts for negotiation support. Interna-tional Journal of Artificial Intelligence, 4(S10):90–117. Special Issue
on Negotiation and Argumentation in Artificial Intelligence.
[Omicini et al., 2008] Omicini, A., Ricci, A., and Viroli, M. (2008). Ar-
tifacts in the A&A meta-model for multi-agent systems. AutonomousAgents and Multi-Agent Systems, 17(3):432–456.
[Omicini et al., 2004] Omicini, A., Ricci, A., Viroli, M., Castelfranchi, C.,
and Tummolini, L. (2004). Coordination artifacts: Environment-based
coordination for intelligent agents. In Proc. of the 3rd Int. Joint Conf.on Autonomous Agents and Multi-Agent Systems (AAMAS’04), vol-
ume 1, pages 286–293, New York, USA. ACM.
[Ossowski, 1999] Ossowski, S. (1999). Co-ordination in Artificial AgentSocieties: Social Structures and Its Implications for AutonomousProblem-Solving Agents, volume 1535 of LNAI. Springer.
[Piunti, 2010] Piunti, M. (2010). Embodied organizations: a unifying per-
spective in programming agents, organizations and environments. PhD
thesis.
[Piunti and Ricci, 2009] Piunti, M. and Ricci, A. (2009). Cognitive ar-
tifacts for intelligent agents in mas: Exploiting relevant information
residing in environments. In Knowledge Representation for Agentsand Multi-Agent Systems (KRAMAS 2008), volume 5605 of LNAI.Springer.
1
[Piunti et al., 2009a] Piunti, M., Ricci, A., Boissier, O., and Hubner, J.(2009a). Embodying organisations in multi-agent work environments. InIEEE/WIC/ACM International Conference on Web Intelligence andIntelligent Agent Technology (WI-IAT 2009), Milan, Italy.
[Piunti et al., 2009b] Piunti, M., Ricci, A., Boissier, O., and Hubner, J. F.(2009b). Embodied organisations in mas environments. In Braubach,L., van der Hoek, W., Petta, P., and Pokahr, A., editors, Proceedings of7th German conference on Multi-Agent System Technologies (MATES09), Hamburg, Germany, September 9-11, volume 5774 of LNCS, pages115–127. Springer.
[Piunti et al., 2008] Piunti, M., Ricci, A., Braubach, L., and Pokahr,A. (2008). Goal-directed interactions in artifact-based mas: Jadexagents playing in CARTAGO environments. In Proc. of the 2008IEEE/WIC/ACM Int. Conf. on Web Intelligence and IntelligentAgent Technology (IAT’08), volume 2. IEEE Computer Society.
[Platon et al., 2007] Platon, E., Mamei, M., Sabouret, N., Honiden, S.,and Parunak, H. V. (2007). Mechanisms for environments in multi-agentsystems: Survey and opportunities. Autonomous Agents and Multi-Agent Systems, 14(1):31–47.
[Pynadath and Tambe, 2003] Pynadath, D. V. and Tambe, M. (2003). Anautomated teamwork infrastructure for heterogeneous software agentsand humans. Autonomous Agents and Multi-Agent Systems, 7(1-2):71–100.
[Ricci et al., 2010a] Ricci, A., Denti, E., and Piunti, M. (2010a). A plat-form for developing SOA/WS applications as open and heterogeneousmulti-agent systems. Multiagent and Grid Systems International Jour-nal (MAGS), Special Issue about “Agents, Web Services and Ontolo-gies: Integrated Methodologies”. To Appear.
[Ricci et al., 2007a] Ricci, A., Omicini, A., Viroli, M., Gardelli, L., andOliva, E. (2007a). Cognitive stigmergy: Towards a framework basedon agents and artifacts. In Weyns, D., Parunak, H. V. D., and Michel,F., editors, Environments for MultiAgent Systems III, volume 4389 ofLNAI, pages 124–140. Springer.
[Ricci et al., 2008] Ricci, A., Piunti, M., Acay, L. D., Bordini, R., Hubner,J., and Dastani, M. (2008). Integrating artifact-based environmentswith heterogeneous agent-programming platforms. In Proceedings of7th International Conference on Agents and Multi Agents Systems(AAMAS08).
[Ricci et al., 2009a] Ricci, A., Piunti, M., and Viroli, M. (2009a). Ex-ternalisation and internalization: A new perspective on agent modu-larisation in multi-agent system programming. In Dastani, M., Fallah-Seghrouchni, A. E., Leite, J., and Torroni, P., editors, LADS, volume6039 of Lecture Notes in Computer Science, pages 35–54. Springer.
[Ricci et al., 2010b] Ricci, A., Piunti, M., and Viroli, M. (2010b). Environ-ment programming in multi-agent systems – an artifact-based perspec-tive. Autonomous Agents and Multi-Agent Systems. Published Onlinewith ISSN 1573-7454 (will appear with ISSN 1387-2532).
[Ricci et al., 2009b] Ricci, A., Piunti, M., Viroli, M., and Omicini, A.(2009b). Environment programming in CArtAgO. In Bordini, R. H., Das-tani, M., Dix, J., and El Fallah-Seghrouchni, A., editors, Multi-AgentProgramming: Languages, Platforms and Applications, Vol. 2, pages259–288. Springer Berlin / Heidelberg.
[Ricci et al., 2009c] Ricci, A., Piunti, M., Viroli, M., and Omicini, A.(2009c). Environment programming in CArtAgO. In Multi-Agent Pro-gramming: Languages,Platforms and Applications,Vol.2. Springer.
[Ricci et al., 2010c] Ricci, A., Santi, A., and Piunti, M. (2010c). Actionand perception in multi-agent programming languages: From exogenousto endogenous environments. In In Proceedings of International Work-shop on Programming Multi-Agent Systems (ProMAS-8).
[Ricci et al., 2007b] Ricci, A., Viroli, M., and Omicini, A. (2007b). TheA&A programming model & technology for developing agent environ-ments in MAS. In Dastani, M., El Fallah Seghrouchni, A., Ricci, A.,and Winiko�, M., editors, Programming Multi-Agent Systems, volume4908 of LNAI, pages 91–109. Springer Berlin / Heidelberg.
[Ricci et al., 2007c] Ricci, A., Viroli, M., and Omicini, A. (2007c).CArtAgO: A framework for prototyping artifact-based environments inMAS. In Weyns, D., Parunak, H. V. D., and Michel, F., editors, En-vironments for MultiAgent Systems III, volume 4389 of LNAI, pages67–86. Springer. 3rd International Workshop (E4MAS 2006), Hakodate,Japan, 8 May 2006. Selected Revised and Invited Papers.
[Ricordel and Demazeau, 2002] Ricordel, P. and Demazeau, Y. (2002).VOLCANO: a vowels-oriented multi-agent platform. In Dunin-Kepliczand Nawarecki, editors, Proceedings of the International Conferenceof Central Eastern Europe on Multi-Agent Systems (CEEMAS’01),volume 2296 of LNAI, pages 252–262. Springer Verlag.
[Rocha Costa and Dimuro, 2009] Rocha Costa, A. C. d. and Dimuro, G.(2009). A minimal dynamical organization model. In Dignum, V., edi-tor, Multi-Agent Systems: Semantics and Dynamics of OrganizationalModels, chapter XVII, pages 419–445. IGI Global.
[Russell and Norvig, 2003] Russell, S. and Norvig, P. (2003). ArtificialIntelligence, A Modern Approach (2nd ed.). Prentice Hall.
[Santi et al., 2011] Santi, A., Guidi, M., and Ricci, A. (2011). Jaca-android: An agent-based platform for building smart mobile applica-tions. In Languages, Methodologies and Development Tools for Multi-agent systems, volume 6822 of LNAI. Springer Verlag.
[Searle, 1997] Searle, J. R. (1997). The Construction of Social Reality.Free Press.
[Shoham, 1993] Shoham, Y. (1993). Agent-oriented programming. Artif.Intell., 60(1):51–92.
[Stratulat et al., 2009] Stratulat, T., Ferber, J., and Tranier, J. (2009).MASQ: towards an integral approach to interaction. In AAMAS (2),pages 813–820.
[Tambe, 1997] Tambe, M. (1997). Towards flexible teamwork. Journal ofArtificial Intelligence Reseearch, 7:83–124.
[Tinnemeier et al., 2009] Tinnemeier, N., Dastani, M., Meyer, J.-J., andvan der Torre, L. (2009). Programming normative artifacts with declar-ative obligations and prohibitions. In IEEE/WIC/ACM InternationalJoint Conference on Web Intelligence and Intelligent Agent Technol-ogy (WI-IAT 2009).
[Viroli et al., 2007] Viroli, M., Holvoet, T., Ricci, A., Schelfthout, K., andZambonelli, F. (2007). Infrastructures for the environment of multiagentsystems. Autonomous Agents and Multi-Agent Systems, 14(1):49–60.
[Weyns and Holvoet, 2004] Weyns, D. and Holvoet, T. (2004). A formalmodel for situated multi-agent systems. Fundamenta Informaticae,63(2-3):125–158.
[Weyns and Holvoet, 2007] Weyns, D. and Holvoet, T. (2007). A referencearchitecture for situated multiagent systems. In Environments for Mul-tiagent Systems III, volume 4389 of LNCS, pages 1–40. Springer Berlin/ Heidelberg.
[Weyns et al., 2007] Weyns, D., Omicini, A., and Odell, J. J. (2007). Envi-ronment as a first-class abstraction in multi-agent systems. AutonomousAgents and Multi-Agent Systems, 14(1):5–30.
[Weyns and Parunak, 2007] Weyns, D. and Parunak, H. V. D., editors(2007). Special Issue on Environments for Multi-Agent Systems, vol-ume 14 (1) of Autonomous Agents and Multi-Agent Systems. SpringerNetherlands.
[Weyns et al., 2005] Weyns, D., Parunak, H. V. D., Michel, F., Holvoet,T., and Ferber, J. (2005). Environments for multiagent systems: State-of-the-art and research challenges. In Weyns, D., Parunak, H. V. D.,Michel, F., Holvoet, T., and Ferber, J., editors, Environment for Multi-Agent Systems, volume 3374, pages 1–47. Springer Berlin / Heidelberg.
[Wooldridge, 2002] Wooldridge, M. (2002). An Introduction to Multi-Agent Systems. John Wiley & Sons, Ltd.
2