Network API Requirements & Architecture

Network API Requirements & Architecture

This document describes essential goals and structural elements required for the Java version of the Network API for NuPIC (Numenta Platform for Intelligent Computing). It is offered as an open outline for discussion and "whiteboard" for illustrating the resolutions decided upon by the participating audience - as well as a final description of the product to be delivered.

Background

A "Network" in this context is a collection of wrapper elements (Node?) which contain discrete HTM components (i.e. SpatialPooler; TemporalMemory) and allow the assembly of these components in such a way where input can be submitted at one end, and output can be extracted at the other. It is a means of manipulating, monitoring and configuring the flow of information through each element as well as its persistence and reification. The term "API" signifies that this work is a developer level interface and intended for a more "knowledgeable" user base as a means of integration into a larger platform or application.

Scope & Purpose

As part of the effort to provide NuPIC functionality in the Java™ language, there is a clear need for a "Network" level interface to the NuPIC algorithmic components. The intention of the Network is to make it easier to fully describe an assembly of algorithmic components; specify their configuration details; execute a process flow and monitor its behavior and state. It should also provide a clear and easy means of integration into the end-user's application. Additionally, it should not exemplify any "personality" of its own, and should intuitively meet the developer's expectations and should transparently and easily be queried for the applicable parts of its internal state. Stated in itemized form (Excerpted from Python Architectural Document):

1. Provide all essential functionality for using HTM Networks, but no more. Any additional functionality is to be provided by end-user libraries.
2. Excellent performance - The Network Engine should add negligible overhead.
3. Easy to understand and use. The API should be consistent and easy to learn; it should not use fancy or obscure language features.
4. Clean architecture and transparent behavior.
5. Easy to add support for new algorithms - (Modular architecture for algorithms; should isolate algorithm developers from needing to know much about Network Engine internals)