Glossary

Figure 1

ActSpec (Action Specification, previously N-tuple): Communication between modules (agents) in the ECG2 framework uses this LISP-like formalism, implemented in JSON. Task specific information is specified using ActSpec/N-tuple templates. The Specializer uses these templates to extract task relevant data from a SemSpec.

Agent: The ECG2 Framework consists of multiple modules, called agents, that can communicate using the Transport mechanism and ActSpec messages.

Analyzer: This module takes input text (or converted speech) and uses its current ECG2 grammar to produce a SemSpec. This involves parsing but also semantic binding as described in the Workbench Tutorial.

Construction: A linguistic construction is a structured <form, meaning> pair at some level including morphology, syntax, semantics, etc. ECG is an implemented Construction Grammar supported by a user friendly Workbench.

Framework: The ECG2 Framework consists of a number of communicating modules, called agents. Communication is managed by a Transport system and employs a kind of agent communication language called ActSpecs. The core Framework includes Transport and core versions of a starter grammar and modules for a UI-Agent and a Problem Solver. ( Cf. Figure 1)

Ontology: Every ECG2 grammar has an associated Ontology which is a subtype lattice of unstructured terms. The Workbench can be used to build and test such ontologies and the Token tool can be used to link these to the vocabulary of an App in an ECG2 product.

Problem-solver: An ECG2 Product adds an NLU front end to some existing App. It is often useful to add functionality not present in the base App which can be done in the Problem Solver. For example, the Morse-based robot demo added path planning not present in Morse. A core Problem Solver agent is included in the core Framework and includes some support for clarification dialogs.

Product: A complete end to end NLU system built on the ECG2 Framework. The simplest one is the Text-Based Demo

Schema: In ECG, semantics is expressed in terms of several kinds of cognitive, grammatical, and action schemas and bindings among their roles. The meaning pole of a <form, meaning> pair (Construction) is headed by a schema and may entail additional named or evoked schemas and bindings. The Workbench Tutorial has examples.

SemSpec (Semantic Specification): This is a complex graph capturing the bindings among the semantic schemas in an input, specified by an ECG2 grammar and produced by the Analyzer. The Workbench is a sophisticated tool for building and testing grammars.

Specializer: A module in the UI agent that crawls the SemSpec produced by the Analyzer from user input. It employs specifications from ActSpec templates to output task-specific ActSpecs that are transported to a Problem Solver on the App side (right side of Figure 1). A core Specializer is included in the core Framework, but additional (Python) code may be required.

Token: ECG2 grammars use a standard type/token mechanism – For example:”box” is a token of type: ContainerNoun. These correspondences are specified with the Token Tool.

Transport: The system level communication mechanism, described in the wiki and this paper.

UI-Agent: This agent encapsulates the Language side (left side of Figure 1) of an ECG product. There are extensive descriptions in the WorkBench tutorial and the Language-side wiki.

Workbench: This is a large module based on Eclipse that is used for building and testing grammars with the analyzer and also for adding components needed in ECG2 products. There is a tutorial.