The ultimate problem for a large multi-contextual frame database is the matching problem. Slots in the frame have unique names within the frame, but those names include variables that can range over lists of substitutions, be unified with full context in possibly many ways.
That makes the whole thing an N by M problem with, perhaps, N input symbols by M frame slots in the entire database of frames. So what is needed is a primary key for the N input symbols in parallel. Let’s call that L. We can now define the LMN problem:
There are N input symbols in the present state of the system. The experience base has L frames, and the total number of all frame slots is M frame slots in the database. The equivalent retrieval is:
Select (S1 .. Sn, L1 .. Ll, M1 .. Mm)
From Matches
Where PredicateExpr(S[1] .. S[n], L[1] .. L[l], M[1] .. M[m])
Order by FrameID;
That is a deadly _expression_, certain to bring any database in all of creation to its knees.
One alternative I have been exploring, and writing exploratory code for, is to store the graph in a database, with a context that represents contextual symbols in a restricted slice of the stack, which I call the Graph Stack. It solves a lot of representation problems, but it would be better represented as a database that represents a very complex graph, with each context belonging to a specific activity class. The ICOMAs establish the context, and the variable scope is the ICOMAs, typically a small number from 5 to 12. The purpose of the graph stack is to allow each context to refer to its parent’s instantiating context where the ICOMAs are defined, and further up with inheritance of metaphors.
Comments on this conceptual offerings are appreciated,
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2