Dialogflow

deleteFilterValue 

...

Removing feature requests again

Users, of course, should not only be able to add recipe preferences but, when recognizing, for example, there are few or no recipes to their liking that meet the preferences they expressed, should also be able to remove them again to look for other options. They should, for example, be able to say 1. “I wish to remove the onion filter”, preference for vegetables”, 2. “Forget about excluding broccoli”, and 3. “Can you delete the Chinese cuisine”. Add some training phrases with all the different filters that could be deleted.It is important that in your training phrases, you include all filter-related entities and that these entities are also given specific values and parameter names in the Action and Parameters tables. These entities are given new parameters and value names in order to identify them as a filter to be deleted. Specifically, you cuisine preference?”. Of course, they could already get rid of these filters by expressing the opposite, and say, for example, “I would like recipes with broccoli”. However, instead of simply removing the constraint to exclude broccoli, that would also introduce a preference for recipes with broccoli (it is useful to better understand this point to check again how the removal of conflicting requests has been implemented in the ingredient_hierarchies.pl file).

It is worthwhile to briefly analyze the user expression examples above in more detail. You should note that in the first two expressions, the user only mentions an ingredient (type) but not the type of feature or filter (if you recall, the first expression would result in a filter ingredienttype='vegetables' and the second in a filter excludeingredient='broccoli'). In other words, the user mentions a value for a specific type of filter but not the type. In contrast, in the third expression, the user only indicates a feature or filter type (cuisine) but the specific cuisine the preference is about. For this last expression, things get even more complex, as the request might be about excluding a cuisine (e.g., excludecuisine='chinese') rather than including the cuisine. In other words, the request might be about the excludecuisine feature and not about the cuisine feature (your Dialogflow agent will not be able to deal with this kind of subtlety as it does not keep track of the feature requests that have been made; it will be up to your MARBEL Dialog management agent to handle this).

To be able to make sense of user requests asking to remove a value or a filter type, you should add two new intents to your Dialogflow agent. Call the first one deleteFilterValue and the second one deleteParameter (for the latter intent, the name stems from the fact that Dialogflow calls the entity types that have been supplied by the end-user parameters). Making these intents robust, i.e. for ensuring that the potential endless variety of user expressions will be recognized by your agent, you should add training phrases for all the different entity types and parameters/features/filters that a user could ask the agent to delete.

You should annotate the training phrases for deleteFilterValue with existing entity types but use different parameter names to indicate that the values captures should be removed from the feature requests stored in the agent’s conversational memory. You tag the entity in your training phrases as normal and you did before (e.g. using @ingredient) but then you should change the parameter name and value name to “entitynameDel”. Your entity table under Action and Parameters should look like this when you are done. 

...

noMoreFilters 

The ‘noMoreFilters’ intent is used when the user does not want to add any more filters to their recipes list and wishes to see the available recipes.

Prolog and Patterns

a21noMoreFilters 

Example:

A: “What other filters would you like to add”

U: “I do not want more filters  “

A: “Ok. Here is a list of recipes” / “Sorry the list is still too long to show”

a21noMoreFilters pattern handles a user request to not add more feature requests, preferences, or requirements. When filtering the recipes, the user is not shown the list of filtered recipes until there are only 15 (or fewer) recipes. It could be, though, that the user does not wish to filter recipes further. The user would then use the NoMoreFilters intent. The agent can then allow the user to see the list with the ‘grantPicture’ response, or deny with ‘pictureNotGranted’. If the agent grants the user’s request, the to something of the form entitynameDel (we suggest adding Del at the end of each parameter that you already have to facilitate relating them to each other). So, for example, you would add new parameter names for ingredientDel, cuisineDel, durationDel, etc.

For the deleteParameter intent, you should introduce a new entity type called @filterType (with corresponding parameter name) and add as entry entities all the features you have introduced, such as ingredient, cuisine, etc. You may also wish to consider any synonyms that a user might use to refer to any of these features. Again, make sure to include a sufficient number of training phrases to make recognition of this intent robust.

Expressing that you are done

A user should also be able to say it does not want to provide the agent with more information to go on (which does not mean the agent should accept that in all cases!). As we have implemented things thus far, we would expect a user to respond negatively to an agent request to elaborate on what they are looking for:

A: Can you elaborate on what you're aiming for in your recipe?

U: I don't want to add anything else.

Recall that we used the agent intent ackFilter to implement the first move in this fragment as part of the a21featureRequest pattern. If a user complies with the agent’s request, that would trigger another a21featureRequest pattern. If a user does not comply but rather responds negatively, we can also view that as a disconfirmation move. We argue that we can reuse that intent to capture negative responses to the agent’s request. A user, for that matter, could also simply respond to the agent’s move by saying “No, I won’t” or something similar. We implemented this intent before, but we should extend it to now also cover the variety of user expressions a user could use to say they do not want to add anything else. So, you should add training phrases to make sure these expressions are covered too.

Prolog and Patterns

We will begin with implementing a pattern for allowing a user to express they are done, and then get back to what is still missing to implement requests to remove a filter.

A user does not want to specify more recipe constraints

The pattern that we want to implement to enable a user to express they do not want to provide more information is the following:

(A: Can you elaborate on what you're aiming for in your recipe?)

U: I don't want to add anything else.

A: OK. Here is a list of recipes that you can choose from. [Alternative: Sorry, there are still too many recipes left to show them all. Please add more preferences.]

The first move has been put between brackets because, as explained above, it does not belong to the pattern that we want to implement but to the a21featureRequest pattern. The new pattern is named a21noMoreFilters, as it fits best in the A2 category of Request patterns in Moore and Arar’s taxonomy. It starts with a disconfirmation move of the user and continues with an agent intent that either does or does not grant the user’s request.

But what would granting the user’s request mean? The idea is to somewhat lift our previous restriction of only showing pictures of the list of filtered recipes when there are no more than 15 recipes left. The agent can, for example, show the list of filtered recipes if there are a 100 recipes or fewer left when a user indicates they do not want to provide more information. It does not seem reasonable to show many more recipes, as that does not seem to align well with the ambition to develop a conversational first agent. In other words, our agent should not grant the request if the recipe list still is more than a 100 recipes long. (The exact number, of course, is a bit arbitrary, and it is up to you if you want to argue for changing it.)

We can base the name for the agent intent on our design choice to show more recipe pictures and call the one that grants the user’s request pictureGranted, and the one that denies the request pictureNotGranted. Using these labels, you can implement two versions of the a21noMoreFilters pattern in the patterns.pl file. And don’t forget to add responses for the agent intents pictureGranted and pictureNotGranted to the responses.pl file. This will require you to define two rules with a different condition on the number of recipes left. Recall that you can use the recipesFiltered/1 predicate to compute a list of the filtered recipes and use that to compute how many recipes are still left after filtering.

There is still one thing missing… Just by talking the agent will not change the page that is displayed. Recall that you have created two pages for the a50recipeSelect pattern for Capability 5: Filter Recipes by Ingredients and Cuisine. When the agent grants the user’s request we still need to make sure that the second recipe recommendation page showing the recipe pictures is displayed. To make that happen, we need to change the condition for showing that page. We need the store the fact that the user requested this. The idea is to use the conversational memory of the agent for that and update it with this information. Therefore, when the agent grants the user's request, the version of that pattern should end with the agent updating its memory using ‘an [agent, update(['show'='true'])]’. This triggers the showing of recipes by updating the agent’s memory.

Implement the ‘a21noMoreFilters’ pattern in patterns.pl.

In responses.pl we have to make two rules, for ‘grantPicture’ and ‘pictureNotGranted’. An agent can allow the list of recipe pictures to be shown if the list is less than 100 recipes long. An agent cannot grant the recipes if the list is over 99 recipes long. The ‘recipesFiltered’ predicate provides a list of the filtered recipes. Fill in the two rules with the corresponding conditions.

featureInquiry intent

Multiple text predicates take the argument feature inquiry in responses.pl. Each feature inquiry response is actor-intent pair. To change the condition for showing the page in the html.pl file, we can then use the memoryKeyValue/2 predicate defined in the dialog.pl file to add an alternative condition for showing this page.

Finishing the implementation for removing filters

Most of the work that needs to be done to remove filters again has already been done. Various patterns implementing the a21removeKeyFromMemory have already been included in the patterns.pl file (check them out to better understand the variants added for this pattern). The specification of the agent response featureInquiry used in several of these variants, however, is still missing It is up to you to add these in the responses.pl file. The idea is to define four different types of these responses. Each of these feature inquiry responses should be different based on how many recipes there are still left to filter.after applying all the filters, and will require you to define the conditions for when a response is available:

First Rule for Large Number of Recipes

We want to prompt the user for more specific preferences if there are too many recipes . The rule will left. This version of the response should be triggered when the length of the list of recipes is still large (say greater than 890.800):

• Start with the text/2 predicate, where the first argument is featureInquiry.

• The For the second argument will be the you can use a response text such as "What kind of recipe would you like?".

• Use the recipesFiltered/1 predicate to get the list of recipes.Use , the length/2 predicate to determine the number of recipes.Set , and add a condition that the length L must be greater than 890800.

Second Rule for a Moderate Number of Recipes

If there's a moderate number of recipes left (more than 15 but fewer than 891less than or equal to 800), we ask the user to add more preferences unless a certain the memory key-value pair is set.

...

Repeat the initial steps as the first rule.

...

to show recipes has been set (see above):

• Use a response text similar to e.g. "What other preference would you like to add?".

• Set the length Add a condition to be less than 891 and greater than 15.Include a condition using not/1 check that more than 15 but less than 800 recipes are left.

• Also include a condition to check that the memory does not have the key-value pair 'show', 'true'.

Third Rule for No Recipes

If there are no recipes left after filtering, we want to inform the user to remove some

...

feature requests.

• Use the recipesFiltered/1 predicate again.The a response text will be similar to "There are still no recipes, please remove more requirements.".

• Check that the length L is equal to 0 using L=0Use the recipesFiltered/1 predicate again to check that no recipes are left.

Fourth Rule for a Small Number of Recipes or a Show Command

This rule handles two scenarios: either there's a small number of recipes, or the user has explicitly asked to show the recipes despite even when the number .

...

Start with the text/2 predicate for featureInquiry.

...

is greater than 15.

• Use a response text similar to "Here are some recipes that fit your requirements.".

• Use the recipesFiltered/1 predicate to get the filtered list.Create a condition that checks if , and check that the length L is less than 16 but more than 0, or if (use a semicolon ; which represents a logical OR) check that the memory key-value pair '‘show', 'true' exists. This condition is composed of two parts joined by a semicolon ;, representing a logical OR.

Removed Filter

Add this predicate to the responses.pl file in the indicated spot.

% used in a21removeKeyFromMemory for handling deleteParameter. 
text(removedSpecificFilter(DelFilter), Txt) :- 	convert_to_string(DelFilter, Str1), 
	string_concat("I removed the ", Str1, Str2), 
	string_concat(Str2, " requirement.", Txt).

Visuals

...

• is stored in the agent’s conversational memory.

This completes the implementation of all the different cases for the agent’s response. The patterns for removing filters should now work!

Visuals

What you do visually for this capability is up to you.

Test it Out

Now Run your Conversational Agent again and try to remove some of the recipe constraints after you added them.