Posts made by Kevin

These are the automated QA test results (click here) for 12/22/20.

Copyright 2020, Kevin Dowd

Layer-2 Explicit Inference Memories

Whereas layer-1 memories are a collection of general propositions, equivalences and descriptions, layer-2 memories are inference templates, mostly.

if a person is in the woods and the time is night then the person is afraid and the person is cold.

Inferences can be entered on-the-fly, recalled in general memories or save-sets. What makes a layer-2 inference different is that it is not part of the context, not in memory and may not even be on the same computer. Rather, layer-2 inferences are found in a file, a database or perhaps in another copy of Brainhat.

dowd@beast:~/brainhat$ ./brainhat -r memories/inthewoods.txt -2
Starting new memory hash.

Layer-2 inferences are resurrected when a new entry(s) in the context trigger a hash. So, for example, a file might contain the above inference template. Brainhat could learn that the there is a person in the woods. It might then learn that it is nighttime, too, at which point concepts are substituted into the inference and the inference fires.

dowd@beast:~/brainhat$ ./brainhat -A +repeat

>> mario is in the woods
 mario is in the forest.
>> the time is night
 the time is night. cold mario in the forest is cold. he is afraid. afraid cold mario is cold. he is afraid.
>> the princess is in the woods
 the princess is in the forest. she is cold. the cold princess in the forest is afraid.
>> bye

goodbye!

patent pending

Copyright 2020, Kevin Dowd

Dynamic Concepts

A dynamic concept is one that is created at runtime. Dynamic concepts are used for names and addresses. Below, we see the creation of "rover"--the name of a dog.

  >> my dog's name is rover.
   your rover dog belonging to You is rover.
  >> break

   Break in debug at the start:
   debug> list rover
   Meme: default
     (context text) rover->rover-15099 (dynamic_recorded), MID 10000

Because dynamic concepts are not sourced from the vocabulary, their labels (like "rover") have to be stored along with any save sets that reference them.

Hash Tables

Hash tables are a mechanism that aid in the storage and retrieval of data. The simplest form of hash table is a direct hash--a fixed collection of slots numbered from 0 to N-1. To use the hash table, one generates a number from 0 to N-1 as an index into the table. The index chooses the slot. The slot contains something of value.

For illustration, imagine an old hotel with a wall of of wooden box-slots behind the front desk. The slots contain room keys. There is one slot per room. If you have the room number, you can check the slot for the room key. The room number is the index. The room key is something of value to be found in the slot.

Now, suppose that there are many more rooms in the hotel then there are boxes. One would have to share box-slots between rooms. In order to map M rooms onto N hash table slots, one could create an index that is equal to '(room number) modulo N.' In this case, the same hash slot will be used for room 1, room 1+N, room 1+2N, and so on. If the hash table is built to accommodate multiple data sets, then overloading a hash slot won't replace the information within it when new data are stored. Rather, a slot will accumulate additional stored data and grow.

             o
            /|\
   SUBJECT / | \ OBJECT
          /  |  \
   dog (100) |   bone (tag value = 200)
             |
             | VERB
             |
          to chew (tag value = 101)

Hash tables and slots are a mechanism that Brainhat uses to store and retrieve CCs. We can use hashes because individual concepts are associated with tag values. The concepts for "dog," "to chew" and "bone" might have tag values 100, 101 and 200, respectively, for example. These can be combined to create a hash for the CC that represents "dog chews bone." A simple hash would be the sum of all of the values, such as 100+101+200 = 401. To store or retrieve the CC associated with "dog chews bone", one locates a hash table slot associated with the number 401 and finds a reference to "dog chews bone." This could be used in other ways, too; we might ask "does the dog chew a bone?" The hash would again be 401.

Unrelated CCs can yield the same hash value. This will cause them to share a slot. Overloading is permitted; many CCs can share a single slot. Hash slots include extra information to verify that a "hit" matches the values that created the hash. By this, the hash table becomes the long-term directory for locating CCs and searching for knowledge.

Hash Vines

Guided by the hierarchical organization of the vocabulary, Brainhat can recognize a CC containing specific knowledge to be the child of a CC containing abstract knowledge. It is useful for answering questions, invoking inferences and restoring memories. For example, "pet chews bone," "pet action bone", "animal chews thing", "thing action thing" are all abstract cases of "dog chews bone." Any of these abstractions can hash to find "dog chews bone." Therefore, we can ask Brainhat "does an animal chew something?" and the answer is yes; a dog chews a bone.

    >> a dog chews a bone
     a dog chews a bone.
    >> break

    Break in debug at the start:
    debug> eval animal chews something
     animal chews thing.
    "True"
    debug> cont

    >> does an animal chew something?
     yes. a dog chews a bone.

The vocabulary parents of concepts "dog", "to chew" and "bone" create the hashes. Brainhat gathers each concepts' parents into a linear list. Say, for illustration, that the parents for hash variable "dog" include "pet", "animal" and "thing." The parents for "bone" might be "body part" and "thing." "Chew" might simply be classified as an "action." Given all the parents, we can place them side-by-side:

      hash     hash      hash
      var 1    var 2     var 3
  ---------- | ------- | -----------
      thing    action    thing
      animal   chews     body part
      pet        :       bone
      dog        :        :
       :         :        :

In Brainhat parlance, the ordered sets of concepts are called "hash vines" by virtue of the way they hang down from least-specific to most-specific, and by the way the code climbs them: hash searches are bottom-up and breadth-first, meaning that more-specific matches are favored over less-specific. The code reaches the more specific hashes first, like a gorilla climbing a set of vines. Moreover, by the way they are traversed, hash vines can support "occlusion" such that more-specific hashes are reached before less-specific hashes, and thus will take precedence in a search. An example of where this can apply: "Animals like water" is the generalization. "Cats do not like water" is more specific. Thus, a search for "do cats like water? (no)" may locate a match before "animals like water (yes)."

Memories

Earlier, as we were looking at how to program a dog, we considered a simple sequence of statements as a description of what a dog will do when the mailman comes. You could visualize the behavior of the dog because you have worldly experience. Brainhat has no experience with dogs and the things that dogs do. In order to approximate an understanding of a dog, Brainhat has to learn about dogs. It does this by reading programs about dogs. As Brainhat reads, it collects, stores, indexes and groups dog knowledge (CCs) into neighborhoods. These neighborhoods are called memories. Memories are saved into a backing store (disks, databases or other instances of Brainhat acting as memory-servers) in bunches.

The indexes used to store and retrieve memories are called triggers. They are organized and accessed with hash vines. At runtime, the presence of one or more triggers may cause Brainhat to restore a memory. Hearing the mailman and running to the door could resurrect a recollection of barking, for example.

Considered as data, a memory is a short string of CC data structures, fetched in the order in which they were stored. Here are three CCs in the memory that contains: "I hear the mailman," "I bark" and "I run to the door." The three CCs are a snippet of the running context, recorded and indexed for retrieval at some later time.

         Root               Root               Root
          o------------------o------------------o
    SUBJ /|\                /|                 /|\
        / | \ OBJECT       / |           SUBJ / | \ ADVERB
       o  |  o            /  | VERB          o  |  o
     I    |  mailman     /   o              I   |  to door
          |             /      bark             |
     VERB |            / SUBJ             VERB  |
          o hear      /                         o run
                     o

Here's an illustration of (layer 3) memories at work. This first block of code is the input to Brainhat that is used to create a memory:

    the weather was beautiful
    the sun was shining
    i walked on the beach
    i lost my dog

Memories are stored in binary fashion to a backing store, such as file, database or other copy of Brainhat. A subsequent session may access these memories. The following is a demonstration of the retrieval of the memory above in a subsequent Brainhat session:

  >> i walked on the beach
   You did walk on the beach.
  >> the sun was shining
   the shining sun was shining.
  >> did i lose something?
   yes. You did lose your dog.

The conditions that invoke a memory needn't exactly match the triggers that stored it. A subset of triggers may be sufficient. Nor do they have to appear in order. General memories may be invoked by more specific triggers; a memory involving house pets may be resurrected in conjunction with a trigger that refers to a cat or dog, for example (see "hash vines", above). Brainhat will attempt to substitute the specific concepts that trigger a memory into the abstract concepts it may contain; "cat" may be substituted to replace "house pet" in the restored memory, for example.

Because runtime memory triggers are found in the context, a restored memory will likely contain some CCs that duplicate elements of the context that triggered it. A memory will often also contain some CCs that are not already resident in the context. It is this extra knowledge that provides expectation for what might come next, such as "I lost my dog" in the example above. Multiple memories can be restored simulataneously. Unrelated memories can combine. By this, Brainhat can generate fresh observations under novel conditions. The illusion of intuition occurs when conditions cause Brainhat to resurrect old memories and apply them to new situations and new actors.

Orthogonality is an important tool for maintaining coherence in memories. In cases where restoring a particular memory would create an orthogonality violation (causing the dog to be both inside the house and outside the house, for instance), the itinerant memory will be skipped--not restored.

For the time they are relevant, memories are intertwined with the CCs of the recent context and with each other. The memory's constituent concepts (dog, weather, etc.) are merged with the dirty concepts of the current context. When a memory loses relevance, it is removed from the context. The dirty concepts (dog, weather, etc.) are rebuilt and stripped of the contributions from the retired memory. Though the memory may be removed, any newly generated knowledge derived from it will become part of the permanent context; it's ephemeral presence may have permanent effects.

Memories have other uses, as well. When Brainhat is trying to derive the correct interpretation of user input, it may consult memories. If a particular interpretation, in combination with the context, invokes a memory, then Brainhat will favor that interpretation over other possibilities that do not. For instance, if we were to tell Brainhat

  "the dog sees the ball"

memories about a dog and a ball (as a toy) are going to help Brainhat decide that this is a more likely interpretation than a dog watching a large gathering with dancing and an orchestra (another kind of ball).

How are memories created? Memories come from regular language input, like the statements of the dog program or interactive banter about food. When instructed to do so, Brainhat will save snippets of the context from time-to-time, along with index information. Later, when similar input resembles the indexes (triggers), a saved memory will be restored. Creating or restoring memories doesn't interfere with other Brainhat processing. Accordingly, memory creation or restoration (or both) can be enabled during regular interaction to build even deeper memories.

There are four categories of memories with the designations of "layer 1", "layer 2", "layer 3" and "layer 4". The difference between the designations are the thresholds to be met before a memory is eligible for restoration. Layer 1 is intended for memories that require no more than the mention of a pertinent concept as a condition of being restored. For instance, a memory about the sun--"the sun is bright", "the sun is in the sky", "the sun is round", "the weather is not raining"--can be safely resurrected whenever the sun is mentioned. Layer 4 memories, on the other hand, might concern specific situations, such as the presence of the mailman at the door, and be reserved for cases where multiple conditions match. The layers and thresholds are configurable. Their uses are up to the programmer.

We spoke about the context, earlier. In case it's not clear: context and memories are not the same thing. The context provides Brainhat with a background against which to understand new input. Likening the context to a person's mind, the context is a collection of the things that Brainhat is presently concentrrating upon. Memories, on the other hand, are knowledge that is superimposed onto the context opportunistically, and usually temporarily. Memories are akin to notions that pop into one's head and later disappear.

Brainhat Save Sets

Save sets are used store memories, motives and whole-sessions. Via save sets, one can store the complete state of Brainhat today and resurrect it tomorrow. Save sets provide an avenue to serve Brainhat functionality from stateless servers; the clients can keep their own state.

Save sets contain a configurable number of sections that can record context information, discourse buffer information, saved questions, dynamic concepts (created outside the vocabulary) and other sections. Save sets may rest in files, in a backing store or be traded between copies of Brainhat.

Save sets are knowledge storage without the presence of language.

Text Input

Computation is motivated by changing conditions, such as a fact learned from another copy of Brainhat, some input from the programmer, a news feed update or input from an outside agent--a sensor or robot. Brainhat, running as a daemon, can listen to an arbitrary number of connections. Depending on how the connections are opened, Brainhat may expect simple English, a Brainhat save set or an exchange via Brainhat's robot API.

In daemon mode, Brainhat listens for user connections on a TCP port. This port is used for interaction with humans, speech interfaces and a web sockets shim. Interactive connections will typically drop in and out of debug mode to exchange out of band data. Whether invoked as a daemon or interactively, Brainhat opens a default connection to interact with the programmer in simple English:

  >> i am happy
   You are happy.
  >> you are sad
   I am sad.
  >> how are you
   I am sad.
  >> how am i
   You are happy.
  >> my dog knows that his ball is in the water
   your dog knows dog's ball is in the water.
  >> what does the dog know?
   your dog knows dog's ball is in the water.

Live interaction is a way for the programmer to motivate and test Brainhat computation. Live interaction is also convenient to simulate exchanges with outboard sensors or robots.

Any input provided through the default interface is recorded verbatim and also is recorded as "speaker says..." [Foornote: the "speaker" is you, the person interacting with Brainhat]. Programs may react to command line propositions, such as "the ball is red" or with the derived fact that speaker input provided the proposition, e.g. "speaker says the ball is red."

Robot Interface

To connect with a sensor or robot, the programmer designates a concept as a robot and opens a connection to it:

a robot's address is 192.168.0.100:300.
the robot's name is freddy.

This designates a robot and gives it a name. One can subsequentlyzdirect the robot in the imperative tense.

>> tell freddy put the ball in the bin.

The robot will receive a list of field/value pairs, delimited by a start and end statement.

start
tag=4839
subject=freddy
command=put
object=ball
color=red
objprep=bin
prep=in
end

The robot may respond with a status code and optional simple English message. A response of "Y" indicates that the action was completed:

4839:Y

A "N" means the action failed. An optional reason may be provided by the robot.

4839:N:freddy does not have ball

Robot interfaces are asynchronous. At any time, a robot may provide simple language input via its connection to the daemon.

Outbound Text Connections

A Brainhat daemon can open a text channel to external programs or to other copies of the daemon:

a daemon's address is 192.168.0.101:4144.
the daemon's name is freddy.
tell freddy hello.

In this example, the local copy of Brainhat will open a connection to a remote copy and send "hello." When the remote copy responds, it's response will be prepended with "freddy says" to create "freddy says hello" within the context. By this, the source of the input is identified and its value may be associated with the reputation of the source.

A Brainhat daemon can open a text channel to external programs or to other copies of the daemon:

a daemon's address is 192.168.0.101:4144.
the daemon's name is freddy.
tell freddy hello.

In this example, the local copy of Brainhat will open a connection to a remote copy and send "hello." When the remote copy responds, it's response will be prepended with "freddy says" to create "freddy says hello" within the context. By this, the source of the input is identified and its value may be associated with the reputation of the source.

Outbound Context/Memory-Sharing

Brainhat can also open a channel for sharing Brainhat binary save sets. This is particularly useful for sending save sets that contain a portion of the immediate context in anticipation of receiving a remote Brainhat's memories in return.

a memorybank's address is 192.168.0.102:4144.

When a remote daemon connection is opened this way, the local copy of Brainhat will automatically share out sections of the context and receive remote memories in return. By this, a local copy of Brainhat may benefit from the experiences of remote copy of Brainhat.

Unsolicited memories and updates may be received from remote copies of Brainhat while a connection is open.

Motives

Brainhat has a facility where applications may be crafted to pursue specific goals. Imagine, for example, that our dog is told by a camera-robot that it has detected a person's face. We might wish to exercise a decision tree that decides whether to growl or wag the dog's tail, depending on whether the face appears to be friendly. This goal-seeking facility is called Motives. Motives are hand-crafted, N-way branching, overlayed, restartable decision trees. Motives coexist with and combine with memories in order to affect context-dependent behavior.

Each motive is a block of code initiated by a test. When the test evluates TRUE, the block gains focus and its contents execute. The contents of the motive are simple English statements.

    MotiveName: start
    Test:
    Contents:
    Branches: see-a-face, start

    MotiveName: see-a-face
    Test: you see a human face.
    Contents:
        you are afraid.
        tell body-robot crouch.
        tell vocal-robot growl.
        tell vision-robot analyze-face.
    Branches: friendly-face, unfriendly-face

    MotiveName: friendly-face
    Test: face is friendly.
    Contents:
        you are not afraid.
        you are happy.
        tell body-robot stand.
        tell body-robot wag-tail.
        tell vocal-robot happy-bark.
        reset friendly-face.
        reset see-a-face.
    Branches: see-a-face

    MotiveName: unfriendly-face
    Test: face is unfriendly.
    Contents:
        tell vocal-robot angry-bark.
    Branches:

[footnote: The syntax shown is representative of the actual Brainhat syntax, and chosen for illustration.]

The 'MotiveName' field provides a label for the block. This label can be used as a branch target from other blocks.

The 'Test' is a condition that, when true, will cause the the motive block to gain focus.

The 'Contents' are statements that execute when the block gains focus. The statements can be a mix of propositions, inference templates and imperatives.

'Branches' nominate potential next blocks, making them standby-active.

Once a block is active, its Test is armed and will remain that way until the block is reset or executed. Note that many blocks can be active-standby at any time. Focus may shift between blocks that are on separate paths. This makes it possible to pursue many sets of goals (and motive blocks) simultaneously.

Motives interact with memories, causing memories to be restored and retired as a side-effect of the new information a motive may add to context. Unlike memories, however, the contribution of motives is permanent, and becomes part of the ongoing context.

In the case where a motive becomes active, and where its contents will create an orthogonality conflict with the context, portions of the context may be graduated into the preterit. So, for example, if the context says "dog is inside the house" and a newly activated motive says "dog is outside the house", the motive wins and the context changes to say "the dog was inside the house."

A Brainhat server may be invoked with a set of motives pre-activated. When clients connect, the motives will direct their interaction. Additionally, a client may provide its own motives and their state to a Brainhat server. By this, individual clients can persue their own goals on a generically-programmed Brainhat server platform.

Belief Systems

There are mode and debug flags in Brainhat that allow the programmer to modify Brainhat's interpretation and computation. One flag, "verbatim", controls whether speaker interaction is taken at face value. With the "verbatim" flag unset, input of a statement like "the ball is red" records only "speaker says the ball is red." Here is an example:

  >> debug unset verbatim

  >> if i say a thing is red then a thing is blue
   if You say a thing is red then a thing is blue.
  >> the ball is red
   the ball is red. a blue ball is blue.
  >> why
   a blue ball is blue because You say a blue ball is red.

Debug

The program includes extensive debug facilities.

    Commands:
    DEBUG symbol [ location] -or-
    BREAK symbol [ location] -or-
    SET symbol [ location]
      Increment debug count for routine/process/flag,
      and optionally stop at listed locations.
      "location" is one of {start, loc[1-3], finish, all}

    NODEBUG symbol -or-
    UNSET symbol
      Decrement debug count for routine/process/flag.
    CLEAR symboln  Zero the debug count for routine/process/flag.
    DUMP [n]
      Dump optional argument concept (if concept).
      Dump optional conchain (if conchain).
      "n" chooses conchain element.
    RDUMP [n]
      Dump recursively.
    LIST label
      Show all symbols matching label.
    WORDS
      Dump pre-prepared word list.
    LISTM
      Shows loaded motvs.
    SHIFTN number
      Shifts meme processing to motv N.
    SHIFT name
      Shifts motive processing to motv by name.
    STOP
      Stop.
    S[R]DUMP symbol
      Dump symbol from clean symbol table.
    C[R]DUMP symbol
      Dump symbol from context.
    M[R]DUMP symbol
      Dump symbol from MID symbol table.
    X[R]DUMP n
      Dump nth CC from context.
    D[R]DUMP n
      Dump nth CC from discourse buffer.
    Q[R]DUMP n
      Dump nth CC from questions buffer.
    SPEAK [n]
      Speak optional argument concept (if concept).
      Speak optional conchain (if conchain).
    CCSPEAK label
      Speak CC from context.
    XSPEAK [n]
      Speak nth context entry.
    DSPEAK [n]
      Speak nth discourse entry.
      "n" chooses conchain element.
    SQSPEAK/SQ[R]DUMP
      Speak/dump the saved question, if any.
    A[R]DUMP/SPEAK n
      Dump nth anaphor candidate.
    PARSE string.
      Parse and read back the input.
    EVAL string.
      Evaluate the truth value of the input.
    REDIR flag.
      Output debug for "flag" to stderr.  "Flag" may additionally
      be specified as "journal", in which case the journal output is
      redirected.
    STDERR ipaddr port.
      Send stderr to a socket waiting at ipaddr:port.
    ARGV
      Print out the argument vector for this Brainhat invokation.

Graphical User Interfaces

Brainhat has two limited use graphical interfaces:

• A Windows-based interface provides a SAPI4 connection to speech engines.

• A more comprehensive HTML5/websockets-based GUI is helpful for testing
  programming and vocabulary.

patent pending

Copyright 2020, Kevin Dowd

What is this?

We're going to program with knowledge. It's likely to be different than other kinds of programming you are familiar with. Most languages, like C or Python, are procedural, meaning that code executes in sequence.

    integer i,j,k
    string c
    j = 2
    k = 1
    i = j + k
    string = "here is the answer"
    print string, " ", i
    end

Procedural code executes from the top to the bottom. It might also have flow control statements, like 'if' or 'while,' that cause branches. There may be subroutines an perhaps there's an event loop. The program may jump from place to place, but execution will always be somewhere within the code.

Brainhat is dataflow programming, and dataflow programming is different. There are no flow control statements. There's no program, in regular sense. Rather, the data themselves direct execution.

"the dog is hungry."

Think of this statement as an assignment. It adds to the collection of things that are known.

"if the dog is hungry then the dog wants to eat."

This statement is executable; it becomes part of the program. When the two statements find each other, there will be side-effects, such as:

"the dog wants the dog to eat."

How do the statements find each other? They're hashed. When hashes match, Brainhat executes. This, in turn, can generate more hashes, knowledge and other side-effects. Hashing is the key to recalling memories, testing for the truth or existence of knowledge and for triggering inferences.

Procedural programs are deterministic. But in Brainhat, where the programming can be modified by additional input, the answer can change. Moreover, two copies of Brainhat running side-by-side might provide different results. This is because all input is interpreted against a context, and contexts can differ. If you say "the dog is hungry," I will understand what you mean. But the resulting knowledge probably won't be the same as yours. That's because I understand "the dog is hungry" in my context, using my image of a dog and what a dog likes to eat. You understand it in your context. My dog might be brown; yours could be tan. If you had said "the tan dog is hungry," I would have had an entirely different understanding. My dog is brown. Ergo, you must be talking about a different dog. That's the tricky part, and the fun it all: human language makes knowledge portable, but it leaves out the details.

Here's how "the dog wants the dog to eat" looks inside Brainhat:

                           o Root
                          /|\
                SUBJECT  / | \
                        /  |  \
                       / VERB  \
                  dog o    |    \
                           |     \
                           o      \
                        to want    o Root
                                  /|
                                 / |
                                /  |
                               /   | VERB
                         SUBJECT   |
                             /     |
                            o      o
                        dog      to eat

This is a knowledge data structure (called a Complex Concept or CC). It's very much like a diagrammed sentence that you might have created in grammar school English. However, unlike a diagram or the variable j, this data can be modified by changes in the context around it. If we later learn that the dog is brown, this data structure changes too.

It's not all chaos; there is a great deal of formal input processing for shaping input and interpreting it correctly. A number of post processing efforts seek to discover patterns in the context and to pro-actively recall memories and exercise inferences.

Vocabulary

To read human language, Brainhat has to recognize the tokens (words) and it has to make sense of their order. Tokens and order are prescribed by a vocabulary and a grammar. The vocabulary says what the tokens can be. The grammar says how they can be combined. The vocabulary and grammar create the possibilies for, and define the limits of, what Brainhat can understand.

Brainhat's vocabulary is defined hierarchically. A poodle is a dog, a dog is a pet, a pet is an animal, and so on. Concepts for hamster, cat, dog and wildebeest are children (hierarchically) of the concept for animal. So, we may ask if a wildebeest is an animal and whether it shares some features in common with dogs, and the answer will be "yes." However, there is no upward path from wildebeest to pet. Therefore a wildebeest is not a pet.

              o things          o actions          o adjectives
             /|\               /|\                /|\
            / | \             / | \              / | \
           /  |  \           o  |  o to eat     o  |  \
          o   |   \      to be  |           happy  |    o pretty
   vegetable  |    \            o to sense         |
              |     o          / \                 o color
              |   mineral     /   \               / \
       animal o              o     \             /   \
              |\       to hear     to see       o     o red
              | \                           blue     / \
              |  o wildebeest                       /   \
              |                                    /     o
              o pet                               /     pink
             /|\                                 o
            / | \                             scarlet
           /  |  o cat
  hamster o   |
              o dog
              |
              |
       poodle o

A vocabulary definition appears below. This definition has multiple synonyms: "hot dog", "hot dogs" and the name "hotdog-1". To reference this definition, one could refer to it by any of the synonyms, e.g. "the dog ate a hot dog" or "the dog ate a hotdog." [footnote: You'll notice that we've grouped plural and singular forms together. This is not a requirement; the vocabulary can be built so that singular and plural are distinct. For the time-being, and for simplicity, we will work with combined forms.]

    define      hotdog-1
                label           hot dogs
                label           hot dog
                label           hotdogs
                label           hotdog
                orthogonal      food-1
                child-of        food-1

When a word has two or more distinct meanings, there may be two or more definitions. For example, a ball is round, a ball has the quality of being a certain color, a "ball" is a toy. A "ball" might also be a formal dance, with an orchestra and glass slippers.

    define      ball-1
                label           balls
                label           ball
                child-of        toy-1
                wants           color-1
                wants           size-1
                related         round-1
                related         play-1
                wants           shape-1

    define      ball-2
                label           balls
                label           ball
                child-of        party-1
                related         loud-1
                wants           volume-1

To tell the two forms of ball apart, we may add hints to the definitions. If we say "the ball is red," chances are that we'll get the correct sense of the word "ball" because of the hint that says "ball-1 wants color-1". Once Brainhat has been processing for a while, reliance on hints in the vocabulary become less important. Instead, Brainhat will look to memories and context when trying to determine the sense of a word.

Grammar

Grammar defines how the vocabulary elements can be combined. Consider the statement: "I hear the mailman." The words "I" or "mailman" may play the part of a subject or object. The word "hear" can only take the part of a verb. Using a grammar rule like this, we can recognize "I hear the mailman":

grammar_rule = subject + verb + object,

Brainhat tags parts of speech--the subject, verb and object--and places them into a data structure that represents the statement. Once the knowledge is captured, the original statement is no longer needed.

                o Root
               /|\
     SUBJECT  / | \ OBJECT
             o  |  \
            I   |   o mailman
                |
           VERB |
                o
              to hear

In Brainhat terminology, each of the vocabulary elements--"I", "to hear" and "mailman" is called a concept. Any combination of concepts is called a complex concept or CC. Compiling the statement "I hear the mailman" produces a CC data structure that resembles the diagram, above. A CC can be indexed, stored, recalled, compared and transformed:

   >> i hear the mailman
    You do hear the mailman.
   >> what do i hear?
    You do hear the mailman.
   >> do i hear the mailman?
    yes. You do hear the mailman.
   >> what do i do?
    You do ask do You hear the mailman.

Orthogonality

Returning to the definition of the concept hotdog-1: as a child of concept food-1, the concept hotdog-1 becomes part of a class that may include hamburgers, potato chips and chicken parmigiana, provided that they are also children of food-1.

    define  hotdog-1
            label           hot dogs
            label           hot dog
            label           hotdogs
            label           hotdog
            label           weiner
            orthogonal      food-1
            child-of        food-1

    define  hamburger-1
            label           burger
            label           haburger
            orthogonal      food-1
            child-of        food-1

Hot dogs are food. Hamburgers are food. But hamburgers are not hotdogs. Indicating orthogonality makes it possible to tell them apart. The directive "orthogonal food-1" instructs Brainhat that hotdogs and hamburgers are exclusively different than other concepts that are also declared orthogonal to food-1 (or one of its parents).

   >> what are hotdogs?
    hotdog is food.
   >> are hotdogs hamburgers?
    no. hotdog is not hamburger.

As orthogonality helps to differentiate objects, it applies to attributes, too. [Footnote: an ATTRIBUTE is an adjective or propositional phrase, typically, though it can be a binary large object (BLOB), too, such a thumbprint, picture or voice scan.] The "red dog" is not the "blue dog,"the "first dog" is not the "second dog", and the "dog in the restaurant" is not the "dog in the library."

   >> the first dog sees a cat
    the first dog sees a cat.
   >> the second dog sees a squirrel
    the second dog sees a squirrel.
   >> does the first dog see a squirrel?
    maybe. the second dog sees a squirrel.

Orthogonality may apply to whole clauses playing the part of subject or object. For instance "the party at the beach" may be orthogonal to "the funeral for my uncle." Tests for orthogonality of more complex CCs like these may take place by semantic evaluation.

Inheritance and Orthogonality and Truth

Computing with knowledge, we need to be able to ask whether something is true or false, or whether we don't know the answer. Truth is important for steering processing, and invoking inferences and memories. Truth motivates computation.

Brainhat's vocabulary is built of taxonomies. Every concept, except for the very top concepts, is the child of another. Some are the children of many. A toy is a thing; a ball is a toy. Inheritance is functionally broken, however, when orthogonality is detected. A blue ball is not a red toy, for example.

Just as individual concepts can be the children of others, whole CCs (complex concepts, described above) can be the children other CCs. For one CC to be the child of another, the child CC must contain the same basic parts of speech as the parent. [Foornote: In Brainhat parlance, we say that two CCs have the same shape.] Furthermore, each of the child's constituent concepts, taken in pairwise comparison to the parent's, must be child concepts, or be the same.

To take a few examples, the CC on the left is a proper child of the CC on the right. Each of the concepts in the left-hand CC is a child of each of the concepts on the right, and the two CCs have the same shape.

            Root                     Root
           o                        o
          /|\                      /|\
    SUBJ / | \ OBJ           SUBJ / | \ OBJ
        /  |  \                  /  |  \
       o   |   \                o   |   \
    dog  VERB   o ball     animal  VERB  o toy
           |                        |
           o                        o
         to see                  to sense

The next two CCs do not have a child/parent relationship because they have different shapes. This is because links are different; OBJECT versus ATTRIBUTE. They also lack pairwise inheritance in all but the OBJECT.

            Root                     Root
           o                        o
          /|\                      /|\
    SUBJ / | \ OBJ           SUBJ / | \ ATTRIBUTE
        /  |  \                  /  |  \
       o   |   \                o   |   \
    dog  VERB   o ball     animal  VERB  o happy
           |                        |
           o                        o
         to see                  to be

In this next comparison, the shape is the same. The corresponding concepts are identical. In fact, the CCs are identical. A concept can be a child of itself; the child/parent relationship is valid.

            Root                     Root
           o                        o
          /|\                      /|\
    SUBJ / | \ OBJ           SUBJ / | \ OBJ
        /  |  \                  /  |  \
       o   |   \                o   |   \
    dog  VERB   o ball       dog  VERB   o ball
           |                        |
           o                        o
         to see                  to see

Next, we have two CCs that do not share a child/parent relationship because at least one of the constituent parts-of-speech is not a child of the other, even though they have the same shape.

            Root                     Root
           o                        o
          /|\                      /|\
    SUBJ / | \ OBJ           SUBJ / | \ OBJ
        /  |  \                  /  |  \
       o   |   \                o   |   \
    dog  VERB   o ball       dog  VERB   o ball
           |                        |
           o                        o
         to see                  to eat

In this next example, the constituent concepts of "dog sees red ball" ("dog", "to see" and "ball") are all proper children of the corresponding concepts in the itinerant parent. The shape is the same, too. However, the concepts occupying the OBJECT positions are orthogonal because they bear orthogonal ATTRIBUTEs ("red" versus "blue"). Thus, even though each of the concepts that make up the two CCs have child/parent relationships, orthogonality between the concepts breaks the child/parent relationship between the CCs; when we test to see if the left-hand CC is a child of the right, the answer is NO.

            Root                     Root
           o                        o
          /|\                      /|\
    SUBJ / | \ OBJ           SUBJ / | \ OBJ
        /  |  \                  /  |  \
       o   |   \                o   |   \
    dog  VERB   o ball       dog  VERB   o toy
           |    |                   |    |
           o  ATTRIBUTE             o  ATTRIBUTE
      to see    |             to see     |
                o                        o
              red                      blue

Reviewing all of the examples again, we ask the question:

is the CC on the left a child of the CC on the right?

The answers are TRUE, MAYBE, TRUE, MAYBE and FALSE, in order. "TRUE" signifies that the relationship is established; one CC is the child of another. An answer of "FALSE" means that the two are the same shape, but in opposition, due to an orthogonality. "MAYBE" means that there is insufficient shared structure to answer the question. For instance, in the second example, the CC representing 'the dog sees a ball' neither is nor isn't a child of 'the dog is happy'. Accordingly, the answer is MAYBE; the two CCs can't be compared.

Other parts of speech within CCs will affect the child/parent comparison, too. Negation, for example, in a comparison of "ball is not blue" (child) "the ball is red" (parent) will return TRUE. If we reverse them, testing to see whether "the ball is red" is a child of "ball is not blue", the answer will be MAYBE.

Tense can be attached to verbs and attributes. This also affects child/parent comparisions. Take, for example, "the ball is blue" test as the child of "the toy was red." The answer is MAYBE because the two CCs occur in diferent tenses. Orthogonality really only applies when attributes are in the present tense.

   >> the ball is red
    the red ball is red.

   >> debug eval the ball is red
    the red ball is red.
   "True"

   >> debug eval the ball was red
    the red ball was red.
   "Maybe"

   >> debug eval the ball is blue
    the red blue ball is blue.
   "False"

   >> debug eval the ball is not grey
    the red not grey ball is not grey.
   "True"

There are a number of situations where Brainhat may ask itself "is this CC a child of that CC?" or "is this CC true?" The answer may be unknown; "is this CC true?" could return MAYBE. Given an answer of MAYBE, Brainhat will often initiate a more aggressive search for the answer in what is called "self talk." Brainhat will reformulate a question to itself (in English) and process it as if it came from the user. Self-talked input may cause inferences to fire, memories to be restored or motives to be advanced--all of which can lead to a more definitive answer to "is this CC true?"

Context

As Brainhat processes, it builds and updates running context and discourse buffers. These provide a background against which Brainhat can better understand what might come next. A simple illustration of the role the context is the resolution of pronouns. If we refer to something by "he", "she" or "it", we're hoping that the program will recognize these as wild cards for some definite noun or noun phrase that came before.

   >> i see the dog
    You see the dog.
   >> it is hungry
    the hungry dog is hungry.

The "it" we are referring to in the statement above is an immediate reference to a dog, fetched from the context. An example matching a noun phrase:

   >> the princess loves luigi it
    the princess loves luigi.
   >> mario hates it
    mario dislikes the princess loves luigi.

"W" words (who, what, when, where and why) can be satisfied by the context, too.

   >> the cat meows
    the cat meows.
   >> the dog barks
    the dog barks.
   >> what meows
    the cat meows.
   >> does something bark?
    yes. the dog barks.

The context grows as the program runs. Older knowledge is pushed to the back. New entries are added to the front. By this, the resolution of ambiguous references evolves to favor the new. This shows the context following "the cat meows" and "the dog barks":

   >> debug
   Break in debug at the start:
   debug> xspeak 1
    You say the dog barks. the dog barks. You say the cat meows. the cat meows.

The CCs of the context are the product of parsing, disambiguation and an election process that arrives at a single input interpretation. The product may be constructed from a combination of clean and dirty concepts. Clean concepts are those that are sourced from the vocabulary, but have not been modified. Dirty concepts are those that have been modified. An example of a clean concept is "dog." An example of a dirty concept is "happy dog." Below, we see two concepts for dog--one dirty and one clean:

  >> happy dog
   dog to be happy.
  >> break

   Break in debug at the start:
   debug> list dog
   Meme: default
     (clean text) dog->dog-1 (clean), MID 10000
     (context text) dog->dog-14c57 (dirty), MID 10000

For any vocabulary concept, there will always be a clean original. The original is never touched. Rather a dirty copy is created and modified when necessary. During processing, Brainhat strives to create as few dirty copies as possible. Two copies of "dog"--clean and dirty--may be sufficient for the life of a session. A case where Brainhat will create multiple dirty copies is where an orthogonality is detected.

  >> the happy dog has food
   the happy dog has food.
  >> the sad dog does not have food
   the sad dog does not have food.
  >> is the happy dog the sad dog
   no. the dog is not the happy dog.
  >> break

   Break in debug at the start:
   debug> list dog
   Meme: default
     (clean text) dog->dog-1 (clean), MID 10000
     (context text) dog->dog-17028 (dirty), MID 10000
     (context text) dog->dog-1f64f (dirty), MID 10000

Now, we see two dirty dogs: one is happy; one is sad.

patent pending

Copyright 2020, Kevin Dowd

Layer-1 Memories

There's a particular flavor of Brainhat memory that forms the basis for common knowledge, like the color of bananas or where you'd expect to find a refrigerator. In Brainhat parlance, these nuggets of common knowledge are called layer-1 memories--very basic stuff, generally true.

When one is crafting knowledge for Brainhat, the effort is typically one of constructing a scenario, like a day at the beach or an elevator ride. But, you never know when bananas are going to come up, and it might be nice to know something about them, like their color.

Layer-1 memories have the qualities that they are simple to invoke, will not be recalled if they conflict with the context, and can be overridden easily. Unlike other types of memories that intermingle with the context, recalled layer-1 memories are referenced but never actually installed.

Here's a layer-1 memory:

bananas are yellow.

This memory typically be contained in a file. Let's call it bananas.txt. To compile the memory, you would invoke Brainhat like so:

./brainhat -r bananas.txt -1

This will add "bananas are yellow" to the collection of memories. To access the memory, we run Brainhat in autorecall mode, with the -A flag:

dowd@test:~/brainhat$ ./brainhat -A +repeat

>> what color are bananas
 yellow banana is yellow.
>>

Some bananas are red. The notion that bananas are yellow can be overidden.

dowd@test:~/brainhat$ ./brainhat -A +repeat

>> what color are bananas
 yellow banana is yellow.
>> bananas are red
 red banana is red.
>> what color are bananas
 red banana is red.
>> are bananas yellow?
 no. banana is red.
>>

If you are running Brainhat as a daemon, and if the daemon is a memory server, it will make "bananas are yellow" available to other copies of Brainhat, too.

-Kevin

patent pending

Copyright 2020, Kevin Dowd

Vocabulary

To read human language, Brainhat has to recognize the tokens (words) and it has to make sense of their order. Tokens and order are prescribed by a vocabulary and a grammar. The vocabulary says what the tokens can be. The grammar says how they can be combined. The vocabulary and grammar create the possibilies for, and define the limits of, what Brainhat can understand.

Brainhat's vocabulary is defined hierarchically. A poodle is a dog, a dog is a pet, a pet is an animal, and so on. Concepts for hamster, cat, dog and wildebeast are children (hierarchically) of the concept for animal. So, we may ask if a wildebeast is an animal and whether it shares some features in common with dogs, and the answer will be "yes." However, there is no upward path from wildebeast to pet. Therefore a wildebeast is not a pet.

              o things          o actions          o adjectives
             /|\               /|\                /|\
            / | \             / | \              / | \
           /  |  \           o  |  o to eat     o  |  \
          o   |   \      to be  |           happy  |    o pretty
   vegetable  |    \            o to sense         |
              |     o          / \                 o color
              |   mineral     /   \               / \
       animal o              o     \             /   \
              |\       to hear     to see       o     o red
              | \                           blue     / \
              |  o wildebeast                       /   \
              |                                    /     o
              o pet                               /     pink
             /|\                                 o
            / | \                             scarlet
           /  |  o cat
  hamster o   |
              o dog
              |
              |
       poodle o
  

A vocabulary definition appears below. This definition has multiple synonyms: "hot dog", "hot dogs" and the name "hotdog-1". To reference this definition, one could refer to it by any of the synonyms, e.g. "the dog ate a hot dog" or "the dog ate a hotdog." [footnote: You'll notice that we've grouped plural and singular forms together. This is not a requirement; the vocabulary can be built so that singular and plural are distinct. For the time-being, and for simplicity, we will work with combined forms.]

    define      hotdog-1
                label           hot dogs
                label           hot dog
                label           hotdogs
                label           hotdog
                orthogonal      food-1
                child-of        food-1

When a word has two or more distinct meanings, there may be two or more definitions. For example, a ball is round, a ball has the quality of being a certain color, a "ball" is a toy. A "ball" might also be a formal dance, with an orchestra and glass slippers.

    define      ball-1
                label           balls
                label           ball
                child-of        toy-1
                wants           color-1
                wants           size-1
                related         round-1
                related         play-1
                wants           shape-1

    define      ball-2
                label           balls
                label           ball
                child-of        party-1
                related         loud-1
                wants           volume-1

To tell the two forms of ball apart, we may add hints to the definitions. If we say "the ball is red," chances are that we'll get the correct sense of the word "ball" because of the hint that says "ball-1 wants color-1". Once Brainhat has been processing data for a while, reliance on hints in the vocabulary become less important. Instead, Brainhat will look to memories and context when trying to determine the sense of a word.

patent pending

These are the automated QA test results (click here) for 10/14/20.

Copyright 2020, Kevin Dowd

Introductory Hands On

This chapter introduces Brainhat by example. As we look at examples, we will also have the opportunity to introduce terminology and discuss how knowledge is handled within Brainhat.

To run Brainhat from the command line, go to the directory where you have unpacked the program and enter "./run". The "run" script will check for changes you might have made in the configuration files, update as needed, and then start the program, like so:

% ./run
make: 'data' is up to date.
Initializing

>> hello
 hello.
>> goodbye

goodbye!
%

Brainhat comes with a basic vocabulary and grammars that support all of the exercises we will present. You are encouraged to experiment as we proceed. Be aware that if something doesn't work the way you hope, it may be because the vocabulary or grammar don't currently cover it. We will talk about how to extend both much later on.

We refer to simple English as code. Once parsed, stored and indexed, the code becomes knowledge, and may be executable. The exact nature of the stored knowledge is affected by context, which is the product of code that came before.

In Brainhat, an individual knowledge entity is called a concept. A concept is similar to a vocabulary word. For example, "dog" is a concept:

>> dog
 dog.

When we combine two or more concepts, we create a complex concept or CC:

>> dog is happy
 happy dog is happy.
>> dog
 dog is happy.

Attribute assignment

Attribute assignments are the combination of a concept that is a thing with a concept that is an attribute. Below, we build a dog with several attributes:

% ./run
>> dog is happy
 happy dog is happy.
>> dog is hungry
 happy hungry dog is hungry.
>> dog is big
 hungry happy dog is large.
>> bye

Once we have a dog, we can ask questions about the dog's attributes.

% ./run
>> dog is happy
 happy dog is happy.
>> dog is hungry
 happy hungry dog is hungry.
>> is dog hungry?
 yes. happy dog is hungry.
>> is dog happy?
 yes. hungry dog is happy.
>> bye

Just as concept for happy is an attribute, so is the concept for sad. These two concepts are orthogonal, meaning that you cannot attach both concepts to a third concept at the same time. Orthogonality is useful because it makes it possible to differentiate things based on their attributes.

% ./run
>> dog is happy
 happy dog is happy.
>> is dog happy?
 yes. dog is happy.
>> is dog sad?
 no. dog is happy.
>> bye

Attribute assignments can be explicit or implicit. The examples we have looked at so far demonstrate explicit assignments. Implicit attribute assignments occur when an attribute is adjacent the subject. An example of an implicit assignment is the application of happy in the following example:

% ./run
>> happy dog is hungry
 happy hungry dog is hungry.
>> is dog happy?
 yes. hungry dog is happy.
>> is dog hungry?
 yes. happy dog is hungry.
>> bye

Something to be careful about: the use of orthogonal implicit attributes can spawn multiple variants of a CC; though you may believe that you are dealing with just one copy of dog, you may find that you actually have two. Here's an example of how this can happen:

% ./run
>> happy dog is hungry
 happy hungry dog is hungry.
>> sad dog is hungry
 sad hungry dog is hungry.
>> describe dog
 happy dog is hungry. sad hungry dog is hungry.
>> bye

We have already seen that attributes sad and happy are orthogonal. The concept for dog cannot carry two orthogonal attributes at the same time and in the same tense; that is, we cannot have a "happy sad dog." Accordingly, the above code produces two CCs for dog--one that is happy, and one that is sad. This might be exactly what you want, in which case the example shows how it's done.

When making explicit attribute assignments, and when there is an orthogonality, Brainhat will push the older attribute into the perfect past tense. By this, a dog that was once sad may become happy:

% ./run
>> dog is sad
 sad dog is sad.
>> dog is happy
 past sad dog is happy.
>> bye

Attributes can take the form of prepositional phrases, too.

% ./run
>> the dog is in the water.
 the dog is in the water.
>> where is the dog.
 the dog is in the water.
>> bye

As with simple attributes, prepositional phrases can be orthogonal. For example, the dog cannot be inside the house and in the yard at the same time. This is because the objects of the prepositions, house and yard, are orthogonal, but the preposition, in, is the same.

% ./run
>> dog is in the house.
 dog is in the house.
>> is dog in the yard?
 no. dog is in the house.
>> bye

We could keep the objects the same and vary the preposition and get a similar result. Here we find the the orthogonality between prepositions inside and outside:

% ./run
>> the dog is inside the house.
 the dog is inside the house.
>> is the dog outside the house?
 no. the dog is inside the house.
>> bye

As we have seen, orthogonal attributes can coexist if they are in different tenses. More precisely, orthogonal attributes can coexist as long as they are not both in the present tense. It is possible to have orthogonal attributes in future or past tenses, such as "the dog was happy" in combination with "the dog was sad" as both could have been true at different times, and so may co-exist. Here are some explicit attribute assignments in several tenses:

% ./run
>> i was sad.
 You were sad.
>> i am angry.
 You are angry.
>> i will be happy
 You will be happy.
>> bye

Possession is another form of attribute based on the prepositional notion of belonging to, as demonstrated in the following example:

% ./run
>> the dog's ball is red.
 dog's red ball belonging to dog is red.
>> the cat's ball is blue.
 cat's blue ball belonging to cat is blue.
>> is cat's ball red?
 no. the ball is blue.
>> bye

A name is another form of attribute. Names have the special property that they can be used in a position where a reference to a concept that is a thing would typically appear.

% ./run
>> the big dog's name is rover
 large rover dog is rover.
>> the little dog's name is sparky
 small sparky dog is sparky.
>> rover is hungry
 large rover dog is hungry.
>> sparky is happy
 small sparky dog is happy.
>> bye

Following the name assignment, we can use "rover" in place of "the large hungry dog" or "large dog" or "hungry dog."

Propositions (not prepositions)

In Brainhat, we refer to a statement that uses verbs other than to be as a proposition. Here's an example of a proposition. The verb is to want:

% ./run
>> the dog wants a bone.
 the dog wants a bone.
>> does the dog want a bone?
 yes. the dog wants a bone.
>> bye

Many complex concepts (CCs) have tense, number and person (TNP) attached. The tense, number and person are derived from the subject and a verb or auxiliary verb. The tense portion of a CC's TNP is one of past, present, future, conditional, future conditional, and so on. Here are a few examples of tense:

% ./run
>> i saw my mother.
 You did see your mother belonging to You.
>> i see my country.
 You see your country belonging to You.
>> i will see europe.
 You will see europe.
>> bye

Auxiliary or helper verbs like do, did, will and would can also carry tense, like so:

% ./run
>> i saw the princess.
 You did see the princess.
>> did i see the princess?
 yes. You did see the princess.
>> do i see the princess?
 maybe. You did see the princess.
>> bye

Tenses may be grouped for simplicity. For instance, the English gerund may be understood as the present tense, as in the following example:

% ./run
>> i am sleeping.
 You sleep.
>> bye

One particular tense--the future imperfect--is programmed to be recognized by Brainhat post-processing as an opportunity for asking a question (if Brainhat doesn't already know the answer). This functionality is configurable.

% ./run
>> i might like french fries.
 You might like fries. do You like fries?
>> bye

A CC's number is derived from the subject, and can be either of singular or plural. For simplicity, most of the concepts within a Brainhat vocabulary distribution are in the singular with plural forms as aliases for their singular counterparts, as demonstrated here. This, too, is configurable:

% ./run
>> the cats chase the dogs.
 the cat chases the dog.
>> bye

A CC's person comes from the subject, too. I (or brainhat) is first-person; You (or speaker) is second-person; almost every other object is in the third-person. Combinations of TNP are derived from the components of the input and become part of the knowledge represented by the corresponding CC. Here, we demonstrate how the number and person found on the verb are subordinate to the number and person of the subject. In each case, we have used the verb infinitive, yet produce a sensible CC:

% ./run
>> i to be hungry.
 You are hungry.
>> you to be happy.
 I am happy.
>> the dog to eat his food.
 the dog eats the dog's food belonging to the dog.
>> bye

Brainhat resolves pronouns from the immediate context. Gender is taken into consideration. Often, pronouns are ambiguous, in which case Brainhat attempts to resolve based on proximity or position.

% ./run
>> the princess is pretty.
 the pretty princess is pretty.
>> mario is ugly.
 ugly mario is ugly.
>> the food is delicious.
 the delicious food is delicious.
>> she likes him to eat it.
 she likes ugly mario eats the delicious food.
>> who is she?
 the pretty princess to be pretty woman.
>> bye

In some cases, Brainhat will resolve anaphors. These are pronouns at the end of a statement that reference a noun at the beginning, such as:

% ./run
>> mario knows that he is happy
 mario knows mario is happy.
>> bye

Sometimes, they're implied:

% ./run
>> mario wants to see the dog
 mario wants mario to see the dog.
>> bye

As we have seen in the last few examples, the object in a proposition can be another proposition, as with "mario wants mario to see the dog", just above. Object propositions may also be referenced by (event) pronouns:

% ./run
>> the princess swam in the river.
 the princess swam in the river.
>> mario liked it.
 mario liked the princess swam in the river.
>> bye

Propositions built with stative verbs make an assertion about the subject. They are similar to attribute assignments made with the verb "to be". However, they describe an action performed by or on behalf of the subject; they don't bind the the attribute to the subject. For example:

% ./run
>> mario seems happy
 mario appears happy.
>> is mario happy
 maybe. mario.
>> how does mario seem?
 he seems happy.
>> bye

Later, we will see that implicit or explicit inferences provide a path to attach happy to mario when he seems to be happy. Or, on the contrary, inferences may provide a path to sad.

In the same way that a stative verb combined with an adjective says something non-binding about the subject, a stative verb combined with an object proposition makes the object non-binding. We say that the object proposition is in the subjunctive case. This will become clearer with an example:

% ./run
>> mario believes that the princess loves luigi
 mario thinks the princess loves luigi.
>> does the princess love luigi?
 maybe. I do not know.
>> does mario believe that the princess loves luigi?
 yes. mario thinks the princess loves luigi.
>> bye

The fact that mario believes that the princess loves luigi doesn't necessarily make it so. What we do know is that mario believes it.

A little digression: thus far in our examples, Brainhat has believed everything I've said. Consider, however, that it could all be prefaced with "You say...". It's the subjunctive at work again, just like in the previous example. Why should Brainhat believe anything that I say just because I say it?

% ./run
>> the dog is happy
 the happy dog is happy.
>> what do i say
 You say the happy dog is happy.
>> bye

Brainhat believes what I say because that's the default setting. However, we can change it so that Brainhat registers what I say, but doesn't necessarily believe it. There is a debug flag, verbatim, that we will reset for this purpose:

% ./run
>> debug unset verbatim
>> the dog is happy
 the dog is happy.
>> is the dog happy?
 maybe. the dog.
>> do i say that the dog is happy?
 yes. You say the dog is happy.
>> bye

Once Brainhat is free to believe as it wishes, it needn't trust the code from it's interlocutor. In this example, Brainhat believes the opposite of when I tell it, based on an inference template:

% ./run
>> debug unset verbatim
>> if i say the dog is happy then the dog is sad
 if You say the dog is happy then the dog is sad.
>> the dog is happy
 the dog is happy. the sad dog is sad.
>> why
 the sad dog is sad because You say the sad dog is happy.
>> bye

Concepts for things, attribute, verbs, etc., live in a taxonomically ordered vocabulary. A dog is a pet, a pet is an animal, and so on. At the same time, a dog is a mammal, a mammal is an animal, and so on. We say that pet and mammal are parents of dog and that dog is a child of mammal and pet. Each concept may have zero, one or more parents. The inter-relationships between parents and children can be arbitrary with the exception that no concept can be its own parent. A concept's relationship to its parents and children play a role in recognizing the concept as a specific instance of a general reference to its parent or vice versa.

% ./run
>> is a dog a pet?
 yes. a dog is a pet.
>> is a dog an animal?
 yes. a dog is a animal.
>> is a dog a mammal?
 yes. a dog is a mammal.
>> is a dog a thing?
 yes. a dog is a thing.
>> is a dog a fish?
 no. a dog is not a fish.
>> bye

The answer to the last question, "is a dog a fish", is "no" because fish and dogs are orthogonal within the vocabulary. If I were to ask "is the dog a banana?", the answer would be "maybe." This may seem odd to you; a dog is certainly not a banana as we know it. However, we will see later that we can make a relationship between dogs and bananas by saying "the dog is a banana" or "the dog is not a banana", in which case the answer will be "yes" or "no."

Here's an important point: within Brainhat, yes means something is definitely the child of something else; no means something is definitely not the child of something else (due to orthogonality or a knowledge); or maybe, which really means that the two cannot be compared.

Whole CCs can be compared to other CCs as long as their piecewise components (subject, verb, attribute, object, whatever) have a homologous superior/inferior parent/child relationship.

% ./run
>> dog sees cat."
 dog sees cat.
>> does dog see animal
 yes. dog sees cat.
>> does something see cat
 yes. dog sees cat.
>> does something sense something?
 yes. dog sees cat.
>> does dog see fish?
 maybe. I do not know.
>> bye

We start with the proposition "dog sees cat." We ask "does something sense something?," and this returns true because each of the concepts in the question (something, sense and something) is a parent of the corresponding concept in the answer (dog, sees and cat) and because "something senses something" is the the same shape as "dog sees cat." That is: "thing verb thing."

The last question, "does dog see fish?" comes back "maybe" because fish is not a child of cat, therefore "dog see fish" is not a child of "dog sees cat." Accordingly, we never get to the point where we would ask if fish and cat are orthogonal because the two CCs don't have a parent/child relationship in the first place. The two CCs cannot be compared. This is what we want.

Intransitive

An intransitive verb is one that takes no object. Examples of intransitive verbs are to sleep or to wonder. One does not say "I sleep my lunch" or "I wonder the banana." But, a reflexive "I sleep myself" almost makes sense.

A transitive verb, on the other hand, is one that takes a subject and an object. Examples of transitive verbs are to eat or to want, as in "I eat my lunch" or "He wants a doughnut." Transitive verbs can be used intransitively, too, with a subject implied, such as I eat or he sings.

In Brainhat, intransitive objects are represented by the concept things, which is at the top of the taxonomy for all things--dogs, french fries, potato bugs. So, when you input "mario sleeps", the CC that's generated captures "mario sleep things." Likewise, when you
ask "does mario sleep?", the question is internally represented as "does mario sleep things?"

% ./run
>> mario sleeps
 mario sleeps.
>> luigi talks
 luigi talks.
>> the princess sees bananas
 the princess sees banana.
>> does mario sleep?
 yes. mario sleeps.
>> does luigi talk?
 yes. luigi talks.
>> does the princess see?
 yes. the princess sees banana.
>> does mario sleep bananas?
 maybe. I do not know.
>> bye

Equivalence

In Brainhat, the assignment of one concept as the child of another is termed an equivalence. Examples are "the dog is a banana" or "mario is the king". When "mario is the king" is input, it causes the concept for mario to become a child, hierarchically, of king. The term equivalence isn't perfect; the two concepts are not made equivalent; one becomes subordinate to the other. However, once we say "mario is the king", all of the parents of king become parents of mario.

% ./run
>> mario is an onion.
 mario is a onion.
>> is mario a vegetable?
 yes. he is a onion.
>> bye

We can also say that mario is not something, like so:

% ./run
>> mario is not the king.
 mario is not the king.
>> is mario king?
 no. he is not the king.
>> bye

Orthogonality applies to the relationships formed by equivalences:

% ./run
>> is a fruit a vegetable?
 no. a fruit is not a vegetable.
>> mario is a fruit
 mario is a fruit.
>> is mario a vegetable?
 no. he is not a vegetable.
>> bye

Explicit Inferences

Explicit inference templates are a executable code stored in the subjunctive. Elements of the template--subject, verb, attribute, etc.--are unresolved references to concepts that may fill their spots if the inference is executed. Here's a simple example:

% ./run
>> if i love you then you love me.
 if You love Me then I love You.
>> i love you
 You love Me. I love You.
>> why?
 I love You because You love Me.
>> bye

Here's an inference template with more complicated substitutions:

% ./run
>> if an animal sees something then an animal eats something.
 if a animal sees thing then a animal eats thing.
>> bird sees a grape
 bird sees a grape. bird eats a grape.
>> cat sees a bird
 cat sees a bird. cat eats a bird.
>> bye

Orthogonality makes it possible to build inference templates that would otherwise be difficult to express:

% ./run
>> if a dog sees another dog then the dog barks at the other dog.
 if a dog sees another dog then the dog barks at the dog.
>> a dog's name is fido.
 fido is fido.
>> a dog's name is sparky.
 sparky is sparky.
>> fido sees sparky.
 fido sees sparky. fido barks at sparky.
>> bye

In this case, the concepts another and other signal orthogonality between the second dog and the first dog. By this, we can reference two dogs in an inference template and be able to tell them apart at runtime. Other orthogonality clues can come from first versus second or this versus that.

When the result of one inference provides the input for the next, we say that the inferences form a chain. Chaining is applicable to explicit and implicit inferences alike. Here's an example with explicit inference chaining:

% ./run
>> if i am happy then you are happy
 if You are happy then I am happy.
>> if i see a toy then i am happy
 if You see a toy then You are happy.
>> if i look then i see a ball
 if You look then You see a ball.
>> i am looking
 You do look. You see ball. You are happy. I am happy.
>> why
 I am happy because You are happy.
>> why
 You are happy because You see ball.
>> why
 You see ball because You look.
>> bye

An explicit inference template is executable code. Execution of an inference depends on the conditions of the template being true. When Brainhat recognizes that some knowledge in the context that may invoke an inference, it substitutes elements of that knowledge into the inference template and tests for truth. To be successful, the substituted concepts must be children of the corresponding concepts of the template and there must be no orthogonalities.

% ./run
>> if i see a red house then i am happy.
 if You see a red house then You are happy.
>> i see a house.
 You see a house.
>> Am I happy?
 maybe. You.
>> i see a blue house.
 You see a blue house.
>> Am I happy?
 maybe. You.
>> i see a red house.
 You see a red house. You are happy.
>> bye

The inference does not fire the first time because "I see a house" does not satisfy "I see a red house." The inference does not fire the second time because "I see a blue house" not satisfy "I see a red house." Moreover, it's orthogonal. When we say "I see red house," the condition is satisfied and the inference fires.

% ./run
>> if i see a red house then i am happy.
 if You see a red house then You are happy.
>> i see a house
 You see a house.
>> debug eval i see a house
 You see a house.
 "True"
>> debug eval i see a red house
 You see a red house.
 "Maybe"
>> bye

Implicit chaining occurs when memories are restored. We will look at implicit inferences when we explore memories, later on.

patent pending

Here's Brainhat's rendition of Goldilocks and the Three Bears:

goldilocks girl is goldilocks. she walks in the forest. goldilocks
girl sees a house in the forest. a house in the forest belongs to a
family. first papabear bear is papabear. first papabear bear is
large. second mamabear bear is mamabear. second mamabear bear is
medium. third babybear bear is babybear. third babybear bear are
small. nobody are home.

goldilocks girl does go in a house. she does go into the kitchen.
bowl are in the kitchen. bowl in the kitchen does contain porridge.
the first bowl in the kitchen does belong to first bear. the first
bowl in the kitchen are too hot. the second bowl does belong to
second bear. the second too cold bowl are too cold. the third bowl
does belong to third bear. the third good bowl are good. goldilocks
girl does eat bear's porridge belonging to third bear. goldilocks
tired girl are tired at that she does eat bear's porridge belonging to
third bear.

goldilocks girl does go to the living room. she are goldilocks are
tired. chair are in the living room. bear's first chair in the
living room are belonging to first bear. bear's first chair in the
living room are too large. bear's second chair are belonging to
second bear. bear's second chair are too large. bear's third chair
are belonging to third bear. bear's third chair are good. goldilocks
girl does sit in third bear. she does break bear's third chair.

goldilocks girl are tired. bed are in the bedroom. bear's first bed
in the bedroom are belonging to first bear. bear's first bed in the
bedroom are too hard. bear's second bed are belonging to second bear.
bear's second bed are too soft. bear's third bed are belonging to
third bear. she are goldilocks are tired.

second bear does come home. third bear does come home. the first bear
does come home. the first bear does see somebody've eat the bear's
porridge belonging to the first bear. second bear does see
somebody've eat bear's porridge belonging to second bear. third bear
does see somebody've eat bear's porridge belonging to third bear. the
first bear does see somebody've sit on bear's first chair. second
bear does see somebody've sit on bear's second chair. third bear does
see somebody've sit on bear's third chair. the first bear does see
somebody've lay in bear's first bed. second bear does see somebody've
lay in bear's second bed. third bear does see somebody've lay in
bear's third bed. third bear does see somebody in bear's third bed.
goldilocks girl does jump out bear's third bed.

We're working hard to have a development release before the end of the year. At that time, I will be looking for a small group of developers to test and create content. Write me if you are interested.

-Kevin

August, 1996

You cannot achieve the impossible without attempting the absurd.

This project is called "huey" which is a rough agglomeration of the words "human" and "ynterface." The goal is to make a program that can understand language, maintain context, remember, and answer questions. A lot of work has been done on natural language and cognition by a lot of very talented people; I am trying to be realistic about my expectations for the project. At the same time, I have been thinking about the problem on and off since 1980, when I took a natural language processing course at the University of Connecticut.

My approach is brute force. I am going to go over every corner of the colloquial language, identifying relationships between words and ideas. The machine can compile these into conceptual "families" or topological "neighborhoods"--places where like ideas reside. Together, these relationships will provide a platform for "basic knowledge"--the kinds of understandings that everyone has about the world about them.

New information, taken as natural language, will be compiled into strings of idea "family" identitifiers. A given utterance may be parse any of N ways. Each possibility will be matched against the collection of "basic knowledge," and against the current context to find a best match. As time goes on, the machine may learn more about its surroundings from its conversations with others.

A lot has to go right, frankly. I have dismissed the problem of attempting to make the machine really "know" anything. I believe it is possible to almost know something by knowing things about it.

Anyway, the result should be a lot of data structures and code. Wish me luck.

-Kevin Dowd