Artificial intelligence systems integration
The core idea of Artificial Intelligence systems integration is making individual software components, such as speech synthesizers, interoperable with other components, such as common sense knowledgebases, in order to create larger, broader and more capable A.I. systems. The main methods that have been proposed for integration are message routing, or communication protocols that the software components use to communicate with each other, often through a middleware blackboard system. Most artificial intelligence systems involve some sort of integrated technologies, for example, the integration of speech synthesis technologies with that of speech recognition. However, in recent years there  has been an increasing discussion on the importance of systems integration as a field in its own right. Proponents of this approach are researchers such as Marvin Minsky, Aaron Sloman, Deb Roy, Kristinn R. Thórisson and Michael A. Arbib. A reason for the recent attention A.I. integration is attracting is that there have already been created a number of (relatively) simple A.I. systems for specific problem domains (such as computer vision, speech synthesis, etc.), and that integrating what's already available is a more logical approach to broader A.I. than building monolithic systems from scratch. Why integration? The focus on  systems integration, especially with regard to modular approaches, derive from the fact that most intelligences of significant scales are composed of a multitude of processes and/or utilize multi-modal input and output. For example, a humanoid-type of intelligence would preferably have to be able to talk using speech synthesis, hear using speech recognition, understand using a logical (or some other undefined) mechanism, and so forth. In order to produce artificially intelligent software of broader intelligence, integration of these modalities is necessary. Challenges & solutions. Collaboration is an integral part of software development as evidenced by the size of software companies  and the size of their software departments. Among the tools to ease software collaboration are various procedures and standards that developers can follow to ensure quality, reliability and that their software is compatible with software created by others (such as W3C standards for webpage development). However, collaboration in fields of A.I. has been lacking, for the most part not seen outside of the respected schools, departments or research institutes (and sometimes not within them either). This presents practitioners of A.I. systems integration with a substantial problem and often causes A.I. researchers to have to 're-invent the wheel' each time  they want a specific functionality to work with their software. Even more damaging is the "not invented here" syndrome, which manifests itself in a strong reluctance of A.I. researchers to build on the work of others. The outcome of this in A.I. is a large set of "solution islands": A.I. research has produced numerous isolated software components and mechanisms that deal with various parts of intelligence separately. To take some examples: With the increased popularity of the free software movement, a lot of the software being created, including A.I. systems, is available for public exploit. The next natural step is  to merge these individual software components into coherent, intelligent systems of a broader nature. As a multitude of components (that often serve the same purpose) have already been created by the community, the most accessible way of integration is giving each of these components an easy way to communicate with each other. By doing so, each component by itself becomes a module which can then be tried in various settings and configurations of larger architectures. Many online communities for A.I. developers exist where tutorials, examples, and forums aim at helping both beginners and experts build intelligent systems (for example the  AI Depot, Generation 5). However, few communities have succeeded in making a certain standard or a code of conduct popular to allow the large collection of miscellaneous systems to be integrated with any ease. Recently, however, there have been focused attempts at producing standards for A.I. research collaboration, Mindmakers.org is an online community specifically created to harbor collaboration in the development of A.I. systems. The community has proposed the OpenAIR message and routing protocol for communication between software components, making it easier for individual developers to make modules instantly integrateble into other peoples' projects. Methodologies. Constructionist Design Methodology. The Constructionist  design methodology (CDM, or 'Constructionist A.I.') is a formal methodology proposed in 2004, for use in the development of cognitive robotics, communicative humanoids and broad AI systems. The creation of such systems requires the integration of a large number of functionalities that must be carefully coordinated to achieve coherent system behavior. CDM is based on iterative design steps that lead to the creation of a network of named interacting modules, communicating via explicitly typed streams and discrete messages. The OpenAIR message protocol (see below) was inspired by the CDM and has frequently been used to aid in the development of  intelligent systems using CDM. One of the first projects to use CDM was Mirage, an embodied, graphical agent visualized through augmented reality which could communicate with human users and talk about objects present in the user's physical room. Mirage was created by Kristinn R. Thórisson, the creator of CDM, and a number of students at Columbia University in 2004. The methodology is actively being developed at Reykjavik University. Tools. OpenAIR Protocol. OpenAIR is a message routing and communication protocol for integrating artificial intelligence systems. The protocol is managed by Mindmakers.org, and is described on their site in the following  manner: ""OpenAIR is a routing and communication protocol based on a publish-subscribe architecture. It is intended to be the "glue" that allows numerous A.I. researchers to share code more effectively — "AIR to share". It is a definition or a blueprint of the "post office and mail delivery system" for distributed multi-module systems. OpenAIR provides a core foundation upon which subsequent markup languages and semantics can be based, e.g. gesture recognition and generation, computer vision, hardware-software interfacing, etc.; for a recent example see CVML"." OpenAIR was created to allow software components that serve their own purpose to communicate  with each other to produce large scale, overall behavior of intelligent systems. A simple example would be to have a speech recognition system, and a speech synthesizer communicate with an expert system through OpenAIR messages, to create a system that can hear and answer various questions through spoken dialogue. CORBA (see below) is an older but similar architecture that can be used for comparison, but OpenAIR was specifically created for A.I. research, while CORBA is a more general standard. The OpenAIR protocol has been used for collaboration on a number of A.I. systems, a list can be found on the  Mindmakers project pages . Psyclone is a popular platform to pair with the OpenAIR protocol (see below). Psyclone AIOS. Psyclone is a software platform, or an AI operating system (AIOS), developed by Communicative Machines Laboratories for use in creating large, multi-modal A.I. systems. The system is an implementation of a blackboard system that supports the OpenAIR message protocol. Psyclone is available for free for non-commercial purposes and has therefore often been used by research institutes on low budgets and novice A.I. developers. Elvin. Elvin is a content-based router with a central routing station, similar to the Psyclone AIOS  (see above). OAA. The OOA is a hybrid architecture that relies on a special inter-agent communication language (ICL) – a logic-based declarative language that is good for expressing high-level, complex tasks and natural language expressions. CORBA. The Common Object Request Broker Architecture (CORBA) is a standard that enables software components written in multiple computer languages and running on multiple computers to interoperate. CORBA is defined by the Object Management Group (OMG). CORBA follows similar principles as the OpenAIR protocol (see above), and can be used for A.I. systems integration. MOSID. The Messaging Open Service Interface Definition (OSID) is  an O.K.I. specification which provides a means of sending, subscribing and receiving messages. OSIDs are programmatic interfaces which comprise a Service Oriented Architecture for designing and building reusable and interoperable software.