Core Communication Modules
The language and action modules are bridged by shared action protocols we call n-tuples. Both the Problem Solver and Specializer have access to n-tuple templates, which are JSON structures oriented towards particular tasks, action, and information retrieval. The Specializer uses information from the SemSpec to fill in a template; the filled-in template is called an n-tuple. This is then transported over a network to the Problem Solver.
See the Transport documentation for more information.
The Core Agent defines a class that has the ability to send and receive n-tuples. Both the Core UI-Agent and the Core Problem Solver subclass the Core Agent.
A Core Agent is designed to be easy to initialize. The only required argument is the desired name of the channel, e.g.:
python core_agent.py Agent1
The above command would create a CoreAgent with a channel name of "Agent1". All CoreAgents have a Transport object as a field attribute, as well as:
- Name ("Agent1")
- Federation (by default, this is set to "FED1")
- Address (the concatenation of a federation and a name, such as "FED1_Agent1")
The federation is an important attribute, since it helps avoid potential name collisions, in the event of running multiple same-named agents on the same network. The federation can be set with an environment variable, e.g.:
export $ECG_FED=FED1
Optionally, the user can also designate a log-file and a log-level, in which to log errors or messages.
read_templates(self, filename)
This method reads in a JSON file from the given filename, and returns an OrderedDict of templates. Since a user can specify an inheritance hierarchy for templates, this method also updates a "child" with the key/value pairs of its "parent", unless a particular key/value pair is overridden. If a specified parent does not exist, the method raises a TemplateException, which should cause the program to quit (as this is almost certainly an error).
Whenever a CoreAgent subscribes to a particular channel, it passes in a callback method, which is called whenever the CoreAgent receives an n-tuple from that channel name. The CoreAgent defines a simple callback method, which just prints out the received n-tuple. Both the UI-Agent and Problem Solver override this callback method as part of their default behavior. Additional callbacks can be written for different purposes, and to subscribe to different channels.
N-tuple templates serve two primary functions in our system:
- Declarative instructions: While building an n-tuple, the templates act as declarative specifications for which aspects of the Semantic Specification the Core Specializer should extract, and give instructions on how the output should be formatted.
- Shared semantics: Templates are oriented towards particular tasks, and are shared between the Specializer and Problem Solver, which establishes a shared vocabulary and semantics between a human user and a robot agent (or other task).
These are high level templates (file), which map the “mood” of a SemSpec onto a given template. The mood corresponds to a given predicate_type.
For example, a Yes/No question like "is the green box near the blue box?" will match to the "yn_question" template.
These are also high level templates (file), which correspond roughly to the Event-Descriptor schemas in ECG. They include event-features (such as modality information like “can”, temporal information like duration and telicity, and whether or not an event is negated), as well as other embedded templates, which are either Parameter Templates, Descriptor Templates, or more event templates. For example, a conditional command like “Robot1, if the box near the green box is red, push it south, otherwise push it north!” would correspond to the conditional EventDescriptor template
The portions of the sentence would map roughly as follows:
condition: {the box near the green box is red}
conclusion: {push it south}
alternative: {push it north}
complexKind: conditional
conditionalValue: bounded
Of course, the contents of the condition/conclusion/alternative roles will also be encoded via n-tuples, using the parameter templates (see below).
These templates (file) correspond roughly to Process schemas in ECG, though importantly, non-Process schemas can be described here, such as schemas/frames for concepts like Possession or Spatial-Relations.