Agreeing on Role Adoption in Open Organisations

The Social Structure of an organisation describes the roles in the organisation. For example, who should locate blocks, who should pickup and return them, how they relate to each other, etc. The Social Structure consists of a list of role definitions, Roles (including their objectives, rights, norms and requirements); a list of role groups’ definitions, Groups; and a Role Dependencies graph.

Abstract organisation objectives form the basis for the definition of the objectives of roles. From the organisation perspective, role descriptions identify the activities and services necessary to achieve its objectives and enable to abstract from the individuals that will eventually perform the role. From the agent perspective, roles specify the expectations of the society with respect to the agent’s activity in the society. In OperA, the definition of a role consists of an identifier, and sets of role objectives (with possibly their sets of sub-objectives), role rights, norms, and the role type.

Figure 1 shows the social structure of the BW4T organisation as used in this paper, and the corresponding role descriptions for the Searcher and Deliverer roles. Player is a group containing the roles Searcher and Deliverer. The arcs in the social structure diagram indicate the dependency relations between roles or groups. That is, the arcs are labeled with the objectives for which the parent role depends on the child role. These dependencies describe how the distribution of objectives in the organisation is realised. OperA identifies three types of role dependencies: bidding [Market], request [Network], and delegation [Hierarchy]. These are important for the realisation of the interactions between role enacting agents within the scenes described in the interaction structure, which is outside the scope of this paper.

In the BW4T example, the organisational objective of collecting the coloured blocks in a particular colour order is split over the two roles in the organisation; the Searchers are responsible for checking all rooms for the blocks and providing the information about block locations and colours to other agents (allRoomsChecked), and the Deliverers are responsible for picking up the blocks of the correct colour and dropping them at the drop zone (allBlocksDelivered). The deliverers thus depend on the searchers for finding the correct blocks, and the searchers depend on the deliverers for collecting the blocks and bringing them to the drop zone.

The Gatekeeper role is not specific to the BW4T domain, but must be present in every OperA organisational model. The gatekeeper is responsible for admitting agents to the organisation by means of asking agents about their capabilities and assigning roles to agents on the basis of this. This is why the Gatekeeper role has been marked as internal (“In”) in the social structure, which means that the agent(s) enacting this role are to be programmed by the designer of the organisation herself, while the other roles are marked as external (“Ex”).

External roles can be played by agents that are designed independently from the society. Individual agents consider joining an organisation when they believe that the enactment of role(s) will contribute to the achievement of some of their own goals. When an agent applies, and is accepted for a role, it commits itself to the realisation of the role’s objectives and it should function within the society according to the constraints applicable to its role(s). This means that agents need to be able to interpret the specification of the role and take this into account in their decision making. These processes are specified in the interaction structure. The social contracts in the Social Model are the result of these processes.

At the highest level of abstraction, norms are the values of a society, in the sense that they define the concepts that are used to determine the value or utility of situations. However, values do not specify how, when or in which conditions individuals should behave appropriately in any given social setup. In OperA, these aspects are defined in the Normative Structure using a deontic logic that is temporal, relativised (in terms of roles and groups) and conditional. The normative structure enables the definition of norms that specify desired behaviour that agents should exhibit when playing the role.

Norms in OperA can be obligations, permissions or prohibitions, represented respectively as O _r φ, P _r φ and F _r φ, where r is a role and φ a predicate in the domain language. Examples of norms in the BW4T domain are the obligation for deliverers to inform others of the blocks that they placed in the drop zone, and the prohibition that more than one searcher is present in the same room at any given moment. The latter can be formalised as:

In the theory of agency, the notions of agent capability and action have been widely researched. The intuition is that an agent possesses capabilities that make action possible. In the literature, there are many approaches to the formalisation of these definitions.¹ Research on the theory of action follows two main schools [9]. The first aims at the explicit representation of action by a specific agent, in terms of dynamic logic or situation calculus; whereas the second is concerned with representing the fact that a certain result has been achieved, such as in the stit theories or in the notion of agency. Based on the philosophical notion that “can” implies ability and opportunity [7], in [9], we have defined agent capability as the inherent skills an agent is endowed with. This implies that having a capability is a necessary but not sufficient prerequisite for exhibiting behaviour that demonstrates the capability. In that work, we discussed the relation between agent capability, ability (the potential or opportunity to act in a certain state) and action (the actual act of bringing a certain state about). This interpretation of capability as ability follows [19], in which the notion of capability is investigated in the context of BDI logic. In agent programming, capabilities have been introduced as a modularisation construct [4, 5] comparable to modules in Goal. Capabilities allow for packaging a subset of beliefs, plans, and goals into an agent module and to reuse this module wherever needed. That is, capability is taken as the capability to achieve goals, which is also the capability type considered in [19].

Although capabilities have been considered in the context of the gatekeeper in [8], modeling capabilities has so far received relatively little attention in OperA. Taking into account the analysis of the BW4T domain and other scenarios, we distinguish four capabilities types [24]: capabilities to execute actions, to perceive aspects of the environment in which the agents operate, to communicate information, questions or requests, and to achieve goals (formulated as objectives in the organisational specification). We believe this to be a suitable distinction since these four types of capabilities correspond to the commonly adopted notion of intelligent agents as being reactive (able to perceive and react to changes in the environment), proactive (act towards achieving goals) and social (communicate with other agents).

We have extended the meta-model of OperA to include the definition of role capabilities as follows:²

The semantics of role capabilities is defined as deontic expressions. That is, capabilities can be defined as norms that apply to agents that enact a role. Capability norms describe the activation and expiration conditions related to the enactment and deactment of the role by an agent. Required capabilities are modelled as maintenance conditions, i.e., as long as the agent is playing the role, it is obliged to have that capability. Formally: where α is an action that can be executed by agents in the environment, p is a situation that can be perceived by agents in the environment, c is a communicative act that can be performed by agents, and ϕ expresses a property of the environment that agents should be able to achieve.

In the BW4T scenario, examples of capabilities for the searcher role are the capability to execute the action of going to a place, the capability to perceive blocks and their colours, the capability to send information about blocks to other agents, and the capability to achieve the goal of having checked all rooms. For example, the required capability of the Searcher to perceive the blocks’ colours is modelled as I.e., upon enacting the role Searcher, the agent is obliged to be able to perceive the colour of the blocks until it deacts the role.

Intuitively, role capabilities describe the minimum skills that an agent must possess in order to enact the role. In that sense capabilities are complementary to role rights, which are capabilities that an agent receives by enacting a role. Which and how many capabilities are to be required from agents enacting a role is a modeling choice and reflect the balance between regulation and autonomy demanded by the application [20]. Basically, the less demands are placed on role enactment, the more autonomy is allowed to specific role-enacting agents, but the less guarantees can be made with respect to the overall organisational behaviour.

The behaviour of the gatekeeper is determined by the specification of the Gatekeeper role. Figure 3 shows the basic specification of the Gatekeeper role, which is standardly provided by OperA. According to this definition, the gatekeeper can decide to accept any agent that applies for a role. Specifying sub-objectives for processAdmission will constrain the gatekeeper to a specific way of admitting agents. For example, sub-objectives will force the gatekeeper to follow these steps in order to achieve the processAdmission objective. A partial definition of the Agent-Admission scene for this situation is depicted in Fig. 4. Landmarks in this scene indicate that the final state admit (corresponding to the realisation of the processAdmission objective) is entailled from achieving state caps_checked, which in turn depends on reaching the states in which each type of capabilities is checked. By refining or relaxing these landmarks, different behaviours can be obtained.

Another way to condition the gatekeeper’s behaviour is by defining norms in the role specification. For example, the norm indicates that the gatekeeper is forbidden to admit agents that do not exactly fulfill all capabilities of the role they aim to play. Other enactment rules can be described similarly. This norm provides a straightforward way of matching the available agents to the role requirements by demanding that each capability of the role can be fulfilled by the agent. That is, if the agent misses even one of the requirements of the role specification, it will not be selected for enactment of that role. This would result in an “all-or-nothing” situation: each role is fulfilled by an agent that has all the capabilities to enact it, and agents with insufficient capabilities are restrained from playing a certain role. In realistic situations, this may be unpractical. In those cases, the norm can be relaxed, for example, to indicate a minimum number of capabilities to fulfill, or to designate some prioritised capabilities that must be fulfilled.

Another possibility would be to keep the norm as above, but to extend the interaction scene to include the possibility for the gatekeeper to suggest a more suitable role to the applying agent, that is, a role for which it does have the required capabilities. For example, in the BW4T scenario, according to this norm an agent without the capability to recognise colour would not be accepted to enact the role of Searcher, but could be suggested to become a Deliverer.

Finally, another possibility for role enactment is to allow one role to be enacted by a set of agents working as a team. In this way, the total capabilities necessary to enact the role should be possessed by the team, which would enable agents to participate that have less capabilities. This is however, an aspect for further research.

The Gatekeeper agent has a number of ways to decide on the trustworthiness of the candidate agents. It could check the trustworthiness upfront, or on the fly. To check the trustworthiness upfront, the candidate agents could be required to present a certificate by a trusted third party to the Gatekeeper that states that the agent is indeed capable of perceiving, acting and/or communicating as promised. This is an easy and effective method, but requires such a third party that can actually check the candidate agents. The checking might be done off line. Alternatively, the Gatekeeper can set up a trial run for the agent to see whether the agent indeed has the required capabilities, before admitting the agent into the real team.

Another approach is for the Gatekeeper to consider the reputation of the candidate agent in the community. There is enough agent literature on reputation and trust mechanisms to choose appropriate and effective mechanisms per application. See, for example, [17, 21, 22]. A last and probably least attractive method, is to use a fundamentally much more complex approach in which the Gatekeeper would ask for the essential code of the candidate agent, and then use verification or model checking techniques to test the code for the desired capability. For literature on model checking agents, see e.g., [3, 16].

Instead of, or in addition to, deciding on the trustworthiness and capabilities of the candidate agent the Gatekeeper can also use monitoring methods to form an opinion of the player agents as they perform their tasks. Keeping a memory of results of monitoring of past performance would be used to decide to accept the agent again for the same role. For example, the GRID community has done research on this topic, see e.g., [18, 25]. The level of monitoring can be made dependent on the sensitivity of the application and also depends on the mechanisms put into place to prevent prohibited actions by the agents.