[Zero]

Hi,

If you want to make a chatbot, you can choose a language like Rivescript or AIML to code it. Answers are triggered from what was said before.

But if you want to make a thinkbot, a bot where thoughts are triggered from previous thoughts, what would be your dream language? If thoughts were JSON docs, then what commands would you need to make your bot?
 

[ivan.moony]

I think these commands would be mandatory:

1. induce new rules that hold on existing input
2. deduce answers from existing input by given rules
3. generate semi-random thoughts for chit-chat if you're building a chatbot

[DemonRaven]

IF you are talking about adding a memory to a chatbot the personality forge does that. I don't recall off hand what programming language it uses but some thing on that order would work.

[spydaz]

If thoughts were owl files ....
Hmm....

[ranch vermin]

The problem with this is, is how did the thoughts get in there?    If its just what the robot saw,  then its just regurgitation of the text going in. (what you are trying to avoid.)  which is what we do.

Im too snowed under with simpler work, to get the energy to think about this properly.

[Don Patrick]

Any decent programming language, I would say, not a scripting language that reads files to access its "thoughts". I would want to keep a great number of recent thoughts in active memory for fast access. Depends on what you mean by "thoughts" though.

[Zero]

1. induce new rules that hold on existing input
2. deduce answers from existing input by given rules
3. generate semi-random thoughts for chit-chat if you're building a chatbot

I agree, though semi-randomness is maybe not necessary if the system is complex enough.

IF you are talking about adding a memory to a chatbot the personality forge does that. I don't recall off hand what programming language it uses but some thing on that order would work.

No I'm not talking about adding a memory to a chatbot. I'm talking about another kind of bot, whose main activity is not to produce answers to the user but rather to produce "thoughts": answers to itself.

If thoughts were owl files

Yes, it's the same: thoughts are directed graphs, JSON docs containing references to one another. We can put OWL in them.

The problem with this is, is how did the thoughts get in there? If its just what the robot saw, then its just regurgitation of the text going in. (what you are trying to avoid.)  which is what we do.

Thoughts are generated by sensing previous thoughts, and by sensing things from outside the program (like user input or web browser).

An AIML file is basically like

Code

trigger => template
trigger => template
trigger => template
trigger => template
...etc

There are two difficult things with AIML: 1) you have huge files hard to maintain and 2) you end up with answers "shadowing" other answers. Moreover, AIML cannot handle structured data, but only flat strings.

Now, what if instead of strings we were using JSON pieces? We could then react on JSON patterns, and emit JSON pieces, that we would call "thoughts".

Next thing: AIML and Rivescript brains are monolithic systems, I mean: the entire system react as a whole. But we know that it is not how real brains work. Real brains have specialised areas, each of which is good at doing one thing.

So, instead of having one single system taking input from user and sending output to user, we could have "areas", taking input from other areas, and sending output to other areas. It would probably be easier to maintain (and no more shadowing since areas are specialised), and more important, we could have dozens of authors working in parallel on one brain, without interferences.

But now, the brain file wouldn't be like AIML anymore (trigger/template + trigger/template + trigger/template), it would be a little bit more complicated. We need to handle the area network topology, thoughts transfer, thoughts transforming, filtering, and probably many more things that I haven't imagined yet. Hence my question: what commands would you need to make your bot?

I would want to keep a great number of recent thoughts in active memory for fast access. Depends on what you mean by "thoughts" though.

In our case, thoughts would be kept in RAM indeed, it needs to be fast. I'm calling "thoughts" a piece of structured data like JSON, with possible reference to other data.

EDIT: typo

[Zero]

I play first, with trivial stuff. We could have area files like this:

Code

{
  "source" : [
    "AreaName1",
    "AreaName2",
    "AreaName3"
  ],
  "behavior" : [
    { "trigger" : "here some JSON pattern",
      "template" : "here a JSON template"
    },
    { "trigger" : "here another pattern",
      "template" : "here another template"
    }
  ]
}

This one would be straightforward: this area treats information from its 3 sources the same way, no matter where it comes from. But we might want to have different trigger/template pairs for data from different sources. So I change the syntax a little, to allow different behaviors for different sources:

Code

{
	"slot1" : {
		"source" : [
			"AreaName1"
		],
		"behavior" : [
			{	"trigger" : "here some JSON pattern",
				"template" : "here a JSON template"
			},
			{	"trigger" : "here another pattern",
				"template" : "here another template"
			}
		]
	},
	"slot2" : {
		"source" : [
			"AreaName2"
			"AreaName3"
		],
		"behavior" : [
			{	"trigger" : "here some JSON pattern",
				"template" : "here a JSON template"
			},
			{	"trigger" : "here another pattern",
				"template" : "here another template"
			}
		]
	}
}

Wow, tabs are big. Nevermind. Now, these are independent behaviors for different data sources. But we probably want to combine data from different sources. So, instead of outputting directly through "template", we could maybe store things for later, like this:

Code

{   slot1:
    {   source:
        [   AreaName1

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template
            {   trigger:
                    here another pattern
                template:
                    here another template
    slot2:
    {   source:
        [   AreaName2
            AreaName3

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template
            {   trigger:
                    here another pattern
                template:
                    here another template
    main:
    {   source:
        [   slot1
            slot2

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template

(This is some kind of indented JSON, hopefully easier to read.)
Now we have a "main" slot, which can take outputs from other slots. It would react only if it has incoming data from every sources (here slot1 and slot2). If one source didn't send anything, "main" waits. Now, slot1 and slot2 don't output things directly, they just prepare preliminary stuff for "main" to process.

Am I understandable?

[Zero]

I play first, with trivial stuff. We could have area files like this:

Code

{
  "source" : [
    "AreaName1",
    "AreaName2",
    "AreaName3"
  ],
  "behavior" : [
    { "trigger" : "here some JSON pattern",
      "template" : "here a JSON template"
    },
    { "trigger" : "here another pattern",
      "template" : "here another template"
    }
  ]
}

This one would be straightforward: this area treats information from its 3 sources the same way, no matter where it comes from. But we might want to have different trigger/template pairs for data from different sources. So I change the syntax a little, to allow different behaviors for different sources:

Code

{
	"slot1" : {
		"source" : [
			"AreaName1"
		],
		"behavior" : [
			{	"trigger" : "here some JSON pattern",
				"template" : "here a JSON template"
			},
			{	"trigger" : "here another pattern",
				"template" : "here another template"
			}
		]
	},
	"slot2" : {
		"source" : [
			"AreaName2"
			"AreaName3"
		],
		"behavior" : [
			{	"trigger" : "here some JSON pattern",
				"template" : "here a JSON template"
			},
			{	"trigger" : "here another pattern",
				"template" : "here another template"
			}
		]
	}
}

Wow, tabs are big. Nevermind. Now, these are independent behaviors for different data sources. But we probably want to combine data from different sources. So, instead of outputting directly through "template", we could maybe store things for later, like this:

Code

{   slot1:
    {   source:
        [   AreaName1

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template
            {   trigger:
                    here another pattern
                template:
                    here another template
    slot2:
    {   source:
        [   AreaName2
            AreaName3

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template
            {   trigger:
                    here another pattern
                template:
                    here another template
    main:
    {   source:
        [   slot1
            slot2

        behavior:
        [   {   trigger:
                    here some JSON pattern
                template:
                    here a JSON template

(This is some kind of indented JSON, hopefully easier to read.)
Now we have a "main" slot, which can take outputs from other slots. It would react only if it has incoming data from every sources (here slot1 and slot2). If one source didn't send anything, "main" waits. Now, slot1 and slot2 don't output things directly, they just prepare preliminary stuff for "main" to process.

Am I understandable?

This is just an example of how things could be. But we could base it on libraries like this one for instance.

For pattern matching, would JSON Schema be overkill?

Since data is structured, we don't need to search for globs in the middle of a string. In triggers, we could use a simple glob-like pattern definition with string containing
<list> if we expect an array [ ... , ... , ... ]
<asso> if we expect an object { ... : ... , ... : ... }
<atom> if we expect an atomic value like string or number
<any> if we expect anything

Then in templates, we insert what was previously captured by inserting a string containing <2>, which will be replaced by whatever was captured in the 2nd glob.

[ivan.moony]

Then in templates, we insert what was previously captured by inserting a string containing <2>, which will be replaced by whatever was captured in the 2nd glob.

I understand you very well and I think you're at a right path. I'm doing something similar, but I'm developing my own pattern recognition language that includes boolean operations on the trigger side and possible multiple results on the template side. I even think that's how humans generally think: they see something around them and that associates them on some thought, which in turn associates them on some other thought and so on.

What you are describing has more power than simple responding to a template. Consider a case where we have canonical template -> trigger expressions like e1 -> e2 -> e3 -> e4. Of course, if one trigger can have multiple templates then we get a tree of templates. This I call deduction and it is capable of deriving logical conclusions (if you enter logic formulas) or solving math problems (if you enter math formulas) or solving chemical reactions and G** knows what else. On the other side, in the other direction of deduction stays abduction that is capable of answering from what circumstances you have to start to reach some consequence (like what compounds have to be picked to get some chemical solution or answering questions: "Why are streets wet, was it raining?").

I'm not sure, but I think that you're reinventing calculus of constructions, or similar branch of science. Beware, even though I, myself am developing such a branch, I'm not an expert in those existing areas, your approach just reminds me of the branches and of my project. Nevertheless, it all sounds cool and promising to me.

Edit:
If you find this post interesting, take a peek at: https://docs.google.com/document/d/1Q8AxXFFgvGb9cHbpyFCUIzz1IDBJu2Wc1q2yUuVdGEE/edit?usp=sharing
(already published in other thread, don't know if you noticed it, but I didn't want to be rood and leave you without information). It has been some time since publishing this, a lot of things changed now in a positive way.

[Zero]

Well honestly, CoC and Synth are too complicated for me to understand. I understand what they're about, but I could not use them unfortunately. I'm just trying to set up a environment in which a lot of mini-chatbots react to JSON patterns by emitting JSON.

I think I'll go with JSON-Schema for pattern matching and JSONexp for JSON construction. Maybe later use a diagramming library to build structures, but I'm not sure yet.
 

[Korrelan]

Mightn't I suggest if your starting from scratch that you add a simple imagination. A few months ago I posted a conversation with a very simple bot I wrote...

http://aidreams.co.uk/forum/index.php?topic=6458.0#.VeRAzSVVhBc

The theory could easily be expanded to cover more complex situations. 

Objects where just mapped into a 3D array... with size and location, attributes etc. 



Then a set of simple functions either answered or tested requests through a sentence parser. Crude but effective. eg.

Code

'// Move object

Sub MoveO(ByVal nn As Long, ByVal dd As Long)

    FindO nn, cx, cy, cz
    
    Select Case dd
        Case 1 'forward
            If m(cx, cy, cz - 1, 1) <> 0 Then
                s$ = "Can't move the " & NameO(nn) & " forwards because the " & NameO(m(cx, cy, cz - 1, 1)) & " is in front of it"
            Else
                m(cx, cy, cz - 1, 1) = m(cx, cy, cz, 1)
                m(cx, cy, cz, 1) = 0
                s$ = "OK! I moved the " & NameO(nn) & " forward"
            End If
            
        Case 2  'back
            If m(cx, cy, cz + 1, 1) <> 0 Then
                s$ = "Can't move the " & NameO(nn) & " backwards because the " & NameO(m(cx, cy, cz + 1, 1)) & " is behind it"
            Else
                m(cx, cy, cz + 1, 1) = m(cx, cy, cz, 1)
                m(cx, cy, cz, 1) = 0
                s$ = "OK! I moved the " & NameO(nn) & " backward"
            End If
            
    End Select
    
    Text2 = Text2 & s$ & vbCrLf
    
End Sub

Tom and Jane are in a relationship... symbolic representations of them could be placed into an area for relationships. They would be actually 'in' the relationship. They are together etc..

Who's taller... you could measure the actual symbolic size.

What's further, bigger... distances. sizes etc could be mapped and measured.

Do you like... symbolic references to people, objects, places could be physically placed on a scale just measured for results.

Would be a good adjunct/ start point... Just my peneth worth

[ivan.moony]

I admitt, CoC or similar might be an overkill if you trying to build just a chatbot. But cool idea there, with just pattern matching - variable passing might be simple enough not to confuse anyone.

[Zero]

Thank you ivan.moony. I'm here currently, WIP:

Using node-webkit, a JSON editor, a directed graph editor. Components are not yet fully connected, but it's in progress!