A framework for organization-aware agents

Abstract

Open systems are characterized by the presence of a diversity of heterogeneous and autonomous agents that act according to private goals. Organizations, such as those used in real-life to structure human activities such as task allocation, coordination and supervision, can regulate the agents’ behavior space and describe the expected behavior of the agents. Assuming an open environment, where agents are developed independently of the Organizational structures, agents need to be able to reason about the structure, so that they can deliberate about their actions and act within the expected boundaries and work towards the objectives of the organization. In this paper, we present the AORTA reasoning framework and show how it can be integrated into typical BDI-agents. We provide operational semantics that enables agents to make organizational decisions in order to coordinate and cooperate without explicit coordination mechanisms within the agents. The organizational model is independent of that of the agents, and the approach is not tied to a specific organizational model, but uses an organizational metamodel. We show how AORTA helps agents work together in a system with an organization for choosing the best tender for a building project.

Appendix: Translating an OperA model

The OperA model [13] proposes an expressive way for defining open organizations distinguishing explicitly between the organizational aims, and the agents who act in it. OperA enables the specification of the organizational structure, requirements and objectives, and at the same time allows participants to have the freedom to act according to their own capabilities and demands. At an abstract level, an OperA model describes the aims and concerns of the organization with respect to the social system. These are described as the organization’s externally observable objectives, i.e. the desired states of affairs for the organization.

The OperA model contains the Organizational Model (OM), which is the result of the observation and analysis of the domain and describes the desired behavior of the organization, as determined by the organizational stakeholders in terms of objectives, norms, roles, interactions and ontologies. The OM consists of four interrelated structures: the social, interaction, normative and communicative structure. The social structure of an organization describes the roles holding in the organization. It consists of a list of role definitions, group definitions, and a role dependencies graph. The interaction structure describes the states that the agents should achieve, in terms of meaningful scenes that follow pre-defined abstract scene scripts. A scene script describes a scene by its players (roles), its desired results and the norms regulating the interaction. A scene script establishes also the desired interaction patterns between roles, that is, a desired combination of the (sub-) objectives of the roles. The normative structure describes expectations and boundaries for agent behavior, and the communicative structure specifies the ontology and the communication language used in the society.

In many ways, the OperA model is richer than the AORTA metamodel. The notion of, e.g., groups and scenes is not present in AORTA, and they cannot be directly translated into an equivalent notion. Furthermore, in some cases, the translation may not be ideal for practical purposes, so it may be necessary to manually change the metamodel after translating the OperA model. Even so, the translation provides a starting point for creating a metamodel, which should be preferred to creating the entire metamodel manually.

In the following we focus on the social, interaction and normative structure, and show how a subset of the OperA model can be translated into the AORTA metamodel. We do not directly consider the communicative structure, but since the ontology defined here is used in the other structures, the communication language is inherently included in the AORTA metamodel as well.

1.1 Social structure

The social structure specifies the roles, groups and role dependencies of the organization. Since the metamodel does not contain the notion of groups, we show only how to translate roles and role dependencies. A role in OperA is a tuple

$$\begin{aligned} role (r, Obj , Sbj , Rgt , Nor , tp ), \end{aligned}$$

where r is the role identifier, Obj and Sbj are objectives and sub-objectives, Rgt is the set of rights associated with the role, Nor is the set of norms and tp is the type of the role (which can be either external or institutional).

The metamodel has no concept of rights and does not distinguish between different role types. A role can therefore at most be described by its identifier, objectives, sub-objectives and norms. An OperA role then becomes $\textsf {role}(r, Obj )$ in the metamodel. We show how role norms can be translated in the normative structure. A set of sub-objectives for objective $\gamma$ is defined in OperA as a set $\varPi \gamma = \{\gamma _1, \ldots , \gamma _n\}$ such that $\overset{n}{\underset{i=1}{\wedge }} \gamma _i \rightarrow \gamma$. For each objective, $\gamma$, we thus add $\textsf {obj}(\gamma , \varPi \gamma )$ to the metamodel.

The social structure defines three kinds of dependency relations: hierarchical, market and network relations. They differ in how agents in the relation have authority over one another: the market relation facilitates bidding, the network relation is based on requests, and a hierarchical relation uses delegation. In AORTA, a dependency relation between roles $r_1$ and $r_2$ means that $r_1$ depends on $r_2$ for the completion of an objective. The AORTA dependency relation is not based on one agent having authority over another, thus it is up to the agents to decide how to use it, for example, by delegate tasks to agents enacting $r_2$. We thus perform the following translation: an OperA relation $r_1 \succeq _\gamma r_2$ becomes $\textsf {dep}(r_1, r_2, \gamma )$ in the metamodel.

1.2 Interaction structure

The interaction structure divides the organizational activity into scene scripts that provide partial ordering of objectives and transitions between scenes that provide synchronization and evolution of roles. Objectives of scenes are partially ordered using landmark patterns, which represent the minimum requirements for achieving the results of the scene.

Fig. 4

Interaction structure with landmark patterns for each scene script. Landmarks with a double edge are results of the scene script

Figure 4 shows an interaction structure with three scene scripts. We use this to show how to perform the translation into the metamodel. Informally, the interaction structure tells us that scene 1 ought to be completed before beginning on scene 2 and 3, and either scene 2 or scene 3 ought to be completed before moving on to the end scene. Furthermore, looking at scene 1, landmark $\lambda _1$ should be completed before $\lambda _2$ and $\lambda _3$, and so on. Since AORTA does not have a notion of scenes, we propose a translation of the interaction structure to conditional obligations with deadline. We basically convert each landmark pattern to a set of conditional obligations, and we connect the scenes using conditional obligations as well.

An obligation $O(p < \delta ~|~c)$ means that p ought to be achieved once c is achieved, and before $\delta$ occurs. We thus propose a translation where each landmark is the objective of an obligation, with the previous landmark(s) as condition and the next landmark(s) as deadline. For example, given a landmark pattern $\lambda _a \le \lambda _b \le \lambda _c$, the obligation to achieve $\lambda _b$ becomes $O(\lambda _b < \lambda _c~|~\lambda _a)$, which states that the agent ought to achieve $\lambda _b$ once $\lambda _a$ has been achieved, but before $\lambda _c$ is achieved, corresponding to the landmark pattern. In other patterns where multiple landmarks must be achieved in parallel before the next landmark, the obligation becomes a bit more complex, since we have to incorporate this. However the well-defined semantics of landmark patterns [32] and of scene transitions make it possible to translate such patterns into conditional obligations that correspond well with the meaning of the pattern. Table 3 lists the different kinds of patterns that can appear in the interaction structure.

Table 3 Different types of landmark patterns and scene transitions and their corresponding conditional obligations with deadline

We deal with the edge cases as follows. If for a landmark $\lambda$ there is no landmark $\lambda ^\prime$, such that $\lambda ^\prime \le \lambda$, then the condition for the obligation to achieve $\lambda$ is $\top$. This corresponds to an obligation that is immediately activated. If for a landmark $\lambda$ there is no $\lambda ^\prime$, such that $\lambda \le \lambda ^\prime$, then the deadline for the obligation to achieve $\lambda$ is $\bot$. This makes it hard to detect a violation, since an obligation is only violated once the deadline is reached, which never happens in this case. In order to accommodate this, it will be necessary to manually change the resulting metamodel to incorporate actual deadlines in these cases.

Example 1

We can use the translation scheme above to translate the interaction structure in Fig. 4. The first objective, $\lambda _1$, is translated into the obligation $O(\lambda _1 < \lambda _2 \vee \lambda _3 ~|~\top )$. The condition is $\top$ since $\lambda _1$ is the first objective. The deadline is reached when either $\lambda _2$ or $\lambda _3$ have been achieved, corresponding the fact that they are after $\lambda _1$ in the partial ordering. The rest of the resulting obligations are shown below.

$$\begin{aligned} \begin{array}{lll} O(\lambda _2 < \lambda _4 ~|~\lambda _1) &{} &{} O(\lambda _3 < \lambda _4 ~|~\lambda _1) \\ O(\lambda _4 < \lambda _5 \vee \lambda _7 \vee \lambda _8 ~|~\lambda _2\wedge \lambda _3) &{}&{} O(\lambda _5 < \lambda _6 ~|~\lambda _4) \\ O(\lambda _6 < \bot ~|~\lambda _5) &{}&{} O(\lambda _7 < \lambda _9 ~|~\lambda _4) \\ O(\lambda _8 < \lambda _9 ~|~\lambda _4) &{}&{} O(\lambda _9 < \bot ~|~\lambda _7 \wedge \lambda _8) \end{array} \end{aligned}$$

In this case, the obligations to achieve $\lambda _6$ and $\lambda _9$ both have $\bot$ as deadline, so it may be necessary to manually change the obligations to use actual deadlines.

The translation shown above omits a few parts of the interaction structure. Transitions between scenes may include role evolution relations, specifying how agents can (or are obliged) to enact a role in the next scene based on there current role. Furthermore, a role evolution may specify a conflict between roles, i.e. that two roles may not be simultaneously enacted by a single agent. This is not captured in the translation above. A role evolution relation is defined by

$$\begin{aligned} role-evolution (s.r_1, t.r_2, SN , \lambda ), \end{aligned}$$

where s and t are scenes, $r_1$ is a role in s, $r_2$ a role in t, SN is the type of relation and can be either necessary, sufficient or conflict, and $\lambda$ is the set of conditions for performing the role evolution (the landmarks that must be fulfilled by the agent). As we are considering only obligations, we are not translating sufficient role evolutions (i.e. the agent is allowed to enact a certain role in the next scene).

A necessary role evolution is translated into the following conditional obligation:

$$\begin{aligned} O_{r_1}(\textsf {rea}(Ag ,r_2) < \lambda _t~|~\lambda ), \end{aligned}$$

where Ag is the agent, $\lambda _t$ is the set of initial landmarks of scene t, and $\lambda$ is the set of conditions for performing the role evolution.

Role conflicts are somewhat problematic in AORTA. Intuitively, a role conflict is translated into the following conditional obligation:

$$\begin{aligned} O_{r_1}(\lnot \textsf {rea}(Ag ,r_2) < \lambda ^r_t~|~\lambda ), \end{aligned}$$

where Ag is the agent, $\lambda ^r_t$ is the set of results of scene t, and $\lambda$ is the set of conditions for the role evolution. However, if the obligation is activated and Ag is not enacting $r_2$, the obligation is immediate satisfied, and can therefore never be violated. The issue stems from the fact that obligations in AORTA are based on achievement, not maintenance, which means we cannot specify an obligation to maintain a state (in this case $\lnot \textsf {rea}(Ag , r_2$). A work-around is to let the activation condition be based on the enactment of both roles:

$$\begin{aligned} O_{r_1}(\lnot \textsf {rea}(Ag ,r_2) < \lambda ^r_t~|~\textsf {rea}(Ag ,r_2)\wedge \lambda ). \end{aligned}$$

That is, whenever the agent enacts both roles, it is obliged to deact the second role. Similarly, a global role conflict can be translated into $O_{r_1}(\lnot \textsf {rea}(Ag ,r_2) < \bot ~|~\textsf {rea}(Ag ,r_2))$.

1.3 Normative structure

The normative structure defines the expected boundaries of the agents participating in an organization. This is done by specifying norms that describe what agents enacting specific roles are expected to do. Norms in the normative structure are divided into role norms, scene norms and transition norms. Role norms define the generally expected behavior of a role regardless of participation in scenes. Scene norms define the expected behavior of roles participating in a specific scene. Transition norms define the limitations related with enacting new roles when moving between scenes, and were handled above in the translation of the interaction structure.

Norms in OperA are specified in Logic for Contract Representation (LCR). Different types of obligations are defined: conditional obligations, obligations with deadline and obligations without deadline. A obligation to achieve p before $\delta$ when c in LCR is translated to $O(p < \delta ~|~c)$ in the metamodel. If $c = \top$, the obligation has no condition. If $\delta = \bot$, the obligation has no deadline, which as discussed causes some issues regarding violation detection.

Fig. 5

The social structure of the RFT scenario. Each node corresponds to a role, and each edge corresponds to an objective dependency between roles

1.4 Example: request for tender

The RFT organization has been implemented in OperA. Our implementation of the bidding procedure is somewhat simple, in that we assume that the bidders simply specify a price for the RFT and the evaluator chooses the lowest bid. Since the process of making such decisions is not in the scope of this paper, we believe this is justified. We briefly describe the implementation and show its translation to the AORTA metamodel. The organization contains five roles, as shown in the social structure in Fig. 5. The social structure furthermore defines dependencies between the roles, based on the organization’s objectives. The roles are translated into the following roles in the metamodel:

$$\begin{aligned}&\textsf {role}(bidder , \{ submitted (RFT , Bidder , Bid ), contractSigned (Contract ) \}) \\&\textsf {role}(contractor , \{ rft (RFT ), published (RFT , Contractor ),\\&\quad contractSigned (Contract ), bestTender (RFT , Bid ) \}) \\&\textsf {role}(evaluator , \{ bestTender (RFT , Bid ) \}) \\&\textsf {role}(publicationBody , \{ published (RFT , Contractor ) \}) \\&\textsf {role}(consortiumPartner , \{ submitted (RFT , Bidder , Bid ), consortium (Bid , Partners ) \} ) \end{aligned}$$

Each role is associated with a number of main objectives. Most of these objectives are in turn associated with a number of subobjectives. We will not go into details with the objective specification, but will use the objectives in the translations below. The objectives are mostly self-explanatory, but will be explained in detail when deemed necessary.

The dependency relations are translated into the following predicates:

The dependency relations let the agents know how to cooperate in order to achieve the objectives. For example, a publication body agent can reason that since the contractor depends on it for publishing the RFT, it can request information about the RFT from the contractor, in order to fulfill its objectives. Furthermore, the contractor can ask the publication body to achieve the goal and provide the agent with the information required to publish it. Notice that the contractor depends on bidders for the submission of bids, while the evaluators depend on the contractor for this information.

The RFT process consists of a number of stages, which are translated into scenes in the interaction structure (Fig. 6). The contractor should enroll a publication body and a number of evaluators. The publication body will publish the RFT once its terms, conditions and deadlines have been decided by the contractor. Potential bidders can prepare a bid, including requesting more information and forming a consortium. They can then submit their bids (before the deadline). In the evaluation process, the evaluators ensure that the bids are compliant and decide on the best tender. Finally, the contract is then awarded to the best tender, and the parts form and sign the contract.

Fig. 6

The interaction structure of the RFT scenario. The forked arcs indicate that all incoming/outgoing scenes must be realized

The following is a subset of the conditional obligations generated from the IS:

$$\begin{aligned} \begin{array}{l} O_{bidder }(bid (RFT ,Bid ) < submitted (RFT , Bidder , Bid )~\\ \qquad \qquad \qquad \qquad |~consortium (Bid , Partners )\wedge infoRequested (Bid ,Request )) \\ O_{contractor }(rft (RFT ) < published (RFT , Contractor )~\\ \qquad \qquad \qquad \qquad |~deadline (RFT , DBid , DEvaluation ,DDecision )~\wedge \\ \qquad \qquad \qquad \qquad ~~terms (RFT ,Terms ) \wedge conditions (RFT , Conditions )) \\ O_{contractor }(contract (Contract , RFT , Bid ) < contractSigned (Contract )~\\ \qquad \qquad \qquad \qquad |~biddersInformed (RFT )) \\ O_{evaluator }(complies (RFT , Bid ) < evaluated (Bid , Result )~\\ \qquad \qquad \qquad \qquad |~published (RFT , Contractor ) \wedge submitted (RFT , Bidder , Bid )~\wedge \\ \qquad \qquad \qquad \qquad ~~evaluator (RFT ,Evaluator )) \end{array} \end{aligned}$$

For example, the contractor should only finalize the RFT once deadline, terms and conditions have been decided, and it should be done before it is being published. Similarly, the evaluator should ensure that a bid complies with the terms and conditions of an RFT before evaluating it, and should only do so once the RFT has been published, the bids are submitted and the evaluators have been assigned.

Finally, the normative structure includes the norms defined in Sect. 5.1. Since the translation is rather straightforward, we simply show a few of the obligations as defined in the metamodel:

$$\begin{aligned} \begin{array}{l} O_{bidder }(submitted (Bid , Bidder , Details ) < time (DBid ) \\ \qquad \qquad \qquad \qquad |~deadline (RFT , DBid , DEvaluation ,DDecision )~\wedge \\ \qquad \qquad \qquad \qquad ~~published (RFT , Contractor )) \\ O_{evaluator }(evaluated (Bid , Result ) < time (DEvaluation )~\\ \qquad \qquad \qquad \qquad |~deadline (RFT , DBid , DEvaluation ,DDecision )~\wedge \\ \qquad \qquad \qquad \qquad ~~submitted (RFT ,Bidder ,Bid )) \end{array} \end{aligned}$$

The norms allow for more specific obligations concerning the objectives. For example, bid submission should happen before the bidding deadline (DBid), and evaluation must be completed before the evaluation deadline (DEvaluation).

The norm concerning evaluators and contractors participating in a bidding consortium may be considered a role conflict, which in the metamodel can be expressed as follows:

$$\begin{aligned} \begin{array}{l} O_{evaluator }(\lnot \textsf {rea}(\alpha ,bidder ) < evaluated (Bid , Result )~\\ \qquad \qquad \qquad \qquad |~\textsf {rea}(\alpha ,bidder ) \wedge evaluator (RFT , \alpha ) \wedge bid (RFT , Bid ) \wedge ~\\ \qquad \qquad \qquad \qquad ~~consortium (Bid , Partners ) \wedge \alpha \in Partners ). \end{array} \end{aligned}$$

That is, an agent enacting the evaluator role is obliged to deact the bidder role, before the bid is evaluated, if that agent is an evaluator in an RFT for which it is also a consortium partner. A similar obligation can be specified for contractors.