Template: Taipei Bus
This document provides more explanations of
- how an app dialogue is linked by a context token in a plan,
- how to design an intent by an expected user utterance
(in the scenario, it means what users may say)
- how to set a belief and which concept should be a belief
Part 1 : An Overview
In this template, there will be five plans referencing corresponding CSR event intents as below:
|
taipeiBus.plan.user.startApp
|
taipeiBus.intent.user.startApp |
|
taipeiBus.plan.user.queryBusWhenArriveStation
|
taipeiBus.intent.user.queryBusWhenArriveStation |
|
taipeiBus.plan.user.querySpecificBus
|
taipeiBus.intent.user.querySpecificBus |
|
taipeiBus.plan.user.querySpecificBus.startStationAndTime
|
taipeiBus.intent.user.querySpecificBus.startStationAndTime |
|
taipeiBus.plan.user.querySpecificBus.willPassSpecificPlaceOrNot
|
taipeiBus.intent.user.querySpecificBus.willPassSpecificPlaceOrNot |
Fig. 1. An overview of the plans in our template
Fig. 2. An overview of the intents in the template
And there are some concepts whose instance may be parameters in my application, like BusColorLine or BusStopStation.
Fig. 3. AN overview of the concepts in template
Part2: What is My First Plan?
The first plan is a cross intent which can trigger my app, so that is taipeiBus.plan.user.startApp. Notice this plan doesn’t need to be filled with an input context because it is the first plan to be triggered, so there is no input context needed to be satisfied.
The intent bound with this plan is taipeiBus.intent.user.startApp. You can find there are some sentences inside the intent, such as我要查詢台北公車資訊, meaning when the user says 我要查詢台北公車資訊, the plan taipeiBus.plan.user.startApp will be triggered. And then the system will perform the action defined in the plan, which returns an output text “你想查詢哪一班公車?” to the app. Also, the system will set an output context to taipeiBus_begin, which is pre-defined in this plan.
Part3: In-App Plans
In Part2, after the action in taipeiBus.plan.user.startApp is done, the context’s status for this domain is taipeiBus_begin.
That means now the plans with input context “taipeiBus_begin” are requesting the DS to listen to them. In this example, these plans are:
1. taipeiBus.plan.user.queryBusWhenArriveStation
2. taipeiBus.plan.user.querySpecificBus
Similarly, if the next user says something to trigger taipeiBus.plan.user.querySpecificBus and the action in that plan is done, the context will become querySpecificInfo, meaning now the plans with the input context “querySpecificInfo” request to be listened by the DS. In this example, the plans are:
taipeiBus.plan.user.querySpecificBus.startStationAndTime
taipeiBus.plan.user.querySpecificBus.willPassSpecificPlaceOrNot
Part4: Belief Extraction and Design
Since in this template, the application may provide some info like “某班車還有幾分會到某站”, you can find in the plan taipeiBus.plan.user.queryBusWhenArriveStation, there is a CSR event intent taipeiBus.intent.user.queryBusWhenArriveStation bound with this plan.
Sentence designers are to design apps based on expecting what users may say. E.g., 紅22何時到捷運關渡站
And since the bus in Taipei might not have a color line, the color concept may not be shown in the user utterance, so the pattern in BusColorLine is set to optional (By clicking the Orange UI, you can find the setting.)
And in the application, the program may need to know what the specific BusColorLine and Bus Number are and the exact busStopStation name, so this template has the responding belief expected to be obtained from the user.
When defining this belief, you will also need to make sure the belief information is synced with the belief property setting in the corresponding plan.
Fig 4. the sentence pattern design in the intent taipeiBus.intent.user.queryBusWhenArriveStation
For example, you need to decide if the belief is required. If the belief is not required, and missed from the user, you will need to design how the DS will try to clarify.
Fig 5. The belief table which can set a property on a belief
Part 5: A picture to help understand the structure