User's selecting a personality type for the chatbot they talk to

I was thinking it would not be hard to have a number of auxiliary responses that can be peppered into an otherwise straight chatbot dialog for product ordering. By grouping such responses into different types you could easily achieve a sense of "businesslike" (no added phrases); "playful" (added phrases are jokes); or "abusive" (added phrases make fun of the user).
No sooner thought than the obvious comes up: how many people will choose an abusive dialog?
Joking aside, another type is "helpful" (added phrases are recommendations  and pieces of relevant information).

What is a conversation?

There are surely many ways to look at "what is a conversation?" One would be from the outside where you classify conversation modes into "harmonious" or "discordant". Another might be to acknowledge that different conversational roles are possible for the conversants. So free-form discussion between "equals" is different from instruction from teacher to pupil, or from boss to assistant.

Perhaps a flaw in generic chatbot thinking is that no such role definition is needed, or that discussion between equals is the correct default. But for a good order chat bot, my vision is that it is taking instructions from the boss, asking intelligent questions, and offering helpful reminders and suggestions. But it does not need any more of an agenda than to keep the discussion focused on an order being completed and moving forward.
Update: Another conversational mode is where two people share an agreement - whether about something they observe together, or something they speculate on - painting pictures for each other.

We still look ok

 

I guess I like this picture. Taken by Gail Coolidge.

Narwhal as a chatbot platform

I put Narwhal in place with the idea of inventing a computer language in which to write English language recognition software. It works fine and I can build a chat bot with it. However, having a computer language is not the same as knowing how to write good programs using it. This gives me a new hill to climb - a hill of how topics can shift dynamically during a conversation. And how that becomes an architecture supported by Narwhal.
As I think about it, it all amounts to the question: what is a conversation? [Which has not yet been within Narwhal's scope.]

Does the tree know about the branch?

I think the tree knows about the branch but the branch does not always know about the tree.

"Liquid, out of my body"

I had a rare moment before being completely awake this morning, where I was in the shower and had a thought that was not that far gone when I made a mistake based on it, causing me to focus and recall the details of the thought. You are always wondering if you think only in pictures, or only in words, or whether there are non verbal, non image modalities. But usually the thought is gone by the time you get around to considering these questions.

In detail: I have an infected ear that I was trying to sooth by standing in the shower and angling my head so the shower spray could reach as far as possible into my ear. I was also brushing my teeth - which is a little awkward with your head tilted a bit on its side. So when it came time to empty my ear, un-tilt my head and have the water drip out, I made a mistake: I spat out the tooth paste foam in my mouth instead. Immediately I set about looking back at the thought I had had that created the plan so poorly executed: the thought was a collection of pictures, held together in a narrative structure: I picture "Liquid" as a vesicle in my head, and "out from body" is a channel opening from that vesicle to the outside of my body, and the liquid escaping that way. For some reason I engaged the mouth "vesicle" rather than the ear "vesicle".
I do not know if "Liquid, out of my body" is a combination of ideas already resident in my mind, ready at any time to be used is situations of expelling liquids, as a fixed part of my planning/action repertoire. Or if such a plan could exist on-the-fly, meeting the needs of the situation creatively. In either case, the thought takes the form of pictures in a matrix of narrative.
So there Wittgenstein!

Rethinking chatnode architecture

As long as it is the conventional way to do something, it is probably wrong. Or at least it could be done better. You can look at the diagrams I posted previously and they may even be correct but what is wrong is the idea that these are "chat" nodes. I think the more correct idea is "data" nodes.
But here is the best insight: that responses can be based on which combination of data nodes are activated by a given input text.

Peter Waksman 1977 - 2017

My favorite picture of me:

And here we are 40 years later

[Better] Chat node architecture

Here the "responder" R is an object with a member R.response( ). There is only one responder in the program so, if you are in its namespace, it can be accessed directly as a global variable and its response() method can be swapped for different things.
Things inside the namespace, can pass R as an argument to sub chats outside the namespace. Inside the namespace, you can set the "global" R.response() back to a parent value after sub-processing. Outside the namespace you also set it back to your parent, but using a passed in version of R rather than accessing a global.

[WRONG] ChatNode architecture

A [WRONG] rudimentary version:

It should be understood that a chat node has a member called Responder that is currently responsible for handling text in and out. The outermost Responder is always in use but sometime is set to one of the sub nodes or sub sub nodes. It is still a brittle architecture.

Here a chat node "home" constructs a sub node during its __init__(). When it constructs the sub node, it passes itself into the sub node as a member 'Parent' of the sub node. Later events can pass control to the sub node via setResponder() and back to the home via restoreControlToParent().
In this way the home node can decide when to handoff responsibility to the sub chat, but it might not get control back. In practice the home node delegates a sub topic to the sub node and gives it responsibility for what to do next.
Example: a Yes/No sub chat can be initiated from a home node, store the result, and return control to the home. It is up to the home node to not lose the context that the question applied to. ETC ETC.

Why you want a sub-chatnode to come and go

A good example is where you need to ask the client a yes/no question. It would be nice to hand-off control to a chatnode designed for that. How it handles non-answers could be app specific.

Doing some more coding

So I coded a ChatNode base class in Python that has a respondText() method. The object contains a set of underlying NARs and wants to be a "center of language processing" for a particular topic. Topics and sub-topics appear to be organized like VARs and so maybe the ChatNodes should be organized in the same way. But what is the natural mode of coexistence for a collection of ChatNodes? I think it might be smart to think of it more in terms of the pieces of data that are maintained within different customized ChatNodes and how those pieces of data are inter related.

I give you: the abutment order, which is part of a  case, which is part of an account. And this order has a past, a present, and a future. And in this order there may be an implant, and an abutment, and a crown or bridge. But the order may also exist in time and space, and even contain a whole discussion of pros and cons, telephone calls back and forth, dentists consulted, box contents, and advice about handling. Not to mention questions.

But that is it. It is doable because, luckily, the most efficient way to store all those intersecting attributes of the "order" are in the narratives that you use to capture the request.

Doing some coding

Man, I did some hard work yesterday and introduced integer variables, which I call "unknowns", into the text, VAR, and NAR handling for Narwhal. This comes hard on a previous week where I introduced recordSlotEvents( ) and got to 1-segmented text. This segmentation shows the data that has been accumulated on the way through a sentence by a given NAR. So today I introduced floating point unknowns and I am proud that the architecture of Narwhal allows adding unknowns in just a couple afternoons, after work.
So, when I use recordSlotEvents( ) for a NAR with a slot containing an integer unknown (INTx) -  sure enough  - the integer entered in the text re-appears in the data. Same for a floating point unknown (FLOATx).
The reason we need this in Narwhal is so it can handle communications with information that is to be relayed rather than absorbed. (I guess it is like delayed recognition.) This is the case for the chatbot I am building for work (at home).

I won't take the time to say this correctly but there is an interesting thing about the "boundary" between when you can get away with a collection of constants versus when you have to deal with actual unknowns. For tooth numbers, input by a user, I can look for the words "one", "two", up to "thirty two" and I can have each one in my program as part of a VAR tree of constants. But I cannot do the same thing for an arbitrary 8 digit number - not for a fundamental reason but for one of convenience. If you had the time, you could avoid using "unknowns".

If the first twenty years of searching for data....

were about finding something somewhat "relevant" to your search, then what if the next twenty years of searching for data be about providing structured information for your search.

A mission statement

I thought of this because it made sense for certain dental industry stalwarts for whom I have a certain affection:

To get customers the knowledge and information they need to place a correct order

I was thinking that a way to do that is:

To be inside the minds of all the Dental and  Dental Lab professionals

 I was thinking a way to do that is:

To be on every desktop in a Dental Office or Lab, as a daily tool

Actually I was thinking the "wave" of communication of the recent past: from phones to internet, to social media, and [I hope] to language interfaces. It suggests that the dynamic and successful Dental Product vendor will be riding the wave. Which means it succeeds by enhancing the types of communication - like training, "other customers also ordered this", good option management during ordering, etc; all in ways that are possible through the newest technologies - not just the internet, not just social media, but voice activated assistants.
For example your social media strategy needs to be coordinated with your training and information sharing functions.

At the root of that is a piece of software on the desktop of everyone who seeks dental information in general. The "Smart Catalog". That would be a steep slope to climb: to be better than Google.

Design informed by the nature of reality

It is not every day that in the middle of program design you stop to consider the nature of reality. But that happens with this language programming stuff. I am thinking about "slot events" where a partially filled NAR "finds" a new slot to fill, in the text it is reading.