| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Recipe Filtering
We need to refine our logic now for retrieving only those recipes that satisfy specific filters. We already introduced a recipeFiltered/3 predicate for 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:
...
Even though some of the recipe features that we have looked at require careful analysis, those that require more work than simply inspecting basic facts in the recipe database were all based on reasoning about individual ingredients. That is, we verified whether an ingredient is of a particular type, either a type of food or a type of dietary restriction. If you like a challenge, you can also consider other recipe features that consider more global features of a recipe, such as a recipe being low-carb or cheap. How would you define the logic for such filters? What kind of information would you need to add to the database to be able to define features like these?
Dialogue Patterns
Requesting a recipe feature
...
A: The remaining recipes are of Japanese cuisine. Is there anything else you'd like?
U: Recipes that use salmonsalt.
A: All the recipes left include salmonsalt. Do you want to add another preference?
...
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 salmonsalt, 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.
...
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 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.
...