OpenAI

Software Requirements Specification

History

Vision

• a specification for Artificial Intelligence (hereafter referred to as AI) core technologies that will allow interoperability, intercommunication and ease of integration.
• a reference implementation that will consist of Artificial Intelligence utilities or libraries that will illustrate how to implement the specification.

Scope

Please keep in mind that this is an evolving document being developed in a distributed environment. As such it will have notes strewn about and conversational pieces interjected with specification pieces. Your constructive feedback is welcome. Please email gleo with any suggestions or comments.

Level 1

Overview

1.1 Communication

Deprecated
Communication between any module was previously required. However, this complicates the module unnecessarily by requiring a communications framework to be included. This item is now removed from the Level 1 specification and will be addressed by a suite of module-to-module interfaces within the reference implementation. This will preserve the orginal intent by allowing the modules to transfer data and control aspects of another modules operation. These abilities will manifest themselves through the use of the rest of this specification.

1.2 Configuration

To allow a module to be dynamic, it must be able to be configured at any moment. This will allow the characteristics of the modules' operation to be dynamically changed in order to adapt to new situations and data streams. Each module should be able to load it's configuration from a file and be ready to begin operation utilizing the new configuration.

1.3 Description

One of the key goals of OpenAI is to provide compatibility between AI modules. To that end, modules should be able to gather information regarding what version and level of the OpenAI specificaton is supported by the module in question. All modules will provide a way to access this information by returning a string of the form "OpenAI Specification Level 1, revision date YYYY/MM/DD"

1.4 Control

1.4.1

To allow the modules to be easily embedded within an application, and to provide a familiar interface to all modules, a specification on controlling the modules is necessary. At a high level, any application using a module should not need to know the type of the module it is controlling. Common functions like start, stop, iterate, etc. should be exposed to other programs to allow control of the module externally. These controlling applications should be able to send commands and access data for any module in the same manner.

1.4.2

It will often be necessary for applications to gain full knowledge of a modules API in order to make specific calls. The full API of each module should be available to an application. By querying a module, an application should be able to get a location to the full API.

1.4.3

It is necessary for the modules to be "well behaved". By this we mean unintrusive to the normal operating environment of the host computer. Any module using sockets should use ports allocated for application use by the IEEE. A module should allow limits to be set on it's usage of the CPU and memory of the host computer.

1.5 Scalability

1.5.1

Significant attention should be paid to the scalability of the modules. They should function in Parallel and Distributed environments. (this may be a separate specification down the road)

1.5.2

If the system is run in a distributed fashion, it will be necessary for applications and other modules to query for existing available modules. A central manager or preferably a networked directory of modules that can cascade updates (similar to DNS) should be in place.

1.6 Persistence and Observation

Each module should be able to save its full state at any moment for persistence and mobility as well as providing insight into the current state of the module for observation and representation (possibly in a graphical manner). To this end, a state engine should be provided that allows multiple levels of description concerning the internal state. The highest level will equal persistence and the full internal state of the module, the intermediate levels will be for different observation tools and the lowest level would be for runtime output.

1.7 Internationalization

Modules should be internationlised. They need to conform to the local language, locales, currencies etc, according to the settings specified in the configuration file or the environment in which they are running in.
Last modified: Tue Jul 17 20:02:23 EDT 2001