1 Introduction

While discussions about the balance between risks and benefits of artificial intelligence (AI) take a significant space in public interest, industry seems to have finally joined (and, maybe, surpassed) academia in valuing AI as one of the pillars of the next industrial revolution. Public institutions have followed, too: for instance, the European Commission already invested 1.5 billion euros in AI for 2018–2020, and many more are planned beyond 2020.Footnote 1 Furthermore, the “American Artificial Intelligence Initiative: Year One Annual Report”, delivered on February 2020 [334], witnesses the record amounts of AI research and development investment, and the same trend is observed in China.Footnote 2

When industry, politics, and society focus on new technologies, the promise of a future astonishing progress is no longer enough, since industry leaders, decision makers, and tax payers call for immediate and visible benefits. That is why, following the recent success of deep learning, and the reviving popularity of many other AI techniques, in the next decade academia is going to devote non-negligible research efforts to intelligent systems, and in particular to intelligent system engineering.

Given the current status of AI technologies—mostly successful in well-delimited application scenarios—, a key issue for intelligent system engineering is integration of the diverse AI techniques: in software engineering terms, not just how to integrate diverse technologies, but also (perhaps mainly) how to preserve conceptual integrity when highly-heterogeneous approaches—bringing about manifold abstractions of various nature—are put to work together.

The most straightforward and generally-acknowledged way to address the above issue is by using agents and multi-agent systems (MAS). In fact, this is the way in which AI has been taught worldwide in the last decades, based on the most used AI textbook [305]: there, the agent abstraction is adopted as the conceptual architecture to frame the many different AI techniques, and MAS abstractions provide sound foundation for the design of intelligent systems. Also, the long-term research activity in fields like agent-oriented computing (AOC)—about MAS programming languages and technologies—and agent-oriented software engineering (AOSE)—about MAS methods, tools, and methodologies—actually makes agents and MAS the most suitable candidates to work as the sources for well-founded technologies and methodologies for intelligent system engineering.

Nowadays, a clear dichotomy is emerging from within the AI area. Whereas the overwhelming success of sub-symbolic techniques like deep learning has basically wiped out most objections against AI, public concern about the forthcoming role of intelligent systems in human society has raised new issues, such as the need of explaining the behaviour of intelligent agents, and make it understandable for humans—particularly when AI plays a critical role within human organisations. The fact is, the overall approach to XAI (eXplainable Artificial Intelligence [28] would seemingly require the extensive adoption of symbolic techniques (possibly integrated with sub-symbolic and non-symbolic ones) in order to reach its main goals—such as observability, interpretability, explainability, and accountability. As a result, exactly when the general focus of AI is on sub-symbolic techniques—as those that have made AI work in real-world applications—, symbolic approaches are beginning to be carefully scrutinised—as those that could make AI also amenable to human understanding.

Among them, logic-based techniques are not just the oldest ones, but possibly represent the most straightforward path towards human understanding: if for no other reason, for the fact that logic—as the study of correct reasoning—targets first of all human cognitive processes. Also, logic-based approaches are since long time at the core of many successful agent-based models and technologies. Generally speaking, cognitive agents in intelligent MAS straightforwardly exploit logic-based models and technologies for rational process, knowledge representation, expressive communication, and effective coordination. Overall, MAS and logic-based technologies have already crossed their paths in the last decades, and can be expected to do so more and more in the years to come.

Altogether, this is why this paper focuses on logic-based approaches in MAS: as they are to be counted among the most promising techniques for building understandable and explainable intelligent systems. More precisely, given the unavoidable push towards the engineering of intelligent systems, here we explicitly target logic-based technologies: we mean to understand and represent the current status of the available logic-based technologies in the MAS field that are actually usable in the engineering of intelligent systems.

Of course, we acknowledge that other papers in the past have already (and often brilliantly) surveyed MAS technologies as well as logic-based approaches within MAS. What motivates a new study on the subject, however, it is not just the renewed interest and public investment on AI, or, our focus on technologies. Instead, to the best of our knowledge, no systematic review has been performed on the subject to date. And, the requirement of verifiability and reproducibility of scientific literature can be satisfied by SLR (systematic literature review) only—particularly nowadays, when AI research is more and more subject to the public scrutiny, precisely for the overwhelming interest it has raised. Then, the goal of this paper is to provide an exhaustive and organised view of the available logic-based technologies for MAS, by performing a carefully-designed and implemented SLR on the subject.

Accordingly, the paper is organised as follows. Section 2 introduces the method used for the SLR, discussing the technical details from the fundamental research questions down to the technical operations actually leading to the material discussed in the paper. Section 3 presents and organises the technologies devised out according to a MAS-based perspective, and provides a brief description for each one. Section 4 collects and displays information from the sources and the selected technologies in form of tables and word clouds. Section 5 provides for an overall view on logic-based technologies for MAS, offering some interpretation criteria on their current state of the art and perspectives. Lastly, Sect.  6 concludes the paper with some final remarks.

2 Method

2.1 Premises

Making a review systematic requires first of all that the main concepts are defined clearly enough not just to make its scope precise, but mostly to make the review itself reproducible—to some extent. This does not mean of course that notions like agents and multi-agent systems are to be re-defined here ex novo, or, with more detail than is typically used in the literature: but, at least, it means that the acceptations of terms used in the remainder of this paper have to be well-founded and understandable.

So, when including/excluding MAS technologies in/from our survey, we refer to the well-known definition of agents by Wooldridge and Jennings [356], or, to a basically-equivalent definition of agents and MAS [280]: agents are computational abstractions encapsulating control along with a criterion to drive control (a task, a goal), whereas MAS are collections of agents interacting (communicating, coordinating, competing, cooperating) in a computational system. Even less problematic is to define what is logic: dating back to Aristotle—whose logic is the instrument for human knowledge [301]—logic studies the way we draw conclusions and express ourselves, and deals with how to formalise it [256]. Since several sorts of logic exists and are adopted in general in the broad context of computational logic, in the following we stick to those logics clearly identifiable in the literature, in terms of name, formal definition, and reference paper(s).

Yet, the main issue here does not concern either MAS or logic. Instead, it comes from our basic choice to focus on logic-based technologies for MAS, and from its motivation as well. In fact, a key point is for agent-based technologies to actually work in the engineering of intelligent systems: correspondingly, in the remainder of this survey we choose to include only logic-based MAS technologies that are both scientifically identifiable and technically available. This means, first of all, that there must exist (at least) a scientific publication that clearly defines and describes the technology (and so, covering both its agent- and logic-based aspects); then, that the technology itself should be clearly mentioned in the reference publication, as well as technically accessible (e.g., from a web site or a public repository) at the time of the survey.

More precisely, in this paper we consider as logic-based MAS technology any agent-oriented software architecture, framework, or language that (i) involves some clearly-defined logic model, and (ii) comes with some actual technological reification. Indeed, we argue that technological aspects are far from being marginal, as technology is “the application of scientific knowledge for practical purposes”,Footnote 3 and now more than ever the engineering of intelligent systems is in dire need of dependable technologies. Clearly enough, technologies may involve logics at several different levels and in disparate ways, in the same way as they may address diverse abstractions of MAS. Within the scope of our work, in particular, we are mostly interested in technologies exposing logic and agent-orientation at the application level—i.e., making logic explicit to their intended users. Consider for instance Jason [42], a well-known MAS specimen of technology inspired by the Belief-Desire-Intention (BDI) architecture [295,296,297]—and hence by the BDI logic—, written in Java. There, BDI logic pervades Jason design, implementation, and API, and is clearly exposed to Jason users. Similarly, Golog [228]—a Prolog-based technology for MAS programming—would have been considered to be a logic-based technology even if it were written in Java, as logic is required by users to build MAS through Golog.

Accordingly, in the remainder of this survey we choose to include only those logic-based technologies for MAS that (i) can be associated with a sound scientific contribution describing some clearly-identifiable software system, framework, or toolkit; (ii) are in the form of executable software, which can be actually reached, downloaded, and tested on some modern execution platform—so that they may actually be used and work in real-world intelligent systems, at least in principle; (iii) can be found via URLs or references from their primary works, or, straightforwardly via web search on the authors’ information—otherwise, any link between the model from the primary work and the technology would be debatable, and possibly arbitrary; (iv) the URL does not belong to some web archive service only—which would clearly witness the fact that the technology is in some state of abandon.

2.2 Research questions

Every SLR [56, 263] is built around some fundamental research question. According to Higgins and Green [176], “A systematic review attempts to identify, appraise and synthesise all the empirical evidence that meets pre-specified eligibility criteria to answer a given research question. Researchers conducting systematic reviews use explicit methods aimed at minimising bias, in order to produce more reliable findings that can be used to inform decision making.”

Our primary research question essentially expresses our main research goal here. In fact, we are interested in understanding

\(\textsf {(G)}\):

What is the role played by logic-based technologies in MAS nowadays?

In order to make it possible to conduct a SLR based on this (quite general and possibly generic) question, it is necessary to re-articulate the research goal in terms of more detailed (secondary) research questions:

\({\textsf {(Q1)}}\):

Which logic-based technologies for MAS are actually available?

\({\textsf {(Q2)}}\):

Which aspects of MAS technologies are affected by logic-based technologies, and to what extent?

\({\textsf {(Q3)}}\):

Which MAS abstractions/issues/features are covered by logic-based technologies?

\({\textsf {(Q4)}}\):

Which sorts of logics are actually exploited to frame logic-based MAS technologies?

\({\textsf {(Q5)}}\):

Which logic-based technologies for MAS are effectively used in real-world domains?

The above questions drive the process of search, by articulating the way in which papers and technologies are looked for, examined, and possibly selected for the review.

2.3 Sources

The electronic sources used in the search process are of two sorts: (i) general bibliographic databases and (ii) specific sources—such as conferences, symposia, and workshops—on the core topics. The former are searched intensively via specific queries, whereas the latter are explored extensively, year by year, volume by volume, paper by paper. This is because small, specialised workshops are often missing from the major bibliographic databases used for our query-based intensive search; instead, one can typically count on the complete indexing of major conferences and international journals. Accordingly, the extensive scrutiny of all the papers published in the specialised workshops on topics near to MAS and logic is mostly intended to complement the intensive search performed throughout the bibliographic engines, so as to result in the most exhaustive search possible overall.

In particular, in the following we extensively consider all the papers published in

  • the International Workshop on Declarative Agent Languages and Technologies (DALT)—10 events (2003–2012)

  • the International Workshop on Engineering Multi-Agent Systems (EMAS)—7 events (2013–2019), including DALT since 2013

  • the International Workshop on Computational Logic in Multi-Agent Systems (CLIMA)—15 events (2000–2014)

  • the Workshop on Logics for Intelligent Agents and Multi-agent Systems (WLIAMAS @ IAT)—3 events (2008–2010)

  • the Workshop on Logical Aspects of Multi-Agent Systems (LAMAS)—8 events (2002, 2010–2015, 2017)

and check them for the required content and references. The aforementioned sources have to be searched extensively given that their coverage by the most common sources for scientific literature is often incomplete at best.

In detail, the sources used for intensive search (via keyword-based queries) are the following:

  1. (i)

    Google Scholar—http://scholar.google.com

  2. (ii)

    IEEE Xplore—http://ieeexplore.ieee.org

  3. (iii)


  4. (iv)


  5. (v)


  6. (vi)

    ACM Digital Library—http://dl.acm.org.

Each of these sources is queried with the following combinations of keywords:

\({\textsf {(KW1)}}\):

multi agent system logic technology

\({\textsf {(KW2)}}\):

multi agent system logic implementation

\({\textsf {(KW3)}}\):

multi agent system logic industry

\({\textsf {(KW4)}}\):

multi agent system logic verification

\({\textsf {(KW5)}}\):

multi agent system logic agent programming

\({\textsf {(KW6)}}\):

multi agent system logic agent reasoning

\({\textsf {(KW7)}}\):

multi agent system logic society

\({\textsf {(KW8)}}\):

multi agent system logic environment

and the first hundred results returned are considered as potential candidates: the occurrence of a logic-based approach for MAS is first checked for each paper, then, in case it is found, the existence of a technology is looked for and possibly verified.

2.4 Papers classification

Papers resulting from the above search activity are classified according to three main classes:

  • primary papers—i.e., those papers introducing and describing a technology of interest

  • auxiliary papers—i.e., those papers mentioning a technology of interest—meaning that the mentioned technology has been employed in some way in the development of the contribution of the paper

  • secondary papers—i.e., those papers surveying technologies of interest.

Given their obvious relevance to a systematic survey, secondary papers are not only used as the direct source for technologies of interest; instead, their extensive and organised bibliographic references is recursively searched for new possible items of interest. In particular, we extensively search references from the following secondary works: [23, 44, 147, 245, 246, 248, 277, 307, 357].

It is worth pointing out that the aforementioned secondary works are similar in purpose to this work, yet they are not systematic literature reviews. This work, in turn, has a wider scope, an updated background, and it is based on a structured and reproducible method. Furthermore, in this paper, we provide a technological assessment of each technology with an unprecedented level of detail. In particular, Baldoni et al. [23] provides a historical overview of the relationship between declarative languages and multi-agent systems, with no ambition of completeness, and no interest in the analysis of technologies. Conversely, this paper aims at understanding and representing the current state of the available logic-based technologies for MAS: so, our SLR focuses on those technologies that are actually usable in the engineering of intelligent systems.

3 Technology synopsis: the MAS perspective

Agents are not alone in MAS. They interact with other agents, and with the surrounding environment as well: a shared view exists in the literature that agent, society, and environment can be taken as the three basic categories to interpret and model the structure and dynamics of non-trivial MAS. This view, proposed by Omicini [273] and backed up—either implicitly or explicitly—by other MAS models—e.g., [286, 350]—, infrastructures—e.g., [298, 344]—, and methodologies—e.g., [91, 104, 166]—drives the organisation of this section. Indeed, the works that meet the selection criteria discussed in Sect. 2, are presented according to the following schema:

  • Agent

    • Programming, reasoning & planning

    • Agent reliability & verification

  • Society

    • Organisational reasoning & coordination

    • Argumentation

    • Reliability & verification of MAS

  • Environment

    • Agents in the Semantic Web (distributed cognition)

    • Situated interaction & coordination

Technologies belonging to each sub-category are presented in chronological order and accompanied by a short description, including primary references, URL referencing the projects home pages, and other related papers, if any. In particular, each technology is described from two different yet complementary perspectives: the MAS and the logical ones. On the one side, the MAS perspective aims at providing an answer to research questions (Q2) and (Q3). On the other side, the logical perspective aims at answering to research question (Q4). Furthermore, each technology description also includes a brief technical assessment aimed at addressing research questions (Q1), and (Q5).

Many technologies are based on, or integrate, more than one logic-based approach. In those situations, we classify a technology according to the “most distinguishing” approach—i.e., the approach for which the technology is mainly known and referenced for in the literature. For instance, let us consider again Jason as an example. To support agent programmers in modelling agent beliefs and deductive reasoning mechanisms, Jason includes a full-fledged Prolog interpreter. Prolog interpreters are considered the main software tool within the scope of logic programming. However, Jason is rarely described as a technology based on logic programming (LP) [234], despite being technically able to handle logic programs. Indeed, the BDI paradigm is far more characterising for Jason than LP: hence, we categorise Jason as a BDI logic technology.

3.1 Agent

From the MAS perspective, most technologies falling under the “Agent” category, are logic-based agent programming languages. Whereas almost all these languages allow for the specification and implementation of societal aspects—via communication actions—and interaction with the environment—via perception and external actions—, their focus is on the description of individual agents, which motivates the inclusion in this section. These technologies are listed in the “Programming, reasoning, and planning” sub-category, and include languages for agents characterised by beliefs (and, depending on the language, other mentalistic notions such as desires, goals, plans, commitments)—such as ASTRA, AGENT-0, AgentSpeak(L) and its Jason implementation, DyLOG, AFAPL, GOAL, JACK, Jadex, eXAT, Rodin, JADL, 3APL and 2APL, TeleoR and Golog-like languages; languages where deliberation is the most characterising feature—such as SHOP, AgentSpeak(ER); languages that extend logic programming with communication, concurrent execution and/or time management—such as CaseLP/DCaseLP, Concurrent MetateM, DALI, Go!, Mozart/Oz. We also include in this sub-category RASP, because of its attention to modelling agent knowledge and reasoning, jDALMAS, which extends the reasoning mechanism with deontic abstractions, and DRAGO, which bases agent knowledge and reasoning on ontologies.

Finally, it is widely acknowledged that many areas of application of MAS clearly require dependable computational systems—and, in particular, that such systems should be verifiable. The last sub-category under the agent perspective is hence devoted to technologies for the (automatic or semi-automatic, static or dynamic) verification of agent-based systems. In the “Agent reliability & verification” sub-category we discuss only one technology, MCAPL, which is more oriented (although not exclusively oriented) towards model checking of individual agents. More technologies are presented in the societal extension of this category.

From the logic perspective, the technologies in the “Agent” category largely emphasise the impact of logic programming on agents specification. In fact, most of them either extend or rely on LP to describe agents behaviours, beliefs, or semantics. This is unsurprising, as the connection between agents and LP has been well understood in the literature since the dawn of the agent-oriented programming research. From the seminal works by Kowalski [212], Dell’Acqua et al. [116], Kowalski and Sadri [213], Bozzano et al. [49] up to the recent work by Calegari et al. [61], logic programming is considered by many scientists as quite a natural choice for specifying, implementing, and verifying rational agents. Among the dozens of surveyed works exploiting LP and its variants, only some of them respect the strict acceptation of (available) technology adopted here.

3.1.1 Programming, reasoning, and planning

AGENT-0 (1991)

figure a

MAS perspective AGENT-0 is a framework for programming MAS. Programming an agent in AGENT-0 amounts at defining its commitment rules which are decisions to perform an action, not to pursue a goal. The conditions under which a commitment can be made are expressed in terms of mental conditions—involving what the agent believes to be true and which commitments it believes to hold—, and message conditions—namely logical combinations of message patterns (From, Type, Content). There, Type may be one among some predefined performatives, as INFORM, OFFER, REQUEST. Agents communicate through message passing and an agent capability is a relation between that agent mental state and its environment. Complex mental categories like desires, goals, intentions and plans are not supported by the language.

Logical perspective AGENT-0 is based on a particular, ad-hoc, modal logic. Modal logic [70, 134] is a suitable and powerful formalism to describe agents as intentional systems, as observed by Wooldridge and Jennings [356] in the early 90s. More precisely, AGENT-0 is an interpreted language based on a propositional temporal logic developed by Thomas et al. [336]. It is a simple point-based temporal language, with facts associated with points in time and possibly nested time-stamped beliefs. The logical language has modal operators representing knowledge, belief, desire, commitment, and ability. According to Wooldridge et al. [357], it represents the foundation for the AGENT-0 semantics: however, it is worth noting that AGENT-0 temporal operators lack a formal logic-based semantics. Given that AGENT-0 has no formal semantics, it is not surprising that also the temporal component of the language is presented in an intuitive, informal way.

figure b

Concurrent MetateM (1993)

figure c

MAS perspective MetateM is a concrete framework for programming MAS through modal and temporal logics. Concurrent MetateM is the multi-agent extension of MetateM: it combines the features supported by MetateM with a model of concurrent computation, providing an approach to the modelling of complex reactive systems. A Concurrent MetateM system contains a number of concurrently executing agents which communicate through message passing.

Logical perspective MetateM interpreter implements an “on the basis of the past, do the future” behaviour based upon the methodology of temporal logic as an executable imperative language presented by Moszkowski [259]. The rules which drive the agent behaviour are temporal logic formulae of the form: “antecedent about the past, consequent about the future”. The methodology finds its root in the work presented by Gabbay [155], stating that any temporal logic formula can be rewritten in terms of one or more \(Antecedent \rightarrow Consequent\) rules. These rules make up the agent specifications and dictate the agent behaviours and, consequently, the MAS dynamics.

figure d

AgentSpeak(L) (1996) & Jason (2006)

figure e

MAS perspective Jason is an interpreter for an extended version of AgentSpeak(L), a logic-based agent-oriented programming language introduced by Rao [294] and based on the Beliefs-Desires-Intentions (BDI) architecture and logic presented by Rao and Georgeff [295,296,297]. Through Jason, developers can model and implement autonomous agents in a goal-oriented way, by writing the plans an agent may choose to adopt when reacting to the many events steering the dynamics of a MAS. All that Jason agents can do occurs due to events, including perception, belief-base update, and message-passing, as well as goal instantiation or satisfaction. The extended AgentSpeak(L) language exploited by Jason essentially provides a practical means of manipulating agent knowledge and activities through a Prolog-like syntax.

Logical perspective The Jason technology is based on the BDI logic. Furthermore, the Jason interpreter comes with an internal, Prolog-like, logic programming engine implemented in Java—supporting annotated logic terms, among the other features. The Jason operational semantics has been defined by Vieira et al. [343]. Based on the BDI logics, Jason expects agents to be defined in terms of beliefs—i.e., the knowledge an agent has about the world—, desires—i.e., the states of the world an agent is willing to pursue or maintain—, and intentions—i.e., the actions in which an agent means to be involved in a given moment. Notice that the Jason technology is aimed neither at formally inspecting MAS nor at automatically deriving MAS properties. Conversely, BDI logic is exploited as an effective programming language for AOP.

figure f

Golog (1997), ConGolog (2000) & IndiGolog (2009)

figure g

MAS perspective In Golog-like programming languages, the agent dynamic world can be modelled by exploiting an explicit representation of the initial state of the system, and the effect of actions on that world. The representation is characterised by axioms provided by users. Golog-like languages allow the developer to program autonomous agents that perceive their environment and plan while operate. ConGolog provides support for concurrent programming, while IndiGolog specialises in providing agents with the ability to sense their environment and plan accordingly.

Logical perspective Both Golog and its successors extend or are implemented in Prolog (SWI-Prolog,Footnote 4 ECLiPSE-PrologFootnote 5). The formalism adopted by these languages is rooted in the Situation Calculus. They consist of Prolog-based meta-interpreters that support a custom action language defined by overriding or defining Prolog operators.

figure h

SHOP (1999)

figure i

MAS perspective SHOP (Simple Hierarchical Ordered Planner) and its variants—SHOP2 by Nau et al. [267] and JSHOP2 by Ilghami [197]—are domain-independent automated-planning systems based on ordered task decomposition, which is a type of Hierarchical Task Network (HTN) planning—see Erol et al. [135] for details. SHOP is based on an action language with a Lisp-like syntax. In particular, SHOP complies with the PDDL specification [253], which is a standardisation effort for planning languages. Since it is based on PDDL, SHOP allows developers to express the “physics” of a domain: making it possible to declare domain predicates and available actions, together with their structure and effects.

As an ordered task decomposition planner, SHOP produces plans where tasks appear in the same order in which they should be executed (total-ordering requirement in SHOP, partial-ordering requirement in SHOP2). This limits the degree of uncertainty about the world, thus reducing the complexity of the reasoning. In addition to the usual HTN methods and operators, SHOP and its extensions can define axioms, mix symbolic/numeric conditions, and call external functions.

Although SHOP is not described as an agent-related technology, it has been employed in some agent-oriented works, referenced above in “Other references”.

Logical perspective Being PDDL-compliant, SHOP is based on predicate logic. As with most AI planners, a logical atom in SHOP consists of a predicate name followed by a list of arguments, and a state of the world consists of a collection of ground logical atoms. As with most HTN planners, a task in SHOP consists of a task name followed by a list of arguments. Although tasks are similar syntactically to logical atoms, they are different semantically since they denote activities that need to be performed rather than logical conditions. However, SHOP implements an inference mechanism based on Horn clauses [190], with support to negation as failure. A transition from a state to another one is accomplished by an instance of an operator whose precondition is a logical consequence of the current state. The knowledge base contains domain-specific knowledge that SHOP may exploit to improve planning in that domain. It consists of axioms, methods, and operators.Footnote 6

figure j

CaseLP (1999), DyLOG (2004) & DCaseLP (2007)

figure k

MAS perspective CaseLP (Complex Application Specification Environment Based on Logic Programming) is a LP-based prototyping environment for MAS, used to develop prototypes in collaboration with the Italian Railways and the Elsag company (now Leonardo s.p.a.) in 1999, for planning goods transportation. DCaseLP [247] is its distributed version (from which the “D” comes from), based on JADE [34], tuProlog [122] and Jess [177]. DyLOG [18]—later renamed “DYnamics in LOGic”Footnote 7—is a high-level LP language for modelling rational agents, based on a modal theory of actions and mental attitudes, where modalities are used for representing actions, while beliefs model the agent internal state. DCaseLP and DyLOG were exploited together to support the design of agent interaction protocols in a methodologically-correct way [19].

Logical perspective CaseLP, DCaseLP, and DyLOG extend, or are implemented in, Prolog. At the technological level, DCaseLP consists of three Java archives, which allow agents specified in declarative languages—including tuProlog and Jess—to be integrated and run in the same JADE environment.

DyLOG is implemented in SICStus Prolog.Footnote 8

figure l

Mozart/Oz (1999)

figure m

MAS perspective The Mozart Programming System is an advanced development platform for intelligent, distributed applications. It implements Oz 3, the latest language of the Oz family [175] of multi-paradigm high-level languages based on the concurrent constraint model. Oz supports declarative programming, object oriented programming, constraint programming, and concurrency. Based upon Oz, Mozart supports multi-paradigm development.

Even though Mozart is not explicitly described as an agent-related technology, it has been exploited by some agent-oriented works, listed in the “Other references” field above.

Logical perspective The Oz programming language combines the logic and functional programming paradigms to support concurrent programming via logical constraint-based inference. The Mozart language and runtime explicitly target search problems through constraint propagation, similarly to what most constraint logic programming (CLP) [200] solvers do. In particular, such sorts of problems can be written in a very concise way in Mozart, letting its syntax and declarative semantics abstract away the details of search.

figure n

GOAL (2000)

figure o

MAS perspective GOAL (Goal-Oriented Agent Language) is an agent-oriented programming language inspired by the UNITY concurrent language [69]. Like UNITY, a set of actions which execute in parallel constitutes a program. However, unlike UNITY, which is based on variables assignment, GOAL incorporates complex notions such as belief, goal, and agent capabilities which operate on high-level information instead of simple values. GOAL agents make decisions based on their beliefs and goals. However, unlike other agent programming languages, GOAL focuses on providing a higher level of declarativeness to agents developers. GOAL agent goals describe what an agent wants to achieve, not how to achieve it—the desire is deliberated via automated reasoning. GOAL supports intra-agent communication, event processing (e.g., perceptions and messages), decision making, symbolic knowledge manipulation exploiting common knowledge representation technologies such as Prolog and OWL/SPARQL [210], in addition to reinforcement learning, and planning. It provides an IDE fully integrated into Eclipse making common editor features available.

Logical perspective GOAL is based on the BDI logic. However, similarly to other agent programming languages like Jason, GOAL mostly focuses on effective agent programming supported by a sound semantics, rather than exploiting BDI logic for MAS formal analysis. The syntax of the GOAL language is Prolog-inspired, therefore intrinsically logical. However, similarly to AgentSpeak(L), a number of constructs are allowed by the GOAL language, supporting goals, beliefs, rules, actions, and procedural knowledge.

figure p

JACK Intelligent Agents (2001)

figure q

MAS perspective JACK is a cross-platform environment developed by the AOS Group, an Australian research oriented company, with the goal of bringing intelligent agents into the industrial playground. It allows the developers to build, run, and integrate commercial-grade multi-agent systems, where agents are inspired by BDI architecture and logics.

A JACK MAS is implemented in an extended variant of Java. Extensions provide the means for manipulating agents plans, events, beliefs, interactions, in addition to ordinary Java computations. However, the most common way to implement a JACK agent goals and beliefs is to rely on object-oriented technology. In this sense, multiple programming paradigms and styles are fruitfully harmonised in JACK to create an industry-ready MAS technology.

Logical perspective JACK is inspired by BDI logics. Similarly to Jason and GOAL, however, the BDI architecture described by Rao [294] is used as a basis to design and implement the JACK computational model. Indeed, in order to facilitate the work of developers—in particular those with an AI background—JACK also supports logical variables and cursors. These can be used to perform complex queries to an agent belief base. Accordingly, the semantics of a JACK program has been described as “midway between the semantics of logic programming (with the addition of type checking in Java style) and embedded SQL” [192].

figure r

Agent Factory Agent Programming Language (AFAPL, 2002).

figure s

MAS perspective AFAPL is another BDI agent programming language, aimed at designing and developing intentional agents. Agent Factory is the tool implementing the AFAPL language. The tool supports the many aspects of MAS developments, including distribution—which is supported exploting the JADE platform. Among the peculiarities of AFAPL, the notion of commitment is the most notable. Agent behaviour is dictated by the goals agents commit to, therefore the developers plan the behaviour of the agents by declaring the conditions for the adoption of the commitments in an explicit way.

Logical perspective AFAPL has been deliberately designed to support “heterogeneous logic-based agent architectures with the goal of providing a common tool set that can be adapted to different agent models, ranging from custom Java agents, through to reactive agent architectures, and finally to high-level agent programming languages” [304]. However, for what concerns agents execution semantics, AFAPL leverages on the BDI architecture as well. In particular, its computational model is inspired to the AgentSpeak(L) one. AFAPL developers can exploit first-order logic expressions to represent both agent beliefs and behaviours.

figure t

DALI (2002)

figure u

MAS perspective DALI is an agent programming language based on the active logic programming language [94] designed to make logical specifications of agents executable. A DALI agent is composed by reactive rules to face the events that can occur in the environment, as well as proactive rules, aimed at allowing the agent to perform actions on its own initiative. The reactive and proactive behaviour of a DALI agent is triggered by external or internal events, which can refer to either the present or the past.

Logical perspective The DALI language is kept as close as possible to the syntax and semantics of the plain Horn-clause language. DALI inference engine is based on an extended form of resolution. The semantics of a DALI program is named “evolutionary semantics” and is defined in terms of a modified program where reactive and proactive rules are reinterpreted in terms of standard Horn Clause rules.

figure v

eXAT (2003)

figure w

MAS perspective The erlang eXperimental Agent Tool (eXAT) is another platform for agent programming, providing high-level abstractions and libraries to support both behavioural and intelligent aspects of an agent in a single platform. It is based on the ErlangFootnote 9 programming language, and provides programmers with a full-fledged framework supporting the design of agent reasoning, behaviours, interaction through a single, coherent technological tool. According to the authors, this is made possible by means of a set of modules strongly tied together. Roughly speaking, modules include: an Erlang-based expert system engine, an execution environment for agent behaviours based on object-oriented finite-state automata, and a module for supporting FIPA-ACL-compliant message passing.

Logical perspective eXAT is based on the Erlang language, which combines logical and functional paradigms, extending the syntax and the semantics of Prolog. Agent programs can be expressed via Erlang functions that can have multiple clauses (like Prolog). These features are used in eXAT to endow agents with automatic reasoning capabilities. For this purpose, eXAT includes an Erlang-based rule production system—namely, ERESYE—aimed at building agent-based expert systems. ERESYE enables the creation of multiple concurrent rule production engines, each with its own facts, composing the mental state of an agent. The platform can be also used to implement coordination among Erlang processes since each engine can behave as a Linda tuple space [160].

figure x

Go! (2004)

figure y

MAS perspective Go! is a multi-paradigm language with a declarative subset of function and relation definitions, an imperative subset that includes action procedure definitions and program structuring mechanisms. Go! is strongly typed and multi-threaded. Threads in a single Go! invocation can communicate either by thread-to-thread message communication or by synchronised access/update of shared data, as dynamic relations. Threads in different Go! invocations can only communicate by using messages.

Logical perspective Although Go! has many features in common with Prolog, some Prolog features that limit readability—like “cut”—are absent from Go!. Instead, it supports higher level programming constructs, like single solution calls, and if rules. Furthermore, functional relationships can be defined through functions. Agents’ threads can also use shared dynamic relations acting as Linda-style tuple spaces. The language is also suitable for representing ontologies exploiting its integration of logic, functional and imperative programming.

figure z

Event-B & the Rodin Platform (2004)

figure aa

MAS perspective Event-B is a formal method with tool support that enables a step-wise development of reactive distributed systems. It specifically addresses the situated nature of MAS. To ensure their correctness and structure their development, Event-B allows developers to rigorously specify complex agent interactions and verify their correctness and safety via formal reasoning. The Rodin tool is intended to support construction and verification of Event-B models.

Logical perspective Event-B is centred around the notion of events (transitions). It is based on first-order logic and a typed set-theory. The models described with Event-B are built by means of two basic constructs: contexts and machines. Contexts contain the static parts of a model whereas machines contain its dynamic parts. Rodin relies on the Event-B method which proposes to use the basic mathematical language (first-order logic, elementary set theory) for writing formal specifications. In particular Rodin exploits predicate logic to formalise and develop transition—intended as events—in MAS.

figure ab

DRAGO (2005)

figure ac

MAS perspective The DRAGO (Distributed Reasoning Architecture for a Galaxy of Ontologies) technology addresses the problem of reasoning with multiple ontologies interconnected by semantic mappings. The agent reasoning process results from a combination of semantic mappings of local reasoning chunks performed in a single OWL ontology [33].

Logical perspective DRAGO exploits description logic (DL) [15] and semantic tuple centres. The DRAGO technology is theoretically grounded on the formal framework of the distributed description logics [47], which extends standard DL with semantic mappings, which can be seen as a bridge rule between different ontologies. This enables the representation of multiple semantically connected ontologies in which the reasoning procedure—according to the distributed contextual reasoning paradigm—is based on distributed tableau techniques, an extension of standard DL tableau.

figure ad

Jadex (2005)

figure ae

MAS perspective Jadex is a software framework for the creation of goal oriented agents following the BDI model. Its main goal is to build up a rational agent layer that sits on top of the JADE infrastructure. Jadex enables the construction of intelligent agents leveraging on sound software engineering foundations. Wherever applicable, object-oriented concepts and technologies are exploited, supporting the description of beliefs, intentions, desires, and plans both in Java and XML. Moreover, the Jadex reasoning engine tries to overcome traditional limitations of BDI systems by introducing explicit goals.

Logical perspective Jadex reasoning engine is based on BDI logic, and combines it with state-of-the-art software engineering techniques involving XML and Java. The initial state of an agent is determined among other things by the beliefs, goals, and the library of known plans. Jadex uses a declarative and a procedural approach to define the components of an agent. Jadex does not enforce a logic-based representation of beliefs, even if it is a viable option. Moreover, ordinary Java objects of any kind can be contained in agent belief bases, allowing for instance developers to reuse classes generated by ontology modelling tools or database mapping layers.

A more declarative way of accessing beliefs and belief sets is provided by queries, which can be specified in an OQL-like language [66]. The beliefs are used as input for the reasoning engine by specifying certain belief states, e.g. as preconditions for plans or creation conditions for goals. The engine monitors the beliefs for relevant changes, and automatically adjusts goals and plans accordingly.

figure af

JADL & JIAC Framework (2006)

figure ag

MAS perspective JADL (JIAC Agent Description Language) is the core of an extensive agent framework called JIAC, and has originally been proposed by Sesseler [313]. JIAC [239] consists of a methodology supported by (i) a Java-based runtime environment, (ii) some tools for creating agents, and (iii) some extensions which range from web-service-connectivity to an OWL-to-JADL translator. A JIAC MAS consists of a number of platforms, each of which has its own directory facilitator and agent management system. Each platform hosts different agents which are specified via the JADL declarative language and consist of a set of ontologies, rules, plan elements, and initial goal states. AgentBeans are Java classes containing methods which can be called directly from within JADL, allowing agents to interact with the real world. JADL provides constructs to describe plans as well as ontologies, FIPA-based speech acts, a (procedural) scripting part for (complex) actions.

Logical perspective JIAC is a comprehensive agent framework including logic concepts like ontology language, trinary propositional calculus, first-order logic, situation calculus, reaction rules, and JADL as a logic-based agent programming language. JADL is based on three-valued predicate logic, thereby providing an open world semantics. It comprises four main elements: plan elements, rules, ontologies, and services. JADL makes it possible to use the concept of uncertainty using a situation calculation that features a three valued logic. The third truth value is added for predicates that cannot be evaluated, with the information available to a particular agent. Thus, a predicate can be explicitly evaluated as unknown. JADL makes it possible to define knowledge bases which most of the rest of the language is based on. Every object that the language refers to needs to be defined in an ontology. Differently from Jason, GOAL, 2APL, the planning mechanism supported by JADL is a first principle planning, with no pre-compiled plan library.

figure ah

2APL (2008) & 3APL (1999)

figure ai

MAS perspective The 3APL language provides programming constructs to implement individual agents directly in terms of beliefs, goals, plans, actions, and practical reasoning rules. Beliefs, plans, rules for revising plans and declarative goals are the basic building blocks of 3APL agents. Declarative goals describe the state an agent wants to reach and can be used to program pro-active behaviour. Plans form the procedural part of an agent and can be executed by the agent in order to achieve its goals. Rules enable the generation of plans on the basis of goals (and beliefs).

2APL (A Practical Agent Programming Language) is a BDI-based agent-oriented programming languages that extends 3APL by Hindriks et al. [182]. It integrates declarative beliefs and goals with events and plans, and provides practical programming constructs to enable the generation, repair, and execution of plans based on beliefs, goals, and events. The operational semantics is given via transitions between configurations. The configuration of an individual agent consists of its beliefs, goals, events, plans, and practical reasoning rules, while the configuration of a MAS consists of the configurations of the individual agents, the state of the external shared environments, and the agents’ access relation to environment. 2APL is equipped with an execution platform and an Eclipse plug-in editor. The platform provides a graphical interface where a user can load, execute, and debug 2APL multi-agent programs using different execution modes and several debugging/observation tools. The platform can be used in the stand-alone mode or in distributed mode using JADE. The adoption of JADE allows a multi-agent program to be run on different machines connected in a network.

Logical perspective 3APL is a multi-agent programming language that presents a mixture of logic programming and rule based systems. The main components of a 3APL agent can be expressed in a declarative way Belief and goal query expressions are either the atomic formulae or a well-formed formulae constructed from atoms and logical connectors.

Conversely, the BDI-oriented multi-agent programming language 2APL enables the implementation of an agent’s beliefs in terms of logical facts and rules. 2APL, as other logic-based agent programming languages, is based on a combination of imperative programming with logic-based knowledge bases. Goals in 2APL are logical formulae that the agents exploit in the execution of a plan, via logical entailment.

figure aj

jDALMAS (2009)

figure ak

MAS perspective jDALMAS is a general-level Prolog implementation of the abstract DALMAS—Deontic Action-Logic Multi-Agent System—architecture by Hjelmblom and Odelstad [185]. The jDALMAS technology enables the specification of agents’ possible actions in specific states. There, an action is permissible if it is not prohibited by the DALMAS normative system. In the deliberation phase, when an agent needs to choose the next action, DALMAS allows it to select an act out of a set of feasible acts. This may lead to a new state, depending on the state of the system when the act is performed. Thus, the choice of act is determined by the combination of the DALMAS preference structure and its deontic structure.

Logical perspective The technology represents the implementation of the DALMAS abstract architecture. The DALMAS architecture is regulated by a normative system consisting of norms, which are expressed in an algebraic notation based on the Kanger–Lindahl theory of normative positions [233]. The Kanger–Lindahl theory is based on Kanger’s deontic action-logic [205], as a mix of action logic in terms of action operator do and deontic logic in terms of shall or may.

figure al

RASP (2010)

figure am

MAS perspective RASP (Resourced Answer Set Programming) extends Answer Set Programming (ASP, by Lifschitz [231]) by supporting declarative reasoning on production and consumption of resources. Although RASP is not, strictly speaking, an agent-oriented paradigm, Costantini and Formisano [96] exploit it to extend (logic) agents reasoning capabilities in a resource-oriented scenario.

Logical perspective RASP combines answer set semantics with quantitative reasoning and with various forms of preferences and conditional preferences on resource usage. Raspberry [100] is a prototypical implementation of a translator from ground RASP to ASP: it leaves unchanged the ASP portion of the input program and translates RASP-rules (those involving atoms specifying amounts of resources) into suitable ASP fragments.

figure an

TeleoR (2015)

figure ao

MAS perspective TeleoR extends the Teleo-Reactive (TR) rule based robotic agent programming language by Nilsson [269]. In both TR and TeleoR programs consist of Guard–Action rules grouped into parametrised procedures. The Guard is a deductive query to a set of percept facts generated from sensors. Actions may be primitive robotic actions, single call to a program procedure, which can be a recursive call, or an update to the belief store. TeleoR also supports reactive task and sub-task behaviours of robotic agents, besides wait/repeat re-start of failed actions, and support for agents multi-tasking.

Logical perspective The TeleoR declarative programming language exploits logical rules for information representation. In particular, each TR node represents both percepts and beliefs through logical facts and rules. Furthermore, TeleoR is based on the Qu-Prolog systemFootnote 10 logic/functional programming language, which extends Prolog with a flexible type system supporting higher-order functional terms and functions. These are exploited in TeleoR for belief storage, inference, and deliberation.

figure ap

ASTRA (2015)

figure aq

MAS perspective Similarly to Jason, ASTRA allows developers to define agent plans in a declarative way; yet, unlike Jason, it offers a tighter integration with the Java language and runtime. Java objects and types can in fact directly be used within ASTRA scripts.

Logical perspective ASTRA exploits BDI logic. ASTRA is an implementation of the AgentSpeak(TR) language (not to be confused with AgentSpeak(ER) presented in the sequel), that is, a logic-based agent programming language combining AgentSpeak(L) with teleo-reactive functions designed and implemented by the ASTRA’s developers.

figure ar

AgentSpeak(ER) & Jason-ER (2019)

figure as

MAS perspective AgentSpeak(ER) is an extension of AgentSpeak(L) featuring plan encapsulation, i.e. the possibility to define plans that fully encapsulate the strategy to achieve the corresponding goals, integrating both the proactive and the reactive behaviour. AgentSpeak(ER) agents expose “g-plans” that can be repeatedly re-executed until a given goal-condition about the beliefs of some agent is met. AgentSpeak(ER) comes with two prototype implementations, one based on ASTRA by Collier et al. [88] and the other one based on Jason. Jason-ERFootnote 11 provides the syntactical and semantic extensions needed by Jason to support AgentSpeak(ER).

Logical perspective The logical perspective is similar to the Jason one with some enhancements. The Jason-ER extension turns out to bring some benefits to agent programming based on the BDI logic, namely: (i) improving the readability of the agent code, reducing fragmentation and increasing modularity; (ii) promoting a cleaner goal-oriented programming style by enforcing encapsulation of reactive plans within goal plans while still permitting purely reactive behaviour; (iii) improving intention management, enforcing a one-to-one relation between intentions and goals—so every intention is related to a single (top-level) goal.

figure at

3.1.2 Agent reliability & verification

MCAPL (2012), Gwendolen & AIL

figure au

MAS perspective Designed by Dennis et al. [120], the Model Checking Agent Programming Language (MCAPL) consists of tools for prototyping BDI agent programming languages and for model checking programs written in such languages via an interface to the Java Path Finder model checker (JPF, [170]). MCAPL consists of (i) the Agent Infrastructure Layer (AIL), which provides a common abstract base for the creation of concrete interpreters for BDI agent programming languages like Gwendolen by Dennis and Farwer [119], and (ii) Agent JPF (AJPF), an extended version of JPF, with a property specification language appropriate for model-checking any AIL-based MAS. An extension to AJPF to generate models also suitable for non-agent model-checkers was developed by Dennis et al. [121].

Although nothing prevents MCAPL from being used in a real MAS context, its most widespread usage is for model checking properties of individual BDI-style agents; for this reason, it is presented in this section rather than in Sect. 3.2.3.

Logical perspective The MCAPL interface allows a user to specify simple properties in a temporal and modal logic and then check that these properties hold using the JPF. Formulas in the MCAPL property specification language have an LTL (Linear Temporal Logic)-based [287] semantics defined by the MCAPL interface.

figure av

3.2 Society

Society plays a central role in MAS technologies, since it represents the ensemble where the collective behaviours of the MAS are coordinated towards the achievement of the overall system goals. Along this line, coordination models glue agents together by governing agent interaction in a MAS, and pave the way towards social intelligence. The selected technologies in the “Organisational reasoning & coordination” sub-category are ALIAS, 2CL, TuCSoN, ReSpecT, and AORTA.

Within an agent society, agents can enter into argumentation processes to reach agreements and dynamically adapt to changes. Dispute and conflict need to be managed in order to achieve a common agreement and to establish the winner argument in case of conflicts. Many technologies exist for solving reasoning tasks on the abstract argumentation frameworks by Dung [129]; problems of this kind are intractable and this calls for efficient algorithms and solvers: the International Competition on Computational Models of Argumentation (ICCMA), whose fourth edition will be run in 2021,Footnote 12 provides a forum for empirical comparison of solvers. Most solvers are based on logic-based programming or logical frameworks including ASP and SAT-solvers, as discussed by Gaggl et al. [156]. The literature on argumentation solvers overlaps to some extent that on agent- and logic-based technologies for argumentation: under the “Argumentation” sub-category, the SLR only includes those argumentation frameworks that are explicitly tagged as agent-based and that can be considered the founders of a given logical model: DeLP, Aspartix, ASPIC+, Dung-o-Matic, TOAST, and SPINdle.

Finally, MAS should be verifiable, also under the social perspective, i.e. in terms of verification of interaction and communication protocols. The “MAS reliability & verification” sub-category thus includes MCK, SALMA, SCIFF, MCMAS, and Trace Expressions.

3.2.1 Organisational reasoning & coordination

ALIAS (1999)

figure aw

MAS perspective The ALIAS architecture introduces abduction in a logic multi-agent environment. It implements a distributed protocol to coordinate the reasoning of all the abductive agents in the system. The global knowledge is represented by a set of abducted hypotheses stored on a Linda-like tuple space—that is, a mechanism to coordinate agent reasoning.

Logical perspective ALIAS is built on top of abductive logic programming [204]. In ALIAS, agents are equipped with hypothetical reasoning capabilities, obtained by means of abduction. The union of their knowledge bases ends up to generate a global knowledge base, which can change in a dynamic fashion, as a consequence of agent movements, and which is maintained coherent as it would be if it was owned by a single entity.

figure ax

TuCSoN (1999) & ReSpecT (2001)

figure ay

MAS perspective TuCSoN is a standard middleware technology based on Java, and on tuProlog [122] engine—that is, a first-order logic technology. Thanks to TuCSoN, both Java and Prolog agents—possibly distributed over the network—can interact via logic tuple centres. The tuple centre model by Omicini and Denti [275] is the core of the TuCSoN coordination infrastructure. Tuple centres are essentially Linda tuple spaces containing logic tuples, observable through logic templates. However, tuple centres are not mere containers of tuples. They can be programmed by agents through the ReSpecT language ReSpecT is in fact a logic-based coordination language aimed at providing for social intelligence in MAS.

TuCSoN supports multiple ReSpecT tuple centres, which can be spatially distributed and connected via linkability [278]. Accordingly, tuple centres can be locally deployed within a physically-distributed environment as discussed by Casadei and Omicini [64], with a possibly huge number of spatial containers and physical devices. Furthermore, tuple centres embody the laws for local coordination, ruling the social behaviour of the agents interacting through them.

It is worth to be mentioned that the current version of TuCSoN is the result of many years of active development by many different people pursuing different goals—as demonstrated by the multiple variants of TuCSoN and ReSpecT described in this section. Thus, as discussed in Ciatto et al. [79], the TuSoW project [78] can be considered a notable rebooting attempt for TuCSoN, focusing on supporting modern mainstream technologies and platforms.

Logical perspective TuCSoN coordination media are tuple centres based on Prolog. The logical feature of TuCSoN tuple centres makes it possible to spread intelligence through the system where needed, for example by exploiting cognitive agents. Coordination media in TuCSoN and ReSpecT (and, in particular, situated ReSpecT) are logic-based tuple centres powered by tuProlog. They can be adopted both for the communication language (logic tuples), and for the behaviour specification language (ReSpecT). Basically, reactions and resources in ReSpecT are defined as Prolog-like rules.

figure az

2CL (2010)

figure ba

MAS perspective 2CL is at the same time a methodology for the design of protocols and a toolkit enabling their engineering. Interactions among agents are represented in 2CL by exploiting commitment-based interaction protocols [148], which normally consist of sets of actions with a shared meaning. From the point of view of an agent, the meaning of an action is completed by the context in which it is used. In other words, the context shapes the behaviour of the agent in that the agent decides which actions to take depending on it.

Usually, commitment-based protocols take into account constitutive rules and not regulative ones. 2CL is indeed based on the notion of behaviour-oriented commitment protocols, which account both for the constitutive and the regulative specifications and that explicitly foresee a representation of the latter based on constraints among commitments. In particular, the language 2CL makes it possible to write these regulative specifications.

Logical perspective From the theoretical perspective, the 2CL tool is an extension of the enhanced commitment machine by Winikoff et al. [354], which allows all the possible executions of a business protocol to be explored, showing all the violations. Its implementation is done in tuProlog, and the software interprets a 2CL business protocol specification by means of a parser written in Java.

figure bb

AORTA (2014)

figure bc

MAS perspective AORTA (Adding Organisational Reasoning to Agents) provides organisational reasoning capabilities to agents implemented in existing agent programming languages—like, for instance, Jason. AORTA assumes a pre-existing organisation, is independent from the agent, and focuses on reasoning rules that specify how the agent reasons about the specification. The organisation is separated from the agent, meaning that the architecture of the agent is independent from the organisational model.

Logical perspective AORTA makes use of tuProlog, so the contents of the agent’s knowledge bases can be translated into Java objects supported by tuProlog. Logic programming and object oriented paradigms are exploited in a synergic integration. AORTA has been implemented on the top of Jason.

figure bd

3.2.2 Argumentation

DeLP (2004)

figure be

MAS perspective Defeasible Logic Programming (DeLP) combines results of logic programming and defeasible argumentation. In particular DeLP is based on the “pure” defeasible model introduced by Nute [272]. The ability to draw tentative conclusions and retract them based on further evidence—which characterises non-monotonic and defeasible logic—is also a relevant feature for agents which deal with uncertainty. DeLP provides the possibility of representing information in the form of weak rules in a declarative manner, and a defeasible argumentation inference mechanism for warranting the entailed conclusions. To solve conflicts, DeLP lets agents perform a dialectical process in which all arguments in favour and against a conclusion are considered, and arguments regarded as ultimately undefeated are considered warranted.

Logical perspective All the technologies for argumentation are based on deontic and defeasible logic. DeLP is based on logic programming: it can be considered as a logic-based approach to structured argumentation.

figure bf

Aspartix (2008)

figure bg

MAS perspective Aspartix is an agent argumentation framework that formalise statements together with a relation denoting rebuttals between them. Its semantics gives an abstract handle to solve the inherent conflicts between statements by selecting admissible subsets of them. Argumentation frameworks can support the decision making of an agent within a modular architecture for agents.

Logical perspective Aspartix is an ASP-based approach to find the justified arguments of an argumentation framework with respect to different acceptable extensions for a broad range of formalisations of Dung’s argumentation framework. It relies on a fixed disjunctive datalog [1] program which takes an instance of an argumentation framework as input, and uses an answer-set solver for computing the type of extension specified by the user.

figure bh

ASPIC+ & Dung-o-Matic (2008) & TOAST (2012)

figure bi

MAS perspective The ASPIC+ argumentation framework by Prakken [293] provides structure to agent arguments, while still allowing an abstract framework to be derived and, ultimately, evaluated using established acceptability semantics. The corresponding technology allow agents to resolve their conflicting arguments through a semantics of their choice, other than specifying priorities or assumption over the rules they leverage upon for reasoning.

Logical perspective ASPIC+ can be considered as the most common structured argumentation approach to Dung’s abstract argumentation. Dung-O-Matic is an engine implemented in Java that reflects the ASPIC+ framework. TOAST is a web service easing the exploitation of ASPIC+, based on Dung-O-Matic. It allows a structured argumentation system to be processed into arguments and attacks from which a Dung-style framework can be derived and evaluated.

figure bj

SPINdle (2009)

figure bk

MAS perspective SPINdle is an open-source Java-based defeasible logic reasoner capable to perform efficient and scalable reasoning on defeasible logic theories. These technologies tackle the way the Semantic Web affects knowledge and information interchange among intelligent agents in multi-agent systems, as well as reasoning interoperability. SPINdle can be used as a standalone theory prover and can be embedded into any applications as a defeasible logic rule engine. It allows agents to issues queries, on a given knowledge base or a theory generated on the fly by other applications, and automatically produces the conclusions of its consequences. The theory can also be represented using XML, for agent communication.

Logical perspective SPINdle is based on the “pure” defeasible model introduced by Nute [272]. Defeasible knowledge can be expressed and conflicts can be solved according to standard defeasible logic [271]. The theory can also be represented using RuleML,Footnote 13 an XML-based standard language that enables users to use different types of rules (such as derivation rules, facts, queries, integrity constraints) to represent different kinds of elements according to their needs.

figure bl

3.2.3 MAS reliability & verification

MCK (2004)

figure bm

MAS perspective MCK is a model checker for the logic of knowledge: it supports several different ways of defining knowledge given a description of a MAS and the observations made by the agents. It automates the MAS formal analysis focusing on how the states of information of agents change over time. MCK can automatically verify whether a specifications expressed in a formal logic of knowledge, probability and time holds in such a system.

Logical perspective MCK allows verification of temporal-epistemic logics using various Ordered Binary Decision Diagram (OBDD, [54]) and SAT based techniques [203]. The MCK input is a system design (represented as a program) and a question (encoded in a formal language that can express properties concerning time, probability and knowledge). MCK supports several different semantics for the agent epistemic state, depending on whether an agent determines what it knows from just its current observation, its current observation plus the current time, or its history of observations (interpreted either synchronously or asynchronously). The temporal dimension is supported by both linear and branching time temporal expressiveness.

figure bn

MCMAS (2006)

figure bo

MAS perspective MCMAS is a model checker for MAS specified through various agent-based logics. The symbolic representation of state spaces and the algorithms for the computation of epistemic operators encoding private and group knowledge and Alternating-time Temporal Logic (ATL, [8]) exploit Ordered Binary Decision Diagrams (OBDDs). Model checking of basic fairness conditions are supported, as well as the generation of counterexamples and witness executions. MCMAS can be used from a shell or via a graphical interface based on Eclipse.Footnote 14

Logical perspective MCMAS model checker includes temporal operators, too. MCMAS supports a rich set of specifications, including Computation Tree Logic (CTL, [85]) operators, epistemic operators, ATL, and notions pertaining to correct behaviour.

figure bp

SCIFF (2005)

figure bq

MAS perspective SCIFF is a model-checker mainly used to verify the compliance of agents to interaction protocols. SCIFF offers variables (e.g., to model time) and constraints on variables occurring in hypotheses and expectations; social goals, defined as predicates, can express the social aim or outcome of some agent interaction, or can be used to start an abductive derivation in the more classical tradition of abductive logic programming. The ability to generate positive and negative expectations, beside making hypotheses, and the concepts of fulfilment and violation of expectations are the core ingredients of dynamic checking of protocol compliance.

Logical perspective SCIFF is based on abductive logic programming. It is an abductive proof procedure mainly used to verify the compliance of agents to interaction protocols. In order to allow such application, SCIFF extends IFF by Fung and Kowalski [154].

figure br

SALMA (2014)

figure bs

MAS perspective SALMA (Simulation and Analysis of Logic-based Multi-Agent models) is a simulation and statistical model checking tool for MAS. The simulated system can be specified exploiting logical axioms based upon the Golog situation calculus. The framework for MAS modelling and verification makes it possible to reason about the interaction of agents with each other and with their (physical) environment.

Logical perspective SALMA extends the classical situation calculus and linear temporal logic so as to address the specific requirements of multi-agent simulation models, in order to simulate and (statistically) model-check them. The system model exploits a first-order logic structure, the simulation is coupled with a statistical model-checker that uses a first-order variant of time-bounded linear temporal logic for describing properties.

figure bt

Trace Expressions (2016)

figure bu

MAS perspective Trace Expressions, named Global Types in the original paper by Ancona et al. [9], are a compact and expressive formalism for modelling “expected behaviours of the system” based on a set of operators to denote finite and infinite traces of events. They have been used to model and verify, among the others, MAS, distributed systems, and data types. RML [149] is a rewriting-based and system agnostic Domain Specific Language for Runtime Verification which decouples monitoring from instrumentation by allowing users to write specifications and to synthesise monitors from them, independently of the system under scrutiny. RML compiles down to Trace Expressions.

Logical perspective The Trace Expressions runtime verification engine is developed in SWI-Prolog, and takes advantage of its native support for cyclic terms and coinductive logic programming by Simon et al. [320].

figure bv

3.3 Environment

When direct interaction and explicit communication do not fit the needs and constraints for agent interaction, mediated interaction and environment-based coordination may come into play. The difference between works on coordination and interaction classified under the “Society” perspective and works listed in this section, is that in the latter coordination/interaction artefacts are meant as runtime abstractions encapsulating and providing coordination/interaction services. Those services can be exploited as the basic building blocks for designing and developing suitable working environments for heterogeneous MAS, supporting MAS coordination for collaboration or competition.

When agents are immersed in a knowledge-intensive environment (KIE), the cognition process goes beyond that of the individual agent, and distributed cognition processes may take place, promoting the idea of intelligent environment [187]. Thus, the environment concept is extended, and it is not just limited to situated action—which motivates the classification of Semantic Web works in the environment abstraction.

Moving from Hendler [174], the “Agents in the Semantic Web” sub-category lists Onto2JaCaMo, AgentOWL, and EMERALD, which exploit semantic web technologies to interoperate. Another technology in the “Environment” category is situated ReSpecT, a technologies for “Situated Interaction & Coordination”. It emphasises the situated component of interaction, thus related to the environment. Inbetween the two categories lays LPaaS (Logic Programming as a Service), a framework that supports the distribution of logic knowledge in the environment, and where artefacts can actively participate in the agent cognitive process. In LPaaS, in fact, artefacts play a supporting role in terms of knowledge repositories (in the form of environment structure and properties) and embed the reasoning process enabled and constrained by the knowledge they embody.

3.3.1 Agents in the semantic web

AgentOWL (2006)

figure bw

MAS perspective AgentOWL supports RDF/OWL ontology models in JADE MAS. It uses JenaFootnote 15 for ontology model manipulation and allows to model the agent knowledge using OWL and to exchange messages with OWL and SPARQL as content language. Ontologies are modelled with ProtégéFootnote 16 following the CommonKADS knowledge and engineering methodology [310]; the MAS design is based on AUML [30] and MAScommonKADS [196].

Logical perspective Being the logic underlying the standard languages for the semantic web—OWL DL, OWL Lite, OWL Full, OWL 2—, description logic underlies, up to some extent, all those technologies used for “agents in the semantic web”. In AgentOWL, OWL is mainly used to represent the knowledge of an individual agent.

figure bx

EMERALD (2010)

figure by

MAS perspective EMERALD is a MAS framework built on top of JADE; it aims at supporting interoperable reasoning among agents in the Semantic Web, by using third-party trusted reasoning services. In EMERALD, every agent can exchange its position justification arguments with any other agent, with no need for all agents to conform to the same kind of rule paradigm or logic. EMERALD provides a knowledge-based agent module based on Jess by Jess by Hill [177].

Logical perspective EMERALD uses OWL as the language to model common knowledge that agents need to share in order to interoperate.

figure bz

Onto2JaCaMo, 2017

figure ca

MAS perspective Onto2JaCaMo supports MAS development in compliance with a well-defined AOSE methodology defined by the authors themselves in Freitas et al. [152]. The tool offers a combined support of forward and reverse engineering, such that changes in one artefact can always be merged into the other without compromising consistency or losing changes; this approach is referred to as “round-trip engineering”.

Logical perspective Onto2JaCaMo uses OWL as the language to model common knowledge that agents need to share in order to interoperate.

figure cb

3.3.2 Situated interaction & coordination

Situated ReSpecT (2008)

figure cc

MAS perspective The ReSpecT event model—which already accounts for situatedness issues by defining an event in terms of its source cause, event target and time at which the event occurred—has been extended in Situated ReSpecT introducing generic environmental resources as a new kind of sources / targets of events so as to account for situatedness and to coordinate a system for sensing and controlling environmental properties.

Logical perspective Situated ReSpecT extends the ReSpecT coordination language for programming tuple centres to govern interactions between agents and environment.

figure cd

3.3.3 Semantic web & situated interaction and coordination

LPaaS (2018) & LVLP (2016)

figure ce

MAS perspective LPaaS [60] and LVLP [59] are two models that—once specialised in the MAS context [274]—answer the need of intelligent environment and situated distributed cognition. LPaaS allows logic-based services to be embedded in the environment and made available to agents as a service. LVLP exploits the notion of labelled variable to allow for domain-specific logic-based computations. Altogether, LPaaS & LVLP models and architectures—and the corresponding technology—support the distribution of (micro)intelligence in pervasive MAS [274].

Logical perspective LPaaS in the MAS context exploits logic programming (and Prolog in particular) for the distribution of intelligence chunks placed where and when needed to locally tackle the specific reasoning needs in complex distributed systems.

figure cf
Fig. 1
figure 1

The cloud of words obtained by the main keywords extracted from the papers subject of the SLR

4 Analysis

4.1 Cloud of words

Figure 1 shows the word cloud generated from all the 271 papers in the survey. In order to give some meaning to this obviously limited, yet synthetic view of the literature, the ten most evident words in the cloud could be divided into three subcategories:

  • agent, action, plan, goal,

  • model, logic, rules, state, belief,

  • language, program/programming.

In short, the picture could be interpreted as suggesting that logic-based technologies in MAS are mostly exploited to make agents act, plan, and achieve goals based on the expressive power of logics in modelling knowledge into rules, states, and beliefs, by providing a well-founded basis for programming MAS via logic languages.

The cloud also highlights the relatively-high frequency of other words, related to the model one, such as: semantics, constraints, properties, ontology, variables, conditions, functions—all of them basically reinforcing the (quite obvious) idea that logic can be essential in formalising MAS and their properties. Further scrutiny reveals that terms time, environment, and event also appear quite often. This hints at the close relationship between agents and environment, and with the events that occur over the time—typically modelled in terms of logics such as temporal logic.

Other interesting words emerging from the cloud are information, reasoning, and intelligence, possibly reflecting one of the main purposes of the logic-based MAS technologies—namely, the design and development of intelligent MAS in knowledge-intensive systems. Finally, words like social, interaction, protocol, and communication highlight the social component of MAS as well as its connection with logic-based technologies.

4.2 Selected technologies: MAS & logic perspectives

In this subsection we further analyse the technologies selected by our SLR—reported in Table 1 in a joint MAS/logic view—, in order to provide additional information about the five research questions—from (Q1) to (Q5).

The most common usage of logic in MAS relates to agents programming and their reasoning/planning capability. Indeed, Table 1 also suggests that logic-based languages have the potential to play a prominent role as intelligence providers: the typical LP features—e.g., programs as logic theories, computation as deduction, programming with relations and inference—make logic languages a straightforward choice for building intelligent components.

Table 1 Logic-based MAS technologies: joint MAS/logic view

A more detailed observation of Table 1 shows the MAS sub-areas where logic-based technologies are extensively exploited are: (i) verification of both agent behaviour and social interaction (or MAS in the whole), and (ii) argumentation—the table only reports on the main “leading technologies” for each argumentation model.

For the former, logic-based techniques are widely recognised to be among the leading technologies for the verification of reactive systems, thanks to properties such as a solid logic ground to build upon, the possibility of providing interactions and communication with both a declarative and an operational semantics, and the chance to define logic-based integrity constraints. For the latter, as far as argumentation is concerned, although all the approaches implement defeasible logics (often with deontic extensions), a leading technology providing a shared set of abstractions is still missing, and each solution is instead typically tailored to a specific application domain. Generally speaking, the potential of logical approaches in norm-based systems and conflict resolution is widely acknowledged—also in terms of explainability of complex MAS.

As far as the environment modelling and engineering is concerned, most technologies target knowledge representation and, in particular, description logics. This is likely due to the environment being the most proper abstraction to encapsulate stateful (and semantic) information, and to work as a support for agent distributed cognition process in knowledge-intensive systems.

(Subsets of) predicate logic, logic programming, and action languages (e.g., situation calculus) have been mostly exploited for behavioural aspects of agents—most likely due to their natural procedural interpretation. On the other side, modal and epistemic logics have been mostly adopted in model-checking and verification technologies, presumably because they make it possible to express meaningful, desired specifications about what agents or societies do or know, while taking time into account.

Also, and quite naturally, one of the most successful logic-based architecture for agents—the BDI one—has never been exploited outside the boundaries of individual agents. This is likely due to the lack of intuitive interpretation of the desire and intention abstraction for both environments and societies.

Table 2 Overview on the selected technologies and their analysis

As far as the simulation tools for MAS are concerned, the SLR also points out that they often do not rely upon a formal logic-based framework: the logic is instead exploited to define the operational semantics of the simulation, or, to express temporal/epistemic specifications in the case of model-checking joined to the simulation process—as in the case of SALMA. This is why we only included in the SLR the few simulation frameworks with a strong logical characterisation; other simulation frameworks exist, such as LEADSTO mentioned in Table 4, but an actually-downloadable implementation could not be found for them—and this was the reason for their exclusion.

The final remark is related to the lack of MAS technologies based on fuzzy or probabilistic logic. This is somehow surprising, given the huge interest of the MAS community towards Bayesian or Markovian approaches. Many theoretical works can be found in this area, yet none comes with a technology that is actually implemented and alive.

4.3 Technological analysis

In this subsection we deepen the analysis of the technologies selected by our SLR in order to provide additional insights about research questions (Q1), (Q3), and (Q4). Table 2 provides an overview of our analysis.

There, we analyse the selected technologies according to a number of technical dimensions, corresponding to the columns of Table 2. In particular: column Fresh. assesses the freshness of each technology, by indicating—when possible—the year of the visible update; column Code provides a qualitative assessment of each technology code base, when available; column Doc. provides a qualitative assessment of each technology documentation, when available; column License indicates under which license each technology is provided, if any; column Target reports on the target runtime platform(s) each technology can be executed upon; column Runs shows our success in executing each technology—or loading it into its target runtime—, possibly after any necessary compilation step; column Benchmark points out whether each technology is distributed with some benchmarks or examples; column Work points out whether each technology works, i.e., if the aforementioned benchmarks / examples can be executed successfully.

More precisely, the freshness of a technology is defined by the year of its most recent release, or, source code modification. The code-base assessment consists of a (possibly missing) integer number ranging from 1 to 5:

  • “1” means the code base is available as a bare archive, even if it appears to have no clear file organisation, and it is comes with no facility supporting the compilation (or, in general, usage) of the code;

  • “2” means the code base is available as a bare archive, and it adheres to a well organised structure or it includes instructions on how to compile/use it

  • “3” means the code base is available through some version control systemFootnote 17 (VSC, henceforth), but poor support is provided for compilation or usage;

  • “4” means the code base is available through some VCS and it comes with some build automation toolFootnote 18 as well, supporting compilation or usage;

  • “5” means the code base is available through some VCS, it comes with some build automation tool, and it is also distributed through some official repository;

whereas a missing value denotes that no assessment can be drawn given the available information—e.g., because we were not able to access any code base.

Similarly, the documentation assessment consists of a (possibly missing) integer number ranging from 1 to 5 as well. In this case, however:

  • “1” means that the only available form of documentation is some textual note briefly describing the technology or how manage the codebase;

  • “2” means that some structured form of documentation exists describing the technology or how manage the codebase;

  • “3” means that a detailed manual or some API reference are available, but not both;

  • “4” means that both a detailed manual and some API reference are available;

  • “5” means that a detailed manual, some API reference, and some usage examples or tutorials are available;

whereas a missing value denotes the total lack of any form of documentation.

Whenever available, the license of each technology is referenced in Table 2 as well, possibly leveraging on well-known license acronyms. For instance, as far as open source licenses are concerned, “GPL” refers to the GNU General Public License,Footnote 19 “LGPL” refers to the GNU Lesser General Public License,Footnote 20 “MIT” refers to the MIT License,Footnote 21 “MPL” refers to the Mozilla Public License,Footnote 22 whereas “Apache” refers to the Apache License.Footnote 23 The absence of licenses for a particular technology is pointed out as well, as it may have an impact on its users.Footnote 24

The target runtime platform is another relevant aspect we analyse for each technology. It provides an intuition of which sorts of machines and devices could in principle be capable of running a given technology. As it clearly emerges from Table 2, the JVM platform is targeted by most technologies. This is why, in the particular case of JVM-based technologies, we try to assess the specific version(s) of the JVM they can run upon. Thus, the “JVM N+” notation indicates that a given technology is tested on all JVM versions ranging from N (included) to version 13 (included)—which is the most recent one at the time of writing—, and only executes without errors starting from version N. Of course, the JVM is not the only platform our selected technologies leverage upon. Some technologies require a compilation step targeting some native platform. So, for instance, in case only the OS operative system is supported, we write “Native / OS” to identify the target platform. Other technologies target the Common Lisp, Python, or Erlang runtimes, which come with several implementations supporting mainstream operative systems, similarly to what JVM does. There exist also technologies targeting specific, well-known, implementations of Prolog, such as SWI-Prolog, SICStus Prolog, or ECLiPSe-Prolog. In this case we simply write a short indicator of the target Prolog implementation (“SWI”, “SICStus”, or “ECLiPSe”), or some piped-separated combination of two or more indicators, in case more than one implementation are supported. Furthermore, a few technologies are available as web services. In those cases, we argue that the actual platform of the service implementation is not essential—this is why we simply denote the target platform as “Web Service”. Finally, there are some technologies which are explicitly aimed at extending (or customising) the Eclipse IDE,Footnote 25 and are not meant to be used otherwise. In those cases, we indicate “JVM” as the target platform, and tag the technology through an ad-hoc footnote.

In order to test whether a technology runs or not, we simply launch it on its target platform—possibly, after performing all necessary compilation/configuration steps. If neither compilation/configuration nor launching produces error or crash, then we say the technology runs, otherwise it does not. Thus, a question mark in Table 2 in the Runs column may indicate either the total lack of any information on how to launch the technology, or, the impossibility of producing/accessing an executable to launch.

Finally, when we are able to run a given technology, we then test it to get further detail, so as to understand if it actually works or not. To do so, we first look for available benchmarks or examples into the running technologies code bases, documentation, or home pages. In case some benchmarks/example are available, we check if they can be run without producing error outputs or crashes. If they can, then the technology works, otherwise it does not. Thus, a missing value in Table 2 in the Benchmark or Works columns indicates that no assessment is needed because the technology does not run. Conversely, a question mark in the same columns denotes the impossibility to perform any further assessment due to lacking benchmarks, examples, or instructions on how to launch them.

Table 3 Statistics on selected technologies

By aggregating the data in Table 2, we can draw several interesting conclusions. Most relevant ones are summarised in Table 3. The most evident information is that only 12 out of 47 technologies have been actively maintained since 2019—i.e., 25.53% of the total. The percentage is lower than 50%, even if we enlarge the spectrum to technologies maintained since 2017. However, most technologies (65.96%) can still be run successfully—regardless of when they were last updated—, even though we are able to make them work in 67.74% of cases only.

Another interesting trait is that—except for JACK—all technologies that are explicitly licensed come with an open source license. These correspond to 55.32% of the total. The amount of unlicensed technologies is quite high as well, as it corresponds to the 40.43% of the total.

It is interesting to note how the JVM is by far the preferred platform for logic-based MAS technologies. Indeed, 63.83% of the selected technologies target some version of the JVM. Other recurring platforms are Lisp-, Prolog-, or native-based.

Finally, it is worth to be mentioned how—except for a few notable exceptions, such as Jason—poor care is given to technologies code bases and documentary resources. Indeed, considering the 1–5 ranges defined above, only 34.04% of the technologies come with a code base whose quality is greater than 3, whereas only 19.15% are scored similarly as far as documentation is concerned.

Table 4 Main technologies excluded from the survey, along with the motivation spanning between (i) “general purpose”, (ii) “no logic”, (iii) “technology not found”

4.4 Rejected technologies

For the sake of completeness, Table 4 summarises the main technologies that were excluded from our SLR, along with the corresponding motivation. In particular, the table shows the instantiation of the criteria for MAS technologies inclusion defined in Sect. 2.1.

Let us recall the inclusion criteria we adopted in this SLR. Contributions are considered as logic-based MAS technologies if all the following conditions simultaneously hold:

  1. (a)

    they can be clearly related to some well-known and shared definition of agent and MAS—e.g., [280, 356];

  2. (b)

    they stick to some logic which is clearly identifiable in the literature, in terms of name, formal definition, and reference paper(s);

  3. (c)

    they are both scientifically identifiable (reference paper) and technically available (i.e., some software actually exists).

The aforementioned criteria find their reification into three main motivations for rejection, described below:

  • general purpose—the contribution may be exploited or referenced in other MAS-related (resp. logic-related) works or technologies, but it is not explicitly intended to target them;

  • no logic—the contribution does not stick to any clearly identifiable logic from the literature;

  • technology not found—no actual software resource, no evidence found that some close-source software actually exists.

Each one of the motivations alone is a sufficient condition for exclusion—so that a contribution is excluded as soon as one of the above conditions is met. So, for instance, all general-purpose Prolog engines (e.g., SICStus, SWI-Prolog, tuProlog, or ECLIPSE-Prolog) are excluded, as they do not intentionally refer to any specific MAS abstraction—criterion (a).

Also, JaCaMo [41] is excluded according to criterion (b). JaCaMoFootnote 26 builds on top of Jason, and integrates Jason Moise [193] for programming agent organisations, and CArtAgO [298] for programming shared environments. However, among these technologies, only Jason is logic-based: CArtAgO and Moise are Java-based technologies whose only connection with logical approaches is via their Jason wrappers. This is why, we choose to include Jason in our technological overview, while excluding JaCaMo, CArtAgO and Moise, despite the corresponding technologies are alive and functioning.

Finally, some well-known logic-based technologies are excluded according to criterion (c), as no actually-downloadable version of the tool could be found—for public link missing, dead link, or no download available. Among the others, technologies such as JASDL, n-Jason (missing link to the corresponding technology) and VerICS and SOCS (dead link) are notable examples of technologies excluded for that specific reason. At last, it is worth to be mentioned that a number of works concerning social commitments have been excluded as well, for similar reasons. The Cupid [74] model, in particular, is a notable example. Given their importance, however, a few comments about their absence are due, as it may seem astonishing. In fact, despite these are well-founded and impactful theoretical works, we were not able to find any runnable technology available to date, neither in the corresponding papers nor on the Web. This is the only reason why these models are mentioned in this section.

5 Discussion

The main question behind this work is (G) “What is the role of logic-based technologies in MAS nowadays?”—as mentioned in Sect. 3. To properly answer this question, we identify five more specific research questions—namely, (Q1), (Q2), (Q3), (Q4), and (Q5)—, and we deeply and systematically inspect the literature in order to support a detailed answer for each of them. In this section we further discuss the contribution from Sect. 3, along with the tables and data from Sect. 4, so as to summarise a brief and explicit response to each research question.

Generally speaking, the fundamental role of logic-based technologies in MAS nowadays is to address the need for intelligence that characterises agent-based abstractions—i.e., the cognitive abilities required by distributed intelligent system components. However, logic-based technologies can seldom be considered to be mature enough to tackle the requirements of industrial and real-word domains. In the following paragraphs, we deepen the discussion by focusing on the specific research questions.

(Q1) Which logic-based technologies for MAS are actually available? The available logic-based technologies for MAS are listed in Table 2. Among the 47 technologies we assess, 21 (i.e., 44.68%) are still alive and working. However, only 12 of them (i.e., 25.53%) show recent updates (since 2019). Also, in terms of the overall assessment of the technology—based on the criteria detailed in Sect. 4.3—, one may notice that only a relatively-small number of them meet basic technological standards.

(Q2) Which aspects of MAS technologies are affected by logic-based technologies, and to what extent? (Q3) Which MAS abstractions / issues / features are covered by logic-based technologies? As summarised by Table 1, logic-based technologies cover almost all the existing MAS abstractions, with a heterogeneous distribution.

In particular, 50% of technologies focus on agent programming, exploiting logic to describe the agent behaviour (at an adequate level of abstraction), as well as their goals and knowledge—often expressed through beliefs, desires, and intentions.

With respect to the society abstraction, there are about 10 technologies identified by this study. Among them, TuCSoN is arguably the most mature one. In TuCSoN, logic is exploited to address coordination issues, as well as reasoning tasks. Other technologies that address agent societies issues are mostly related to defeasible reasoning and, in particular, argumentation. However, our assessment reveals that most of them are not mature enough for distributed MAS environments, although exceptions exist—e.g., ASPIC+. This line of research remains highly promising. It is worth noting that the adoption of a logic-based approach for argumentation purposes has many advantages, which all lead towards explainable systems.

The environment abstraction is the least affected by logic-based technologies: only few technologies deal with MAS environment and adopt logic at the same time. In the few identified technologies, logic is often exploited with the purpose of making the environment intelligent, or, to represent distributed knowledge, possibly exploiting ontologies. However, none of them can be considered actually ready to match the needs of real-world application domains. This is why this research line appears promising and deserves further attention.

Finally, many logic-based formal methods are used for MAS engineering, as well as for model checking and verification [355]. The corresponding technologies found in the SLR are reported under the “MAS/Agent Reliability & Verification” column of Table 1. However, more often than not, the corresponding technologies appear poorly maintained, thus revealing another potentially productive area for applied research.

(Q4) Which sorts of logics are actually exploited to frame logic-based MAS technologies? Most of the selected logic-based MAS technologies are related to logic programming—likely because of its wide diffusion, simplicity, and adaptability—or to the BDI logic—both for the cognitive abstractions that straightforwardly match the needs of rational gents, and for the vast amount of contributions and results on the topic by the MAS community. Furthermore, defeasible and deontic logics are exploited for dealing with uncertain or defeasible knowledge, as well as to address normative concerns. Finally, description logics are widely used in order to represent knowledge of the agents and of the whole system. It is worth noting that some logics, such as fuzzy logic, show great potential for dealing with uncertainty in MAS: nevertheless, none of the research works surveyed actually translate their theoretical contributions into some usable technology.

(Q5) Which logic-based technologies for MAS are effectively used in real-world domains? Among the 47 technologies surveyed, evidences of non-trivial real-world applications can only be found for IndiGolog, JACK, JIAC, and Agent Factory (AFPL). In particular: (i) IndiGolog has been used for programming robot controller, workflow management systems, and web service composition systems [46]; (ii) JACK has been used for building autonomous unmanned air vehicles and manufacturing systems, for simulating the human behaviour, or, for implementing decision support systems [353]; (iii) JIAC has been used in a number of projects that span from simulation and service execution to energy control and home automation [46]; (iv) AFPL has been used for the development of applications in various domains, including e-commerce, ubiquitous computing, mobile computing, robotics, wireless sensor networks, and mixed reality [46]. However, it is worth recalling that only JACK and JIAC are still actively maintained, as highlighted in Sect. 4.3.

Nevertheless, we believe that the amount of mature technologies that are potentially ready to be used in real-world domains is larger than those currently exploited—indeed, the analysis above is intentionally limited to the real-world applications explicitly described in the articles included in the SLR. By considering as mature technologies all the technologies in Table 2 that (i) have been maintained since at least 2 years, (ii) have a scored of at least 3 in their source code and documentation evaluation, and (iii) are still working, the set of mature technologies can be extended to include also ASPIC+, ASTRA, GOAL, Jadex, Jason, MCMAS, Mozart, RML, and TuCSoN.

Final and general remarks This work is motivated by a broader research question—namely:

Given the new challenges that are opening up in the field of intelligent systems and AI for logic-based technologies, do there exist technologies that can be considered ready enough? If not, what is missing?

To answer this question, we should first recall that modern intelligent systems:

  1. (i)

    are deeply intertwined with domains like the Internet of (Intelligent) Things (Io(I)T) and Cyber-Physical Systems (CPS);

  2. (ii)

    are therefore inherently distributed, thus demanding for robustness, efficiency, interoperability, portability, standardisation, situatedness, and real-time support;

  3. (iii)

    need to reconcile and synthesise symbolic and sub-symbolic AI, exploiting the former to explain the latter so as to overcome fears and ethical issues posed by AI by providing for explainability, observability, interpretability, responsibility, and trustability—the scope of XAI.

In the remainder of this section we focus on the issues above, and extract further considerations from the data collected in Sect. 4.

Applicability to distributed domains such as IoT and CPS Often, the existing agent solutions applicable to the IoT and CPS are available only for a specific and limited set of devices. For instance, Agent Factory Micro Edition (AFME) [262] enables the execution of a deliberative agent on top of mobile phones with CLDC/MIDP profiles and Sun-SPOT sensor by means of TCP/IP and Zigbee protocols.

However, some technologies are, more than others, explicitly designed to support IoT domains and CPS. For example, the LPaaS architecture is designed to promote distributed intelligence for the IoT world—offering logic programming in terms of service, and explicitly addressing the requirements and issues of cloud and edge architectures. It exploits the Everything as a Service [27] metaphor to maximise availability and interoperability while promoting context-awareness. From the MAS point of view, LPaaS takes care of distributing knowledge as well as reasoning capabilities placed in the agent environment. Analogously, the situated coordination approach promoted by the TuCSoN/ReSpecT model and technology can be explicitly exploited to handle situatedness in MAS as a coordination issue. Also, TuCSoN provides the main abstractions for IoT environments: environmental resources can be sources of perceptions (like sensors), targets of actions (like actuators), or even both.

Finally, there are technologies that are not explicitly meant to address the IoT and CPS domains, but still let us suppose they would be easily portable to those domains—because of their standard compliance, interoperability, and portability features. Among the many, Jason supports interoperability with non-Jason agents via JADE through FIPA-ACL communication. Similarly, there are extensions to JACK that make it work in open systems. Finally, the Teleo-Reactive approach has been often exploited to facilitate the development of the IoT systems as a set of communicating Teleo-Reactive nodes. The software behaviour of the nodes is specified in terms of goals, perceptions, and actions over the environment, achieving higher abstraction than using general-purpose programming languages and therefore, enhancing the involvement of non-technical users in the specification process.

Symbolic and sub-symbolic integration With respect to the second requirement of AI—i.e., the need to reconcile and integrate symbolic and sub-symbolic techniques—none of the selected technologies has been experimented yet. However, we argue that portable and interoperable technologies might be more suitable for the integration. Anyway, the field is still unexplored and represents a frontier research domain.

Can existing technologies be labelled as ready? If not, what is missing? To recap, the role of logic-based technologies in MAS nowadays exhibits a huge potential for covering the vast majority of intelligent system abstractions. However, just a few among the technologies surveyed can be actually labelled as ready-to-go, in particular when considering the new challenges for symbolic technologies in AI.

In fact, even though 10% of the selected technologies can be considered as mature—in terms of cross-platform support, code quality, and ease of distribution in heterogeneous environments—, they often have not been tested in pervasive and real-world scenarios, yet. This implies, at least, that further research is required to ensure any technological barriers can be overcome. Furthermore, integration with sub-symbolic techniques remains a nice-to-have feature, but it is not actually a thing in any MAS technology, for the time being.

Nevertheless, the selected technologies are an excellent starting point for (i) highlighting the advantages of logic-based technologies, and (ii) broadening the scope of research towards the directions envisioned.

6 Conclusion

SLR originated in the medical research field [176], first of all as a tool to make some sense over the heterogeneity of methodologies, tools, scope, and size, which were severely affecting the overall coherence of the research results (not just methods) in most areas, there. SLR have spread to other research fields, too: in the ICT areas, some of the first SLR can be found in the software engineering field [206], for instance.

Whereas one might argue against the actual need of adopting the SLR approach everywhere—for instance, in the MAS field—yet it should be observed that the ever-growing articulation of most areas in computer science and AI in the last decade has led to a huge popularity and diffusion of surveys—on any possible topics, also given the global popularity of AI and CS nowadays. Most of the surveys around, however, while useful and interesting, typically suffer from the authors’ bias [206], in particular when large research topics are addressed: as such, they typically fail in the essential aspects of reproducibility that should characterise any scientific work [291]. This is where SLR comes at a hand: by providing a technical tool to produce surveys that can be verified and reproduced, since it requires to make the methods used to build the survey explicit and repeatable.

Given the recent popularity of AI, and the potential role that logic-based technologies for MAS could play in the engineering of complex intelligent systems, we think that a SLR targeting MAS technologies based on any sort of logic could be of wide interest. Along this line, this paper presents a SLR on logic-based technologies for MAS.

By logic-based technologies for MAS we mean any agent-oriented software architecture, framework, or language (i) involving some clearly-defined logic model, and (ii) coming with some actual technological reification.

The paper follows the standard SLR method: we carried out a manual retrieval, filtering, analysis, and categorisation of huge number of papers, resulting in 271 documents, retrieved by repeating 8 queries on 6 electronic search engines (Google Scholar, IEEE Xplore, ScienceDirect, SpringerLink, DBLP, ACM Digital Library) and 5 specific conference/workshop proceedings. Whereas search engines are chosen to make our survey as comprehensive as possible, queries are precisely designed to capture meaningful works w.r.t. the main goal (G) of our SLR, other than the 5 specific research questions it has been split into—namely, (Q1) up to (Q5). Our research questions aims at inspecting (i) which logic-based technologies for MAS are available today, (ii) what is the role of logic in these MAS technologies, and (iii) what is the technologies current state and maturity,

The methodological approach and the inclusion, exclusion, and analysis criteria adopted here are carefully designed and described in detail, keeping a tight focus on the reproducibility of the whole process. In particular, we only include works defining or exploiting logic-based MAS technologies according to the above definition and for which the existence of some software reification can be proven.

The technologies resulting from this systematic exploration are analysed and assessed from two different perspectives—namely, the MAS one and the logical one—, thus discussing which specific MAS- and logic-related aspect is tackled or exploited by each technology. As suggested by Omicini [273], we categorise the selected technologies on the three main abstractions in MAS—namely, agents, societies, and the environment—thus revealing an uneven distribution of logic-based technologies on MAS abstractions, and highlighting research opportunities on less popular abstractions—as the environment one.

We also perform a technical assessment of each technology, which enables a detailed discussion on the current state of logic-based MAS technologies. The outcome of the discussion highlights that, as far as logic-based technologies for MAS are concerned—except for some rare important success stories—there is still room for technological advancements. Quite often, in fact, despite the enormous technological effort clearly carried out by the MAS community in the last decades, the technologies cannot be considered mature and ready for use in the new challenging contexts required by AI. Our SLR identifies the most promising research areas, as well as the areas that mainly need technological progress.

Because of the scientific, well-founded, and reproducible approach of this SLR, we believe that it represents a reliable tool to assess the current state of the topic, and we hope it can be used to understand the future directions in this area.