Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel2
outlinefalse
typelist
printablefalse

The next thing we want to add is the capability to filter on dietary restrictions. This will require extensions to your Dialogflow agent for NLU but also require the implementation of new logic in Prolog for filtering the recipe database on these restrictions.

Dialogflow

As a first step, use the following CSV file to upload the dietaryRestiction entity:

View file
namedietaryRestriction.csv
.

...

To make your Dialogflow agent extract this entity, you again need to add more training phrases, and annotate these phrases for the dietaryRestrction entity, and extend the addFilter intent with these phrases. You can use the test console of your agent to verify that it is able to recognize addFilter intents with dietary restrictions and extract the entity entries you just added.

Prolog and Patterns

In the previous capabilities that we implemented for filtering the recipe database, we often could simply use the facts that are part of that database to implement the filtering process (the applyFilter/4 rules). For example, for Capability 5: Filter Recipes by Ingredients and Cuisine we could use the ingredient/2 and cuisine/2 facts, and for Capability 6: Filter by Number of Ingredients & Recipe Steps, we could use time/2 for the cooking duration of a recipe and servings/2 for the number of servings. For computing the number of ingredients and recipe instructions steps, we had to do a bit more work, but these could also be computed quite straightforwardly from these basic facts.

...

Code Block
typeIngredient(Ingredient, 'vegetarian') :-
	not(typeIngredient(Ingredient, 'non-vegatarianvegetarian')), !.

Also add rules for the pescatarian and vegan dietary restriction. That enables our agent to handle at least three of the six dietary restrictions that we added to the dietaryRestriction entity of the Dialogflow agent. We will get back to the other three later. For now, you should assume that we can use the predicate typeIngredient/2 to check if an ingredient meets a dietary restriction. We want to implement a rule now that checks that all the ingredients in a list meet a dietary restriction, such as 'meat' or 'vegan'. You should implement an ingredientsMeetDiet/2 predicate in the recipe_selection.pl file that for any given list of ingredients checks that each one of these ingredients meets a dietary restriction. In other words, write code for the body of the recursive clause for the following rule:

...

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?

Visuals

You can update the visuals based on what you think will help the user the most. Think about how you can support the implemented capability visually.

...