Context Aware Processing

Agents receive stimuli in the form of TMRs - typically from utterances, although not necessarily so. These TMRs are entered into the short-term fact repository, where they are resolved against other known instances if possible, otherwise added as new knowledge.

Inputs, however, need to be processed and understood within a broader context. It is not simply enough to dump every TMR frame into the fact repository; even resolving to existing instances doesn’t lend enough intelligence to understanding the inputs fully.

To more fully grasp the stream of inputs, an agent uses Context Aware Processing; through external stimuli or internal decision making, an agent finds itself in one or more contexts. These contexts can vary - in the case of the robot demo, the context (in English) is “being taught a complex task”.

Contexts

A context enables the agent to process inputs in a specialized fashion. In brief, a context is:

  1. A series of heuristics (pre-FR resolution, post-FR resolution, and additional FR resolution)
    • pre-FR resolution heuristics are run prior to input being resolved to the FR; these heuristics can declare that any of the remaining two stages of agent learning (FR resolution and post-FR processing) should be skipped
    • post-FR resolution heuristics are run after the input has been resolved to the FR (these heuristics can be logically ordered to be semi-dependent on one another; that is, “sub” heuristics can be triggered from another heuristic)
    • Additional FR heuristics are heuristics that are injected into the default set of heuristics used by the FR to perform normal resolution
  2. A collection of meta-contextual properties for use in the FR
  3. A collection of static knowledge modifications that are only applicable while in the context

Both the heuristics and the meta-contextual properties interact with each other to create a state for the context as the agent observes its reality.

Meta-contextual properties are essentially an extension of the ontology that defines a new set of properties whose usage is relevant only within a certain context. These are not “official” properties of the ontology, but they are a set of properties well defined within a context to have specific meanings.

Heuristics will then read, write, and update these meta-contextual properties into the FR as a means of tracking the state of the context. We use a unique namespace to track these properties in the context (to avoid collisions with other contexts), and we use the “*” symbol to identify these properties uniquely from traditional properties found on FR instances.

Static knowledge modifications (lexicon, ontology, etc.) can be used to help with textual domain processing, as well as contextual reference resolution in the fact repository.

An Example

In the context “being taught a complex task”, a subset of the defined meta-properties is:

  • LCT.learning - This is applied to EVENTs that the agent is learning about (still learning, not yet finished learning); (values are True, or False, where False is equivalent to absence of the property)
  • LCT.current - This is applied to an EVENT that has LCT.learning, and is the current focus of the learning effort (in a complex event, this is the current subtree that is being explained); (values are True, or False, where False is equivalent to absence of the property)
  • LCT.waiting_on - This is applied to a non-LCT.current EVENT that has LCT.learning, and its value is another EVENT that is considered a subevent, and is not yet finished being learned
  • LCT.learned - …

(Here, the namespace “LCT” is used as an abbreviation for “learning a complex task”).

And a simple heuristic for learning about a new EVENT, and adding subevents to it would be:

DEFINE LCT_SIMPLE_HEURISTIC (tmr, fr) AS

event = main_event(tmr)
fr_event = corresponding_fr_frame(event, fr)

IF is_prefix(event)
    FOR EACH e IN find_fr_frames(LCT.learning == True)
        e->LCT.current = False
        e->waiting_on = fr_event
        e->HAS-EVENT-AS-PART = fr_event
    fr_event->LCT.learning = True
    fr_event->LCT.current = True

Where:

  • main_event is a subroutine to find the “main” or “head” EVENT frame in a TMR
  • corresponding_fr_frame is a subroutine to find the FR frame generated by a TMR frame (previor to any Context Aware Processing)
  • is_prefix is a subroutine for determining the anchor time of an EVENT frame (testing for, e.g., “we will” rather than “we have”)
  • find_fr_frames is a subroutine to search the FR for matching frames (in this case, to find ones with the LCT.learning property set to True)

Assuming an empty FR, if two input TMRs (containing only a simple EVENT frame each) were input, one after the other, the state of the FR after the first input would look like:

EVENT-FR1

  • *LCT.learning = True
  • *LCT.current = True

And the state of the FR after the second input (assuming the FR does not resolve the two EVENTs to the same frame) would look like:

EVENT-FR1

  • HAS-EVENT-AS-PART = EVENT-FR2
  • *LCT.learning = True
  • *LCT.current = False
  • *LCT.waiting_on = EVENT-FR2

EVENT-FR2

  • *LCT.learning = True
  • *LCT.current = True