Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Dialogflow
Ingredient (type) and cuisine entities
...
A more challenging entity to create is the @ingredient entity that consists of all ingredients that are used in the recipe database. You should extract all of these ingredients from the recipe_database.pl
file. You should be able to find them and automatically extract them by matching with the ingredient(..., <ingredient name>)
. In other words, using some clever data parsing techniques that you apply to the recipe_database.pl
file. Create a CSV file with all the ingredients that you extract from the database that you name ingredient and upload this file to your Dialogflow agent to create an @ingredient entity.
Finally, to be able to filter on cuise extend your Dialogflow agent an @cuisine entity. Here is a CSV file you can use to upload the @cuisine entity into your Dialogflow agent:
View file | ||
---|---|---|
|
Note |
---|
Note that by extracting ingredients only from the recipe database, your Dialogflow agent will only be able to recognize ingredients that appear in that database. If a user would ask for an ingredient that is not in the database, this means the agent will not be able to understand the user! To deal with that issue, you might want to add more ingredients from elsewhere. One place to get more ingredients from is here. |
Finally, to be able to filter on cuisine extend your Dialogflow agent an @cuisine entity. Here is a CSV file you can use to upload the @cuisine entity into your Dialogflow agent:
View file | ||
---|---|---|
|
Note |
---|
A similar issue as for the ingredients also applies to the @cuisine entity. Only some countries are included, while others are not. To address that issue, you might want to think about a solution that uses the @sys.geo-country entity of Dialogflow instead of the csv file. |
Request for recipe features intent
...
Warning |
---|
Test that your intent is correctly recognizing user requests by using the microphone button in the Dialogflow test console (you can also enter phrases in the test console by typing). Try various phrases and check whether what you say is classified as your recipe request intent, and whether the ingredient (types) in your requests are being recognized as ingredient (type) entity (use the Diagnostic Info to check this). |
Prolog and Patterns
We need to refine our logic now for retrieving only those recipes that satisfy specific filters. We already introduced a recipeFiltered/3
predicate for Capability 2: Request a Recommendation but there it did not have to do any serious work yet. We only introduced the base case without any filters (an empty list of filters) but now need to deal with the case where we have some filters that a user provided. The basic idea to define a recursive clause for recipeFiltered/3
is simple: apply the first filter in the list to the recipes and recursively filter the remaining recipes using the remaining filters. We provide you below with the recursive clause that you should add below the base clause that we added earlier in the recipe_selection.pl
file:
...
The first Prolog rule for hasIngredient
is designed to determine if a specific ingredient is used in a given recipe. It simply checks if Ingr
is included in the ingredient list of recipe RecipeID
by using the ingredient/2
predicate (see the recipe_database.pl
file). The second rule is designed to determine if a recipe uses an ingredient type. It assumes that Ingr
is a type of ingredient (such as meat). To check whether a recipe uses that ingredient type, however, we need to find a specific ingredient such as steak that is an example instance of the type (only those are directly associated with a recipe in the recipe database). Another example would be apple as an instance of the type fruit. We do not have to specify all of these relations as a lot of the work has already done for you and you can use the typeIngredient/2
predicate in the ingredient_hiearchy.pl
file (check out the typeIngredient/2
facts in that file). Now use that predicate in combination with the ingredient/2
predicate to define the second rule. Add your rules to the ingredient_hierarchyhierarchies.pl
file.
Tip |
---|
Extend the number of available ingredient types in There are several ways to do this. Key, of course, is to find specific types of pasta that you can use to add facts such as |
...
Let’s inspect this interaction in more detail and analyse how it is organized. In Moore and Arar’s taxonomy, the parts of the dialog in this example where the user adds a feature request in the second and fourth move can be classified as Pattern A2.1: Open Request. We will use the a21featureRequest
label for this pattern and define different variants of it below. The agent initiates with an inquiry about what the user is looking for. This move is part of the a50recipeSelect
pattern, a top level pattern that we added to the agent’s agenda. We previously defined variants for that pattern for Capability 2: Request a Recommendation and Capability 3: Select Recipes by Name. The user responds by informing the agent that they are interested in a particular cuisine (JapanJapanese). This is a feature request that we want the agent to manage by means of a new a21featureRequest
pattern. The idea is that this pattern is inserted while the user and agent are still performing the top level a50recipeSelect
pattern. The a21featureRequest
pattern is inserted as a subdialog, which we indicated in the example above by adding indentation. The response of the agent is an acknowledgement move combined with a renewal of the question whether the user wants to add any other feature. We’ll take it that this move is also part of the a21featureRequest
pattern and ends this pattern. The fourth user move (a second feature request for the an ingredient type pasta) and the fifth agent move repeats the same a21featureRequest
pattern. The interaction concludes with a move of the user mentioning a specific recipe title (Curry noodle soupTeriyaki salmon). That last move and the agent move following it are both part of the a50recipeSelect
pattern we specified for Capability 3: Select Recipes by Name. That pattern added the a50recipeConfirm
pattern into the current session of the agent. This pattern asks the user to check the recipe (while showing all relevant details). You still need to add this pattern to implement the capability we are working on right now below.
From a visual (webpage) point of view, we want to inform the user about the progress that is made. The main difference that we think is relevant here is how many recipes are still remaining. That is, how many recipes satisfy all of the user’s requests. The idea here is that it is not useful to show titles and pictures of a large number of recipes (there would be too many for the user to look at) but to show titles and pictures when the number of remaining recipes has reduced to a sufficiently small number (as a design choice, we have chosen <16 here). Assuming that there are fewer than 16 recipes left that are Japanese and use pastasalmon, at the sixth move in the example above, the user can have a look at the displayed recipe titles that are still left and make a choice. That should also clarify how at that move the user can mention a specific recipe title (they see the titles that are left). After selecting a recipe, the agent acknowledges the choice and asks the user to confirm they would like to cook the recipe. At this stage, the conversational context is the a50recipeConfirm
pattern and the agent should display all relevant details such as instructions and ingredients that help a user make this decision on the corresponding page.
...
A variant for when a user requests a feature while already checking a recipe and the context is
a50recipeConfirm
. That is, the user already has made a choice (e.g., Curry noodle soupTeriyaki salmon), is looking at the recipe details for this choice , but still adds a feature request. We assume that the user is still undecided if they make such a move, and will want to move the conversation back to thea50recipeSelect
pattern stage by inserting that pattern back into the session at the end of the patterna21featureRequest
.A variant for when a user requests a feature while the context still is selecting a recipe (
a50recipeSelect
).
...
In total, you should be implemented four variants of a21featureRequest
pattern for the different conditions: 2 main variants x 2 cases.
...
For the featureRemovalRequest
intent, you should add a simple text/2
fact. Use as response text, for example, "Can you have a look again and remove one of your recipe requirements?".
Visuals
We want to differentiate what we show to a user depending on the number of recipes that still meet the user’s requests. The basic idea is that we should not show a large number of recipes to a user but we can show recipe details when the number of remaining recipes becomes sufficiently small (we chose <16, see also above). As a consequence, we want to create two different versions of the a50recipeSelect
page that we created for Capability 2: Request a Recommendation: one that just shows the feature requests made when there are more than 15 recipes that meet these requests, and another for when there are less that 16 which shows the recipe details (titles and pictures) for all of the remaining recipes.
...
Your final page should look something like this (just an example, you should easily be able to easily improve!).
...
Test it Out
Test it out by Run your Conversational Agent. Try different scenarios where you filter on ingredients, ingredient types, and/or cuisine. For example, try adding requests for the following ingredients one by one in order: ginger, salt, sugar, rice. You should end up with exactly 2 recipes left.
...