Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For this section, you will have to collaborate closely with your Dialogflow and Filter groupmates. Patterns are made up of agent responses and user intents. These user intents are defined by the Dialogflow Intents that your groupmates create. Your naming conventions must match. If you do not know what an intent is, it may be helpful to look into the Dialogflow Intent. You could also have to look for information in the recipe database. 

c10 Greeting Patterns

c10 Greeting with No Introduction

To make a pattern you need to use the Prolog predicate ‘pattern(_)’. This predicate only takes one argument, which should take the form of a prolog list.

...

pattern([c10, [agent, greeting], [user, greeting]]) :- not(agentName(_)).

c10 Greeting with Introduction

 

Pattern C10.1: Opening Self-Identification (Agent)

...

This pattern will be quite similar to the one above but should include the predicate ​​'selfIdentification'. Also, note that the agent must have a name in order to self-identify. 

c10 responses.pl

In responses.pl you will see the fact text(greeting, ""). Fill in the “” with a response you want your agent to give as a greeting 

...

This rule should produce a response that is returned as Txt, and should include the robot's name. 

c30 General Capability Check

Your user wants to know what your bot does. Create a pattern for this. 

...

In responses.pl find text(describeCapability, ""). and fill in the atom with an appropriate response.

c40 Closing 

This is the pattern that closes the conversation between the user and agent, a farewell. In this pattern, our agent should do the ‘sessionCloser’ and say ‘farewell’. (or another phrasing of goodbye that fits to the agent persona your team is designing).

In responses.pl, fill in a final remark from your agent about your program in the session closer and add a farewell. 

B Patterns for Repair

A good handling of repair is vital to making your agent robust to misunderstanding. There are a few common ways in which misunderstanding occur’s, that need to be addressed by proper repair patterns.

b12 The agent does not understand the user utterance

Example:

U: chicken soup

A: what do you mean?

...

In responses.pl: paraphrase requests are determined depending on the context of the conversation (specified as the pattern that is currently active). Under the paraphrase request section in responses.pl you will see ‘text/3’, which specifies the active pattern, the agent response name, and what the agent should say. Fill all these in. 

b13 Out of Context. 

The user said something that Dialogflow can identify with the user’s intent, but your agent is not at a stage where that intent is appropriate. 

...

Fill in all the contextMismatch responses in response.pl. Like the paraphrasing response, it depends on where the user is in your agent’s program. 

b14 User Repetition

The user repeats themselves the user says something that is identified and the agent responds with repeatedUserIntent

In responses.pl fill in a response for the repeatedUserIntent.

b42 Appreciation 

 Example:

U: Thanks

A: You're welcome.

...

Go into responses.pl and fill in the corresponding text fact.

a50recipeSelect: Selecting a Recipe 

Example:

A: Let us find a recipe together.

...

In responses.pl fill in the corresponding responses for specifying goal and recipe inquiry. recipeChoiceReceipt requires a rule. To respond the agent must find the current recipe, access a list of all recipe IDs using the predicate recipeIDs(), check that the current recipe is a member of the list(better safe than sorry), get the recipes name, return a response using string_concat(“Phrase Part 1”, “Phrase Part 2”, Txt). 

a50recipeConfirm: Confirming a Recipe 

after the user selects a recipe the agent should confirm the user’s choice. On this page, the user would see recipe information via visual support.  We foresee three potential situations for this conversation thus we will make three a50recipeConfirm patterns, one for each scenario. The agent uses recipeCheck to ask if the user can look over the recipe information and ask if they want to cook that recipe. The user could confirm, deny, or show appreciation. Look at Dialogflow for the appropriate Intent identification naming.  If the user says they don’t want to choose that recipe we need to go back a step. How would one do this?

...

In responses.pl fill in text ( recipeCheck, “”) 

a21noMoreFilters 

Example

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

...

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. 

Pattern a21featureRequest

 Pattern A2.10: Open Request Series

...

Unlike previous patterns, this pattern will be in a rule. Thus you only have to fill in the head of the rule. For all feature request pattern variations, the conversation starts with the user adding a filter. The intent is categorized by Dialogflow under the label addFilter. After the user adds a filter you should have the agent use the predicate removeConflicts(Params) to remove the conflicting filters. 

Variant 1: a21featureRequest

In variant 1 of a21featureRequest, while already checking a recipe in the confirmation phase, the user wishes to continue filtering or look at other recipes. In this variant we assume some recipes fit the new filter criteria, thus the agent can acknowledge that there are recipes left. The agent should use the acknowledge filter predicate(look for it). In this variant, if the user is at the checking recipe step and wants to look at other recipes then the agent must re-insert a50recipeSelect into its agenda. 

Variant 2: a21featureRequest

A variant for when a user wants to add a specific filter while already checking a recipe but there are no recipes left that satisfy all feature requests. Thus after the user adds a filter, the agent removes conflicts and then finds that there are no recipes left and must inform the user that there are no recipes left that fit the user’s criteria using the predefined predicate in responses.pl. The agent should then ask the user to remove a filter with the predicate featureRemovalRequest. Lastly, in this pattern, since there are no recipes left and the user would already be past the a50recipeSelect step the selection should restart. How would one do this?

In responses.pl you have to fill in an appropriate phrase in text( featureRemovalRequest, “”) 

Variant 3: a21featureRequest

This variant is for when the user is not checking a recipe and there are recipes left that could be filtered. The pattern itself is the same as variant 1 except instead of inserting the a50recipeSelect into its agenda(it's unnecessary if not one is not in the checking recipe step) the agent should continue its feature inquiry and ask the user for more filters. This is done with the text featureInquiry rules which you must finish in responses.pl. Note the response should be different based on the number of recipes left:

...