Theoretical Introduction: Difference to Jason

We describe the difference between LightJason and Jason, because in general the LightJason framework is inspired by Jason, but it is not

• a copy of Jason
• or an extension to Jason

LightJason does not use any code fragments of Jason, so there is no connection between the two frameworks. LightJason is only inspired by the concept of Jason on a theoretical level. We build a fully new framework from scratch. The image allows you to highlight elements by a mouse over effect for better understanding.

Jason Agent Cycle

The Jason agent cycle defines the execution mechanism of an agent and is described in the Jason Book, figure 4.1 (page 68). The cycle execution depends on the ordering of the source code within the ASL file.

LightJason Agent Cycle

From a general point of view we reduce the Jason agent cycle to the necessary elements. This allows us to build a very efficient execution structure based on a parallel data-streaming architecture. On the other hand we generalise the cycle structure, so we can build a more flexible architecture. But keep in mind that the LightJason agent cycle is run in parallel with optional on-demand / lazy-binding data elements.

Perceiving & Messaging

The LightJason AgentSpeak(L++) structure does not distinguish between messages and perceiving. We reduce this concept to two elements:

• triggers which are pushed data for the agent
• on-demand access which is a component of the beliefbase to read knowledge on-demand during runtime

All triggers will be cached, instantiated and executed in parallel during the cycle. During execution new incoming triggers will be stored inside the cache. The execution can get access via unification to the beliefbase, so the beliefs can be unified during execution. A statistic will count fails and successful runs of the plans. The variable builder allows to define any grounded variables and constants on runtime e.g. position data. The structure can be used for faster access to any data without unification.

Terms and Literals

The LightJason architecture does not implement all elements of a logic programming language. We also reduce this concept, so that we can optimise the execution performance. We define two elements only:

• literals which define logic structures, i.e. knowledge with negation, functor, value list
• raw terms which defines a wrapper around any native Java object type

Beliefbase

The beliefbase is not a single element for storing all facts of the agent. The beliefbase is a tree structure for organising the agent knowledge. Nodes of this knowledge tree can be shared over many agents or can be used by on-demand unification, so that the agent can perceive the environment in real time. We split up the beliefbase into three parts:

• storage is a physical or on-demand data structure for storing / generating literals, which are defined by the last element of the functor with negation, values and annotations only
• view is a flyweight pattern to define a path structure for organisation of literals / knowledge, the different path elements are separated by a /. The path structure can be defined for each agent individually, so equal literal objects can be addressed by different paths
• beliefbases are components for connecting the storage and the view and generating triggers for the execution mechanism

For a more detailed description see the efficient beliefbase tutorial, which explains usage and different types of data structures. From a general point of view the beliefbase can help you to organise the knowledge of your agents, so that you can create semantic knowledge sets or ontologies for any kind of information.