See: Description
| Interface | Description |
|---|---|
| AgentAction |
Generic interface to be implemented by classes associated to agent actions
in an ontology.
|
| Concept |
Generic interface to be implemented by classes associated to concepts
in an ontology.
|
| ContentElement |
Interface representing a generic content element, i.e. an
expression that can be meaningfully used as the content of
an ACL message.
|
| Predicate |
Generic interface to be implemented by classes associated to predicates
in an ontology.
|
| Term |
Interface representing a generic term, i.e. an expression
identifying a generic entity (abstract or concrete) that "exist"
in the world and that agents can talk and reason about.
|
| Class | Description |
|---|---|
| ContentElementList |
Utility class to deal with a list of content elements as a
content element itself.
|
| ContentManager |
This class provides all methods to manage the content languages
and ontologies "known" by a given agent and to fill and extract the
content of an ACL message according to a given content language and
ontology.
|
| OntoACLMessage |
Utility class that allow using an
ACLMessage object
as an ontological agent action. |
| OntoAID |
Utility class that allow using an
AID object
as an ontological concept. |
| Exception | Description |
|---|---|
| ContentException |
Base class for OntologyException and CodecException
|
When an agent A communicates with another agent
B, a certain amount of information I is transferred from A to B by means
of an ACL message. Inside the
ACL message, I is represented as a content expression consistent with a
proper content language (e.g. SL) and encoded in a proper format (e.g. string).
Both A and B have their own (possibly different) way of internally representing
I. Taking into account that the way an agent internally represents a
piece information must allow an easy handling of that piece of information, it
is quite clear that the representation used in an ACL content expression is not
suitable for the inside of an agent.
For example the
information that there is a person whose
name is Giovanni and who is 33 years old in an ACL content expression could
be represented as the string
(Person :name
Giovanni :age 33)
Storing this information
inside an agent simply as a string variable is not suitable to handle the
information as e.g. getting the age of Giovanni would require each time to
parse the string.
Considering software
agents written in Java (as JADE agents are), information can conveniently be
represented inside an agent as Java objects. For example representing the above
information about Giovanni as an instance (a Java object) of an
application-specific class
class Person {
String name;
int age;
public
String getName() {return name; }
public
void setName(String n) {name = n; }
public
int getAge() {return age; }
public
void setAge(int a) {age =
a; }
….
}
initialized with
name = “Giovanni”;
age = 33;
would allow to handle it very easily.
It is clear however
that, if on the one hand information handling inside an agent is eased, on the
other hand each time agent A sends a piece of information I to agent B,
1)
A needs to convert his
internal representation of I into the corresponding ACL content
expression representation and B needs to perform the opposite conversion.
2)
Moreover B
should also perform a number of semantic checks to verify that I is a
meaningful piece of information, i.e. that it complies with the rules (for
instance that the age of Giovanni is actually an integer value) of the ontology
by means of which both A and B ascribe a proper meaning to I.
The classes included in this package and its sub-packages are designed to automatically perform all the above conversion and check operations, thus allowing developers manipulating information within their agents as Java objects (as described above) without the need of any extra work.