| 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 cuisinee extend your Dialogflow agent an @cuisine entity. Here is a CSV file you can
| 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:
...
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.
...