An overview of developing Nuin agents

This section of the manual aims to draw together the various components of Nuin to give an overview of how the pieces fit together. Only a high-level view is given here, details are in the relevant chapters of this manual.

In a nutshell, a Nuin agent comprises:

• a collection of agent behaviours, which are specified as plans and embodied by executing a plan in the context of an intention
• a knowledge base, encoded as sentences in a symbolic-logic formalism, together with one or more reasoners to process that encoded knowledge
• a set of zero or more agent services that provide specific capabilities (such as sending messages or retrieving RDF); these capabilities extend the scope and range of agent applications by providing an extension mechanism for an agent's behaviours that is still under the executive control of the agent's plans
• an agent configuration that specifies declaratively which behaviours, knowledge bases and services an agent has (and can supply configuration options to those services)

Developing agent behaviours

The behaviour of a agent at run-time is governed by the interpreter. The interpreter maintains a set of active and suspended intentions, and each intention is the active embodiment of a specific plan, named or anonymous. So, for the agent developer, programming agent behaviours comes down to specifying the agent's plans, and the conditions under which they are triggered.

For many Nuin users, the Nuinscript language is the most convenient way to specify a library of pre-built plans. Nuinscript defines a syntax for writing agent plans in a textual notation, and a parser for generating the Java objects that the interpreter uses. Most agent developers will use Nuinscript at first.

However, it is important to note that Nuinscript is only one way to create the Java plan and action objects for the interpreter. Other script syntaxes, such as an XML syntax could be envisaged (note: no such syntax is planned at the present time). Moreover, other tools could be used to generate plans, such as planning tools or a graphical plan editor.

» nuinscript
» intentions and plans

Developing agent knowledge bases

Nuin agents are based on the BDI architecture, which in turn is based on symbolic logic: predicate calculus with modal symbols. Logical sentences are used to specify the agent's mental states, which in turn direct its behaviours. In addition, much of the activity of a typical agent is itself knowledge-centric: for example, assisting a user to plan a trip, or diagnosing and responding to error signals. It is therefore important for Nuin to have a direct means of representing and processing such knowledge structures.

Nuin's knowledge representation formalism is defined in the org.nuin.ks package. The sub-packages values and sentences define abstractions for constant values and logical sentences respectively. What is actually defined in these packages is a collection of Java interfaces. This allows alternative instantiations of the actual embodiment of a particular element of the knowledge representation. Two such embodiments are provided in Nuin: one default implementation, and one which maps to RDF and OWL data sources.

In order to create KS values and sentences, the factory design pattern is used. In particular, the KsValueFactory creates concrete values that correspond to KS value interfaces, and KsSentenceFactory performs the same role for KS sentences.

The initial state of an agent's knowledge base can be specified in the agent's configuration, it can be defined within Nuinscript script language itself, or it can be loaded by the agent by reference to an external knowledge source when the agent starts up.

» knowledge representation

Using and developing agent services

The Nuinscript language attempts to strike a balance between providing a compact, high-level lanuage for specifying and controlling agent behaviours, and a general-purpose scripting engine. Nuinscript does not attempt to be a complete progamming language. Nor is it feasible for the Nuin platform to provide built-in actions for all conceivable tasks that agents may undertake. Suppose then that we wish to provide an agent with the ability to read RSS streams. Nuinscript is not complete enough to perform this task (nor would it be suited to the language design), and there is no built-in RSS action in Nuinscript. We solve this by providing an RSS service that plugs-in to the agent to provide a set of high-level actions appropriate to RSS feeds, which can then be accessed from the agent's script.

Writing a new service is straightforward. A service has to conform to a particular Java interface, and be registered with the appropriate service registries. The service registry allows an agent's services to be retrieved by name or by type. Both name and type are specified by URI symbols, and the types are typically specified in OWL ontologies (see, for example, service.owl and ServiceVocab). Using a service type to access the service means that plans can be made more modular and robust. For example, the same plan can be used to send messages in an agent that is using Jade for message passing, and another that is using the local message service, by referring to the service type (i.e. service:MessageService)

Invoking an exposed service method is performed via the verbs that the service exposes, represented as symbols. The script syntax to perform a service method is introduced by the @ symbol. See details.

» agent services

Configuring agents

Nuin agents are highly flexible. To fully specify an agent, the agent's plan library, knowledge base, services and basic configuration options (like the agent name) must be specified. In Nuin, this configuration is specified declaratively by encoding it all in a configurer. While the principle is general, the only currently implemented configurer uses an RDF document to provide the configuration data. The statements in the configuration document are marked up using an OWL vocabulary (see config.owl and ConfigVocab). Thus, only the contents configuration document needs to be passed to the agent when it starts, and the configuration process proceeds from there.

In practice, one configuration document will often be used to specify the configuration of a number of Nuin agents. Each configuration is an instance of the config:AgentConfiguration class, and the properties of the instance define the configuration of the agent.

» agent configuration details
» example agent configuration

« prev: design principles | developing agents | next: agent intentions & plans »