Exchanging Data and Ontological Definitions in Multi-Agent-Contexts Systems Stefania Costantini and Giovanni De Gasperis Department of Computer Science and Engineering and Mathematics University of L’Aquila, Italy, email: {stefania.costantini,giovanni.degasperis}@univaq.it Abstract. In recent work we have extended DACMAS, which is a formalization of ontology-based and commitment-based multi-agent systems. Our extension al- lows a system to include not only agents but also external contexts. The objective is that of modeling real-world situations where agents not only interact among themselves, but also consult external heterogeneous data- and knowledge-bases to extract useful information. In this paper we further enhance the approach, so that a querying agent is enabled to specify in ontological terms which data it intends to extract from a context, or vice versa needs to be made aware of onto- logical assumptions the received results are based upon. 1 Introduction In Multi-agent systems (MAS), ontologies constitute a key point in practical applica- tions for agents defining and maintaining their own knowledge base, and for inter-agent communication. It is generally acknowledged that the ontology used for communica- tion must be agreed upon and understood by the agents composing a MAS, and in fact virtually all Agent Communication Languages (ACLs) allow for the specification of the ontology for communication. In interesting recent work [1], Calvanese De Giacomo and Montali take the explicit stance that data maintained by the agents impact on the dynam- ics of a MAS, and to the evolution of inter-agent communication. They thus formulate an approach, called DACMAS (Data-Aware Commitment-based MAS) based upon the DRL-Lite Description Logic [2]: in DACMAS, a set of agents is augmented with an institutional agent which owns a “global” TBox, representing the basic concepts, rela- tions and constraints which are proper of the domain in which the agents operate. Each agent in a DACMAS is then equipped with a local ABox which is consistent with the global TBox. As agents composing a DACMAS are autonomous entities, mutual con- sistency of the ABoxes is not required. Agents are also equipped with a set of reactive and proactive rules, where proactive rules model communications, and reactive rules model internal updates. Communication in DACMASs is based upon commitments (cf. [3, 4] and the refer- ences therein), which constitute a relatively recent but very well-established approach to agent communication. In DACMASs, the institutional agent is aware of all agents participating in the system and of their interaction, and implements the “Commitment machine”, which manages commitments lifecycle. More precisely, agents in a DAC- MAS communicate by interchanging events, which may then lead to commitment for- mation. For instance, a potential buyer sends an event to a seller in order to register as customer. When (via an internal update) the seller does so, it sends to the buyer events representing offers. Only later, in case, e.g., the customer decides to buy, commitments are (conditionally) created by the institutional agent about, e.g., payment and delivery. In [5] we have extended the DACMAS approach to include the possibility, for agents, to gather information from external heterogeneous data sources. In real-world applications in fact, decisions (such as, e.g., whether to accept a customer or whether to issue an order to a certain seller, whether to enroll a candidate student, whether to concede a loan and at which conditions, etc.) are taken, via suitable reasoning strate- gies, after consulting a number of information sources that can be not only internal, but also external to the agent system, and that cannot be in general standardized. We considered as a basis the DACMAS approach because it introduces the element of log- ical ontologies within simple rule-based agents, of which they provide a specification only concerning the few kinds of reactive and proactive rules mentioned above. There- fore, in our opinion the approach can be seen as a useful general framework that can be specialized to many rule-based languages, in which to program the reasoning and delib- erative components of agents, or further generalized communication modalities. Such languages can be, e.g., AgentSpeak (cf. [6] and the references therein), GOAL (cf. [7] and the references therein) 3APL (cf. [8] and the references therein), METATEM(cf. [9] and the references therein), KGP (cf [10] and the references therein), DALI (cf. [11, 12]), or other agent-oriented languages [13]. The DACMAS approach is interest- ing also for its potential for affordable verification, again due to the rule-based nature of DACMAS agents. In the Artificial Intelligence and Knowledge Representation field, the managed Multi-Context Systems (mMCS) approach has been proposed to model information exchange among heterogeneous entities [14, 15]. In this proposal, there is a number of (information) contexts that are essentially kinds of heterogeneous reasoning enti- ties, which include so-called bridge rules that enable interaction. MCSs assume real heterogeneity and partial information about information sources, wherein interesting comprehensive existing approaches such as, e.g., “Agents and Artifacts” (cf. [16] and the references therein) assume that external sources can be described, or even manipu- lated by agents of the MAS. This is often not the case, as external knowledge bases are “opaque” and what is known is limited to the kind of information that can be obtained. The approach of DACMACSs (Data-Aware Commitment-based managed Multi- Agent-Context Systems) [5] integrates DACMASs and mMCS. This by augmenting the set of participating agents by a set of contexts, and by equipping agents with special communicative rules that are a variant of bridge rules. We have assumed that contexts, though heterogeneous in nature, accept relational-like queries, and in particular datalog queries (that correspond to the select-project-join fragment of SQL) with negation. The main features of the DACMACS proposal are in summary the following. (1) Agents can query (sets of) contexts, but contexts cannot query agents. (2) Agents are equipped, like contexts in MCSs, with bridge rules for knowledge interchange. Their application is however, differently from MCSs, not automatic but rather determined via special trigger rules, which allow a bridge rule to be invoked upon certain conditions and/or according to a certain timing. (3) The result of a bridge rule is interpreted as an agent-generated internal event, which is captured by reactive rules which may determine modifications to the agent’s ABox according to suitable reasoning techniques for the analysis and the incorporation of the newly acquired knowledge. In this paper we intend to further extend the approach so as to make it more re- alistic in terms of data management. In DACMACS we have assumed that contexts, though heterogeneous in nature, accept relational-like queries, and in particular data- log queries1 (that correspond to the select-project-join fragment of SQL) with negation. Here, we first of all assume that all agents and contexts in a DACMACS are equipped with their local TBox. For agents, it can be considered to be an addition to the global TBox. We still consider contexts as “black-boxes”, though we assume them to be able to access their associated TBox. In this way, contexts can be able to cope with the case where a querying agent is not able to specify in ontological terms the features of the data it intends to obtain (for instance, a University office may ask the tax office for the names of low-income students who should be given some practical and/or financial help, without however being aware of the precise regulations according to which a stu- dent can be considered to be “low-income”). A context will now be enabled to retrieve such ontological definitions in its own TBox. Also, the requesting agent can be made aware of ontological assumptions the results are based upon (in the example, the reg- ulations for obtaining advantages). In extended DACMACS therefore, agents are more “demanding” w.r.t. external sources. Extended DACMACS agents are then able to safely incorporate ontological defini- tions provided by external sources int their own TBox, so as to accordingly incorporate acquired data into their ABox. The paper is organized as follows: in Sections 2 we provide the necessary back- ground notions about mMCSs, DACMASs and DACMACSs. In Section 3 we present and illustrate, also by means of examples, the extended approach. We also discuss whether properties of mMCSs and DACMACSs extend to the new formalization. Fi- nally, in Section 4 we conclude. 2 Background 2.1 mMCS (Managed) Multi-Context systems [15, 18] aim at making it possible to build systems that need to access multiple possibly heterogeneous data sources, called “contexts”, de- spite the variety of formalisms and languages these data sources can be based upon. The device for modeling the necessary information flow among contexts is constituted by “bridge rules”, which are similar to datalog rules with negation (cf., e.g., [17]). Bridge rules allow for inter-context communication: in fact, each element in their “body” ex- plicitly includes the indication of the context from which information is to be obtained. Reporting from [15], a logic L is a triple (KBL ; CnL ; ACCL ), where KBL is the set of admissible knowledge bases of L, which are sets of KB-elements (“formulas”); CnL is the set of acceptable sets of consequences (in [15] they are called “belief sets”, but we prefer to abstract away from “mentalist” concepts), whose elements are data items or ”facts”; ACCL : KBL → 2CnL is a function which defines the semantics 1 c.f., e.g., [17] for a survey about datalog and the references therein for more information. of L by assigning each knowledge-base an “acceptable” set of consequences. A multi- context system (MCS) M = (C1 , . . . , Cn ) is a heterogeneous collection of contexts Ci = (Li ; kbi ; bri ) where Li is a logic, kbi ∈ KBLi is a knowledge base and bri is a set of bridge rules. Each such rule is of the following form, where the left-hand side s is called the head, also denoted as hd(ρ), the right-hand side is called the body, also denoted as body(ρ), and the comma stand for conjunction. s ← (c1 : p1 ), . . . , (cj : pj ), not (cj+1 : pj+1 ), . . . , not (cm : pm ). For each bridge rule included in a context Ci , it is required that kbi ∪ s belongs to KBLi and, for every k ≤ m, ck is a context included in M , and each pk belongs to some set in KBLk . The meaning is that s is added to the consequences of kbi whenever each pr , r ≤ j, belongs to the consequences of context cr , while instead each ps , j < s ≤ m, does not belong to the consequences of context cs . If M = (C1 , . . . , Cn ) is an MCS, a data state (“belief state” in the terminology of [15]) is a tuple S = (S1 , . . . , Sn ) such that each Si is an element of Cni . Desirable data states are those where each Si is acceptable according to ACCi . A bridge rule ρ is applicable in a data state iff for all 1 ≤ i ≤ j : pi ∈ Si and for all j + 1 ≤ k ≤ m : pk 6∈ Sk . Let app(S) be the set of bridge rules which are applicable in a data state S. We will now introduce managed MCS (mMCS) though in a simplified form with respect to [15] (in particular, our formulation is in between those of [15] and [18]). While in standard MCSs the head s of a bridge rule is simply added to the “destina- tion” context’s data state kb, in managed MCS kb is subjected to an elaboration w.r.t. s according to a specific operator op and to its intended semantics: rather than simple addition, op can determine, e.g. deletion of other formulas upon addition of s, or any kind of elaboration and revision of kb w.r.t. s. Formula s itself can be elaborated by op, for instance with the aim of making it compatible with kb’s format. For a logic L, FL = {s ∈ kb | kb ∈ KBL } is the set of formulas occurring in its knowledge bases. A management base is a set of operation names (briefly, operations) OP , defining elaborations that can be performed on formulas, e.g., addition of, revision with, etc. For a logic L and a management base OP , the set of operational statements that can be built from OP and FL is FLOP = {o(s) | o ∈ OP, s ∈ FL }. The semantics of such statements is given by a management function, which maps a set of operational statements and a knowledge base into a modified knowledge base. In particular, a man- agement function over a logic L and a management base OP is a function OP mng : 2FL × KB L → 2KBL \ ∅ Bridge rules for context Ci have the same format as in standard MCSs, except that the head now belongs to FLOP , and is then of the form o(s). Semantics of (simplified) mMCS are in terms of equilibria. A data state S = (S1 , . . . , Sn ) is an equilibrium for an MCS M = (C1 , . . . , Cn ) iff, for 1 ≤ i ≤ n, there exists kb0i = mngi (app(S), kbi) such that Si ∈ ACCi (kb0i ). Thus, an equilibrium is a global data state composed of acceptable data sets, one for each context, considering however inter-context communication determined by bridge rules and the elaboration resulting from the operational statements and the management function. Equilibria may not exist, or may contain inconsistent data sets (local inconsistency, w.r.t. local consistency). A management function is called local consistency (lc-) pre- serving iff, for every given management base, kb0 is consistent. It can be proved that a mMCS where all management functions are lc-preserving is locally consistent. Global consistency would require the Si ’s to be consistent with each other, but this stronger property is not required in this context. Intuitively, a data state is an equilibrium whenever the application of a bridge rule according to the destination context’s strategy for incorporating new knowledge pro- duces a result which is compatible with the context’s semantics for its data sets. Notice that bridge rules are intended to be applied whenever they are applicable. 2.2 DR-Lite in a Nutshell We assume as known the basic notions about Description Logic and ontologies [2]. In particular we consider here DLR-Lite [2, 19], of which however we provide only the very basic elements, as far as they are needed in what follows. In general terms, in this logic (1) A TBox is a finite set of assertions specifying: concepts and relations; inclusion and disjunction among concepts/relations; key assertions for relations. (2) An ABox is a finite set of assertions concerning concept and relation membership. In essence, a TBox describes the structure of the data/knowledge, and the ABox specifies the actual data/knowledge instance. (3) In DLR-Lite, data can be queried via UCQs (Union of Conjunctive Queries) and ECQs (Existential Conjunctive Queries): the latter are FOL (First-Order Logic) queries involving negation, conjunction and the existential quantifier, whose atoms are UCQs. In DLR-Lite, concepts C and relations R are built from atomic concepts N and atomic relations P (of arity ≥ 2) where: a concept is either an atomic concept or a unary relation or a conjunction between concepts; a relation is either an atomic relation or any projection of an n-ary relation. Formally, the semantics of DL-Lite is defined in terms of first-order interpretations consisting of a nonempty interpretation domain and an interpretation function which maps concept conjunction over the intersection of their interpretations, and treats rela- tions in the obvious way. A DLR-Lite TBox is a finite set of assertions of the form: E1 v E2 (concept/relation inclusion) E1 v ¬E2 (concept/relation disjointness) (key i1 , . . . ik : R) (key assertion) where each of the ij s is between 1 and the arity n of R: in fact, the key assertion indicates which of the arguments of R compose its primary key. In the following, we use â to denote an ordered set of elements, typically for relation arguments when the arity is irrelevent, thus writing, e.g., R(x̂). To ensure decidability of inference and good computational properties, no relation can appear both in a key assertion and in the right hand side of a relation inclusion assertion. A DLR-Lite ABox is a finite set of assertions of the form: N (a1) (concept membership assertion) P (a1 , . . . , an ) (relation membership assertion) where P has arity n, and a1 , . . . , an denote constants. The semantics is provided by stating when an interpretation I satisfies assertions, which is done in the obvious way. An Ontology O is a couple hT , Ai where T is a TBox, encoding intensional knowl- edge, and A is an ABox, encoding extensional knowledge about individuals objects. Query answers, as usual in ontologies, are formed by constants denoting individuals explicitly mentioned in the ABox. The certain answer to an UCQ q the set substitutions θ of the free variables of q with constants in A such that qθ evaluates to true in every model of O. The certain answer to an ECQ defined by combining the certain answers of the composing UCQs through first-order constructs, and interpreting existential vari- ables as ranging over the constants in A. DLR-Lite enjoys desirable computational properties w.r.t. query evaluation, which is tractable in both time and data complexity (please refer to the above references for discussion). 2.3 DACMASs and DACMACSs The definition of a DACMACS (Data-Aware Commitment-based Multi-Agent-Context Systems) [5] extends that of DACMAS as the set of participating agents is augmented with a set of contexts, which are to be understood as data sources which can be consulted by agents. Both approaches are based upon DLR-Lite ontologies. In both DACMASs and DACMACSs a MAS is equipped with a global TBOX, while each agent owns its local ABox, that must be consistent with the global TBox. As agents composing a DACMAS are autonomous entities, mutual consistency of the ABoxes is not required. Bridge rules similar to those of MCSs can be defined also in DACMACS agents. Agents are moreover equipped with local management functions, which can perform any elab- oration for acquiring data and for keeping each agent’s local ABox consistent. In the following, let a logic, a management base and management functions be as specified in Section 2.1. Formally, we have (where T , E, X , I, C and B are borrowed from the DACMAS definition): Definition 1. A DACMACS (Data-Aware Commitment-based managed Multi- Context MAS) is a tuple hT , E, X , Y, I, C, Bi where: (i) T is a global DLR-Lite TBox, which is common to all agents participating in the system; (ii) E is a set of predicates denot- ing events (where the predicate name is the event type, and the arity determines the content/payload of the event); (iii) X is a finite set of agent specifications; (iv) Y is a finite set of context names; (vv) I is a specification for the institutional agent; (vi) C is a contractual specification; (vii) and B is a Commitment Box (CBox). The global TBox lists, as in DACMASs, the names of all participating agents in connection to their specifications, but now it also lists the description of all available external contexts, for which (differently from agents) no specification is available within the system. An additional list of contexts locally known to an agent may be included in the agent’s ABox. Each context has a name and a role, indicating to agents the kind of information that can be obtained from such context. For simplicity, we assume that roles are specified as constants, that context names include all the information needed for actually posing queries, and that all contexts accept datalog queries. The last assumption is without loss of generality, as most realistic query languages admit a well-defined correspondence with datalog. An agent’s specification includes a (possibly empty set of): communicative rules, which proactively determine events to be sent to other agents; update rules, which are internal reactive rules that update the local ABox upon sending/receiving an event to/from another agent. the other participants. A communicative rule has the form Q(r, x̂) enables EV (x̂) to r where: Q is an ECQ query, or precisely an ECQl with location argument @Ag to specify the agent Ag to which the query is directed (if omitted, then the the agent queries its own ABox); x̂ is a set of tuples representing the results of the query; EV (x̂) is an event supported by the system, i.e., predicate EV belongs to E; r is a variable, denoting an agent’s name. Whenever the rule is proactively applied, if the query evaluates to true (i.e., if the query succeeds) then EV (x̂) and r are instantiated via one among the answers returned by the query, according to the agent’s own choice. For instance, an agent may find the name r of the provider of a service (if several names are returned, only one is chosen) and then send to this provider a subscription request (instantiated with the necessary information x̂) in order to be able to access the service. Update rules are ECA-like rules2 of the following form, where α is an action, the other elements are as before, and each rule is to be applied whenever an event is either sent or received, as specified in the rule itself: on EV (x̂) to r if Q(r, x̂) then α(r, x̂) (on-send/on-receive) Update rules may imply the insertion in the agent’s ABox of new data items not previ- ously present in the system, taken from a countably infinite domain ∆. Each context may include bridge rules, of the form specified in section 2.1, where however the body refers to contexts only, i.e., contexts cannot query agents. In the DACMACS approach, also agents may be equipped with bridge rules, for extracting data from the contexts listed in the global TBox (while data exchange among agents occurs via explicit communication as defined in DACMASs). Bridge rules in agents are of the form: A(x̂) determinedby E1 , . . . , Ek , not Gk+1 , . . . , not Gr where A(x̂), called the conclusion of the rule, is an atom over tuple of arguments x̂. The right-hand-side is called the body of the rule, and is a conjunction of queries on external contexts. Precisely, each of the Ei s and each of the Gi s (where k > 0 and 2 ’ECA’ rules stands for ’Event-Condition-Action’ rules, and specify reaction to events. Such rules are present in some form in all agent-oriented programming languages and frameworks. r ≥ 0) can be either of the form DQi (x̂i ) : ci or of the form DQi (x̂i ) : qi where: DQi is a datalog query over tuple of arguments x̂i ; ci is a context listed in the local ABox with is role, and thus locally known to the agent; qi = Role@inst(rolei ) is a context name obtained by means of a standard query Role@inst to the institutional agent inst (notation ’@’ is borrowed from standard DACMASs), performed by providing the context role rolei . We assume that all variables occurring in A(x̂) and in each of the Gi s also occur in the Ei s. The comma stands (here and below) for conjunction. Assuming (without loss of generality) that all the x̂i s have the same arity, when the rule is triggered (see below) then the Ei s may produce a set of tuples, some of which are discarded by the Gi s. Finally, A(x̂) is obtained as a suitable projection. Within an agent, different bridge rules have distinct conclusions. The management operations and function are defined separately (see below). E.g., Role@inst(student office) would return the name of the context corre- sponding to the student office. An agent-to-context datalog query is of the form Q :- A1 , . . . , An , not B1 , not Bm with n + m > 0 where the left-hand-side Q can stand in place of the right-hand-side (so, by abuse of notation ’ :- ’ stands for ’≡’). Each the Ai s is either an atom or a binary expression involving connectives such as equality, inequality, comparison, applied to variables occurring in atoms and to constants. Each atom has a (possibly empty) tuple of arguments and can be either ground, i.e., all argu- ments are constants, or non-ground, i.e, arguments include both constants and variables, to be instantiated to constants in the query results. All variables which occur either in Q or in the Bi s also occur in the Ai s. Intuitively, the conjunction of the Ai s selects a set of tuples and the Bi s rule some of them out. Q is essentially a placeholder for the whole query, but also projects over the wished-for elements of the resulting tuples. While bridge rules occurring in contexts are meant to be automatically applied whenever the present data state entails the rule body, bridge rules in agents are meant to be proactively activated by the agent itself. To this aim, we have introduced suitable variants of DACMAS’s communicative and update rules. In our context, a trigger rule has the form Q(x̂) enables A(ŷ) where: Q is an ECQl query, and x̂ a set of tuples representing the results of the query; A(ŷ) is the conclusion of exactly one of the agent’s bridge rules. If the query evaluates to true, then A(ŷ) is (partially) instantiated via one among the answers returned by the query, according to the agent’s own choice, and the corresponding bridge rule is triggered. Since agents’ bridge rules are executed neither automatically nor simultaneously, the definition of management function must be revised. First, notice that for each agent included in a DACMACS the underlying logic (KBL ; CnL ; ACCL ) is such that: KBL is composed of the global TBox plus the local ABox; ACCL is determined by the DRL-Lite semantics, according to which elements of CnL are computed. If an agent is equipped with n bridge rules, there will be n operators in the agent’s management base, one for each bridge rule, i.e., OP = {op1 , . . . , opn }. Each of them which will at least make the acquired knowledge compatible with the global TBox (possibly by means of global ontologies and/or by means of the techniques discussed in [20] and/or via forms of meta-reasoning, cf., e.g., [21] for an overview). FLOP is defined as in Section 2.1, but instead of a single management function there will now be n management functions mng b1 , . . . , mng bn , again one per each bridge rule. They can however be factorized within a single agent’s management function with signature (as in MCSs), for agent a, OP mng a : 2FL × KB L → 2KBL \ ∅ which specializes into the mng i s according to the bridge-rule head. Whenever a bridge rule is triggered, its result is interpreted as an agent’s gener- ated event and is reacted to via a special ECA rule: this functioning is similar to inter- nal events in the DALI agent-oriented programming language [22, 11]. In particular, A bridge-update rule has the form on A(x̂) then β(x̂) where: A(x̂) is the conclusion of exactly one bridge rule, and x̂ a set of tuples representing the results of the application of the bridge rule; β(x̂) specifies the operator, management function and actions to be applied to x̂, which may imply querying the ABoxes of the agent and of the institutional agent, so as to re-elaborate the agent’s ABox. We now need for DACMACS agents an enhanced agent specification (augmented w.r.t. the DACMAS one, which included only the agent’s name and communication and update rules, where also the agent’s ABox was left implicit). In particular, the en- hanced agent specification is a tuple ha, Aa , mng a , Πi, where a is the agent specifi- cation name, Aa is the agent’s ABox, mng a is the agent’s management function and Π is the set of rules characterizing the agent. In particular, Π = Πcu ∪ Πbtu ∪ Πaux , where Πcu is the set of communicative and update rules, Πbtu is the set of bridge, trig- ger and bridge-update rules, and Πaux the set of the necessary auxiliary rules. Notice that, though not explicitly mentioned, auxiliary rules where implicitly present also in the definition of DACMASs, unless one considered all necessary auxiliary definitions as built-ins. The definition of data state and of equilibria must also be extended. In partic- ular, if M is a DACMACS where (C1 , . . . , Cj ) are the composing contexts and (Aj+1 , . . . , An ) the composing agents, j ≥ 0, n > 0, a data state of M is a tuple S = (S1 , . . . , Sn ) such that each Si is an element of Cni . If S = (S1 , . . . , Sn ) is a data state for a DACMACS M , a bridge rule ρ occurring in each composing context or agent is potentially applicable in S iff S entails its body. For contexts, entailment is the same as in MCSs. For agents, entailment implies that all queries in the positive part of the rule body succeed w.r.t. S, and no query in the negative part of the rule body succeeds w.r.t. S. A bridge rule is applicable in a context whenever it is potentially applicable. A bridge rule with head A(ŷ) is applicable in an agent Aj whenever it is potentially applicable and there exists a trigger rule of the form Q(x̂) enables A(ŷ) in the specifi- cation of Aj such that Cnj |= Q(x̂). Let app(S) be the set of bridge rules which are applicable in data state S. Desirable data states are those where each Si is acceptable according to ACCi . A data state for a DACMACS M is an equilibrium iff, for 1 ≤ i ≤ n, there exists kb0i = mngi (app(S), kbi) such that Si ∈ ACCi (kb0i ). In [5] we have extended some of the formal results which hold for mMCS and for DACMAS to the new setting. In fact, assuming that all management functions (both those related to agents and those related to contexts) are local consistency (lc- )preserving, then we can prove that a DACMACS M is locally consistent, i.e., that the addition of the new data does not introduce inconsistencies in the agents’ ABoxes w.r.t. the global TBox. Lc-preserving management functions are those which perform “care- ful” updates according to [20]. The execution semantics of a DACMACS can be defined by extending the transition system defined for DACMAS. 3 Extensions In this paper we propose extensions to the DACMACS approach so as to make data ex- traction from contexts more general and flexible. We remain for the sake of simplicity in the hypothesis of datalog queries (with negation) as defined above, which correspond to the select-join-project-setminus fragment of SQL. Notice that all variables in a data- log query are implicitly existentially quantified. Such queries correspond to DRL-Lite existential conjunctive queries (ECQs) in the simple form where a conjunct is simply an atom rather than a disjunction (cf. [23] and the references therein). Moreover, they allow for tractable ontological query-answering. In order to allow for ontological queries, we have to assume contexts to be equipped with their private TBox. We may also assume that both agents and contexts are able to access some kind of global ontology to achieve interoperability (think, e.g., simply of a dictionary) but we will not go into detail on this aspect. In an extended DACMACS also agents will have their own private TBox. However, we assume that each agent’s TBox is to be intended as the union of the global and the local TBox, and that such union is consistent. As seen below, the local TBox can be updated in consequence of data acquisition from contexts via bridge rules. We also assume that the global TBox in a DACMACS constitutes, in the terminology of [24], a protected fragment, in the sense that no update made to the agents’ local TBox fragments is enabled to affect the global TBox. As a motivating example, consider a University that intends to establish which students are eligible for a job on campus. The conditions are that the student’s fam- ily income must be low, and the student’s grades must be good or excellent. In a DACMACS representing the University, the agent student office secretary may con- sult the contexts student office for grades and tax office for family income. In this case, in DACMACS one would define a bridge rule, providing (in datalog) the ontological definition of desired results: eligible(stud) determinedby low income(stud ) : tax office, not nonexcellent(stud ) : student office low income(stud ) :- student(stud ), (1) family income less than threshold (stud , inc, inc threshold ). nonexcellent(stud ) :- student(stud ), (2) grade less than threshold (stud , grad , grade threshold ). The assumption which is implicit in this bridge rule is that contexts are equipped with an engine which is able to parse and execute datalog queries, and that the terminol- ogy used in the query fits with the one used in contexts. Otherwise, as mentioned one might assume that contexts might try to parse queries based upon global ontologies and meta-ontologies (in case of failure in doing so, the query would consequently fail). The other assumption is that the secretary is aware of the criteria for defining an income as low and a student as excellent. Let us assume instead that the secretary is not aware of such criteria. A first exten- sion consists in the possibility for the querying agent of omitting query definitions, in the example (1) and (2), thus delegating to the contexts the task of finding, in their own TBox, ontological definitions suitable for answering a query (in case of failure in doing so, the query would consequently fail). A second extension allows the querying agent, in the example the secretary, to acquire from contexts not only query answers, but also the ontological definition on which they are based. In this case, the above bridge rule would be reformulated as: eligible(stud) determinedby low income(stud ) : tax office : D1 , not nonexcellent(stud ) : student office : D2 where D1 and D2 are variables, to be instantiated respectively to (1) and (2) by the tax office and student office contexts. Then, the definition of a bridge rule can be reformu- lated as follows. Definition 2. In an Extended DACMACS , a bridge rule occurring in an agent’s speci- fication has the following form. A(x̂) determinedby E1 , . . . , Ek , not Gk+1 , . . . , not Gr A(x̂), called the conclusion of the rule, is an atom over tuple of arguments x̂. The right-hand-side is called the body of the rule, and is a conjunction of queries on ex- ternal contexts. Precisely, each of the Ei s and each of the Gi s (where k > 0 and r ≥ 0) can be either of the form DQi (x̂i ) : ci or of the form DQi (x̂i ) : qi , or of the form DN Qi (x̂i ) : ci : D where: DQi is a datalog query over tuple of argu- ments x̂i ; ci is a context listed in the local ABox with is role, and thus locally known to the agent; qi = Role@inst(rolei ) is a context name obtained by means of a stan- dard query Role@inst to the institutional agent inst (notation ’@’ is borrowed from standard DACMASs), performed by providing the context role rolei ; DN Qi (x̂i ) is a datalog atom representing a query, for which no definition is provided; D is a variable, to be instantiated by ci to the definition of DN Qi (x̂i ). The contents to which D gets instantiated are coped with by means of a suitable operator and management function. We assume that all variables occurring in A(x̂) and in each of the Gi s also occur in the Ei s. The comma stands for conjunction. Within an agent, different bridge rules have distinct conclusions. The management operations and function are defined separately (see previous section and Definition 4 below). The operator management function relative to the update of the agent’s local TBox via the acquired ontological contents is unique, i.e., it is the same for every bridge rule and for every context which is queried. We extend the definition of DACMACS agent so as to introduce the local TBox together with the possibility of updating it, in con- sequence of the application of enhanced bridge rules. We assume to provide a unique TBox operator and management function to be applied whenever a TBox update is performed. Definition 3. An agent specification is a tuple ha, Ta , Aa , op T , mng a , mng T , Πi, where: a is the agent specification name; Ta is the agent’s local TBox; Aa is the agent’s ABox; mng a is the agent’s management function; op T and mng T are the local TBox update operator and management function (seen in Definition 4 below); Π is the set of rules characterizing the agent. In particular, Π = Πcu ∪ Πbtu ∪ Πaux , where Πcu is the set of communicative and update rules, Πbtu is the set of bridge, trigger and bridge-update rules, and Πaux the set of the necessary auxiliary rules. Definition 4. The local TBox management function has signature mng T : op T × T B → 2T B \ ∅ where T B is the set of all possible TBoxes, so Ta ∈ T B. We require op T and thus mng T to respect the principles stated in [24] for TBox update: (i) Satisfiability Preservation Updates should preserve satisfiability of basic concepts and roles. (ii) Protection Updates should preserve the protected fragment of the TBox. A naive strategy for achieving such principles and also for preserving consistency of the ABox w.r.t. the TBox can be the following. Definition 5. Let DN Qi (x̂i ) : ci : D be a query to context ci occurring in an agent a’s bridge rule. Let DN Qi (x̂i ) = R(x̂). Take as given the agent’s global and local TBox. The TBox management function mng aT associated to the agent a can specify for the update operator op T a behavior that generates the updated agent’s local TBox as follows. 1. Create a new concept or relation in the local TBox (depending upon the arity of R), named Rci . That is, the query result is “indexed” via the name of the context providing its definition. 2. for each atom A(ŷ) occurring in the conjunction of atoms to which D has been instantiated create a new concept or relation in the local TBox (depending upon the arity of A), named Aci . 3. If Rci is an atomic concept and atomic concept R already exists either in the global or in the local TBox, then create the assertion Aci v A. If Aci is an atomic concept and atomic concept A already exists either in the global or in the local TBox, then create the assertion Aci v A. 4. Analyze the variable occurrences in DN Qi (x̂) and D and their concatena- tions so as to generate inclusiveness and disjointess assertions for the new con- cepts/relations. 5. Use the query results to generate new ABox assertions, that are by definition con- sistent with existing ones. The definition of data state and of bridge rule applicability is the same as in DACMACS . The definition of equilibrium has now to encompass TBox management. Definition 6. A data state for an Extended DACMACS M is an equilibrium iff, for 1 ≤ i ≤ n, there exists kb0i = mng T ◦ mngi (app(S), kbi) such that Si ∈ ACCi (kb0i ). It is easy to see that: Proposition 1. The TBox management function mng aT for generic agent a specified as stated in Definition 5 fulfills the update principles (i)-(ii). It follows that: Proposition 2. Given mng aT as specified as stated in Definition 5 and lc-preserving management function mnga , then the overall agent a’s management function mng aT ◦ mnga is lc-preserving. Therefore, local consistency of an extended DACMACS can be guaranteed by suit- able TBox update management. In fact, analogously to mMCS also for DACMACSs it holds that: Proposition 3. Let M be an extended DACMACS such that all management functions associated to the composing agents and contexts are lc-preserving. Then M is locally consistent. The execution semantics of an extended DACMACS can be defined by extending the transition system defined for DACMAS in [1]. Nice results are provided in [1] for DACMASs about verification using a variant of µ-calculus, which is a powerful temporal logic used for model checking of finite-state transition systems, able to express both linear-time temporal logics such as LTL and branching-time temporal logics such as CTL and analogous (for the formal definition of this variant, the reader may refer to [25] and to the references therein). These results rely upon state boundedness, in the sense that for each agent in a DACMAS ther exists a bound on the number of data items simultaneously stored in its ABOX. These results can be extended to DACMACS assuming state-boundedness (with the same bound) for both agents’ ABoxes and contexts’ data instances. For extended DACMACS , we have also to assume that all the agents’ and contexts’ local TBoxes can be consistently merged into the single global TBox. The problem here is twofold: (i) It must be assumed that contexts’ TBoxes (as well as ABoxes, actually) are publicly available. (ii) It must be assumed that a satisfactory merge of the TBoxes is indeed possible, where for satisfactory we mean without loss of information with respect to the sources. These assumption can be realistic in specific settings, but are not in the general case. Therefore, extended DACMACS are more flexible and more suitable for real- world agent-data-context integration application. However, the added flexibility makes verification a much more problematic issue. 4 Concluding Remarks In this paper we have extended DACMACS which are in turn a generalization of DAC- MAS, which is a formalization of ontology-based and commitment-based multi-agent systems. Our extension allows a system to include not only agents but also external contexts, which can return to agents not only query answers, but also the ontological definitions they are based upon. The objective is that of modeling real-world situations where agents and contexts actually constitute the analogous of a kind of data integra- tion system. In this vision, both single agents and the overall system is able to evolve by incorporating new data/knowledge, and new ontological information. Similarly to what argued for DACMAS and DACMACS , instances of Extended DACMACS are readily implementable via standard publicly available technologies. We are not aware of similar proposals in rule-based approaches. Future directions include a full implementation and realistic experiments. This work stems from a prac- tical experimentation in personalized home healthcare (that for lack of space we could not report here), where we had to cope with the gap existing between the ontological de- scription of each patient’s health history and individuality, and the standard ontological descriptions which can be supposed to be available in medical knowledge sources. References 1. Montali, M., Calvanese, D., De Giacomo, G.: Verification of data-aware commitment-based multiagent system. In: Proc. of AAMAS 2014. (2014) 157–164 2. Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F.: The descript. log. handbook: Theory, implementation, and applications. Cambridge Univ. Press (2003) 3. Singh, M.P.: Towards a formal theory of communication for multi-agent systems. In My- lopoulos, J., Reiter, R., eds.: Proc. of the 12th Intl. Joint Conf. on Artificial Intelligence, Morgan Kaufmann (1991) 69–74 4. Singh, M.P.: Commitments in multiagent systems: Some history, some confusions, some controversies, some prospects. In Paglieri, F., Tummolini, L., Falcone, R., Miceli, M., eds.: The Goals of Cognition. Essays in Honor of Cristiano Castelfranchi, College Publications, London (2012) 601–626 5. Costantini, S.: Knowledge acquisition via non-monotonic reasoning in distributed heteroge- neous environments. In Calimeri, F., Ianni, G., Truszczynski, M., eds.: Logic Programming and Nonmonotonic Reasoning, 13th International Conference, LPNMR 2015, Proceedings. Lecture Notes in Computer Science, Springer (2015) 6. Bordini, R.H., Hübner, J.F.: BDI agent programming in agentspeak using Jason (tutorial paper). In Toni, F., Torroni, P., eds.: Computational Logic in Multi-Agent Systems, 6th International Workshop, CLIMA VI, Revised Selected and Invited Papers. Volume 3900 of Lecture Notes in Computer Science., Springer (2006) 143–164 7. Hindriks, K.V., van der Hoek, W., Meyer, J.C.: GOAL agents instantiate intention logic. In Artikis, A., Craven, R., Cicekli, N.K., Sadighi, B., Stathis, K., eds.: Logic Programs, Norms and Action - Essays in Honor of Marek J. Sergot on the Occasion of His 60th Birthday. Volume 7360 of Lecture Notes in Computer Science., Springer (2012) 196–219 8. Dastani, M., van Riemsdijk, M.B., Meyer, J.C.: Programming multi-agent systems in 3apl. In Bordini, R.H., Dastani, M., Dix, J., Fallah-Seghrouchni, A.E., eds.: Multi-Agent Program- ming: Languages, Platforms and Applications. Volume 15 of Multiagent Systems, Artificial Societies, and Simulated Organizations. Springer (2005) 39–67 9. Fisher, M.: MetateM: The story so far. In Bordini, R.H., Dastani, M., Dix, J., Fallah- Seghrouchni, A.E., eds.: PROMAS. Volume 3862 of Lecture Notes in Computer Science., Springer (2005) 3–22 10. Bracciali, A., Demetriou, N., Endriss, U., Kakas, A., Lu, W., Mancarella, P., Sadri, F., Stathis, K., Terreni, G., Toni, F.: The KGP model of agency: Computational model and prototype implementation. In: Global Computing: IST/FET Intl. Workshop, Revised Selected Papers. LNAI 3267. Springer-Verlag, Berlin (2005) 340–367 11. Costantini, S., Tocchio, A.: The DALI logic programming agent-oriented language. In: Logics in Artificial Intelligence, Proc. of the 9th European Conf., Jelia 2004. LNAI 3229, Springer-Verlag, Berlin (2004) 12. Costantini, S.: The DALI agent-oriented logic programming language: References (2012) at URL http://www.di.univaq.it/stefcost/info.htm. 13. Bordini, R.H., Braubach, L., Dastani, M., Fallah-Seghrouchni, A.E., Gómez-Sanz, J.J., Leite, J., O’Hare, G.M.P., Pokahr, A., Ricci, A.: A survey of programming languages and platforms for multi-agent systems. Informatica (Slovenia) 30(1) (2006) 33–44 14. Brewka, G., Eiter, T.: Equilibria in heterogeneous nonmonotonic multi-context systems. In: Proc. of the 22nd AAAI Conf. on Art. Int., AAAI Press (2007) 385–390 15. Brewka, G., Eiter, T., Fink, M.: Nonmonotonic multi-context systems: A flexible approach for integrating heterogeneous knowledge sources. In: Logic Programming, Knowledge Rep- resentation, and Nonmonotonic Reasoning - Essays Dedicated to Michael Gelfond on the Oc- casion of His 65th Birthday. Volume 6565 of Lecture Notes in Computer Science., Springer (2011) 233–258 16. Omicini, A., Ricci, A., Viroli, M.: Artifacts in the a&a meta-model for multi-agent systems. Autonomous Agents and Multi-Agent Systems 17(3) (2008) 432–456 17. Apt, K.R., Bol, R.: Logic programming and negation: A survey. The Journal of Logic Programming 19-20 (1994) 9–71 18. Brewka, G., Eiter, T., Fink, M., Weinzierl, A.: Managed multi-context systems. In: IJCAI 2011, Proc. of the 22nd Intl. Joint Conf. on Art. Int., IJCAI/AAAI (2011) 786–791 19. Artale, A., Calvanese, D., Kontchakov, R., Zakharyaschev, M.: The DL-lite family and rela- tions. CoRR abs/1401.3487 (2014) 20. Calvanese, D., Kharlamov, E., Nutt, W., Zheleznyakov, D.: Updating ABoxes in DL-lite. In: Proc. of the 4th Alberto Mendelzon Intl. Workshop on Foundations of Data Management. Volume 619 of CEUR Workshop Proceedings., CEUR-WS.org (2010) 21. Barklund, J., Dell’Acqua, P., Costantini, S., Lanzarone, G.A.: Reflection principles in com- putational logic. J. of Logic and Computation 10(6) (2000) 743–786 22. Costantini, S., Tocchio, A.: A logic programming language for multi-agent systems. In: Logics in Artificial Intelligence, Proc. of the 8th Europ. Conf.,JELIA 2002. LNAI 2424, Springer-Verlag, Berlin (2002) 23. Heymans, S., Eiter, T., Xiao, G.: Tractable reasoning with DL-programs over datalog- rewritable description logics. In: ECAI 2010 - 19th European Conf. on Artificial Intelligence, Lisbon, Portugal, August 16-20, 2010, Proc. (2010) 35–40 24. Zheleznyakov, D., Calvanese, D., Kharlamov, E., Nutt, W.: Updating TBoxes in DL-lite. In Haarslev, V., Toman, D., Weddell, G.E., eds.: Proc. of the 23rd Intl. Workshop on Description Logics (DL 2010. Volume 573 of CEUR Workshop Proceedings., CEUR-WS.org (2010) 25. Calvanese, D., De Giacomo, G., Montali, M., Patrizi, F.: Verification and synthesis in de- scription logic based dynamic systems (abridged version). In Faber, W., Lembo, D., eds.: Web Reasoning and Rule Systems - 7th Intl. Conf., RR 2013. Volume 7994 of Lecture Notes in Computer Science., Springer (2013)