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 an event to an action that should be taken when the event occurs. An action will be triggered instantly the event which maps to the action is matched.

Plan IDs

The name of a plan is represented by its plan ID, and every plan should have a unique plan ID.

Comments

This is where you can write comments about the plans you are making, and the comments you have written will appear beside each plan name on the plan directory. Please see Fig. 1 and Fig. 2.

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

 

Fig. 2. Under the plan tab, the comments you have written will show up beside the plan name within parentheses in the plan directory.

 

Plan Priority (in-app)

It is possible that the DS finds a user utterance that matches more than one intent, thus triggering more than one plan, a situation that may lead to potential ambiguity about which plan should be chosen to be triggered. Therefore, the plan priority is designed to avoid this problem by allowing developers to put more weight on some plans, making plans with higher priorities chosen before others.

 

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-1: Have you seen the movie + {the actionMovie class}?
        intent-2: Have you seen the movie + {the crimeMovie class}?

In addition, we've also defined two plans, plan-1 and plan-2. Plan-1 is triggered by intent-1, and plan 2 is triggered by intent-2.

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 we used the handy functionality of the plan priority. Let's give plan-1 a higher priority over plan-2. Then the DS will decide it is plan-1 instead of plan-2 that should be triggered.

 

Input Contexts (and Output Contexts)

Roughly speaking, contexts store useful information obtained from what a speaker has previously said.

To give an intuitive explanation of what contexts are, let's assume a speaker says, "I feel like listening to music." If the DS successfully recognizes the speaker's intent, it will start playing a song. After a while, the speaker, however, realizes she has something more important to do and 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 she wants to turn off the music rather than turn off something else, such as the TV or a 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 we did not have this functionality.

Hence, the ability to store contexts is of great importance in case the DS needs to find the real meaning of a sentence that has different interpretations depending on its context. 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.

 

Why DO We Need To Store Contexts?

Regarding when contexts matter, supposing a developer defines a plan (say, plan A) requiring an input context, its action 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.

To sum up, the output context 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 to 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 the + new item icon below), and 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, 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

The events of a plan are triggered if the utterance of one of the events is matched.

 

Event Type

1. CSR

CSR stands for Continuous Speech Recognition.

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

Actions

The actions 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 from the user.

 

Condition

Technically, 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 END
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.

3. Text

The message to be responded.

4. Emotion (which could be natural, happy, sad, or angry)
5. Alpha (which is a floating point number between 0.0~1.0)

Beliefs

Understanding what a belief is and how to use it is of crucial importance, 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

Developers 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, the app's developer 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

A new feature. TBD

3. notRequriedButTry

A new feature. TBD

 

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 we extract a belief from this class. Also we define an intent = "I plan to see {the human class}." Because the human class is multivalued, this intent can cover 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 covered 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, meaning the DS can ask the user for clarification in more than one way.

Note that the prompt to be asked is randomly chosen.

 

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, even though the speaker has not provided the required belief yet. This also implies that the plan won't be triggered.

 

Belief Clarification Context

Regarding belief collection, supposing 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 some plan that takes the belief clarification context as its input context.

 

FunctionName

A new feature. TBD

 

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 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".