Entities enable Watson to identify details and

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 suggestion's 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 in 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 a 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 his own the user's ultimate

goal and match it on an intent based on the examples that we trained it on.

For entities, Watson will only detect the exact values and

synonyms that we 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 had 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 column is use to indicate a specific value within the entity.

This will come in handy when we design the dialogue, and we want to provide different

responses for occasion 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 location is.

Our response could for example ask what the specific location 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, alight and in purple in the input,

is a synonym we declared for the sickness value within the occasion entity.

He will therefore associate the user input with the flower suggestions intent,

and with the occasion call in 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 dialogue, entities with a space

will have to be referred to by surrounding them by parentheses.

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're 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-month-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're adding a large number of examples for

intents, it might be more convenient to import a CSV file

that you have 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 will be imported as a synonym for

the value on that same row.

You would end up with as many row 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 the 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,

the 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's Conversation UI to input the data manually,

as I will show you in module three.

Entities

How to Build a Chatbot Without Coding

Conheça os instrutores