Beyond Coding: Watson Assistant Entities — Part 4, New System Entities
In the previous article we looked at system entities — a group of Watson pre-packaged entities available for commonly used concepts. We also saw that this useful feature allows us to quickly build a powerful assistant without having to spend time creating synonyms or Regular Expression patterns.
But system entities are going through an improvement process! In this article we’ll be looking at the upcoming new system entities and the major improvements upon the current system entities.
System Entities, New And Old
We should first understand that at the time of this article, the new system entities are in Open Beta. This means that:
• New system entities may slightly change in the future
• New system entities are available to users, not just Beta users
• They are only available for certain languages (see the System entity feature support details table on the Supported Languages page for more information)
Also, not all system entities have gone through changes. We’ll only be looking at system entities which have been overhauled. If a system entity is not mentioned in this article it means that it will continue with its current behaviour (see the previous article Beyond Coding: Watson Assistant Entities Part 3 — System Entities for system entity behaviours).
Now let’s look at some of the new system entity features to help you get an understanding of what’s available and what might be useful to you.
The Date System Entity
As we’ve seen, the Date system entity identifies dates and date ranges, but the new Date system entity allows for additional date detection.
With the current Date system entity a customer might mention an incomplete date, such as “Show me the invoice for 11th of May”. The Date system entity will assume the customer is talking about the future date (such as 11th May 2020) — in other words the following year will be inserted into the date to form a complete date structure.
With the Alternatives feature, the system entity will now supply a list of alternative dates — including the current year. This allows us to get a better understanding of the specific date without having to create complex structures to define aspects such as year.
The Date/Time link now improves the connection between date and times being mentioned in a customer’s query. For example, if a customer were to say “I want to make an appointment for Monday at 2pm”, the current Date and Time system entities would detect the relevant information. With the new Date system entity, both date and time are detected by the Date entity.
This means the assistant has detected a link between the two components, that the customer is likely talking about a time for the specified date. With the current system entity no such link is detected and the system treats the information as two separate items.
If you’ve ever had to deal with public holidays you know that sometimes they occur on slightly different dates. The Festival improvement helps alleviate some of the holiday headaches!
With the Festival improvement the system entity will detect that a significant day has been mentioned, such as New Year. The added advantage is that the system will also use the date and populate the Alternatives feature to help determine the year — does the customer mean New Year from the current year, or the following year?
The Range Link feature allows the assistant to detect a range of dates mentioned in the customer’s query. For example, if a customer were to say “Can I make a booking from 16th May to 1st June?”, the assistant would detect that a range of dates have been mentioned as well as the start and end dates — in this case starting at 16th May and ending at 1st June.
The Number System Entity
The Number system entity also has a Range Link addition. This is similar to the Date Range Link, but based on number detection instead of date detection.
For example, if a customer were to say “I want to buy items 12 to 15”, the system entity would detect the start and end of the range — allowing for a smoother understanding of the customer’s interaction, rather than forcing the customer to identify every item number.
The Time System Entity
The current Time system entity automatically assumes a time indicator. For example, if a customer says “Can I make a booking at 2?”, the system entity assumes the time discussed is 2am. In some cases this might be correct, but not in all cases.
This is where the Alternatives feature helps to determine the correct time. This feature provides an alternative time to that which was identified — in this case it would detect that the alternative is 2pm and allow the system to confirm the correct time.
If a customer uses the 24-hour time format, for example, “Can I make a booking at 14?”, the entity will detect that 2pm is being discussed and will not provide an alternative time.
The Time system entity also has a Range Link feature. If a customer were to say “Can I make a booking from 2pm to 5pm”, the system entity would detect the range starting at 2pm and finishing at 5pm.
The advantage is that the system entity will also recognise a time range when the time indicator isn’t provided — and customers can often do this!
For example, “Can I make a booking from 2 to 5?”, would be detected as a time range beginning at 2am and ending at 5am. When associated with the Alternatives feature, the system can begin to identify if the customer was truly talking about 2am, or 2pm.
However, if the customer were to say “Can I make a booking from 14 to 17?”, the time range would be detected as 2pm to 5pm and an alternative wouldn’t be provided.
More often customers will use 12-hour time rather than 24-hour time, so the Alternatives feature is a great way to clarify the customer’s interaction.
One pitfall to look out for is the case where customer omit time indicators and don’t use time formats — for example, “Can I make a booking from 230 to 530?”. The Time entity won’t identify this as a time range.
This is where the Number Range Link can be used. The Number system entity will identify the range starting at 230 and ending at 530. This would allow your assistant to then ask subsequent questions to confirm the time range, or to ask the customer if they could include the time indicators (am/pm). Providing a much better experience than not detecting the range at all.
One thing to note, if the customer provides a time format, such as “Can I make a booking from 2:30 to 5:30?”, the system will detect the time range (and provide alternatives where required).
The last improvement we’ll look at is the Part Of Day feature. Currently the Time entity interprets the time of day references as the following:
• “Morning” is interpreted as 9am
• “Afternoon”, “Evening” and “Night” are interpreted as 6pm
The Part Of Day feature extends this existing component to provide a wider range of times by returning a range of hours, as follows:
• “Morning” is now interpreted as 6am to 12pm
• “Afternoon” is now interpreted as 12pm to 6pm
• “Evening” is now interpreted as 6pm to 10pm
• “Night” is now interpreted as 10pm to 11:59pm
This wider range of interpretations allows for a better understanding of a customer’s interaction.
Other System Entity Improvements
The feature discussed above are some of the more commonly used, but there are several other features available which you may find useful.
You can find more information about the features discussed here and technical changes for new system entities at the New system entities page.
More About Entities
Now we’ve taken look at system entities we’ll be taking a closer look at implementing user generated entities. 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!
