Coordinated inductive learning using argumentation-based communication Abstract This paper focuses on coordinated inductive learning, concerning how agents with inductive learning capabilities can coordinate their learnt hypotheses with other agents. Coordination in this context means that the hypothesis learnt by one agent is consistent with the data known to the other agents. In order to address this problem, we present A-MAIL, an argumentation approach for agents to argue about hypotheses learnt by induction. A-MAIL integrates, in a single framework, the capabilities of learning from experience, communication, hypothesis revision and argumentation. Therefore, the A-MAIL approach is one step further in achieving autonomous agents with learning capabilities which can use, communicate and reason about the knowledge they learn from examples. The current dominating paradigm in machine learning (ML) is that data of interest is first collected in a single repository and then learning upon that data is performed-we will call this paradigm the centralized viewpoint of ML. In this paper we explore a paradigm in which data collection and learning are interleaved: rather than completely collecting all the data in a single repository, learning is performed on data collected in different repositories; later, depending on the results obtained from learning, further data exchange can be performed if needed, potentially triggering further learning. We will call this paradigm the decentralized viewpoint on ML. Learning in decentralized ML happens in two stages: in the first one, learning is performed separately with the data existing in each repository; in a second stage, the result of learning is coordinated between the agents (with some potential data exchange).. A common misconception about this decentralized viewpoint is that it is not needed, and the research focus in the ML community is moving towards a big data approach. However, the movement towards large amounts of data is about size, and does not imply the basic assumption of the centralized viewpoint on ML: that all relevant data can be centralized in one place before learning. Our claim is that, in general, it is unrealistic to assume that all relevant data can be centralized in one place, and therefore a decentralized viewpoint on ML is realistic, useful and strategically significant. In this approach to decentralized learning, the only additional assumption needed is that, although some reasons might preclude centralizing all data, some partial communication of data and learning results among the different repositories involved is possible.. In this paper, we focus on logic-based inductive learning in the context of decentralized ML, where communication will be addressed through a multiagent systems (MAS) approach, where agents can learn from each other by some regulated communication process. Specifically, we study a formulation of decentralized learning that we call coordinated inductive learning (CIL). The goal in CIL is for each agent to learn an agreed-upon hypothesis that is consistent with all the data known to all the individuals, but without having to share all such data. In fact, since (as we will experimentally show) a large part of the content exchanged during communication are induced rules, rather than raw data, this has two clear advantages:. (1) the size of communicated content decreases and (2) privacy concerns are diminished.. In order to achieve CIL, we propose an approach called Argumentation-based MultiAgent Inductive Learning (A-MAIL). The A-MAIL framework integrates inductive learning and argumentation-based communication to achieve CIL. The key idea in A-MAIL is that hypotheses inferred through inductive learning can be seen as arguments in an argumentation process. Therefore, agents can use argumentation to reach an agreement over those hypotheses and learn from each other. Since the agents will change their inductive hypotheses to reach this agreement, we can characterize this process as (argumentation-based) learning from communication. Specifically, A-MAIL consists of three processes: (1) the inductive learning process, giving the agents the ability to learn hypotheses from examples; (2) the argumentation process, with which agents can communicate, attack and defend hypotheses; and (3) the hypothesis revision process with which agents update their hypotheses after receiving new arguments. Thus, one of the main contributions of A-MAIL is that it studies how to integrate, in a single framework, the capabilities of inductive learning, learning from communication, and argumentation.. In general terms, we are proposing that the integration of learning and argumentation can support decentralized learning. In a previous theoretical work [39] we presented a proof that, under certain conditions, induction plus argumentation in a multiagent system with decentralized data is actually equivalent to learning from a centralized repository of data. That work showed that by having a logic model of non-monotonic reasoning for induction, and another model of non-monotonic reasoning for argumentation, both can be integrated as a model of a MAS that learns from data and communication in a correct way (where correctness means that what is learnt in a MAS is logically equivalent to what is learnt in centralized learning with a single repository of data). The limitation of such theoretical approach is that the theoretical guarantees only hold in the (more limited) context of Boolean inductive concept learning, and that we did not present any specific algorithm nor interaction protocol, just a theoretical proof of the feasibility. In this paper, and based on those theoretical results, we present and empirically evaluate A-MAIL, which is a practical approach allowing agents to inductively learn from their data and also from communicating with other agents in a MAS. As we will see, however, A-MAIL is not restricted to Boolean inductive concept learning and allows the induction of rules that are not 100 % correct-as is the usual and practical approach in ML inductive concept learning techniques.. The remainder of this paper is organized as follows. Section 2 introduces the problem of CIL. Then Sect. 3 presents A-MAIL, a framework to achieve CIL, while Sect. 4 presents how A-MAIL is used for CIL. An experimental evaluation of A-MAIL in several domains is explained in Sect. 5. Later, three sections wrap up the paper with a discussion about A-MAIL's contributions (Sect. 6), related work (Sect. 7), and conclusions and future work (Sect. 8). In this paper we focused on a multiagent learning scenario called CIL, where groups of agents benefit from collaboration and communicating with other agents in order to improve the quality of their individual hypotheses. We proposed the A-MAIL framework to address CIL and, to evaluate our approach, we used a collection of ML datasets showing that A-MAIL can, effectively and efficiently, achieve CIL. The core notion of the A-MAIL framework is that agents learn from communicating with each other in a principled way, namely using an argumentation-based communication process that allows both detecting errors in knowledge (blame assignment) and agreeing on which changes should be effected to correct those errors.. One of the most interesting aspects of A-MAIL is that it integrates and automates in a single framework the capabilities of learning from experience, learning from communication, hypothesis revision and argumentation. Moreover, the integration of argumentation with (inductive) learning allows agents to be completely autonomous in all aspects of argumentation: generating arguments and counter-arguments, attacking and defending arguments, and finally reaching an agreement on the acceptability of specific arguments (by the group)-all of which is based on the empirical foundation given by individual learning from examples. All of those capabilities can be integrated to achieve complex tasks such as CIL, where the theoretical foundation for that integration is modeling both inductive inference and argumentation as non-monotonic reasoning [39] . In this paper we presentes and evaluate A-MAIL, a computational realization of these theoretical notions. Notice, however, that the theoretical model in [39] is an idealization of the whole A-MAIL approach, where only perfectly Boolean rules are assumed to be inductively valid, in which case the process is guaranteed to converge. The experimental evaluation of the A-MAIL framework shows that in the more general, and close to practice concerns, approach where induced rules are merely τ -acceptable, the agents can achieve an agreement on inductive hypotheses and improve their individual hypotheses.. Moreover, the A-MAIL framework achieves CIL in an efficient way, in the sense that the communication involves a reasonable number of messages to achieve a good collection of inductive hypotheses that are consistent with the individual viewpoints of each agent. Finally, we showed that, assuming finiteness in the generalization space being explored, the empiricist strategy is assured of finding τ -acceptable hypotheses. The A-MAIL approach is thus one step forward in achieving autonomous agents with learning capabilities which can use, communicate, critique, and reason about the knowledge they learn from examples. While computational argumentation models are based on the notion of attack (among rules), empirical inductive learning is based on the notion of support (of rules with respect to known examples). The approach of A-MAIL is to combine both notions seamlessly. Support is integrated into the argumentation model as part of the τ -acceptability evaluation, while attacks are incorporated in the learning process as a form of communication between learning agents. This form of communication can be seen as a generalization of the classical (and simpler) teacher/apprentice (or oracle/learner) interaction. 22 As part of our future work, we intend to study open multiagent system scenarios with heterogeneous agents where each agent uses different learning methods, hypothesis revision mechanisms, or marking functions. Concerning A-MAIL we intend to explore the integration of weighted argumentation systems, such as [23] , into the A-MAIL framework; this would eliminate the need to define a τ -acceptability threshold, and thus take into account rule confidence as part of the argumentation process, further tightening the integration between induction and argumentation. Finally, we would like to study scenarios where individuals in a multiagent system systematically explore distinctly different parts of large datasets, and then engage in coordinating their inferred hypotheses. We have presented a rather general framework of inductive learning from communication.. In our framework, any number of agents learn not only from the data they have available but also by communicating with other agents using a regulated form of interaction based on computational argumentation. In the experiments presented here, the goal of the learning agents is to engage in communication until they agree that their individual hypotheses are adequately supported by the empirical data available to all of them (the task we have called CIL).. We can view this approach as a generalization of the classical teacher/apprentice (or oracle/learner) scenario, in which a simple form of interaction is performed where the teacher (oracle) communicates positive and negative examples to the apprentice. Another, more complex scenario is the active-learning [19] scenario where the examples sent by the oracle are selected by the apprentice following some heuristic evaluation. 21 Our teacher/apprentice interaction, in comparison, is based on argumentation, and rules are also exchanged in addition to examples. Moreover, the rules being exchanged are responsible for the fact that the apprentice can learn so fast with a smaller number of examples than would be necessary in a simpler mode of interaction.. The argumentation process incorporates the blame assignment requirement of learning processes: each attack, be it a rule-argument or an example-argument, corresponds to some agent detecting some specific lack of knowledge in another agent. Moreover, since this detection is based on what the first agent has learnt, this agent is in position to become a teacher by providing the other agent (that becomes the apprentice) with information amenable to correct that fault. Thus, the roles of teacher and apprentice are dynamic, and assigned seamlessly by the argumentation process to those who have the capability (to teach) and the need (to learn) in a completely decentralized way.. The role of blame assignment in learning processes has been explicitly addressed by goaldriven learning [30] . Goal-driven learning decomposes the learning problem in three steps: blame assignment, learning goal generation, and repair (or learning) strategy. This approach considers a single agent reasoning introspectively about detecting its own failures (blame assignment), deciding what needs to be learnt to correct it (learning goal generation), and determining a way to achieve this goal (repair strategy).. In our learning from communication approach, however, more than one agent is involved in solving the learning problem. For instance, consider the situation where an agent A 2 communicates the attack β 1 α 1 to an agent A 1 . This means that A 2 has detected an error in the rule α 1 learned by A 1 . Moreover, A 2 is also indicating that β 1 is correct and should become a learning goal for A 1 . Now, A 1 may or may not accept this attack; if A 1 accepts β 1 , then A 1 engages in a hypothesis revision process (i.e. the repair strategy in A-MAIL). However, if A 1 does not accept β 1 , then A 1 will engage in the process of attacking β 1 , thus reversing the roles of A 1 and A 2 .. Finally, notice that accepting an attacking argument (as a learning goal) depends on whether an agent is rationalist or empiricist. Thus, rationalist and empiricist agents will generate learning goals, and engage in repair strategies, in different circumstances. The rationalist agent generates a learning goal when it is unable to defeat the other agent's contention, while the empiricist agent generates a learning goal when empirical support justifies so.. The experiments in Sect. 5 focus on a scenario with n fixed agents, but this is just a device for evaluating A-MAIL performing CIL. Our approach encompasses dynamic scenarios interleaving data collection and learning. For example, consider the scenario where after learning is coordinated by n agents, one of the participating agents receives brand new data that compels it to change its hypotheses. This is a particular case of our general approach, in which n agents engage in the CIL process while the starting point happens to have n − 1 agents already coordinated. Another scenario could be as follows: after learning is coordinated by n agents, assume a new agent appears and joins the system with brand new data; again this is a particular case of our general approach, in which n + 1 agents engage in the CIL process while the starting point happens to have n agents already coordinated. In both scenarios our approach works seamlessly, since they are particular cases of the n uncoordinated agents scenario used in Sect. 5.. Finally, learning from communication, as we are advocating here, seems particularly interesting to lifelong (or "never-ending") learning. In systems performing lifelong learning, e.g. NELL at Carnegie Mellon, humans need to "correct" by hand, from time to time, some hypotheses learnt by the system [13] . We can view this as a particular case of the teacher/apprentice scenario, but without any principled methodology guiding the changes effected upon the lifelong learning system. Our approach would be to consider this as a particular case of our teacher/apprentice scenario, where a human could correct a lifelong learning system (and justify those corrections) using argumentation. The lifelong learning system could work on a rationalist or empiricist approach: in the rationalist approach, the corrections argued for by humans carry a certain weight of authority (since they would be accepted if the system cannot defeat them), while in the empiricist approach the system takes a more skeptical view of the teacher, and will engage the human in an argumentation process until the system obtains enough empirical support to autonomously accept the intended corrections. The integration of arguments into a ML framework is a recent idea, receiving increasing attention. For example, the argument-based ML framework [38] , although not using argumentation per se, assumes the arguments are given as the input of the learning process. In contrast, A-MAIL generates arguments by induction and uses them to reach agreements among agents by using argumentation-based communication. Argument-based ML is more closely aligned to the ABUI algorithm. Moreover, argumentation has been applied to clas-sification problems [3, 41, 58] , but with a focus on arguing about the classification of one or more particular examples, rather than about building general inductive hypotheses, as in this paper.. In our approach we chose to use the existing concept of marking functions [51] to determine argument acceptability. This notion is very closely related to that of a categorizer in Besnard and Hunter's argumentation approach [7] . A categorizer can be seen as a mapping from argumentation trees to numbers. Thus, a marking function can be seen as a binary categorizer that assigns 1 (accepted) or 0 (defeated) to each subtree. Moreover, as part of our future work, we would like to explore the use of accumulators (functions that, given a categorizer, accumulates all the information in all the argument trees for and against a conclusion into a pair of numbers). Accumulators are interesting when multiple argumentation trees exist for the same conclusion, and would allow agents to gauge evidence for and against labeling a specific instance as belonging to the target concept C or not.. Multiagent learning (MAL) has been studied from many perspectives [56] , going back to the first dedicated workshop jointly organized by the ECML-2000 and Agents-2000 conferences [54] and continued in the ALAMA/ALA series of workshops. Historically, the most common approach has been that of reinforcement learning in multiagent settings [33] . Our work, however, is more closely related to classification in MAS [37] than to reinforcement learning. Also, our setting is a collaborative learning setting, rather than an adversarial learning setting [55] , and we focus on learning from explicit communication-rather than implicit communication or coordination, e.g. as in using stigmergy [4] . In the following, we will briefly overview related work in several subareas of multiagent learning, which are related to our work.. Concerning multiagent reinforcement learning, the main theoretical difference with respect to the centralized scenario was stated by Littman [33] : In a multiagent setting, the optimal policy depends on the behavior of the other agents (that can also be learning) and the environment is not stationary anymore. Therefore, the convergence property of single agent reinforcement learning does not apply. A significant amount of work has been done in this area, such as the work of Hu and Wellman [25] or Bowling and Veloso [10, 11] .. A more closely related area is that of integrating CBR into multiagent systems. Prasad et al. [48] proposed an approach based on distributed case retrieval (where agents can retrieve examples from the other agents in the system in order to solve new problems). This approach is closely related to the work of Plaza et al. [45] , who also focused on distributed case retrieval. Other approaches to CBR in multiagent systems are those of McGinty and Smyth [35] , Leake and Sooriamurthi [31, 32] and our previous work [46] . The main difference between those pieces of work and this paper is that A-MAIL aims at being a general framework for learning from communication, that does not assume agents are using CBR.. Our work is also related to multiagent inductive learning. One of the earliest in this area was MALE [52] , in which a collection of agents tightly cooperated during learning, effectively operating as if there was a single algorithm working on all data. Similarly, DRL [49] is a distributed rule learning algorithm based on finding rules locally and then sending them to the other agents for evaluation. The main difference with respect to our work is that their goal is to parallelize a given rule-learning algorithm to obtain a single centralized hypothesis. In contrast, A-MAIL is a multiagent approach, where each agent is individually responsible for its own hypothesis, and where argumentation is used as a shared communication framework.. The ways in which multiple theories learned by different agents, represented as disjunctions of rules, can be merged has also been explored [12] . This method is iterative, and rules are added one by one to a unified theory attempting to maximize some accuracy criterion. The idea of merging theories for concept learning has been also studied in the framework of Version Spaces [24] , albeit in a centralized way. Concept learning in multiagent settings has recently been addressed in the SMILE framework [8, 9] , where they study how broadcasting of examples among agents can be used to "critique" (i.e. attack) hypotheses learned by other agents. The main difference here is that, in SMILE, agents only exchange examples, where as A-MAIL allows for a richer communication including rules. SMILE is in fact more related to our previous work [43] , where we defined two strategies called AMAI and RAMAI. AMAI and RAMAI can be used by groups of agents to attempt CIL but only exchanging examples. These methods achieve an acceptable degree of success, but require exchanging a very large amount of examples.. Finally, a related area is that of multi-task learning (MTL) [16] , where instead of learning one task from different collections of examples, the goal is to learn a set of similar tasks from potentially different collections of examples. The idea is that by learning not just one task, but also other related tasks, some transfer learning might occur, thus leading to improved performance of the main task. The main difference with respect to A-MAIL is that MTL focuses on a single agent learning multiple tasks, without communicating with other agents.

O B I O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Automatic transformation of iterative loops into recursive methods Context: In software engineering, taking a good election between recursion and iteration is essential because their efficiency and maintenance are different. In fact, developers often need to transform iteration into recursion (e.g., in debugging, to decompose the call graph into iterations); thus, it is quite surprising that there does not exist a public transformation from loops to recursion that can be used in industrial projects (i.e., it is automatic, it handles all kinds of loops, it considers exceptions, etc.).Objective: This article describes an industrial algorithm implemented as a Java library able to automatically transform iterative loops into equivalent recursive methods. The transformation is described for the programming language Java, but it is general enough as to be adapted to many other languages that allow iteration and recursion.Method: We describe the changes needed to transform loops of types while/do/for/foreach into recursion. We provide a transformation schema for each kind of loop.Results: Our algorithm is the first public transformation that can be used in industrial projects and faces the whole Java language (i.e., it is fully automatic, it handles all kinds of loops, it considers exceptions, it treats the control statements break and continue, it handles loop labels, it is able to transform any number of nested loops, etc.). This is particularly interesting because some of these features are missing in all previous work, probably, due to the complexity that their mixture introduce in the transformation.Conclusion: Developers should use a methodology when transforming code, specifically when transforming loops into recursion. This article provides guidelines and algorithms that allow them to face different problems such as exception handling. The implementation has been made publicly available as open source. Iteration and recursion are two different ways to reach the same objective. In some paradigms, such as the functional or logic, iteration does not even exist. In other paradigms, e.g., the imperative or the object-oriented paradigm, the programmer can decide which of them to use. However, they are not totally equivalent, and sometimes it is desirable to use recursion, while other times iteration is preferable. In particular, one of the most important differences is the performance achieved by both of them. In general, compilers have produced more efficient code for iteration, and this is the reason why several transformations from recursion to iteration exist (see, e.g., [12, 15, 17] ). Recursion in contrast is known to be more intuitive, reusable and debuggable. Another advantage of recursion shows up in presence of hierarchized memories. In fact, other researchers have obtained both theoretical and experimental results showing significant performance benefits of recursive algorithms on both uniprocessor hierarchies and on shared-memory systems [20] . In particular, Gustavson and Elmroth [4, 10] have demonstrated significant performance benefits from recursive versions of Cholesky and QR factorization, and Gaussian elimination with pivoting.. Recently, a new technique for algorithmic debugging [14] revealed that transforming all iterative loops into recursive methods before starting the debugging session can improve the interaction between the debugger and the programmer, and it can also reduce the granularity of the errors found. In particular, algorithmic debuggers only report buggy methods. Thus, a bug inside a loop is reported as a bug in the whole method that contains the loop, which is sometimes too imprecise. Transforming a loop into a recursive method allows the debugger to identify the recursive method (and thus the loop) as buggy. Hence, we wanted to implement this transformation and integrate it in the Declarative Debugger for Java (DDJ), but, surprisingly, we did not find any available transformation from iterative loops into recursive methods for Java (neither for any other object-oriented language). Therefore, we had to implement it by ourselves and decided to automatize and generalize the transformation to make it publicly available. From the best of our knowledge this is the first transformation for all kinds of iterative loops. Moreover, our transformation handles exceptions and accepts the use of any number of break and continue statements (with or without labels).. One important property of our transformation is that it always produces tail recursive methods [3] . This means that they can be compiled to efficient code because the compiler only needs to keep two activation records in the stack to execute the whole loop [1, 11] . Another important property is that each iteration is always represented with one recursive call. This means that a loop that performs 100 iterations is transformed into a recursive method that performs 100 recursive calls. This equivalence between iterations and recursive calls is very important for some applications such as debugging, and it produces code that is more maintainable.. The objective of this article is twofold. On the one hand, it is a description of a transformation explained in such a way that one can study the transformation of a specific construct (e.g., exceptions) without the need to see how other constructs such as the statement return are transformed. This decomposition of the transformation into independent parts can be very useful for academic purposes. In particular, the paper describes the transformation step by step using different sections to explain the treatment of advanced features such as exception handling and the use of labels. Because we are not aware of any other publicly available description, some parts can help students and beginner programmers to completely understand and exercise the relation between iteration and recursion, while other more advanced parts can be useful for the implementors of the transformation. On the other hand, the proposed transformation has been implemented as a publicly available library. From the best of our knowledge, this is the first automatic transformation for an object-oriented language that is complete (i.e., it accepts the whole language). Example 1.1. Transforming loops to recursion is necessary in many situations (e.g., compilation to functional or logic languages, algorithmic debugging, program understanding, memory hierarchies optimization, etc.). However, the transformation of a loop into an equivalent recursive method is not trivial at all in the general case. For this reason, there exist previous ad-hoc implementations that cannot accept the whole language, or that are even buggy. For instance, the transformation proposed in [7] does not accept exceptions and it crashes in situations like the following:. for (int i = 0; i < 10; i++). for (int j = 0; j < 10; j++) break;. due to a bug in the implementation. Consider the Java code in Algorithm 1 that is not particularly complicated, but shows some of the difficulties that can appear during a transformation. This algorithm contains two nested loops ( while and for). Therefore, it would be normally translated to recursion using three methods, one for the original method example, one for the outer loop loop1, and one for the inner loop loop2. However, the use of exceptions and statements such as break and continue poses restrictions on the implementation of these methods. For instance, observe in line 11 that the control can pass from one loop to the other due to the use of the label loop1. This forces the programmer to implement some mechanism to record the values of all variables shared by both loops and pass the control from one loop to the other when this point is reached. Note also that this change in the control could affect several levels (e.g., if a break is used in a deeper loop). In addition, the use of exceptions imposes additional difficulties. Observe for instance that the inner loop throws an exception Exception1 in line 10. This exception could inherit from IOException and thus it should be captured in method loop2 and passed in some way to method loop1 that loop1:. while (x < 10) { Before we started the implementation of our library, we thought that compiling loops produces more efficient object code than compiling recursive methods. Therefore, we implemented our library not for efficiency reasons, but to gain other advantages of recursion that are useful in many situations such as, e.g., debugging, verification or memory hierarchies optimization.. The lack of an automatic transformation from loops to recursion is surprising, but it is even more surprising that no public report exists that describes how to implement this transformation. Hence, in this article we solve both problems. First, we describe and exemplify the program transformation step by step. Each kind of Java loop, namely while/do/for/foreach, has been described independently with a specific treatment for it that is illustrated with an example of use. Moreover, we provide a complete treatment of exceptions, return, and break and continue statements that can be parameterized with labels. Second, we present an implementation that is:. Complete. It accepts the whole Java language.. Efficient. Both the transformation and the generated code are scalable as demonstrated by our empirical evaluation. The generated code implements all the optimizations and it is tail-recursive. This property is missing in other implementations (e.g., [20] ), and it is important not only for the sake of efficiency. Concretely, an infinite loop can only be translated to equivalent recursive methods if they are tail-recursive. Otherwise, the transformed code would produce a stack memory overflow not occurring in the original code.. Automatic. The transformation only needs to input a source program and it automatically searches for the loops and transforms them. The theoretical relation between iteration and recursion has been studied for decades in different paradigms, with regard to types, with regard to procedures, from a mathematical point of view, from an algorithmic point of view, etc. There is a big amount of work that studies this theoretical relation (see, e.g., [6, 9] ).. On the practical side, there exist many different approaches to transform recursive functions into loops (see, e.g., [12, 15, 17] ). This has been in fact a hot area of research related to compilers optimization and tuning. Contrarily, there are very few approaches devoted to transform loops into equivalent recursive functions. However, recursion provides important advantages in debugging [14] , theorem proving [16] , verification [18] and termination analysis [5] .. For instance, algorithmic debugging is a debugging technique that asks the programmer about the validity of method executions, i.e., an algorithmic debugger can ask the question: object.method(40,2)=42?. If the answer is yes, then the debugger knows that this particular execution of the method was correct. If the answer is no, then the debugger knows that method method or one of the methods invoked during the execution of method is buggy (and it continues asking questions in that direction to find the bug). The final output of the debugger is always a buggy method. This is often very imprecise and forces the programmer to inspect the whole method to find the bug. If we are able to transform all loops into recursive methods, this means that algorithmic debuggers are able to detect bugs inside loops, and report a particular loop as buggy. For this reason, the debugger DDJ implements our transformation from loops to recursion since version 2.6.. In some articles, some transformations are proposed or mentioned for particular kinds of loops. For instance, in [5] a transformation for while-loops is used to detect the termination conditions of the transformed recursive functions. Unfortunately, the other kinds of loops are ignored, but they provide a treatment for the break statement (however they do not allow the use of labels, which is what introduces the complexity in the transformation).. In [20] , authors argue that recursive functions are more efficient than loops in some architectures. In particular, they want to measure the performance benefits of recursive algorithms on multi-level memory hierarchies and on shared memory systems. For that, they define a transformation for do-loops (very similar to the Java's for -loop).. 1 The use of break and continue is not accepted by the transformation.. Myreen and Gordon describe a theorem prover in [18] . In their examples, they include an ad-hoc transformation of a while-loop to an equivalent recursive function. This is done because the recursive function facilitates the verification condition generation and avoids the inclusion of assertions in the source code.. We have not been able to find a description of how to transform some specific loops such as foreach-loop. Moreover, the program transformations that appear in the literature are just mentioned or based on ad-hoc examples; and we are not aware of any transformation that accepts break/continue statements with labels. The use of exceptions has been also ignored in previous implementations. From the best of our knowledge no systematic transformation has been described in the literature yet, thus, researchers and programmers are condemned to reinvent the wheel once and again.. The lack of a systematic program transformation is a source of inefficient implementations. This happens for instance when transforming loops into functions that are not tail-recursive [20] or in implementations that only work for a reduced subset of the languages and produce buggy transformed code in presence of not treated commands such as throws, try-catch, break or continue [7] .. In this work, we also describe our implementation that is the first to accept the whole Java language; and it allows us (in the particular case) to automatically transform a given loop into a set of equivalent recursive methods, or (in the general case) to input a program and output an equivalent program where all loops have been automatically transformed into recursion. This library has been already incorporated in the Declarative Debugger for Java (DDJ) [13] .. Even though we present a transformation for Java, it could be easily adapted to many other languages. The only important restriction is that goto statements are not treated (we discuss their use in Section 6). Moreover, our transformation uses some features of Java:. • it uses blocks to define scopes. Those languages where blocks cannot be defined, or where the scope is not limited by the use of blocks should use fresh variable names in the generated code to avoid variable clashes between the variables of the transformation and the variables of the rest of the program.. • it assumes that, by default, arguments are passed by value. In those languages where the default argument passing mechanism is different, the transformation can be simplified. For instance, with call by value, exceptions need a special treatment described in Section 5. With call by reference, this special treatment can be omitted.

O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O B O B O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A META-TOOL TO SUPPORT THE DEVELOPMENT OF KNOWLEDGE ENGINEERING METHODOLOGIES AND PROJECTS Knowledge-based systems (KBSs) or expert systems (ESs) are able to solve problems generally through the application of knowledge representing a domain and a set of inference rules. In knowledge engineering (KE), the use of KBSs in the real world, three principal disadvantages have been encountered. First, the knowledge acquisition process has a very high cost in terms of money and time. Second, processing information provided by experts is often difficult and tedious. Third, the establishment of mark times associated with each project phase is difficult due to the complexity described in the previous two points. In response to these obstacles, many methodologies have been developed, most of which including a tool to support the application of the given methodology. Nevertheless, there are advantages and disadvantages inherent in KE methodologies, as well. For instance, particular phases or components of certain methodologies seem to be better equipped than others to respond to a given problem. However, since KE tools currently available support just one methodology, the joint use of these most apt phases or components from different methodologies for the solution of a particular problem is hindered. This paper presents KEManager, a generic metatool that facilitates the definition and combined application of phases or components from different methodologies. Although other methodologies could be defined and combined in the KEManager, this paper focuses on the combination of two well-known KE methodologies, CommonKADS and IDEAL, together with the most commonly-applied knowledge acquisition methods. The result is an example of the ad hoc creation of a new methodology from pre-existing methodologies, allowing for the adaptation of the KE process to an organization or domain-specific characteristics. The tool was evaluated by students at Carlos III University of Madrid (Spain). The purpose of knowledge engineering (KE) is to design and implement computer systems known as knowledge-based systems (KBSs) or expert systems (ESs). KBSs and ESs solve problems through the representation and manipulation of knowledge in different ways, such as with frames, inference rules, or scripts. The basic structure of these kinds of systems is composed of an ontology, that is, a static representation of the world. An ontology was defined by Gruber [1] as "a specification of a conceptualization" and, generally speaking, is a representation of the elements, or concepts, of the world, together with the attributes that define it and the relationships between them. The other common element of KBSs is a set of inference knowledge, or rules, representing how to solve problems defined in this world. In KBSs, ontologies are considered to be the static (i.e., invariant) part, while inference rules represent the dynamic part. The definition of both components is achieved through a process whereby knowledge from different sources is acquired and modeled. The main source used consists of human experts with the knowledge necessary to solve domain problems in a near-optimal manner. It is the work of a knowledge engineer to extract, model, and represent knowledge in a software tool able to solve problems in a specified domain (i.e., KBSs) and, additionally, demonstrate an effectiveness similar to that of a human expert solving the same problems (i.e., ESs).. In this context, the paradox of expertise arises as one of the most important drawbacks in the implementation of KBSs. This paradox means that the more expertise a human expert has in a certain domain, the more difficult it is for the expert to explain how he solves domain problems [27] . In addition, while knowledge engineers are assumed to be rather good at modeling and representing knowledge, they do not necessarily have to be domain experts. Rather, they must only acquire relevant knowledge from domain experts. This knowledge acquisition plays a central role in KE since it is:. • Present in the whole life cycle of a KBS project.. • Very costly in terms of time and money.. • Difficult and tedious.. The integration of knowledge acquisition, conceptualization, and formalization with the classical methodological phases of any software (i.e., analysis, design, implementation, and evaluation) has led to the production of several KE methodologies, as summarized in Section 2. Attached to the majority of these methodologies is a support tool, facilitating the application of the methodology (or at least parts of it) and the corresponding development of the KBS. However, the application of a particular methodology or tool constrains the potential development of a KBS, since good elements from other methodologies and tools must be discarded [2] .. This drawback of having to select a particular methodology and discard all others may be avoided with a generic meta-tool, allowing for the combination of parts of different methodologies. As demonstrated in this paper, the Knowledge Engineering A new generic tool to support the development of knowledge engineering projects 3. Manager (KEManager) allows the user to create ad-hoc combined methodologies for the design and development of KBSs.. Preliminary research conducted focused on how to build a generic KE metatool, taking into account the most common methodological phases, pre-existing tools, and a requirements specification. The conclusions of this analysis, similar to those reached in an earlier study [8] , outlined how the meta-tool could cover any methodology, as well as the usability, friendliness, and effectiveness required. With these conclusions, an informal set of requirements and a high-level design of the intended KEManager architecture were proposed. Implementation of the generic meta-tool directly folowed (see Section 5 figures).. The final step in the research conducted involved the development of a use case and the administration of a user evaluation. While any methodologies could have been chosen to demonstrate the usefulness of their combination under a single support tool, CommonKADS [4] and IDEAL [5] [6] [7] were selected here, focusing particularly on the integration in an ad hoc methodology of IDEAL problem identification and CommonKADS conceptualization. As both IDEAL and CommonKADS methodologies are taught by the study authors in their courses at Carlos III University of Madrid (UC3M), their selection permitted an evaluation of KEManager by select UC3M students.. Since the first prototype became available in 2008, KEManager has been used by students at UC3M and the Universidad Nacional de Educación a Distancia (UNED). At the former institution, KEManager has been used as part of a fourth-year undergraduate course in the Computer Science and Engineering degree program. A set of polls and questionnaires were distributed to the students in order to obtain feedback about errors, potential improvements, general user satisfaction, as well as other considerations related to the KEManager. This data set indicates the degree of effectiveness achieved by the tool and points the way to future improvements and modifications to be made.. The remainder of this paper is divided as follows. In Section 2, related work is discussed. Section 3 offers traditional definitions for common methodological phases, as well as a brief look at currently-existing KE tools. Section 4 informally lists software requirements and indicates the high-level architecture of the KEManager. Section 5 explains the implementation and principal features of the meta-tool. Section 6 presents KEManager results in the use case with IDEAL and CommonKADS, obtained from evaluations conducted by UC3M students during the course of two academic years. Finally, Section 7 draws conclusions from study and evaluation findings and discusses areas for future research. Results and analysis from this study show that the definition of a new methodology from a combination of different, pre-existing KE methodologies is possible through the application of the KEManager meta-tool. The meta-tool was created following the determination that the current state of the art for KE tools did not permit this possibility. The KE methodologies used here were those taught at the UC3M. The principal contributions of this study may be summarized as the following:. • A brief analysis of KE and the most important tools currently used with A new generic tool to support the development of knowledge engineering projects 27 it.. • A comprehensive description of the features of KEManager, the generic meta-tool developed here, which the user may define and use with different parts of any methodology's phases, and which includes several methods for the identification of a problem and the acquisition and modeling of knowledge.. • Results from student evaluations of KEManager performance in class projects offer valuable feedback about meta-tool weaknesses and suggestions about how these weaknesses may be eliminated.. Although the meta-tool possesses a particular strength (i.e., the ability to define and use a combined methodology with a good degree of completeness) not present in any other currently existing tool, student questionnaire responses we consider that it still has some indicate that meta-tool functionality could be increased even further with the elimination of particular weaknesses. The quality of the interaction between the meta-tool and user was identified by students as the greatest weakness to be addressed.. The methodology combined by the students integrates the problem identification evaluation method and knowledge acquisition techniques suggested by the authors of IDEAL, and the knowledge and communication models produced by the conceptualization phase of CommonKADS. While the combination used here was easy to execute, other combinations could be more complex and, therefore, produce interesting problems to solve in future studies. That said, as KEManager was defined to function as a generic tool that could combine any KE methodology, and in order to facilitate student comprehension of the two particular methodologies, no ad hoc features from IDEAL or CommonKADS were included in the GUI.. The questionnaire results considered here indicate not only the strengths and weaknesses of KEManager as a tool, but they also hint as how student evaluators felt about the problem identification and conceptualization phases, themselves. While it is not possible to obtain quantitative measurements about how the particular combined methodology phases facilitated the KE process, future studies could, as mentioned in the introduction, use KEManager with different methodological combinations, comparing and contrasting them with user evaluations (as done for the single combination defined from IDEAL and CommonKADS). A further benefit offered by KEManager that may be exploited in the future is its ability to facilitate the indirect comparison of the relative strengths of certain parts of a methodology over others (although subjectively with user surveys).. While all minor technical problems reported by students have since been fixed, the current meta-tool may be improved/extended in four principal ways. Firstly, student questionnaires can be redesigned in order to obtain higher quality student feedback. The second way is related to how the tool is extended. One question that frequently arose during the implementation of the tool was whether KE phases and knowledge acquisition techniques could be defined as a composition of services, understood as the small functionality of the tool covering the GUI, model representation, and printing, rather than of methodologies. In other words, then, an extensible framework could be made with a finer granularity than a KE methodology. Thirdly, many other combinations of pre-existing KE methodologies can be developed in order to determine whether KEManager is generic enough to include them. Fourth and finally, the way the use of a combined KE methodology is evaluated (e.g., time taken, student final grades, or project size) could be automated, such that the contribution of KEManager to respond to KE difficulties could be appreciated more objectively.. In closing, this study has introduced a new meta-tool which presents an entirely unique strength: the ability to define and use combinations of KE methodologies. It is the authors' hope that the study prompts researchers and developers to view KE methodologies in a different light. While KEManager has, until now, been used exclusively for academic purposes at the UC3M and UNED, feedback on the use of KEManager in the industry would be welcome. In order to promote the free use of the tool (including its extension) not only for academic purposes, the software has been released on SourceForge and a website dedicated to the tool will also be launched. A methodology is defined as a set of steps or phases for the achievement of an objective. In other words, "a methodology describes how a project is organized, the order in which the tasks are executed and the interfaces defined between them" [9] .. In the context of KE, a methodology can be defined as a set of techniques, procedures, and tools to acquire, represent, implement, validate, integrate, and maintain the knowledge inside in an ES. There are several methodologies defined to work in KE that come from traditional software engineering methodologies [3] . Originally, methodologies were based on prototyping, an encode and repair approach. Later, methodologies had cascade life cycles in which the input of each phase is the output of the previous phase. With such a methodology, when errors are detected, it is possible for them to be fixed in previous phases without starting from scratch. Nevertheless, all requirements must be defined at the beginning of the project, something that is not possible with KE. Another alternative used is the spiral life cycle. In it, all phases are repeated to generate intermediate products that are evaluated to define new requirements, evaluate costs, and select the best alternative for the following cycle. In IDEAL [5] [6] [7] , an extension of this approach known as conical, or 3D spiral, life cycle is represented, allowing the definition of new requirements when the system is deployed. Table 1 presents the chronological development of these methodologies. One of the first implementations of a tool for KE was KEDE [18] , developed with Common Lisp using different knowledge representation formalisms (KRFs) with the aim of increasing the number of solvable problems for a KBS produced with the tool. In a study by Huneault [19] , different KE tools are described and classification criteria, from the KRF used (mainly rule-based and object-oriented) to the estimated building cost of a KBS in certain environments (mainly power plants), are introduced. The high cost of building KBSs and the losses in quality and productivity observed, mainly due to the subjective selection of tools and rep-A new generic tool to support the development of knowledge engineering projects 5 resentations, brought attention to the need for a structured method for the building and integration of knowledge modeling in KBSs.. A study performed on nuclear power plants [20] shows the importance of knowledge acquisition and the verification and validation of the resulting knowledge base to produce reliable KBSs through the implementation of a knowledge acquisition tool. Additionally, ontologies have been gaining importance [21] in the representation of knowledge bases inside KBSs.. Focusing on the graphical user interface (GUI), the acquisition tool, Protégé [22] , presents the concept of a component or plug-in to extend and adapt the tool such that it may be more effective with a greater diversity of problems and domains. The knowledge acquisition process has also been applied in other AI disciplines such as automated planning [23] through a graphical tool designed for the acquisition, validation, and maintenance of planning domain models.. Tagger [24] is a real-time tool allowing the user to define tags at different levels of abstraction during a knowledge acquisition session. The authors give a more specific description of the knowledge acquisition bottleneck mentioned in the introduction and stress the importance of the knowledge acquisition session in itself, in addition to the further processing.. In Chan [25] , the design and implementation of a software tool based on the inferential modeling acquisition technique is demonstrated for the construction of ontologies in an application domain. The study emphasizes the importance of acquired knowledge reusability in order to solve different problems in the same domain, thereby alleviating part of the knowledge acquisition bottleneck. XML is also proposed as a way to import and export information to and from the tool.. The Knowledge Engineering Suite [26] is a tool for working with ontologies in the Semantic Web. One of the Suite's principal features of interest is that it permits several knowledge engineers and experts to work at the same time.. All tools reviewed above cover particular phases of the KE process or are designed to work in given domains. It is the objective of the present study to allow for the integration of the advantages offered by these tools through the design of a meta-tool capable of suporting several KE methodologies and adaptable to different domains.. Considering the problems that the previously-cited authors had set out to resolve and the choices made to develop the corresponding tools to work in KE, this study is justified for the for basic improvements it proposes for KE: (1) a more effective knowledge acquisition process, (2) a more proper way of representing, managing, and reusing knowledge, (3) a mechanism to improve, adapt, and extend previouslydiscussed issues, and (4) a more effective interaction between the system and the user (i.e., GUI). The overarching goal of the study is the development of a metatool (i.e., generic framework) that works in KE and in which the user may combine methodologies, acquisition techniques, and representation formalisms together with a proper way to interact with these through a well-defined and accessible GUI. The present section attempts to determine the essential features that must be implemented by a software tool such that the majority of KE methodologies are addressed. In addition, we describe some of the available tools. In this section, the two-step development process for the meta-tool is described. In the first step of the process, the framework and common elements of the system were implemented. Included among these common elements were the main window of the GUI, the external tools providing specific functionalities, and all base classes required for the definition of plug-ins with new methodologies, phases, knowledge acquisition techniques, and graphic diagram elements. Figure 7 shows the main window of the system. The main element defined inside the meta-tool is the KE project. A project is a representation of all information gathered with all tasks done, all diagrams defined, and other additional information, depending on the particular KE methodology. When the user creates a new project, it is necessary to specify the KE methodology to be used. This selection determines the phases with which the user will work. Whatever the choice, however, the user may access all knowledge acquisition techniques implemented. As explained in the introduction, the knowledge acquisition phase is shared by all methodologies and present (with a particular degree of importance) throughout the entire life cycle of the project. Figures 8 and 9 show the form implemented to work with a KE phase and knowledge acquisition technique. In both examples, the information presented in the GUI is grouped into tabs. Each tab is related to a specific step in the knowledge acquisition technique or phase.. Every phase or knowledge acquisition technique may have graphic diagrams. For instance, Figure 10 presents an example of a diagram with an evaluation task specified in the CommonKADS methodology.. The second step in the meta-tool implementation involved the specification of the KE methodologies, knowledge acquisition techniques, and diagrams palette. As explained in Section 2, the KE methodologies currently specified in the meta-tool are IDEAL and CommonKADS. The diagrams defined were those required to work with both KE methodologies together (with principal components in UML). The knowledge acquisition techniques implemented were the following:. • Knowledge extraction from texts (see Figure 11 ).. • Open interview (see Figure 12 ).. • Structured interview (see Figure 13 ).. • Triadic method (see Figure 14) .. • Grid (see Figure 15 ).. All knowledge acquisition techniques share the same tabs, save the one implementing the acquisition session. In knowledge extraction, the GUI allows the user to specify different text sources and analyze the texts used. The open interview session was modeled as a tree of general questions in which an initial set of questions was defined. Other questions derived from this set may be considered following the response given by the expert. In the structured interview, the session was modeled as a set of short questions grouped according to the objective pursued by each. The triadic method shows a list of objects and a table of three elements selected, together with an explanation of why two of these elements were grouped together and the third kept separate. Finally, the grid illustrates a way to create a grid session by specifying the objects and attributes, and setting different values for each pair.. All other tabs are common to the knowledge acquisition techniques implemented and allow the user to acquire, model, and represent the knowledge specified during the session; for example, defining new concepts and terms, creating diagrams, and specifying rules. In order to cover the conceptualization phase specification in CML2, the CML2Editor, a previously-released tool (and CS senior project of David García, supervised by study author Javier Carbó) for the editing and syntactical analysis of files in CML2 was included in the meta-tool. Following the completion of the framework implementation, the following functionalities were achieved:. • A fully operative tool allowing the definition of KE methodologies, acquisition techniques and diagram representations through plug-ins.. • A complete easy-to-use GUI for interaction with the user.. • An easy way to manage KE projects, regardless of the methodology selected.. • Multilingual support.. The meta-tool described here is publically available on SourceForge [32] . It can be downloaded, evaluated, and used without restrictions. Once made public, the metatool was distributed among KE students at UC3M in order to test its effectiveness and receive feedback. This feedback allowed the authors to further evaluate and improve the meta-tool. The following section presents and discusses the evaluation results obtained.

O O O O O O O B I O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O B O O O B O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


A Storage-Efficient Suffix Tree Construction Algorithm for Human Genome Sequences The suffix tree is one of most widely adopted indexes in the application of genome sequence alignment. Although it supports very fast alignment, it has a couple of shortcomings, such as a very long construction time and a very large volume size. Loh et al. [7] proposed a suffix tree construction algorithm with dramatically improved performance; however, the size still remains as a challenging problem. We propose an algorithm by extending the one by Loh et al. to reduce the suffix tree size. As a result of our experiments, our algorithm constructed a suffix tree of approximately 60% of the size within almost the same time period. Since human DNA sequences were announced as the product of the Human Genome Project (HGP), a lot of research activities are under way for practical application of the sequences. One of them is aligning short genome subsequences of 100 ∼ 1000 length to the human genome sequences [3] - [5] . This application is getting more attention along with the recent advances in DNA sequencing technology * * * . For fast alignment, it is essential to use efficient indexes; the suffix tree, suffix array, and compressed suffix array are the most widely adopted [1] - [5] .. The suffix tree supports very fast alignment and can also be used in many other applications such as finding frequent subsequences, common subsequences, and maximal palindromes [3] , [8] , [9] . However, it has a couple of shortcomings; it requires a very long time to construct and also occupies a large volume size [6] , [8] . Loh et al. [7] proposed a suffix tree construction algorithm to cope with the first shortcoming. The algorithm dramatically reduced the construction time by making the most of recent multi-core CPUs and minimizing disk access costs.. In this paper, we propose a suffix tree construction algorithm, which is an extension of the one by Loh et al. [7] , for coping with the second shortcoming of the suffix tree. Since it is impossible to reduce the number of nodes in the suffix tree for a given sequence, our approach reduces the storage size of the suffix tree nodes. As a result of our experiments, compared with the one by Loh et al. [7] , our algorithm constructed a suffix tree of approximately 60% of the size within almost the same time period. Figure 1 shows the suffix tree for a genome sequence X = ATAGCTAGATCG$ [7] . The symbol '$' is attached at the end of X to prevent any suffix from being the prefix of any other suffixes and hence to enable the efficient processing of suffixes. A genome sequence X = x 0 x 1 . . . x n−1 $ of length n contains n suffixes. The suffix tree for X should have n terminal nodes; they have one-toone correspondence with the suffixes and contain the positions of the corresponding suffixes. For instance, by searching for a suffix S = AGATCG$ using the suffix tree in Fig. 1 , we go through internal nodes N 1 and N 11 and then reach the terminal node 6, which indicates that the suffix S is located at position 6 in X. In this section, we first briefly introduce the suffix tree construction algorithm by Loh et al. [7] , which we call the FAST algorithm in this paper. FAST is based on a 'divide-andconquer' strategy and divides all the suffixes in the genome sequences into multiple partitions. For a pre-specified prefix Fig. 2 Node data structure of the FAST algorithm: Information on the inbound edge is contained together [7] . length p, each partition is composed of the suffixes with the same prefix of length p, and hence there are 4 p partitions. FAST constructs the suffix subtree for each partition. Since the suffixes with different prefixes cannot be inserted in the same suffix subtree, the construction of a suffix subtree for each partition can be performed separately from the others. FAST assigns the construction of different suffix subtrees to different processes. The recent design trend of CPUs not only raises their clock speeds but also builds multiple independent cores in a single CPU to enable intra-CPU parallel processing. By using a multi-core CPU, the processes launched by FAST are executed in parallel by different cores, and therefore the performance of suffix tree construction is significantly improved.. Moreover, FAST almost eliminates random disk accesses, which were the major cause of performance degradation of the previous disk-based suffix tree construction algorithms [1] , [3] , [8] , [9] . In general, even when accessing the same amount of disk volume, the performance greatly depends on disk access patterns; sequential access can improve the performance more than hundred times compared to random access. FAST constructs the suffix subtree for each partition in a contiguous memory chunk and then stores the chunk sequentially in disk † . This helps to minimize the disk access costs and hence the performance is dramatically improved. Figure 2 shows the node data structure of the suffix tree constructed by FAST. Fields a and b (a ≤ b) indicate the start and end positions of the inbound edge label. For instance, the inbound edge label of terminal node 6 in Fig. 1 is found at position (8, 12) in X, and hence the field values are a = 8 and b = 12. The field right stores the pointer to the next sibling node; the pointer is not a physical memory address but a relative offset from the start of the memory chunk in which the suffix subtree is constructed. By using such pointers, even when the suffix subtree is saved on disk and then reloaded into a different position in memory, there is no need to adjust the pointers. The field foo indicates a pointer to the leftmost child node in an internal node or the position of the corresponding suffix in a terminal node. The field sub indicates the number of the chromosome referenced for processing the node. The human genome sequences are composed of 22 chromosome pairs (numbered 1 ∼ 22) and x/y (sex) chromosomes (46 in total). Chromosome 1, which is the largest, spans about 247 million base pairs.. Hunt et al. [3] proposed the first algorithm to construct the suffix tree for human genome sequences. Since then, a few more algorithms with improved performance were proposed [1] , [8] , [9] . Since the suffix tree for human genome sequences has a very large volume size, these algorithms construct disk-based suffix trees. The common shortcomings of these algorithms are that they cannot fully utilize the recent multi-core CPUs and incur random disk accesses. FAST tackled these shortcomings and achieved a dramatic performance improvement; however, there was no improvement in the storage size of the suffix tree by FAST.

O B I I O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


How much of the global information and communication explosion is driven by more, and how much by better technology? Technological change in the digital age is a combination of both, more and better technology. The article quantifies how much of the technologically-mediated information and communication explosion during the period of digitization (1986 -2007) was driven by the deployment of additional technological devices, and how much by technological progress in hardware and software. We find that technological progress has contributed between two to six times more than additional technological infrastructure. While infrastructure seems to reach a certain level of saturation at roughly 20 storage devices per capita and 2-3 telecommunication subscriptions per capita, informational capacities are still exploding. Besides progress in better hardware, software for information compression turns out to be an important and often neglected driver of the global growth of technologically mediated information and communication capacities. A decomposition of technological change in the digital age shows that the world's technological capacity to store, communicate and compute information has mainly been driven by better, and not merely more technology. The only exception to this trend is broadcasting, which was hardly digitized during the period of the study (only 25 % of broadcasted information was digitized in 2007). Our approach includes progress in software compression and it shoes that software compression rates play an important and often neglected role when quantifying informational capacities, especially during periods of digitization.. On the one hand, this finding is of methodological interest and stresses the importance of normalizing information capacities on justifiable compression rates (see Hilbert and López, 2012b) . On the other hand, it is also of practical relevance, because the vast majority of digital policies are based on mere proxies of our informational capacities, such as on statistics of the number of technological devices and subscriptions (Hilbert, 2011; ITU, 2012, Ch.5; Hilbert, 2013) . We have seen that the amount of technological devices and subscriptions are increasingly playing a secondary role in the digital age. This implies that the basic roll-out of the technological infrastructure of the global "Network Society" (Castells, 2009) has reached a certain level of saturation, while the capacity on basis of this fundamental infrastructure is continuously advancing. Despite stagnating stocks of devices and subscriptions, we continue to expand our technological information, communication, and computation capacities through incessant technological progress. This implies that any quantitative assessment of the digital age requires an accounting that goes beyond the traditional inventory of technological devices and subscriptions, and captures informational capacities in terms of both more and better technologies (see e.g. Hilbert, 2013) . 1986-1993; 1993-2000; 2000-2007 (percentage points) of the drivers of storage (in optimally compressed MB); broadcasting and telecom (in optimally compressed Mbps); and computation (in MIPS) according to equation (2)

O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O