We describe the difference between LightJason and Jason, because in general the LightJason framework is inspired by Jason, but it is not
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.
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.
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.
The LightJason AgentSpeak(L++) structure does not distinguish between messages and perceiving. We reduce this concept to two elements:
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.
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:
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:
/. The path structure can be defined for each agent individually, so equal literal objects can be addressed by different paths
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.