EEL 5937

The Bond Agent System(4)

EEL 5937 Multi Agent Systems

Lecture 18, March. 6, 2003

Lotzi Bölöni

EEL 5937

Bootstrapping a multi-agent system

EEL 5937

Bootstrapping multi-agent systems

• Creating a set of agents which will act in a coalition.– In practical deployments, only agents working on behalf

a single user are started like this.

• All the projects can be seen as examples of this.– Even if some of the agents in the projects are in

adversarial relations.

• It can be done:– By hand using the Jade Remote Agent Manager.– By a bootstrapping agent.

EEL 5937

Bootstrapping agent.

• A bootstrap agent– Bootstrap.py (see example in the prisoners dilemma

directory)– Takes a bootstrap file as input. – Starts the agents described (potentially on multiple

machines)– Terminates.

• The format of the bootstrap file:<host> <blueprint file> <agent name>

• Example bootstrap file:

localhost bond\applications\prisoners_dilemma\simple\Judge.py Judge

localhost bond\applications\prisoners_dilemma\simple\Prisoner1.py Prisoner1

localhost bond\applications\prisoners_dilemma\simple\Prisoner1.py Prisoner2

EEL 5937

Basic strategies.Strategy database

EEL 5937

Strategy Database

• Contains a collection of general purpose strategies.

• Promotes code reuse.

• Utility strategies – Running applications

• System strategies– Running applications, running scripts– Transfering files (FTP etc)– Mail, Http

• Agent manipulation– Remotely starting, stopping agents, etc.

• Agent protocol implementation– Question/Reply– Contract net, auctions, etc.

EEL 5937

Utility strategies: WaitAndTransitionStrateg

y• Usage:

– addState(WaitAndTransitionStrategy())– addState(WaitAndTransitionStrategy(5000, SUCCESS))

• Functionality:– Waits for the specified number of milliseconds than

performs the transition specified.

• Transition:– The transition specified (SUCCESS by default)

EEL 5937

Utility strategies: DummyStrategy

• Usage:– addState(DummyStrategy())

• Functionality:– Blocks indefinitely. (Used for debugging)

• Transition:– None.

EEL 5937

Utility strategies:ShowMessageStrategy,

ShowErrorStrategy• Usage:

– addState(ShowMessageStrategy(“Message”))– addState(ShowMessageStrategy(“ErrorMessage”))

• Functionality:– Shows a message / error message in a dialog box.

Transitions when the user clicks on the button.

• Transition:– SUCCESS

EEL 5937

Utility strategies: ChoiceStrategy

• Usage:– addState(ChoiceStrategy(“Proceed?”))

• Functionality:– Shows a dialog with the message with two buttons.

• Transition:– SUCCESS if the Yes button is pressed.– FAILURE if the No button is pressed.

EEL 5937

Utility strategies: ExitAgentStrategy

• Usage:– addState(ExitAgentStrategy())

• Functionality:– Terminates the agent by calling doDelete().

• Transition:– None (the agent will be terminated).

EEL 5937

Embedding Python/Blueprint code in

strategies• There is a special strategy called

BlueprintStrategy which allows us to write the entire strategy in Python

• Useful for:– Rapid prototyping (no compilation needed)– Machine generated code.– Code with evaluated expressions. – Strategies which need the parsing capabilities of

Python.

• Usage (in Blueprint)s = BlueprintStrategy(“print ‘Hello’\ncurrentStrategy.exitWith(SUCCESS)")

S = BlueprintStrategy(blueprintfile=“Strategy1.py”)

EEL 5937

Python/Blueprint strategies

• The code you specify is going to be executed in the action() function.

• There are several predefined variables:– agent – points to the agent– currentStrategy – points to the current strategy

• Terminating the strategy:– currentStrategy.exitWith(SUCCESS)– Or FAILURE, IDLE etc.

• Remember, that this has to be valid Python code– Line alignment– Import

• You can use all the Java functionality as well.• Most of the utility strategies are

implemented this way.

EEL 5937

State in the agents

EEL 5937

Understanding the state and knowledgebase

• The knowledgebase of the agent contains highly structured, ontologically represented information

• There is also some other state information stored in the strategies themselves.

EEL 5937

Using the Jade “datastore” in Bond agents

EEL 5937

Using the data store

• The data store of strategies is a small associative memory attached to the individual strategies.

• It can store any Java object.• Adding values to the data store:

– String value = “Hello”;– getDataStore().put(“Label”, value);

• Retrieving values from the data store:– String value2 = getDataStore().get(“Label”)

• The data store is attached to strategies. Its role is essentially similar to local variables.

• Advantage: it can be managed when checkpointing or migrating agents (much more difficult for local variables…)

EEL 5937

Sharing data between strategies using data

stores• The planes and the multiplane state machine

itself have their own data stores. • This can be used to share data between

strategies. • Eg. sharing the data with all the strategies in

the same plane:

getPlane().getDataStore().put(“CommonValue”, “x”);

• Sharing the data with all the strategies in all planes:

• theAgent().getTheMultiplaneStateMachine().• getDataStore().put(“ReallyCommon”, “z”);

EEL 5937

Using the Protégé-2000 knowledgebase in Bond

EEL 5937

Using the Protégé-2000 knowledgebase

• Every Bond agent has a private knowledgebase, which is implemented using the Protégé-2000 backend.

• The knowledgebase is created when the agent started and deleted when terminated.– You can explicitly save it, however.

• The Bond knowledgebase can be accessed from the agent:– theAgent.getBondKnowledgeBase()

• You can also have access to the underlying Protégé-2000 knowledgebase directly:– theAgent.getBondKnowledgeBase().getProtegeKB();– It is recommended that you use this only when it is

really needed.

EEL 5937

Bond core ontology

• By default, the knowledgebase of a Bond agent contains this.– To check it in Protégé-2000, the file name is

kb/BondCore.pprj

• Contains basic definitions:– AgentInfo, Belief, Desire, Intention– Program, File– Small ontology of time

EEL 5937

Domain specific ontologies(creating)

• Agent designers should create their own ontology specific to the problem the agent solves.

• For example:– Commerce ontology (money, products, customer types

etc)– Battlefield ontology (units)– Geographical ontology (geographical entities, terrain

types etc)

• Multiple agents can share the same ontology.• Some agents might need more than one.• When designing ontologies:

– Ontologies might rely on each other (“include” concept in Protégé)

– All domain specific ontologies can rely on BondCore

EEL 5937

Domain Specific Ontologies

(importing in agents)• The ontologies should be imported into

agents in the Blueprint script:– includeKnowledgeBase(“Geography") – This assumes the existence of the file kb/Geography.pprj

• You don’t need to explicitly include BondCore

• You don’t need to explicitly include the ontologies on which your domain specific ontologies rely on.

• You can share domain ontologies between agents (these files will not be changed).

EEL 5937

Domain Specific Ontologies (using in

strategies) theKB = theAgent.getBondKnowledgeBase();

Cls theClass = theKB.getCls(“Customer");

for (Iterator it=theClass.getDirectInstances().iterator();

it.hasNext(); ) {

InstanceWrapper inst = new InstanceWrapper(

(Instance) it.next(), theKB);

String customer = inst.getSlotAsString(“Name");

System.out.println(“Customer = ” + customer)

inst.setSlot(“Touched”, new Boolean(true));

}