Communication Ontological Description
This activity aims at describing communications and conversations among roles. Communications are a more refined way for interacting compared to the basic Interactions allowed to the AbstractRole. Interactions identified in the problem domain are specialized in this domain in communications. The model of role communication is based on the assumption that two roles, which wish to interact, share a common ontology. This common knowledge is represented in the communication by a set of Ontology Elements. A conversation is a specialization of communication in which content (Language, Encoding, Ontology) and control (Protocol) of the communication are detailed. A conversation mainly consists of FIPA5 speech acts[29, 30] and protocols. A protocol defines the sequence of expected messages.
Scenario descriptions are one of the basis of this activity since they introduce the first set of interactions in which each role is involved. Useful information for designing a correct structure for interactions could come from the solution ontology, where the necessary knowledge structures are defined. The dynamics of interactions is also related to the results of Interactions and Role Identification, and Capacity identification diagrams.
Communication Ontological Description is depicted by a class diagram where classes represent roles and associations represent communications. The attributes of each communication (Ontology) and each conversation (Ontology, Content Language, Interaction Protocol) are specified by an association class. The direction of each conversation is explicitly oriented from the initiator of the conversation to the other participant roles.
MAS Metamodel Elements
Define(Communication), Define(Conversation), Relate(Communication, Predicate), Relate(Communication, Concept), Relate(Communication, Action), Relate(Conversation, Protocol), Relate(Conversation, Language).
Work to be done
Each set of interactions between two roles has to be clustered in one or more communications/conversations. At this stage we could regard the previous studied interactions as messages of the communication/conversation. Interactions linking a boundary role to another boundary one are generally refined in communications (usually these interactions are mediated by the environment and therefore are not classical message-based conversations). They can be based on events or other stimuli sent from one role to the other. Interactions between classical (i.e. non-boundary) roles are refined in conversations with a defined protocol, a referred ontology and an associated content language. As a consequence in conversations, the sequence of messages will be ruled by a proper interaction protocol. The content will be related to the exchanged information or required exhibition of a capacity through an explicit reference to the adopted ontology. This is in accordance with the FIPA specifications (that we largely adopt), where conversations consist of speech acts . FIPA also specifies a relevant number of interaction protocols but a new one, if necessary, can be designed as reported in section 5.4. This activity should also describe data structures required in each role to store exchanged data by adding the necessary ontological structure to roles. These structures are of course based on the elements of the solution ontology.
Let’s now consider the Team Simulation organisation of our example. In this organisation six interactions have been identified. Two of them may be modelled as a conversation. For instance, the interaction between Players Simulator and Role Assigner may be considered as a conversation respecting the FIPA Inform Communicative Act , manipulating the Strategy Role Assignment predicate previously defined in the Solution ontology and adopting the RDF (Resource Description Framework) content language . Figure 20 describes several of the communications and conversations of the Team Simulation organisation.
|Figure 20: Class diagram describing some of the communications/conversations designed for the Robot Soccer Simulator case study |