| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Dialogflow
As a first step towards recipe recommendation, we want a user to be able to ask for a random recipe recommendation. The idea is that the agent would randomly select one of the recipes from its database and recommend that to its user. This may not seem particularly useful at this stage, when you only have implemented Capability 1: Greet, and Self-Identify. A user cannot yet have made any requests for specific features of a recipe. However, at a later stage, when a user can also already have made such specific feature requests, adding this capability makes more sense. In these cases, a user simply may not want to add any other feature requests and ask the agent to recommend an arbitrary recipe from those that satisfy the requests they have made thus far. We want to prepare the agent for doing just that already now. The first thing to do to enable this, is to create another intent in your Dialogflow agent for requesting a (random) recipe recommendation. To create such an intent, you should follow the same steps as before:
...
| Warning |
|---|
Test that your intent is correctly recognizing user requests by using the microphone button in the Dialogflow test console. Try various phrases and check whether what you say is classified as your recipe recommendation intent. |
Prolog and Patterns
This section is about implementing the dialog management capabilities of the conversational agent but also about implementing the domain logic that the agent needs to be able to perform its task. As our conversational agent is a task-based agent for recipe recommendation, the conversational competence of our agent focuses on patterns and responses for recipe recommendation. The logic that we need to implement concerns the capabilities our agent needs to reason about user requests about recipes that are available in the agent’s database. We will first focus on adding some conversational capabilities for our agent to respond to a user request to provide a (random) recipe. As before, in the approach to dialog management that we use here, this will require the definition of a pattern and the specification of a (textual) response to the user request. When we have completed that part, we will continue with the part focusing on implementing the reasoning capabilities for extracting such a recipe from the database in Prolog. This will require the definition of several rules for extracting a suitable recipe from the agent’s recipe database.
...
This clause specifies that if there are no filters to apply (i.e., the filter list is empty), the output of filtering a list RecipeIDs of recipe identifiers remains unchanged and is that same list of recipe identifiers RecipeIDs.
Visuals
Recipe recommendation page
...
At this stage, for this capability, we will only provide code for a very basic skeleton page that provides the minimal functionality needed to implement the main requirement for this page: enable a user to talk to the agent by means of a microphone button. The design is kept minimal below and in the step-by-step walkthrough below we will only use a single and simple alert element to style the page. As the recipe recommendation page will be the first interaction point for users that are actually interested in finding a recipe, we leave it up to you to try and make this page more inviting and add clear and useful content that the agent will show. Note that we will also ask you to extend this page at a later stage when you are implementing Capability 45: Filter Recipes by Inclusion CategoricalIngredients.
Step 1: Adding the head of a Prolog rule for a recipe recommendation page.
...
The next page that we want you to add is a recipe confirmation page. At the end of the pattern enabling a user to request a (random) recipe, the agent inserts the a50recipeConfirm pattern ID in the agenda. No pattern has been added for this pattern ID yet, but because it will appear at the top level in the agent’s agenda, we can already create a confirmation page for the recipe that is selected. The idea is that this page allows the user to preview the recipe and indicate whether it is satisfied with the recipe (confirm) or not (disconfirm). To enable a user to make this decision, the main requirement for this page is that it shows the recipe’s name, and what the end result of cooking the recipe will look like (a picture of the recipe). A second requirement is that the page shows a microphone button to enable the user to inform the agent about whether it wants to (dis)confirm the recipe. Note that at a later stage, we will ask you to extend the recipe confirmation page when you implement Capability 56: Filter by Numerical CharacteristicNumber of Ingredients.
For the design, a https://www.w3schools.com/bootstrap4/bootstrap_cards.asp element seems a suitable element for styling the page. We will use it below to create a first (but still simple) recipe confirmation page with a basic recipe card. We will want to generate the following HTML code for this card:
...
We have introduced the bare essentials for the these pages but you should feel free to modify it in any way you like , and to make it look more appealing. However, please note that the a50recipeConfirm page is extended later to include recipe information. More information about these extensions can be found here: https://socialrobotics.You should make sure, however, atlassian.net/wiki/spaces/PM2/pages/2229600267/Capability+6+Filter+by+Number+of+Ingredients#Visuals
It is important that you make sure that the requirements marked in bold in the text are met.
...
You can also check whether the intent recognition works. In your Dialogflow agent in the Training Tool, you should be able to see a conversation listed with a greeting and requestRecommendation intent. You also should be able to see the SIC server received those intents with transcripts from Dialogflow in the terminal where you started the server. You should see something like this:
...