User:Ramòntezuma/2apl

2APL (= APAPL = A Practical Agent Programming Language) is an agent programming language and platform, developed at the University of Utrecht. This programming language enables the implementation of software agents in terms based on the BDI-model, like Beliefs, Goals and Plans. 2APL is the successor of 3APL, which was also developed at the Utrecht University. 2APL was built on top of the JADE-platform. This enables the 2APL-agents to communicate according to the FIPA-standards.

A 2APL Multi agent system consists of the following:

• One or more 2APL-files containing the agents in their initial states;
• A MAS-file;
• (Optional) One or more environments, written in Java.

2APL agent

A 2APL agent can be implemented in a file with the extension '.2apl'. It consists of the following components:

Beliefs

The beliefs of a 2APL agent describes the initial knowledge of the agent about the environment, the agent itself or other agents. In a .2apl-file, the term 'Beliefs:' indicates that the lines below are beliefs. 2APL uses the Prolog syntax for the beliefs of an agent.

Example:

Beliefs:
  lorem(ipsum).
  dolar(sit) :- amet(consectetur).

BeliefUpdates

The BeliefUpdates describe the rules of how an agent should update it's beliefs. A BeliefUpdate has the following form:
{ preconditions } Name( parameters ) { postconditions }.
The preconditions should be satisfied in order to execute the update. these conditions have the form of Prolog-facts, seperated by a comma.

The name of a BeliefUpdate must start with a Capital letter. Otherwise, the 2APL interpreter can't find a difference between BeliefUpdates and PC-rules. The parameters of a BeliefUpdate should also start with an uppercase letter, as usual for Prolog variables.

The postconditions describe the actual changes of the agent's beliefs and have the same form as the preconditions. Using the keyword not, beliefs can be removed from the agent's beliefbase.

Example:

BeliefUpdates:
  { lorem(ipsum) }  Dolor(X, Y)  { not sit(X), sit(Y) }

Goals

The goals are the agent's desires; what the agent wants to achieve. Goals are also written in Prolog, seperated by a comma (not a dot!). When the agent has a belief similar to a goal, the goal is considered to be achieved and will be dropped. As an alternative, the instruction dropgoal(goal) can be used in the content of a PG-, PC- or PR-rule.

Example:

Goals:
  lorem(ipsum),
  dolar(sit)

Plans

The instructions below the Plans:-keyword are the initial actions the agent will perform in order to meet it's goals. These plans will be executed immediately after starting the agent.

Example:

Plans:
  lorem();
  ipsum()

PG-rules

The PG-rules or Planning Goal-rules describe how new plans should be made. A PG-rule has the following form:
goal <- preconditions | { plans }
On the left hand of the arrow, we see the goal which this PG-rule is about. On the right hand, before the pipe, we define the preconditions of the PG-rule. In a PG-rule, the preconditions are seperated by a logical and or or. Between the braces, the code of this PG-rule is placed.

Example:

PG-rules:
  lorem(ipsum) <- dolor(sit) |
  {
    skip
  }

There can be more than just one PG-rule per goal, as long as the preconditions differ.

PC-rules

The PC-rules or Procedure Call-rules define rules that resemble procedures or functions like in the programming language C. The form of a PC-rule is as follows:
name(parameters) <- preconditions | { plans }
The name of the PC-rule can be anything, as long as it starts with a lowercase letter. The parameters should be variables starting with an uppercase letter, seperated by comma's. The preconditions have the same form as those of the PG-rules.

Example:

PC-rules:
  lorem(Ipsum, Dolor) <- sit(amet) |
  {
    skip
  }

PR-rules

The PR-rules or Plan Repair-rules describe what the agent should do when the execution of a plan fails. The PR-rules have the form:
plan <- preconditions | { code }
At the left hand of the arrow, the regarding plan is defined. The preconditions have the same form as those of the PC- and PG-rules.

Example:

PR-rules:
  lorem(ipsum) <- dolor(sit) |
  {
    skip
  }

MAS

The .mas file specifies the initialisation of the environments and which agents should be included in the Multi agent system. A .mas file contains XML code.
Example:

<apaplmas>
  <environment name="lorem" file="path/to/an/environment.jar">
    <parameter key="dolor" value="sit" />
  </environment>
  <agent name="ipsum" file="path/to/an/agent.2apl"/>
</apaplmas>

In the example above, you can see an environment being initialised with a parameter. This parameter has a key 'dolor' and a value 'sit'. Also, an agent is inserted into the MAS with a certain name 'ipsum' and the path to the .2apl sourcefile. Note that the name of the agent should start with a lowercase letter, because an uppercase letter would conflict with variables in the 2APL-files. The 2APL interpreter does not warn you for this.

2APL Environment

blabla

External links

• example.com