Monday, June 11, 2018

Refactoring "context"

Retired and with plenty of time to try to pull together some kind of focus, I have been thinking about "context". I have been treating it as a property of a conversation, so that chatbot architecture would be responsible for it and that is wrong. In a conversation there is one context per participant but each participant is operating within a structure [whatever it is] that is self contained and meaningful without being generated by a conversation. In other words context is really something that should be handled properly in core Narwhal files.

I have been trying hard to get this stuff straight. It seems there is a concept of context frame that can contain other context frames and has a form something like this:

ContextFrame
  • id (a self vocabulary list)
  • Environment (properties and parts of the parent frame)
  • modifiers (a tree of categories and values)
  • parts (contained context frames)
  • relations (narratives for connecting text to filled values)
I am trying to get straight things like: how does a "currentContext" pointer get switched from one to another context. How data can be stored in parallel instances of a template that defines the contextFrame contents.

In terms of "old" Narwhal ideas, what this whole program of understanding "context" as an attribute of language underlying conversation amounts to is a reformulation of the "vault" concept; so the vault will have much more structure. It will store these elusive template instance records but the language program for interpreting text can be designed around narrative structures that are automatically used to relate those templates....blah blah blah.

One important clarification is that to "attach" a context frame to the incoming text is the same as assigning values to its data template.

No comments:

Post a Comment