Auto news on Youtube Oct 29 2017

Entities enable Watson to identify details in the user's input which we can then use

to provide different responses to the user.

For example, "Which flowers for a birthday?" and "What are the best flowers for Valentine's

Day?" both express the #flower_suggestions intent that we defined before, however the

two requests will require different responses.

So, to differentiate these two requests, we can use entities.

Entities have a name and a series of values.

These values, in turn, have associated synonyms.

Synonyms are optional, but recommended, given that the user might enter the same concept

using a different word.

When Watson Conversation parses the question from the user, it will try to first detect

the matching intent and then any matching entities.

Extracting both intent and entity from the user's question enables us to provide very

specific and precise responses to the user.

Unlike intents, where Watson will figure out on its own the user's ultimate goal and

match it to an intent based on the examples that we trained it on, for entities, Watson

will only detect the exact values and synonyms that we've specified.

If we enable the fuzzy matching option, which is currently in beta, then misspellings of

the specified values and synonyms will also be detected.

Also, unlike intents which start with a pound symbol, entities start with an @ sign.

Not to be confused with Twitter handles.

In our flower suggestion example, we could define an @occasion entity that has several

values, one for each different occasion.

For example, we can have birthday, Valentine's Day, sickness, funeral, and so on, as its

values.

We can then provide synonyms for each of these values, if any are available.

In Watson's eyes, the question "Which flowers for a birthday?" will then be interpreted

as having: #flower_suggestions intent, @occasion as the

entity, and birthday as the value of the entity.

Note that the colon (:) is used to indicate a specific value within the entity.

This will come in handy when we design the dialog and we want to provide different responses

for @occassion:birthday and, say, @occasion:sickness.

When we build our chatbot in the next module, we will see how to handle users who are less

specific and don't specify what the actual occasion is.

Our response could, for example, ask what the specific occasion is.

Follow up questions of this kind tend to make our chatbot more human-like and generally

more useful.

Here, when we enter the question "Can you suggest get well flowers?" to test the chatbot,

Watson detects that our intent is flower_suggestions.

It also detects that get well (highlighted in purple in the input) is a synonym we declared

for the sickness value, within the occasion entity.

It will, therefore, associate the user input with the flowers_suggestions intent and with

the @occasion:sickness entity.

When designing the dialog and defining what to reply to the user, we'll be able to check

for which entity value has been triggered by the user and respond accordingly.

Entity values can contain spaces.

However, when designing the dialog, entities with a space will have to be referred to by

surrounding them by parenthesis.

For example, @occasion:(Valentine's Day).

When it comes to entities, you don't have to do all the work.

Thankfully, there are some predefined system entities that you can use in your chatbot.

They are disabled by default, but you can enable one or more, and even all of them.

When enabled, these entities get added to our chatbot and Watson is then able to automatically

detect various predefined pieces of information from the user input.

For example, by enabling @sys-date Watson will detect any date in the user's input.

The user might type "next month" somewhere in their question, and Watson will bind it

with the @sys-date entity and the date value in the full year, dash, month, dash day.

My recommendation is not to clutter your chatbot with system entities.

Instead, only enable those that you actually need for your own specific bot.

Before moving on to the dialog portion of this module, I wanted to mention that it is

possible to import (and export) intents and entities.

In fact, if you are adding a large number of examples for intents, it might be more

convenient to import a .csv file that you've generated with a program like Excel or Google

Sheets.

The format is quite simple.

For intents, you would have the questions in the first column, and the corresponding

intent in the second column.

Then export to comma separated value from your program.

Note that in this case, you would not prefix the intent with the pound symbol.

For entities, you would have one column for the entity name (again without the @ symbol)

and a second column for values.

Any extra value in successive columns would be imported as a synonym for the value on

that same row.

You would end up with as many rows as you have entity values.

If you are consulting the Watson Conversation documentation in relation to this, you might

come across the term Ground Truth.

Ground Truth is a collection of vetted data that we feed Watson to train it, in our particular

domain.

Whether you enter your examples manually in Watson Conversation or you import them from

a comma separated file, that matching between the examples and the intents is Ground Truth.

Of course, it's perfectly possible to build a chatbot without importing intents or entities

from CSV, entirely relying on Watson Conversation's UI to input the data manually, as I will show

you in Module 3.