Plans

• What is a plan?
• Plan IDs
• Comments
• Plan Priority
• Input Contexts (and Output Contexts)
• Events
• Actions
• Beliefs
• An Example

What is a plan?

---

A plan defines a mapping from a group of events to a set of actions. The system will take actions instantly any one of the events occurs.

Plan IDs

---

The name of a plan is represented by its plan ID. Every plan needs a unique plan ID.

 

Comments

---

This is where you can comment on the plan you are creating. The comments you have written down will appear beside each plan name on the plan tab page. Please see Fig. 1 and Fig. 2.

Fig. 1. You can write comments describing the purpose of the plan in the comment field.

 

Fig. 2. On the plan tab page, the comments you have written down will show up beside the plan name within parentheses on the plan tab page.

 

Function Name

When a semantic conflict arises because of more than one possible meaning of an intent,  the DS will take advice from the function names to generate a clear clarification question.

The clarification question might be something like "Would you like to run FunctionName1 or FunctionName2?"

Moreover, if FunctionName1 = FunctionName2, the DS will create a fine clarification question according to AppName.

At this stage, we offer four languages. Choose one as the language for the name field.

 

Plan Priority (in-app)

---

Suprisingly, sometimes the DS might find a user utterance matches more than one intent, meaning more than one plan could be triggered, but only one plan can be triggered at a time, so which one? The DS depends on plan priority to pick the right plan. You can put more weight on some plans, making plans with higher priorities chosen before others.

There are in total five priority levels you can choose from: highest, high, medium, low, lowest.

An Example

For example, supposing we have two movie classes named actionMovie and crimeMovie collecting movie names of two genres---action and crime. The former collects action movies, and the latter crime movies. Also, suppose there is a movie called Suicide Squad that is in both of the classes. Furthermore, we have two intents as follows:

        intent₁: Have you seen the movie + {the actionMovie class}?
        intent₂: Have you seen the movie + {the crimeMovie class}?

In addition, we've also defined two plans, plan₁ and plan₂. Plan₁ is triggered by intent₁, and plan₂ is triggered by intent₂.

In this case, if a user says "Have you seen the movie Suicide Squad?", how does the DS know which plan will be triggered? It's time to use plan priority. Let's give plan₁  a higher priority over plan₂. Then the DS will decide it is plan₁ instead of plan₂ that should be triggered.

 

Input Contexts (and Output Contexts)

---

Knowing how contexts work is key to creating plans. Roughly speaking, contexts store useful information obtained from what a speaker has previously said.

To give an intuitive explanation of what contexts can do, let's suppose in a living room there is a woman wanting to listen to some music, so she says, "I feel like listening to music." If the DS successfully recognizes her intent, it will start playing a song, a random song, maybe. After a while, she, however, realizes there is something more important to do, so she says, "turn it off." At this moment, owing to the context recorded previously ("I feel like listening to music."), the DS knows exactly that she means to turn off the music, rather than turn off something else, such as the TV or light. Therefore, as you can see, the DS can discover the hidden meaning of a sentence. It would be impossible for the DS to figure out what exactly should be turned off, if it did not store contexts.

Furthermore, a context could be either an input context or output context. An output context is a piece of information produced by the action of a plan that has output context defined. A plan produces its output context once its action is triggered, and this output context could be taken in as an input context (a piece of information that some plans might be in need of) of other plans afterwards.

We've given you a vague description. As an app developer, however, the only thing you need to know is that contexts, inclusive of input contexts and output contexts, connect plans together.

In the above picture, Plan 1 does not need any input context and produces an output context called context1.  Plan 2 needs an input context context1 and produces an output context context2. Thus, context1 produced by plan 1 will be fed into plan 2 as its input context. Similarly, Plan 3 needs an input context context2 and produces no output context.

How an action is triggered?

Regarding when contexts matter, supposing you've defined a plan (say, plan A) requiring an input context, the action of the plan won't be triggered except

1. the utterance of plan A is matched, and that
2. some other plan has already produced an output context which matches the input context of plan A, so that output context can be fed into plan A.

To sum up, the output contexts of a plan could be the input context of another plan.

 

An Example of How To Use Contexts

Fig. 3 shows a plan requiring an input context called greeting_id, which might or might not have been produced by another plan. Providing that greeting_id has been produced by some plan and stored in the system, the plan greetingPlan can go ahead and take it; therefore, its input context requirement is satisfied. In contrast, supposing that greeting_id has not yet been produced, then the plan greetingPlan cannot be satisfied; consequently, the action of greetingPlan won't be triggered even if the utterance is matched.

In the figure below, we can see that the output context has been set as buying, meaning if the action of greetingPlan is triggered, it will produce the output context buying, which, as mentioned before, might be useful if some other plan needs it as its input context.

 

Fig. 3. Plan requiring an input context called greeting_id.

 

Set Conditional Statements on an Output Context

A plan might have more than one action (you can add more actions by clicking + new item below). When the event occurs, which action should be triggered is based on the conditional statements of the actions. An action will be triggered only if its condition is true. The system provides various options for writing a conditional statement.

Fig. 4 shows a simple compound condition representing the expression: ((beliefA > 1) && (beliefB > 4)).

 

Fig. 4. ((beliefA > 1) && (beliefB > 4)).

 

Note that in the picture above, beliefA and beliefB are surrounded by curly brackets. For further information on the way curly brackets are used, please see Beliefs in this page

 

Events

---

Pay attention to the hierarchy of events. The outermost element is the events element, within which there might be an event element, which has an event type element and an intent ID. The intent ID is the innermost element. Clicking +new item allows you to add a new element.

An event of a plan is triggered if what the speaker says matches the intent ID.

More details:

Event Type

1. CSR

CSR stands for Continuous Speech Recognition.

• CSR Intent ID: This event type requires an intent ID.

 

Actions

---

Pay close attention to the hierarchy of actions. For example, the outermost element is the actions element, within which there could be an action element, which has a condition, output contexts, and a task list, which might contain an item. You can go all the way down to the innermost element. 

An action of a plan won't be triggered unless:

1. the condition is satisfied,
2. one of the events is matched, and
3. all the required beliefs are collected as expected from the user.

More details:

Condition

Consider a plan to be a function that has two inputs. One takes in an input context and the other an intent ID (or multiple intent IDs, if the plan has defined more than one event). If the latter (the intent ID) is triggered, the plan will be activated, thus triggering its actions.

However, we can also define a condition (or an if-statement) on an action, and the action will be triggered only if the specified condition is true.

 

Operands to Set Up a Condition

1. Always: The default value of a condition is "always", which in logic equals true, meaning the action will be activated once an event is triggered.
2. Compound
3. Number
4. String
5. Boolean

The last four operands are fairly self-explanatory.

 

Operators to Set Up a Condition

The four operators that you can work on with to set up a condition are as follows:

1. AND
2. OR
3. NOT AND
4. NOT OR

Again, the above operators are rather self-explanatory.

 

Output Contexts

An output context will be produced after the action defining it has been triggered.

For information on how to set up output contexts, please see Input Contexts (and Output Contexts) in this page.

 

Task Type

1. TTS

TTS stands for "text to speech". And the response field is where you define the response of an action. Typically a response is a message.

2. Lang

The language in which the action responds. At this stage, we offer four languages for you to choose from.

3. Text

The message to be responded.

Beliefs

---

An intent may contain valuable information that might be pivotal in the future. The DDE Editor can extract this helpful information from a speaker's utterances and store it in beliefs, which you can think of as variables. These extracted beliefs can be manipulated afterwards.

Declaring Beliefs

You declare beliefs under the plan tab. We can see that in Fig. 5, we declare a belief with ID=brand_name, which is of the class motorcycle_brand. Note that we can also give the belief a default value or make it required.

 

Fig. 5. Belief Declaration. (need to update screenshot)

 

Belief IDs

The belief ID is the name of a belief. No two beliefs are allowed to have the same ID.

The Drop-Down List

There are three options from which you can choose:

1. Required

If the value of a belief is essential to a dialogue configuration, you can set the belief to "required" by checking its "required" box so that later on, if a speaker fails to provide the information of this belief, in order to remind him/her, the system will prompt a question asking for the missing information lest the DS be stuck and do not know its next move.

2. NotRequired

You can set the belief to "not required", if you want to enter the plan without finding out the value of the belief.

3. notRequriedButTry

The server allows the dialogue to enter this plan without getting beliefs. But it will try to ask whatever questions you put in the "prompt" to get back the value of the belief.

Multivalue

If the multivalue box of a reference class is checked, it means this class can hold multiple variables. For example, suppose we have defined a class called human with its multivalue checked, and a belief is extracted from this class. Also we have an intent = "I plan to see {the human class}." Because the human class is set as multivalued, this intent can match sentences such as "I plan to see my brother this weekend." or "I plan to see Father and Mother this weekend." The latter could not be matched were the multivalue box not checked.

Homonym

Regarding belief collection, suppose we have a class instantiated by three instances, namely deer, dear, kid. You might have noticed that the words deer and dear are homonyms having the same pronunciation but different meanings. Also assume there is a sentence called X designed to extract a belief from this class. Now supposing a speaker says the sentence X, owing to the same pronunciation the two words (dear and deer) have, there is no way for the DS to distinguish deer from dear, making it impossible to decide what the speaker means and which value, deer or dear, it should assign to the belief. Therefore, in this case, our system design to solve this problem is by setting the belief to both values: deer and dear, providing that the homonym box is checked. (Format: belief = [dear, deer])

Classes

This is where you enter the class from which a belief is extracted.

Default Values

You can give a default value to a notRequired belief. Thus, in this case, the DS won't ask the user for clarification even if s/he does not provide some of the crucial beliefs.

Prompts

A prompt of a belief is a response said to the speaker, to urge him/her to provide the required belief (essential information), if s/he fails to do so.

In addition, you might have noticed that more than one prompt can be defined for each belief, which implies the DS can ask the user for clarification in more than one way, but only one of the prompts will be chosen, randomly. 

At this stage, we offer four languages to choose from. (See the picture below) Choose one for every prompt as its language.

Belief Clarification Times

The Belief Clarification Times field defines the maximum number of times the DS will ask the user for the required beliefs s/he fails to provide. The DS will stop asking once the number of times the DS has asked the user exceeds its maximum. It should be noted that developers should set the belief to either "required"  or "not required but try" to trigger the function. 

Belief Clarification Context

Let's suppose a plan fails to collect some beliefs from the speaker, in this case, the DS will first produce a context specified in the belief clarification context field before asking him/her to provide the missing beliefs. S/he can either respond to the prompts to provide the beliefs or say anything that triggers any plan that takes the belief clarification context as its input context.

Extracting Beliefs in a User's Utterances

Fig. 6 shows you how to extract a belief from a sentence. The screenshot on the left shows how to set a phrase belief, and the screenshot on the right shows how to set a belief.

1. Set Phrase Beliefs:
   Let's look at the first sentence first. This sentence is dissected into two parts --- I want to + {buy_a_vehicle}, where buy_a_vehicle is a phrase class reference (referring to a class instantiated by phrases). We can see that the belief called buy_a_vehicle_belief is extracted from this sentence. Later on, if someone says, "I want to buy a lorry.", the value of buy_a_vehicle_belief will be bound to lorry. As a result, we can retrieve and use the value stored in this belief afterwards under the plan tab.
2. Set Beliefs:
   In the right screenshot, let's look at the second sentence. It is composed of two parts, one of which is recommend, the other vehicle, where vehicle is a class reference. We see that a belief called vehicle_belief is extracted from the vehicle class. Thus, if someone says, "recommend a truck", the belief vehicle_belief will be bound to truck.

Fig. 6. This two figures show you how to set a belief on a phrase class and how to set a belief on a normal class.

 

An Example

---

Fig. 7 shows you how to set up a plan. In this example, we created a plan for saying “hello” to users. If the user's utterance matches the intent with id=greetingIntent_id, the action of the plan will be triggered. At the same time, the action also produces an output context (greeting_id). Then the system will respond to the user with "hello".

Fig. 7. A plan that says "hello".