Because

Let me first give an example of a ‘because’ statement that a user might say:

I have a dog because I like animals.

This statement is a bit of an oversimplification, perhaps just right for an example.   It doesn’t only specify why I have a dog, but also that I have a dog and that I like animals. All this data should be stored and retrievable so that the system can answer questions like:

Why do I have a dog?

Do I have a dog?

Do I like animals?

So, before we can store the data, we need to find an input pattern that’s able to handle ‘I have a dog because I like animals’. To start with, we could do something like:

I have a $value because $reason [.]

This can work for many possible input values, except that the ‘I’ vs ‘you’ change is difficult to do since there is no knowledge of the context (‘you’ can change into ‘I’, ‘me’,… depending on the context), so this is the least usable pattern, but there are other possibilities.  For example, lets take:

I have a $value because I like $object [.]

or better:

I have a ^value:noun because I like ^object:noun [.]

With this input pattern, we are able to extract all the valid data so that it can be stored in memory and we also have static text for ‘I’, which can easily be transferred manually. A small improvement might be to replace ‘$value’ with ‘^value:noun’ so that only a proper noun can be captured instead of things like ‘I have a pretty big keyboard on my lap sitting there because I like typing’. The same goes for ‘$object’. As in the previous example, ‘typing’ could probably better be transformed to ‘type’ before you store it, so in the pattern you could replace ‘$object’ with ‘^object:verb’ or ‘^object:noun’,… Anyway, lets take a look at how the do-patterns would look like for storing this info:

#user += $value

#user.like.($object) = yes

#user.($value):why = “because you like $object”

In the first line, we create a ‘has’ data item for ‘$value’. The second line adds the ‘object’ to the ‘like’ list, with the value ‘yes’ so that it’s clear the user likes it. And the third line stores the reason why the user has a ‘value’. ‘:why’ is a function that provides access to the ‘reason’ data-tree. What you store in ‘:why’ is completely up to you. In this example, we store a text, between brackets, cause I wanted to preserve the spacing, but you could also treat it as a sub asset (or anything else, like a link to another rule), allowing you to write paths like #user.($value):why.object.

Why

Once you have stored  the information, you can retrieve it again if the user asks a why question. Here’s a possible input pattern that you could use for capturing this question:

Why do I have a $value [?]

or better:

Why do I have a ^value:noun [?]

And the output pattern could look something like:

You have a $value #user.($value):why

or better:

Bot says when:  #user.($value):why

You have a $value #user.($value):why

else:

I don’t know why you have a $value

That was easy enough. The first line is the most basic approach, the only problem with it: if the bot doesn’t know, it returns ‘You have a’. Which is no good. Better to put it in a conditional and check if there is a ‘why’ value, if there is non, let the bot say it doesn’t know. To check if there is a ‘why’ value, simply put the path in the ‘when’ close. This will check if the result of the path has a value. To check if it doesn’t have a value, use the not (!) operator in front of the pattern, like so:

Bot says when: !#user.($value):why

I don’t know why you have a $value

else:

You have a $value #user.($value):why

Improvements

Right now, we have a working system to handle because/why type of things, but it’s not very flexible, I mean, there are tons of reasons why you can have something, and not just because you like something else. Also, there are more people then just ‘I’, so lets improve the input patterns a bit and make things more flexible.

Using the Thesaurus

Lets start with ‘I’. As you had probably already guessed, the thesaurus variables are ideally suited for this. So, here’s an improved input pattern:

^s:pronoun.subject (have|has) a ^value:noun because ^w:pronoun.subject like ^object:noun [.]

Ok, that’s already a bit more complicated. The ^s variable can capture any child of the pronoun ‘subject’.  If you check in the thesaurus, under the pronoun POS, there are a bunch of greyed-out items, one of which is ‘subject’. These are ‘placeholders’, that is: these thesaurus items don’t actually contain a word, only a label. So our ^s variable can’t actually catch the word ‘subject’, but only it’s children: I, you, he, she, they, we, it.

The do-patterns also become a bit more complicated, since we will now have to calculate the inverse of the pronoun and we also have to extract the asset out of it. Luckily, there are some helper functions for this:

#($s:ResolvePerson) += $value

#($w:ResolvePerson).like.($object) = yes

#($s:ResolvePerson).($value):why = “because &w:InvertPerson ^verb.like:conjugate($w:ResolvePerson) $object”

:ResolvePerson is able to extract the asset (or concrete representation) out of a word.  At the time of writing: I and you  are supported. Names, ‘He’, ‘she’, ‘it’,… need some further testing.
:InvertPerson uses thesaurus links to jump from one person to it’s inverse, if there is one. So ‘you’ becomes ‘I if ‘you’ was used as a subject.
:Conjugate will try to find the correct conjugation of a verb, based on the argument that is supplied. This has to be an asset, usually the asset representation of the sentence-subject. So if you want to conjugate for ‘I’, you pass in ‘#bot’. ‘You’ becomes ‘#user’, and so on.

Split the patterns

The second improvement that we can make to the pattern is a bit more radical and relies on a special feature of the pattern matcher. You see, the pattern matching process is not restricted to finding just 1 pattern in the input. It will try to find the longest possible sequence of patterns that it can. That is, if the same words can be caught with a single pattern, this pattern will get precedence over a sequence of patterns. But if the pattern matcher can do a longer match by using 2 patterns instead of 1, that will become the result. This allows us to split up the first part of the sentence: ‘I have a $value’ from ‘I like $object’. opening up a whole new range of possibilities, and more importantly: saving use lots of duplicate work. The do-patterns become a little different though. First the input-patterns:

Topic: HAVE

^s:pronoun.subject (have|has) a ^value:noun

because ^s:pronoun.subject (have|has) a ^value:noun

 

Topic: LIKE

^w:pronoun.subject (like|likes) ^object:noun [.]

because ^w:pronoun.subject (like|likes) ^object:noun [.]

As you can see, not much has changed except that they are now 2 sets of patterns and each set has a version with and without ‘because’ in the front. We could also have written them as:

Topic: HAVE

[because] ^s:pronoun.subject (have|has) a ^value:noun

Topic: LIKE

[because] ^w:pronoun.subject (like|likes) ^object:noun [.]

But we aren’t. Instead, we keep each input-pattern in it’s own rule so that each can have it’s own set of do-patterns. This way, the ‘because’ version can be treated differently. Basically, what it comes down to is this: when there is no ‘because’, we simply store an extra memory field called ‘subj’ which allows us to recall the left part of the asset operation (excluding the attribute). When we have a because, we check if the ‘subj’ field is set and if so, we store the ‘:why’ in this field. Here are the do patterns:

Topic: HAVE

#bot.who = $s:ResolvePerson

#bot.Inverted = “#bot.Inverted because $s:InvertPerson ^verb.have:conjugate(#bot.who) a $value”

#bot.attribute = $value

#bot.who += $value

#bot.value = #bot.who.($value)

#bot.Subj = #bot.Who

#bot.Subj.(#bot.attribute):why = “because $s:InvertPerson ^verb.have:conjugate(#bot.who) a $value”

Topic: LIKE

#bot.who = $s:ResolvePerson

#bot.Inverted = “#bot.Inverted because $s:InvertPerson ^verb.like:conjugate(#bot.who) $value”

#bot.value = yes

#bot.attribute = $value

#bot.who.like.($value) = yes

#bot.Subj = #bot.who.like

#bot.Subj.(#bot.attribute):why = “because $s:InvertPerson ^verb.like:conjugate(#bot.who) $value”

The full code example can be found in {documents}\NND\Demos\Why_Because2.dpl. As you can see, it’s a bit more code then where we originally started. Though if you look a little closer, a lot of it is boiler-plate stuff: store who, attribute, value, subj, inverted.
Key advantage here: with only a few patterns we can have any type of combination: have because like, like because have,  have because have, like because like, because have, because like, have, like, have because like because have,….

The basic set-up is always the same, we dissect the sentence into it’s parts so that they can be reused in other parts. here’s what we need:

• calculate ‘who’ (the asset form of the subject part in the sentence = I, you, he,…) so we can reuse it and don’t have to recalculate it each time.
• store the the inverted sentence, for output generation (can always be useful)
• the attribute and value (‘color’ is the attribute of ‘yellow’). In this example, strictly speaking not really required, but other parts of the concept rely on this data, so best to get used to it.
• subj: sometimes, the ‘who’ isn’t enough to find out where some data needs to be stored. ‘like’ (and most other verbs) is a good example of this. So if we want to get to the correct data path later on, we need to store this new path, hence the existence of ‘subj’.
• If ‘when’, ‘where’, ‘how’,… is also present in the sentence, these are all data parts that can be stored like attribute, value or more complex sub structures.

There are a few extra do-patterns required to get this working correctly. The ‘who, inverted, value, attribute, subj’,… fields of the #bot are all temporarily, that is: they are supposed to be used as mid-term memory, for as long as the current input is being processed, so that the information can be passed along from one pattern to another. This means that we need to remove the data after the input has been processed so that it wont interfere with any of the next input. This can be done from the Chatbot’s properties view (select the menu item view/chatbot properties, next go to the ‘Do after output’ tab.). here’s how it would look like for this example (can be simplified, which we will do in the next example):

#bot –= Inverted

#bot –= Who

#bot –= Subj

#bot –= attribute

#bot -= value

Also, in this example, I only used thesaurus variables. You can achieve similar results with regular variables, but there has to be a small change in the pattern definition for it to work properly. Everything has to do with the fact that a regular variable can only determine it’s end by what is defined after the variable, and if the pattern definition ends with a regular variable, it will collect the remainder of the input and never jump to another pattern. So we need to put something behind the variable if the ‘because xxx’ needs to be handled correctly. This can be done by moving the ‘because’ from front to back like so:

Topic: HAVE

I have a $value [.]

I have a $value because

Topic: LIKE

I like $value [.]

I like $value because

The biggest disadvantage: you need extra patterns to handle a ‘because xxx’ (not shown or included in the demo), but on the plus side, the do-patterns become a little simpler using this type of pattern definition style. For a complete example, see: {Documents}\NND\Why_Because.dpl.

Sub topics

There’s one more trick we can use to make the patterns more flexible and which will also resolve a final problem caused by using multiple rules as we did in the previous step. You see, finding a list of unrelated rules is primarily done to recognize multiple sentences in the input and not for splitting up a single sentence. That’s because all the outputs from those rules are always automatically combined. So you can’t change the order or content. This can make output management a little tricky.

The solution comes in the form of sub-topics or sub-rules. With this technique, it’s possible to reference a topic or rule by it’s name from within a pattern in the same or other topic. This allows us to split the ‘because’ out into a third topic and then group them all back together into a single rule, which will be the final, single result. So, on the input side, it becomes more flexible, and thanks to a special variable ‘$output’ and a switch in the chatbot properties, we can also take control of the output side. more on that later, lets first start with the input patterns, how do you declare sub-topics?

Topic: HAVE

^s:pronoun.subject (have|has) a ^value:noun

Topic: LIKE

^s:pronoun.subject (like|likes) ^value:noun [.]

Topic: BECAUSE

because

Topic: BECAUSEHANDLER

~have

~like

~becauseHandler ~because ~becauseHandler

The first 2 input patterns should be familiar by now, nothing has changed since before, only the ‘because’ version has been eliminated. The first new topic is also nothing special, just a single word ‘because’.  The magic happens in the last topic, which groups all the other topics together.

~ is used to indicate a Topic reference. It’s always followed by the name of a topic and possibly a dot followed by the name of a rule. It’s meaning is simple: include all the patterns in the rule(s) of the specified topic at the location of the reference. Here’s an example for sub rules:

~have.statement because ~like.statement //presumes that topics ‘have’ and ‘like’ have a rule labeled ‘statement’

Now, if you look at the last topic: ‘BECAUSEHANDLER’ you’ll notice that it only contains references to other topics, it’s a root topic. In this example, it’s purpose is to provide a place to declare the output for every topic, so we can combine things correctly + it also stores the ‘why’ relationship. Also, if you look at the last pattern, it references it’s own topic, 2 times. This is recursion and allows us to recognize a sequence of ‘becauses’ like: I have x because I like y because I have z,….

You might be wondering why it’s the BECAUSEHANDLER that stores the ‘:why’ link and not the ‘BECAUSE’ itself. That is because at the time of the ‘Because’ pattern, the reason is not yet known (this is defined in the next pattern, which hasn’t been processed yet), so it can’t link anything up yet. To overcome this, we make certain that there is an extra rule that gets executed after every other part of the sentence: the BECAUSEHANDLER.  In other words, the ‘becauseHandler’ is a way to perform some code after all the patterns have been processed.

By the way: topic names can be edited in the ‘project view’ (select the topic, press F2 or right mouse click/rename). A topic name should be unique within the project if you want to use it as a sub-topic, otherwise it’s not that important, but the UI will always warn about duplicate names and those topics will have a red icon instead of blue. The name of a rule is always visible in the ‘description view’s title when the rule is selected.  It can be changed in the topic editor: select the entire rule (don’t click on a pattern, but on the background of the rule). With F2, you get a dialog to change the name.

Let’s continue with the do patterns.  For ‘have’, ‘why’ and ‘like’, they remain very similar: the patterns are used to store the inverted sentence, who (asset), the attribute, the value and the ‘subject’. In this example though, instead of directly storing it under the ‘bot’, it is stored underneath ‘mem’ so that we can move the entire result set with 1 statement later on. So here’s a small example of the ‘have’ do-patterns:

#bot.mem.attribute = $value

#bot.mem.who = $s:ResolvePerson

…

And so on. The really interesting stuff happens in the ‘BECAUSE’ and ‘BECAUSEHANDLER’ topics. Note that this time, we have some do-stuff in the ‘calculate’ area and others in the ‘do’ section. The major difference here: ‘Calculate’ is done, just before any of the conditions are evaluated, so this allows us to do pre-calculations that can be used in those conditions.

Topic BECAUSE:

#bot.because = #bot.mem

#bot -= mem

Topic BECAUSEHANDLER:

Rule ~becauseHandler ~because ~becauseHandler

Calculate:

$result = “because #bot.mem.Inverted”

$path = #bot.because.Subj.(#bot.because.attribute)

Output when: #($path):why == $result

Yes, I now #bot.because.inverted because #bot.mem.inverted\.

else

I see, #bot.because.inverted because #bot.mem.inverted\.

       Do

#($path):why = $result

Rule ~have

$output

First off, BECAUSE: this moves the ‘mem’ field to ‘because’ and ‘mem’ is cleaned/deleted. Basically, we store the data of the previous sentence and prepare to collect the data for the next sentence. The ‘because’ field will later on be used to link to the newly collected ‘mem’ field. Note that this rule doesn’t generate any output.

Secondly comes the ‘BECAUSEHANDLER’. This builds up the result that needs to be stored in ‘:why’ and calculates the location where this info needs to be stored (in $path). Before actually committing the data to memory though, a check is done to see if it was already known. If so, a different response is given compared to when it is not yet known. In the latter case, the info is also stored.

For the other rules (~have and ~like), we simply declare the $output variable in the output section, indicating that we want to reproduce the output of previous topic.  Note that the use of this $output variable can be controlled in the chatbot’s properties view. When turned off, it will function as a regular variable, and the output of all the patterns will simply be combined. This allows you to select between a simple styled bot or something more advanced.

Finally, as already mentioned, we still need to do some clean-up after the input. Since we have grouped all the mid-term memory in 2 fields: ‘mem’ and ‘because’, cleanup becomes a little simpler (Note: sometimes the ‘because’ part doesn’t exist, but that’s ok, nothing will be removed in this case):

#bot –= Mem

#bot -= because

I guess that’s about it for now.

Well, we went from simple, straight forward, fire-cracker-leveled patterns to something that’s more akin to ‘rocket science’. The combination of memory, thesaurus and sub-topics might just turn out to be a very explosive mix. I for one, am very interested to see where all this will eventually lead too… Stay tuned.

Short term memory

Or also called ‘volatile’ as it’s content is lost in time, can be accessed through the use of variables in the patterns.  Input patterns support 2 types of variables: regular variables, which can collect any type of content and thesaurus variables, which can only collect words that are equal to or are children of the thesaurus item referenced by the variable (in other words, they are filters). Asset variables, a third type of variable, is theoretically also possible, but not yet implemented. These are also filters, like thesaurus variables, except that they filter on concrete (asset) data instead of abstract (thesaurus) data.

The basic usage of this short term memory is simple: to provide a mechanism for collecting values of variable parts in the input patterns so that these values can later be used in the output and do-patterns for providing a response and feeding the long term memory.

Regular variables

As already mentioned, regular variables can’t filter on the values that they collect, but they are optionally able to limit the number of words that they collect, either as a specific number or a range. Here are some short input-pattern examples:

I’m called $var[.]

I’m called $var:1[.]

I’m called $var:1-3[.]

I’m called $var:4:CollectSpaces[.]

Copy $from:collectSpaces to $to:collectspaces

The $var constitutes the variable (‘$’ is the variable operator, followed by the name). Every word (except spaces, if ‘CollectSpaces’ is not specified) is collected by this variable until the pattern matcher finds a word in the input that follows the variable in the pattern or until the range is fully used. This variable can then be used in the output and do-patterns of the same rule (and also from other rules, if you are certain that the input-pattern is part of the result set, which can be checked upon, more on that  later).

Thesaurus variables

Thesaurus variables are a special type of input variable: they provide a mechanism for filtering possible input to a sub-branch of the thesaurus. If the input can’t be found in that branch, the pattern wont be activated. So, this is a filtering mechanism. The actual value that was found, can be accessed like any regular variable, through it’s name. There is no mechanism for providing length or range values though since they have no meaning here: it’s either an exact match with a thesaurus node or it isn’t. Here are some examples:

I’m called ^var:noun [.]

I’m called ^var:noun.name [.]

I’m called ^var:noun.(first name) [.]

I’m ^var:number years old[.]

A thesaurus variable always starts with  a ‘^’ followed by it’s name. The ‘:’ indicates the start of the thesaurus path and should always be followed with a POS (part of speech). These are the supported POS values:

noun, verb, adjective (or adj), adverb (or adv), article (or art), pronoun (or pron), conjunction (or conj), interjection (or inter), preposition (or prep), number, integer (or int), double.

You can stop there, which would indicate that you want any word of the specified part of speech. You can also continue the path with a ‘.’ followed by a text value (put into brackets if it’s multiple words).  This allows you to further refine the thesaurus path. Note that you don’t need to start at the root of the thesaurus that you are using, just as long as you are comfortable that it will point to a unique word within the tree (otherwise you can have multiple matches,… which might also be desirable). Note that the last 3 POS values (number, int and double) can’t have any further path specifiers, they have to stop at the POS value.

Collecting multiple values

It’s possible to use the same variable name multiple times in the same input pattern. This allows you to collect a list of values for the same variable. Thesaurus and regular variables can be intermixed. Here are some examples:

{$name ,} and ^name:noun.name are here  //catches something like: Tom, Flint and Warner are here

Note that there is a difference when a regular variable collects multiple words at a single location compared to when it collects single words at multiple locations in the pattern. When a single location collects multiple words, this group of words is combined into a compound word (as in ‘baby gear’), but when words are collected at multiple locations, a list is created. This list can later-on (in the long term memory) be labeled as AND, OR or LIST (unspecified).

Using short term memory

Up until now, we’ve only been talking about how to collect the values for the short term memory.  Of course, there’s no point in doing that unless you can actually do something with these values. That’s done in the output and do-patterns. As already mentioned, you access the content through the variable names. Here are some output-pattern examples:

Ok, I see, your name is $var\.

So you are $var, nice to meet you!

So, you can $verb:Infinitive, can you?

I see, $name:interleaf(“\, “, ” and “)

At it’s most basic form you specify the ‘$’ operator followed by the name of the variable that you want to render. Note that you should always use the ‘$’ operator while rendering, even if the value was collected using a thesaurus variable ( ^ ). This is because the ^ operator is used to access the long-term, abstract memory (the thesaurus data itself).

Rendering the value as it was collected, is useful but often we want to do a little more, sometimes we need to do some kind of change or transformation to the values, like conjugating a verb, get the plural of a noun or find the attribute for the value (see later),…  This is done through functions that you define in the path. A function starts with a ‘:’ followed by the name of the function (a list of all the available functions will come shortly) and optionally a list of arguments for the function, specified between brackets and separated by a ‘,’. Note: if you use the ‘,’ sign as an argument value, it must always be escaped with a \ Also, if you need to preserve spaces, the argument should be placed between brackets (as in the last example).

Long term memory

The second major type of memory that’s available to the bot is used to store and retrieve values so that they can cross the boundary of the single-shot input/response system, in other words: long term memory. Currently, there are 2 types: a thesaurus structure for storing abstract information and assets which maintain concrete knowledge.  Typically, you use this data to compare against short-term variables, render previously stored data or store newly acquired knowledge.

The thesaurus

As already mentioned, thesaurus variables are used in the input-patterns so that the valid content for a variable can be filtered.  When the ‘^’ operator is used in output, conditional or do patterns however, it behaves a little bit different: it becomes a value generator instead of collector.  Consider the following output patterns:

We are in ^noun.month[$time:month-1]

I like ^noun.food.(Italian food):random

I ^verb.be:conjugate(#bot) trying something complicated   //render: I am trying something complicate

As you can see, a thesaurus output-path contains a mix of statics and functions which eventually result into 0, 1 or 2 values. Because they render values and don’t collect it, no name is required. You can use the [] operator to select a child at a specific index position, like in the first example, which is used the generate the name of the month instead of a number. Note that the index is 0 based. In case that a static path item contains multiple words (like ‘Italian food’), use () brackets to group them. Also, if there are no values found for the path, any spaces that follow it in the output are stripped.

You can also store new data in the thesaurus. This is done in the calculation or do-sections. There are basically 2 operations that you can do at 2 different levels: you can add or remove values either as thesaurus children or as conjugations/references. To explain the difference between children and conjugations or references, take the following examples and how they are stored:

In the first example, we are declaring a child relationship: house is a building. If you have done any coding before, the syntax might be vaguely familiar: the left part of the statement contains the thesaurus path, the ‘+=’ operator to indicate that we want to create an ‘is child’ relationship, and on the right-side comes the value that needs to be stored. This could be a variable reference, an asset, another thesaurus path,….

The second and third examples look identical and for all intent and purpose, they are. The only difference is on the inside: in the first example ‘plural’ is a known conjugation form, ‘opposite’ is not. The statement used for storing this information, is a little bit different. First of, the thesaurus path ends with a ‘->’ followed by the name of the relationship that you would like to edit. Next, we use the ‘=’ assign operator instead of ‘+=’ to indicate that we want to change the relationship value.

The 2 last examples demonstrate what happens when you use the –> operator together with the += assignment or when you use multiple –> operators. When combining += with –>, you will first calculate the full result of the left side.  So in our example, we first take the singular value of ‘birds’, then we add a child to this result, which is ‘bird’. A similar thing happens when you use multiple –> operators: the value is calculated.

Except for the POS value at the start of the path, every other item in a thesaurus path can be a static, a variable reference, an asset path or another thesaurus path. This allows for tremendous flexibility in the way that you store data. We could generalize some of the previous statements like this:

^noun.building += $value

^noun.($singular)->plural = $value

^adj.good->($relationship) = $value

Removing values from the thesaurus is done using the ‘-=’ operator or by assigning to the ‘null’ value. Like with storing, all parts can be static or variable. This is probably best explained with some examples:

Assets

As already mentioned, assets could theoretically also be used in the input, but that’s not yet supported. If someone has a need for this, let me know, it’s not that tremendously difficult to add, it just creates a little more overhead.

Anyway, like thesaurus paths, asset paths can be used in output, do and conditional patterns. They are declared in much the same way as thesaurus paths by using the ‘.’ (dot) or ‘:’ (function) operators, except that they start with a # and ‘–>’ (links) are not supported.  For the thesaurus path, the ‘.’ (dot) operator selected a child node, for assets, this selects an attribute value. Here are a few output examples:

My name is #bot.name

your children are called #user.child.name:interleaf(“\, “, “ and “)

a book is made of $(#(^noun.book).component.name):interleaf(“\, “, “ and “)

Bot and User are hardcoded assets and refer to me and you respectively, from the bot’s point of view. In the third example, the first value in the asset path, is actually a thesaurus path. This results in concrete information about abstract data (a book is made of paper, ink, glue,…).

Also in the last example, the entire asset is the first value in a normal variable path, because an asset path will always calculate it’s result based on 1 value, if the previous path item resulted in multiple values (like ‘component), the next part of the path is calculated as if there was only 1 result (internally, a split is done), and only at the end of the path, all results are joined. This doesn’t work for ‘:interleaf’, it expects a list of values to combine. A variable path can do this, hence this construct.

To store asset data, the = (assign), += (assign add), != (assign not) and !+= (assign add not) operators are used. Removing data is done with the –= (assign remove) operator.   Take the following examples (input statement to the left, how to store/remove it to the right):

When you use the ‘=’ (assign) operator, you declare an ‘is’ relationship: ‘color’ becomes the attribute, ‘blue’ the value. Since ‘blue’ is not an asset, but just a word, we have a terminator: blue can’t have any more children.  But, there is a way to cross this border, by using the ‘:extra’ function, as in the 5th example.
If instead, you want to declare that something is not y, you can use the not-assign operator (!=). This allows you to still store the information that something is not. Be careful though, there is a thin line between being and not being, if you don’t check on this in the conditions, you might say that something is, while it isn’t (sounds familiar?).

The ‘+=’ or assign-add operator is used to create ‘has’ relationships, like in the second example. The major difference with the first one is that ‘dog’ becomes the attribute and the value becomes a new asset that will represent the dog. There is also the not version:  !+= which is used to indicate that the asset doesn’t have something.

If you want to create a list of values, you can use either the ‘;=’, ‘|=’ or ‘&=’ operators. The first one creates (or adds to) a generic list, the second is for OR lists and the last for AND lists. The generic list operator can add to any type of list without modifying it’s type. The |= and &= operators will change a generic list to OR and AND respectively. When you try to add an item to an OR list with an AND operator, you create a new list object that contains the original OR list and the newly added item. the same goes for an OR operator with an AND list.

Finally, you can also actually remove an attribute value. This is done with the ‘-=’ operator. The  right-side should be the name of the attribute that you want to remove. The value that is removed get’s cleaned up automatically, so if the value was another asset which isn’t referenced anymore after the remove, the entire asset will be destroyed. (Removing items from a list has to be done with the ‘:Remove’ function.)

As already mentioned, every asset value can always use the ‘:extra’ function to get to a sub-asset. There are a few other functions worth mentioning which allow you to expand the dataset that the asset can store. These are used to declare things like when, where, why, how, amount,… Functions are:

Mid term memory

Some functions, like the ‘:attribute’ function (which is able to extract, for instance,  ‘color’ from ‘blue’, or ‘name’ from ‘Jan), make use of context, if it is declared. This context is usually a list of asset paths that point to some memory region of the bot. The idea is that, together with a response, you also generate the meaning of what was said and store this information in the asset that you declared as context. If you refresh this context on each run, you effectively have simulated mid term memory.

The basic setup for using mid term memory consist out of:

• a global context declaration so that the system knows where to go look for contextual info.
• some global do-after-each-statement patterns. These are responsible for erasing the previously collected data and possibly creating an echo.
• some global do-on-startup patterns which will remove any data from the previous run.
• do-patterns on each rule to actually collect the knowledge about what is being said.

Context:

#bot.memory.subject

#bot.memory.attribute

#bot.memory.object

#bot.PrevMem.subject

#bot.PrevMem.attribute

#bot.PrevMem.object

 

Do after output:

#bot.prevmem = #bot.memory

#bot –= memory

 

do on startup:

#bot –= memory

#bot –= prevmem

 

on pattern (example pattern = I like $value [.])

#bot.memory.subject = #user

#bot.memory.attribute = like

#bot.memory.object = $value

 

Mid term memory also becomes very useful once you start working with recursive sub rules/topics. This technique allows you to rebuild the extracted data.

Patterns

All the different types of patterns (input, output, conditional) could also be considered as a form of long term memory. Internally, they are stored in exactly the same manner as all the other data. As such, they can also be manipulated in a similar manner as the other long term data. Although, at the time of writing, there is still limited support for this.  More on that to come.

I’ve been having a huge smile on my face all day

For the interested, here’s a screenshot of the rule that enables this trick (click to enlarge):

The important bit is the :complete after the variable $ToComp which performs the calculation.

Here’s another screencast that shows what’s happening behind the scenes (basically, it’s a walkthrough of the neural code in the designer):

Note: Deprecated!

An introduction

In short, a flow is a template definition of recognizable data. It is used to transform a stream of neurons into another stream of neurons (doesn’t sound very useful, but trust me, it is).  To get a visual image on how a flow works, you can perhaps think of those toddler toys where the child needs to fit different types of blocks into different types of wholes (see image).

Well, a Flow is the yellow filter at the top of the box. As the blocks pass along, a flow tries to find a set that fits it’s filter. When it finds one, it collects this set, tags it, and stores it for further use. This process is done by the flow recognition algorithm.

A flow is a template definition, used to recognize sequences of data in a stream.

flow items

So, what is this filter that’s supposed to recognize the data, actually constructed of? Well, flow definitions are very (mmm, perhaps not so very) similar to Coco/R definitions. In short, you use constants, other (nested) flows, loops and options to build up a definition. Here’s a short example:
This flow can recognize the sequence: Agent verb possibly followed by a not. It’s actually the definition for the simple past tense (there’s an extra hidden filter on ‘verb’ which I’m not showing yet for this example). ‘Agent’ is underscored, indicating that it is another flow, verb is not, so it’s a static, like not. Which is surrounded by strait brackets, indicating that it’s optional. So basically, this flow can recognize statements like: I swam, you dug, the brown men found not,… Without the filter (like here), sentences like: I fish, they eat not,… would also be recognized.

Statics and nested flows

Most of the items in a flow definition tend to be statics and other, nested flows. This forms the meat, the data that can be found in the input stream itself. When 2 statics are declared in sequence, the same sequence needs to be found in the input, without anything in between.

Nested flows can easily be recognized. They are underlined. If you double-click on them, you will jump automatically to the flow (you can navigate back and forward between the selected flows using the navigation commands). Behavior-wise, nested flows are the same as statics. If you declare 2 nested flows in sequence, the input stream should contain the data for the 2 flows in the same sequence.

Floating flows

A floating flow is a special type of flow that can be recognized anywhere in the stream without having to be specifically declared in any other flows. They are mostly used for things like spaces and newlines. You usually don’t integrate them into other flows, as nested.

Floating flows can be destructive or not. When a destructive flow is found, it will break up the recognition of other data in the stream. So this type of flow can not be found between 2 statics, but can be between 2 nested flows or between options, loops or conditional parts (see further). If you need to have a floating flow between 2 statics, it needs to be non destructive. The type of flow can be assigned from a context menu on the flows: you can select for normal flows (not floating), floating (visualized by a green bar in front of the flow) and non destructive floating (displayed using a blue bar).

You can also specify if the data that a floating flow finds is discarded or not. Discarding the data can be useful in cases where you are really not interested in it, like for empty space. This is also selected from the context menu on the flows and is visualized by using an extra bar at the end of the flow.

Options

With an option you can define a number of different paths, from which 1 can or has to be selected. The following example of options defines the ‘can’ verb:A blue block (also called ‘conditional part’) represents a single path. If the frontal bracket of the options contains a vertical line, 1 path has to be selected, if there is no line, no path has to be selected but 1 can be. The content of a conditional has to be recognized in the same sequence as the way that it is defined and can consist of statics, flows, loops and other options, but no conditional parts. The option itself can only contain conditional parts.

Just like statics and nested flows, you can also reuse the same option in different places. In fact, the more you can do this, the more processing power can be saved. The same goes for the conditional parts (the blue blocks). These can also be shared by different options (and loops). This can be done by drag and drop from within the editor.

Loops

Loops are very similar to options, they also consist of conditional parts and they can also be defined with a vertical line in front, indicating that 1 path has to be selected or not. The main difference with options is that a loop can recognize 0, 1 or more of it’s conditional parts in sequence. They are declared using curly brackets, like in the following example: This loop simply declares a sequence of digits, with at least 1 required digit. In other words, it’s the definition for an integer.

Loops can have some more lines in the front to declare extra info. If there is a green line present, to the right of the black one, it means there can’t be a floating flow in between 2 conditional parts, otherwise this is allowed (see floating flows). A red line to the left of the black one, indicates exactly the opposite: 2 conditionals need to have a floating flow in between them for a valid parse (not often used).

As a final example, here’s the entire scanner definition which is used to recognize words, numbers (integer and doubles), signs and spaces:

For instance, the abstract can be ‘a house’ while the concrete is ‘The house that I live in,… my house. Aici needs a way to distinguish the 2 and be able to find relationships between both. This is done through the use of different data structures.

Objects

Lets start with the objects, these are the simplest. They represent abstract knowledge. Every interpretation of every word is represented by an object. For instance, ‘house’ can mean the house that you live in, but could also refer to a musical style. So there is an object for each interpretations of the word. Furthermore some words can have synonyms, words that have the same meaning. For instance, ‘house’ and ‘home’ could be considered as synonyms, or house and ‘house music’. With ‘house music’ being a compound word: 2 words joined together to form a new meaning. Other examples of compound words are: car factory, fire hose, film studio,…

Another bit of information that can be useful to know about a word, is how it should be interpreted in the context of a sentence: can it be a noun, verb, adjective,…. Sometimes, a word can have multiple interpretations, while being used as the same sentence type (like house), sometimes multiple sentence types are allowed for a single meaning (colors for instance can be used as adjectives or nouns: ‘my eyes are blue’, ‘that blue is pretty’ ). As a speed optimization, we group all the objects together that have the same part of speech, but with different meanings in ‘Pos-groups’, though this is not required.

As a visual example, let’s take the objects ‘hello’ and ‘goodbye’ (as in a greeting). Both are nouns (it’s an hello and a goodbye). Both have multiple synonyms: hi, howdy, bye,..  So here’s how this would look like:

Relationships between objects: the Thesaurus

Objects are stored in a thesaurus like structure to indicate relationships between them. For instance, both ‘aici’ and ‘jan’ are names, so  this could be expressed in a thesaurus relationship like in the 2 images below:

Notice (to the left) that the ‘noun’ filter was selected in the thesaurus together with the ‘is a’ relationship. To the right, you can see how this is represented internally: Name points to an ‘is a’ cluster, which contains all the related objects. So the ‘Noun filter works by only displaying objects that point to ‘noun’ or are clustered by a ‘noun’ pos-group while the ‘is a’ relationship will filter out all but the clusters attached to the roots using this ‘is a’ neuron.

Sometimes a root object doesn’t have any children (as in cluster-children, not in the thesaurus). This makes the object a dummy, a placeholder that shouldn’t be used for input or output directly, but only for filtering. Some examples of these dummies can be seen when the ‘pronouns’ are selected.

The thesaurus relationships can be used in frames to filter the input in a general way and to perform lookups by the actions. For instance, the ‘be name’ frame (in the ‘names’ editor) has an ‘object flow’ element that filters on ‘name’ through the ‘is a’ relationship, as seen in the image below.

This means that the frame is only selected when the input contains the result of an object flow that is the child of an ‘is a’ cluster, attached to ‘name’ or one of it’s thesaurus children (so multiple levels are allowed).

To create this type of filter by the way, you simply drag ‘name’ from the thesaurus to the filter area.

Actions also make use of these thesaurus relationships in a very similar way. For instance, an action could check if an object  is allowed to/can be the name of something (‘my name is Jan’). Or, in sentences like: ‘this is blue’, the thesaurus is used to find out what ‘blue’ actually is: a color (I’m jumping here, keep with me, It will become clear very soon).

An object can also be the child of multiple items in a thesaurus. For instance, ‘blue’ is both the child of ‘colorful’ and ‘sad’ (child of ‘emotional’). Note that these are all adjectives, hence we say ‘colorful’ instead of ‘color’. To find out which relationship to take, we can make use of a log of previously made statements or a list of focused objects. The most important usage of either color(ful) or emotion(al) in this log, triggers it for the new input. Most important can be interpreted very broadly: it could be ‘newest log item’, or ‘most talked about’,… If it is impossible to solve this, a question needs to be asked.

Anyway, once you have figured out which path to take in the thesaurus: colorful, we still have an adjective. If the same logical concept/idea can be expressed in multiple parts of speech, using different words (like color-colorful) and you want to be able to jump between the 2, you need to have a relationship between them. As I already stated, we interpret ‘blue’ as a ‘color’, not ‘colorful’. Why, will become more clear when we talk about the assets, for now lets just take it that we need to change from adjective or verb to noun. As you can see in the image, the thesaurus has a special section to define this type of relationship: the left part of the table contains the link meaning, the right section is the ‘from’ part of the link.

The same can be done for verb conjugations. In English, a verb usually has 3 different conjugational forms, other languages have others, so the thesaurus allows you to define this type of relationship free form, much like the part of speech relationships. When you create a new verb though, the designer will try to fill in all the conjugations (if it finds neurons titled ‘present particle’, ‘past particle’ and ‘third person present’. It’s always best to check them before storing the default though, since it doesn’t know about irregular verbs and sometimes it/I may simply goof up.

The verb conjugations, compared to the part-of-speech relationships, are used a bit differently. These serve their purpose while parsing the input and generating output. Some flow elements try to search for conjugation relationships while filtering (in the ‘FilterCode’ tab) in order to get the correct parse. For instance, in the ‘model verbs flow’, this is used to make certain that a verb is the present particle. The same goes for generating output: when a verb is used in certain situations (ex: ‘what’ contains a verb instead of a noun), we need to generate it’s present particle form (or another, depending on the exact situation).

Assets

Up until now, all relationships were between objects, so between abstract knowledge only. To record a network’s experiences (the data that it records), we use assets and asset relationships.

At it’s core, an asset is a cluster with meaning ‘asset’ (we’re very original here), which contains a number of child neurons that represent property-value pairs for that asset. This is done through links to objects and/or other assets, using the meanings: attribute, value, amount,… From this basic structure, we can start to play and create meaningful relationships.

As usual, a picture says a thousand words, so to the left, I’ve displayed a debug view of the ‘text channel’ neuron (the text input channel of AICI). Why this neuron? If you look closely, it has a link that points to an ‘asset’ cluster, using the meaning ‘Pr:You’. So with this image, I’ve got 2 birds with 1 stone: the asset and how to find the asset that AICI is using for the person on the other side of the channel .

A text channel stores a reference to the asset that represents the entity it is communicating with using a link with meaning ‘Pr:you.

As a side note, linking ‘you’ to the text channel, allows the system to talk to multiple users at the same time: each on their own channel.

So what’s stored in this asset anyway? As you can see, there are 2 child neurons in the asset, so 2 data items: the first has an attribute (property) of ‘entity’ and a (property) value of ‘animate entity’. The second asset-child  points to ‘eye’ for the attribute, the value is another asset and it has a general amount of ‘plural’.

Note that the attribute should always be a noun. Having a fixed transformation point facilitates the search.  Why a noun: well, all adjectives and action-verbs can be converted to a noun, but not the other way round. This conversion can be done using the part of speech relationships that were previously described.

The ‘entity’ property is how AICI tries to classify assets: is it an object, animate, animal, human,… If you look at the thesaurus (in the designer), ‘entity’ is a noun-root and the asset-child’s value is one of it’s children. This is a rule: when the value is an object, it must have a thesaurus relationship with the attribute. This type of child asset represents the ‘x is an y’ type of relationship. Here, it is ‘I am an animate entity’, an other example could be:  ‘I am a human’, which would/should map to the same asset-child.

- An asset-child with an object as value represents an ‘x is an y’ sentence structure.
- In this case, the value must have a thesaurus relationship with the attribute. This relationship can span multiple levels.

AICI at the moment,  presumes that an ‘entity’ that is able to communicate through a text channel, must be animate (mammal, AI,…). So, even if this information is not yet provided, it is presumed to be the case. This is done cause the property and value play a role in other parts of the network.

The second asset-child has another asset as value. This type of relationships represents the ‘x has an y’ sentence structure. More specifically, in this example we said: ‘I have blue eyes’. This also explains the undefined ‘plural’ amount: eyes is plural and was converted into a single value, but since we don’t know exactly how many, we keep a ref to the multiple. The sub asset also has it’s own child-asset, which defines the ‘color-blue’ part of the example sentence. Through this nesting, it is possible to describe complex entities that consist out of multiple parts of knowledge.

An asset-child that references another asset as value, represents an ‘x has an y’ sentence structure.

Objects referencing assets

Assets aren’t exactly islands, independent of everything else. No, they too are referenced in many different ways. We already saw 2: assets attached to child-assets, and to the text-channels.  There’s one more reference worth mentioning at this moment: objects that reference assets. Yes, assets don’t just reference objects, it can also go the other way round. This is used to represent general knowledge about general things, like: ‘a human has hands’, as depicted in the image to the right. The same thing is also valid for statements like ‘an x is a y’: they are represented as assets, linked from objects.

Note: I did a bit of recycling with regards to the meaning of the link from the object: it also uses ‘asset’, which is the same as the meaning for the cluster.

An object that references an asset cluster, using ‘asset’ as meaning for the link, is used to represent statements of the form: ‘an x is/has a y’

The important difference between stand alone assets and assets that are linked to objects, are the information that they represent about the agent of a sentence: stand alone assets represent concrete agents: I, you, the book,… while object referenced assets represent abstract agents: a book, a human,…

These 2 data structures: objects and assets, are simple, but, I believe, flexible enough to represent a whole world of information. It is not as much the the querying and reshaping of the data as it will, in the end, be the automatic creation of these structures which I believe will ultimately be the truly interesting thing. With a query, we can retrieve data, reshaping it allows us to find truths, fallacies and falsities in the data, but a correct automatic creation of a new, complex asset, is in fact, a new entity.

In the end, all is just structure.

In case you are looking for a mental image to visualize this whole concept, try this: Resonance. When a link gets activated (for instance, the one to the very first neuron), it creates a resonance that triggers one or more other neurons. This excitation in turn can cause another link between 2 neurons to be activated, causing more resonance and so and and on until the whole thing settles down.

I have absolutely no prove or idea that this is how it works in the real world, that’s just how my model can be interpreted. Truth be told, this is not how I conceived the thing (aka lets try to create a model that uses resonance), it was rather more like: I have 2 neurons, they are linked, how can I make something happen? Well, I can attach some code to the link and execute that. Cool. But, wait a moment, that looks like resonance…

and we just passed ‘culminate’, pfff