Beyond Coding: Watson Assistant Entities — Part 3, System Entities
In the first two articles, we examined the part entities play in an assistant and the difference between entities as synonyms versus entities as patterns.
In this article, we’ll be looking at system entities and how they differ from user-generated entities. We’ll also examine some helpful tips on how to avoid potential pitfalls to make sure you’re getting the best out of system entities.
User Generated Entities vs System Entities
As we’ve seen, user-generated entities allow you to create your own custom entities — either as synonyms or patterns. But what about those times when we want to identify a number? What do we do when we want to understand the user is talking about a date? Surely we don’t want to create and import these common entities every time we build an assistant!
This is where system entities can be used. System entities are a special type of entity which uses patterns and synonyms, but they are a part of the Watson system. This means we can implement them in our system for every skill and they will work the same way for every build.
However, it’s important to note you cannot modify these entities. They are available for use in all assistants, but the definitions — the synonyms and patterns — behind each entity exists within the Watson Assistant code and is not exposed to users.
To find the list of system entities you need to log in to your Watson Assistant, then click on Entities. You will then see two entity options — My entities and System entities. Click on System entities to display the list of available entities.
The first thing you should notice is the naming convention of system entities. All system entities start with the prefix “sys-”. This allows Watson Assistant to differentiate between an entity created by a user and those available to all users.
What this means is you cannot create a user-generated entity which starts with the prefix “sys-”.
Let’s look at each system entity to get a better understanding of what they can do. We’ll focus on the non-Beta system entities for this article.
The Currency System Entity
As the name suggests, this system entity is used to detect a currency value. If the user mentions a currency and a dollar value Watson Assistant detects the currency type and the number mentioned.
For example, a customer may say “I want to withdraw $50 from my account”. The assistant will recognize that a currency has been mentioned (dollar symbol) and the amount (in this case 50).
But what if the customer were to say “I want to withdraw fifty dollars from my account”? No problem! Watson Assistant recognizes a currency is mentioned as well as a number, even though digits weren’t used.
The Currency system entity identifies the type of currency used by the customer:
• “I want to withdraw fifty pounds from my account” would be identified as Great British Pounds (GBP)
• “I want to withdraw fifty euro from my account” would be identified as Euro (EUR)
• “I want to withdraw fifty Japanese yen from my account” would be identified as Yen (JPY)
But what happens if you’re in a country where the currency indicator is “dollars”? When Watson Assistant detects the currency type as “dollar”, or the dollar symbol (“$”), the default is USD. For any other currency which uses the terminology “dollar”, the user will have to state the specific type — such as “I want to withdraw fifty Australian dollars from my account”.
If the currency type is irrelevant to your build, you can ignore this aspect. Otherwise, you will need to take this into account when trying to determine which “dollar” currency is referenced.
It’s also important to understand if the customer’s interaction doesn’t include a currency indicator (dollars, $, etc) the assistant will not identify the number. For example, “I want to withdraw 50 from my account” will not be identified as a currency. Instead, you would need to use the Number system entity (discussed further on).
The Date System Entity
This system entity detects dates mentioned by a customer. It recognizes different types of dates and date formats (such as DD/MM/YY, MM/DD/YY, and YYYY-MM-DD).
For example, a customer could mention “Book an appointment for 13/1/2022”. The system entity detects the date is the 13th of January, of the year 2020. The statement “Book an appointment for 1/13/2022” would produce the same result.
But it can also detect the same date if the customer were to say any of the following:
• “Book an appointment for 13th January 2022”
• “Book an appointment for January 13, 2022”
• “Book an appointment for 13 Jan 2022”
It should be noted that the system entity is not case sensitive — thus January and January are the same things.
You should also be aware of the pitfall which applies to English language assistants only. The default date detection for English assistants is MM/DD/YYYY. In other words, 1/4/2022 is detected as 4th January, 2022. The assistant detects a date as DD/MM/YYYY only when the first number is greater than 12.
This is why “Book an appointment for 13/1/2022” and “Book an appointment for 1/13/2022” produce the same result — 13th January, 2022. However, the statement “Book an appointment for 1/4/2022” would be detected as 4th January, 2022. Again, this is for English language assistants only. In future articles, we will examine how to account for this and correct the information, but for now, you should be aware of this pitfall for English language assistants only.
The previous example deals with explicit dates mentioned in the customer’s interaction. But what if the customer didn’t know the specific date? What if they just knew they were available next Tuesday? Watson Assistant handles that for you!
The customer could say “Book an appointment for next Tuesday”. Watson Assistant understands that the user is referencing a date (Tuesday) and the future (next). In this case, the assistant would detect that the customer is talking about the first Tuesday after today.
This doesn’t mean the Tuesday next week, it means the first Tuesday which occurs after the current date. It’s important to understand the distinction.
For example, if a customer is interacting with your assistant on a Monday afternoon they may mean the Tuesday occurring next week (in approx. 8 days time). Watson Assistant will interpret “Book an appointment for next Tuesday” as tomorrow (in less than 24 hours time). This is because the system entity is looking for the first instance of Tuesday after today (Monday).
The same applies to the detection of previous days mentioned — such as “I had a booking last Tuesday”. If the customer is interacting with the assistant on a Wednesday, it detects the date as yesterday (the first Tuesday before the current date), rather than the Tuesday approx. 8 days ago.
This pitfall applies to all assistants, not only English language assistants. We will also look at ways to work around this pitfall in future articles.
The final aspect of the Date system entity is that it can detect date ranges. This means if a customer were to say “I need to make a booking next month”, the system will detect a date range within the interaction (first of next month to the last of next month). The same applies to date ranges such as “next week”, “next year” etc. While the system entity wouldn’t pinpoint a specific date, it does provide the understanding that a range of dates is applicable.
The Number System Entity
As the name suggests, this system entity detects numbers used in the customer’s interactions. The entity can detect cardinal numbers (and cardinal number words), such as 1, 2, three, four, etc. But it cannot detect ordinal numbers, such as 1st, 2nd, third, etc.
While this system entity is simple to understand, when used in conjunction with the Currency system entity you have a powerful set of tools. For example, a customer might be in a rush and decides to say “I want to withdraw 50 from my account”. There aren’t any currency indicators in the sentence which means the Currency system entity will not trigger. But with the Number system entity, your Assistant can identify the numeric value.
The Number system entity will also detect numbers used as part of a currency. For example, “I want to withdraw $50 from my account” would trigger both the Currency and Number system entities.
In future articles, we’ll examine situations where you might prefer to use the Number system entity versus the Currency system entity.
The Percentage System Entity
The Percentage system entity detects whether a percentage has been mentioned in the customer’s statement. For example, if the customer were to say “I want 30% of my account transferred”, the assistant would detect that a percentage had been mentioned. The same would apply if the customer had said: “I want 30 percent of my account transferred”.
It should be noted that a percentage range would also be detected. For example, “I want 25–30 percent of my account transferred”, would trigger the Percentage system entity indicating that the percentage mentioned was 25 and 30.
Also note that the percentage in the sentence “I want 25 to 30 percent of my account transferred” would produce a different trigger. Only the number adjacent to the word “perfect” (or the % sign) (in this case “30”) is detected as a percentage.
The Percentage system entity overlaps with the Number system entity. A percentage trigger will also trigger detection from the Number system entity. This would allow for a combination to compensate for any pitfalls, such as the percentage example above where only the “30” is detected.
The Time System Entity
This system entity detects times mentioned by a customer. This system entity typically works in conjunction with the Date system entity, but they do function independently.
For example, a customer might say “Book an appointment for 3pm”. The Time system entity will detect that a time (3pm) has been mentioned. But what if the customer didn’t think to mention the am/pm indicator, but instead said “Book an appointment for 3”. The Time entity will not detect a time in this case since we can’t be sure the customer doesn’t mean book an appointment for 3 people. But, if the sentence had been “Book an appointment at 3”, the entity detects a time (“at 3”), but detects the time as 3am!
The Time entity can also detect implied times. For example, “Book an appointment in 3 hours”. The entity would interpret this as a time 3 hours into the future from the time the interaction occurred. The great thing is that the Date system entity detects that the user is talking about a date as well and automatically calculates the date discussed.
The other feature the Time system entity shares with the Date system entity is the ability to detect ranges. For example, “Book an appointment for 2pm to 3pm” is detected as a range starting at 2pm and ending at 3pm. But, “Book an appointment for 2–3pm” would be detected as a time range starting at 2am and ending at 3pm. There are techniques we can use to navigate around these pitfalls, which will be discussed in future articles.
It’s important to understand the subtleties of this system entity, as what we might expect may not be what the system has detected. By understanding these nuances, we can anticipate, and account for, pitfalls.
System Entity Benefits
Now that we’ve looked at each of the system entities why would we use them if we have the freedom to generate our own? One reason is re-usability. We can implement system entities across multiple assistants and they function the same way in every build.
But, beyond identifying information, system entities allow us to extract the information for later use — without creating Regular Expression patterns. The patterns are built into the system entity and we can easily extract the identified value!
So, with system entities, we have a great package where we can easily detect and, if required, extract data. The added benefit is that we can control whether to use them for our assistant. Unlike user-generated entities, we can turn system entities on or off. This means we can either use the pre-packaged system entity or if we prefer, create our own version.
System entities are a great solution to commonly used concepts and they are always available. They help to speed up our build time and get the assistant up and running that much faster!
More About Entities
Now we’ve taken look at system entities we’ll be taking a closer look at implementing entities in general. In future articles, we will examine:
- How to use entities
• How to determine which entities we need
• Entity Best Practices
Stay tuned for future updates!
