Beyond Coding: Watson Assistant Entities — Part 2, The Faces Of Entities

Oliver Ivanoski
IBM watsonx Assistant
5 min readAug 28, 2019
Photo by Brett Jordan on Unsplash

In the first article, we went through an overview of where entities fit in the Watson Assistant structure. We also touched upon the different types of entities and their benefits.

In this article, we will take a closer look at the different types of entities — synonyms and patterns. As we know, entities are a feature which allows us to group items or concepts. This allows us to strengthen the intelligence of our Watson Assistant. But to further improve a customer’s (or end-user’s) experience, we can use entities to recognize patterns and extract data.

Entities are also broken down in two areas. The first is user-generated entities and the second is system entities. For now, we will focus on user-generated entities (entities you create for your assistant). System entities will be discussed in other articles.

User Generated Entities — Synonyms

At their very core, entities are synonyms which help the assistant determine what the customer is asking (in conjunction with intents). Entities are the mechanism by which we link concepts (words) to one another.

Consider entities to be a collection of groups. Each entity contains its members, and each member contains its synonyms.

The simplest example (which has been used to explain various concepts) is the group of Animals. For instance, we want to provide people with an assistant which helps them navigate a zoo’s enclosures. Part of the process is to understand which animal is being discussed.

With this in mind, we would create an entity called Animals. Within this entity, we would have several animals and their synonyms.

For example, “Hippopotamus” would have the synonyms “hippo”, “river horse”, “hippopotami”, “hippopotamuses” (to take into account the evolution of language) and perhaps even “Hippopotamus amphibious”. For this example, we will ignore the pygmy hippopotamus.

You would then continue to add synonyms for animals as required. But the level of detail depends on the domain, or topic, the assistant will discuss. In our fictional zoo, all birds may be housed in a single enclosure, which means you could create “Birds” as part of the “Animals” entity and populate it with synonyms such as “parrot”, “owl”, “kookaburra”, “condor”, “eagle” etc. If the birds were scattered in multiple enclosures, you could create an entry for “Birds of prey” / “Raptors”, “Nocturnal birds” or “Marsh birds”.

An example of the Animals entity

The delineation on how to define the entity is something we will look at in future articles, but for now it should be understood that an entity is the umbrella concept while the entries underneath it are the group’s members.

Possible expansions of the Animals entity

This now means the assistant now understand that a hippo and a parrot are both animals.

But is that the extent of the synonyms capability? Not at all. We could expand the entity synonyms to use phrases, or multiple concepts.

Consider the phrase “Tell me about”. It’s an indicator that the customer is asking for information. We could create entities for the components, but a phrase entity would suffice. We could consider adding “Explain to me”, “What do you know”, “Do you have information”, etc. By going beyond simple word synonyms, we begin to expand the building blocks — and the power — of entities in our assistant.

We’ll take a closer look at creating and defining entities in future articles, for now, it’s important to understand that entities aren’t limited to single concepts or words — as I’ve mentioned, an entity houses the groups of similar concepts.

User Generated Entities — Patterns

Entities as synonyms are useful in identifying information and determining the topic being discussed. But is data identification the most we can expect? Definitely not!

With pattern entities, you can tell the Watson assistant that you expect customers will provide certain data types — anything from an email address to an alphanumeric serial number. With pattern entities, you’re only limited by the customer information you need to identify.

Unlike Synonym Entities, Pattern Entities identify a recognizable pattern in the customer’s query. The structure of the pattern is determined by the regular expression (or regex) defined in the entity. I won’t delve into regular expressions (not only is the subject extensive, but there are numerous online resources which can help), but I will provide a simple example to better understand what we mean by Pattern Entities.

A pattern entity should follow the same considerations as a Synonym Entity — a top-level entity containing groups of concepts. But instead of synonyms, you are simply defining patterns.

It should be noted, an entity cannot be both a Synonym Entity and a Pattern Entity — entities can only be one or the other.

With that in mind, let’s consider our zoo navigation example. Our customers have been traveling around the zoo and they are told about discounts and offers with the zoo’s partners. To find the best discounts for their area, we need a zip code. With System entities, we can’t do anything more than understand the topic is “zip code” and “discounts”.

So, we create a new entity — Contact_Details. We now have an entity devoted to understanding how we can communicate with the customer. But more importantly, we can extract the information.

Once we have the high-level entity, we add a “Zip” entry. We then tell the assistant which regular expression pattern we want to use — (\b|\s)\d{5}(\b|\s). This simple example tells the system to look for continuous 5 digits with spaces or boundaries around those digits.

An example of Pattern entities

We now have a way of identifying the pattern, we can now extract this information from the customer’s response. The way we achieve this will be discussed in future articles, but for now we should understand that once we have the zip code we can decide what to do next — send it to the discount systems to display partners; provide analytics for the zoo to determine where they should increase discount partners and so on.

More About Entities

Now we’ve taken a quick look at the two different types of entities available. It’s important to understand how they work and how they differ to get the best out of entities. We’ll be looking at entities in-depth in future articles, where we examine:

  • How to use entities
  • How to determine which entities we need
  • Entity Best Practices

Read about pre-built system entities in the third article of this series.

--

--