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.