We provide entities that identify objective information from the user input, like
time, date, and addresses.
These built-in entities extract primitive values like strings and integers, but can
also extract more complicated values from the user input using groups of properties.
Note
Whenever you define a variable as an entity in a YAML-based dialog flow, be sure to
match the entity name and letter case exactly. For example, you’ll get a validation
error if you enter confirm: "YESNO" instead of confirm:
“YES_NO”.
Built-In Entities and Their
Properties 🔗
Entities extract content using properties, each of which recognizes a specific
value. You can see these properties in the JSON output that’s returned by the NLU
Engine. In this output, the matched entities display along with the value that they’ve
identified from the user input. Within your dialog flow definition, you can use these
properties to isolate a specific facet of an entity value.
While
each entity has its specific properties, all entities have the following
properties:
Property
Description
beginOffset
The beginning offset of this slotted entity value starting at
0.
endOffset
The ending offset of this slotted entity value starting at
0.
originalString
The original string that was extracted from the query for this
entity slot or the response to the prompt.
Note
The DATE, TIME, and DURATION
entities are deprecated in Release 22.08. These entities are not available to skills
created on this version of the platform. They use the DATE_TIME entity instead. Existing skills upgraded to 22.08
will continue to support these legacy system entities, though there may be some
behavior changes.
This entity
is deprecated in Version 22.08 and is unavailable to skills created
on this version of the platform. For skills created using prior
versions, consider using the DATE_TIME entity instead.
Note: When the user input names a day, but provides no
other temporal context, the system considers this a future date. For
example, it considers Wednesday in the following input as next
Wednesday, not the current Wednesday or the prior Wednesday.
Book me a ticket for Wednesday.
I want to file an expense report for
Wednesday.
You can override this behavior by applying an ambiguity resolution rule. While the DATE
entity resolves to format of several supported locales, you can opt
to ignore the format of the detected locale, and impose a default
format and a tense (future, past, nearest, etc.) by applying an
ambiguity resolution rule.
Interpretation of February 23 per the time resolution rules. Because the use case is for
scheduling a meeting, the date will always be interpreted as
forward-looking.
"value": "P1W": An ISO 8601 interchange
standard representation of weekly/once a week, where
P is the duration desigator and
W is the week designator.
DURATION
The amount of time between the two endpoints of a time
interval
This entity is deprecated in Version 22.08
and is unavailable to skills created on this version of the
platform. For skills created using prior versions, consider using
the DATE_TIME entity instead.
An email address. The NLU system can recognize email
addresses that have a combination of the following:
part before the at (@) symbol:
uppercase and lowercase letters in the Latin
alphabet (A-Z and a-z)
digits (0-9)
the following printable characters:
!#$%&'*+-/=?^_`{}~
dot (.)
part after the at (@) symbol:
uppercase and lowercase letters in the Latin
alphabet (A-Z and a-z)
digits (0-9)
hyphen (-)
ragnar.smith@example.com
LOCATION
Extracts cities, states, and countries from the user's
input.
Redwood City
CA
USA
city
state
country
"LOCATION": [ { "originalString": "Redwood City, CA, USA",
"name": "redwood city, ca, usa", "country": "usa", "state": "ca",
"city": "redwood city", "entityName": "LOCATION" }
]
NUMBER
Matches ordinal and cardinal numbers. You can resolve a
entity as the locale-specific format (grouping of thousands by
full stops, commas, spaces, etc.).
1st
first
1
one
PERSON
Recognizes a string as the name of a
person.
The PERSON entity can't match
names that are also locations (for example, Virginia
North).
To expand the PERSON entity to always match the
people in your organization, you can associate it with a Value List
Entity.
John J. Jones
Ashok Kumar
Gabriele D'Annunzio
Jones, David
Cantiflas
Zhang San
Virginia Jones
name
"PERSON": [ { "originalString":
"John J. Johnson", "name": "john j. johnson", "entityName": "PERSON"
} ]
PHONE NUMBER
A phone number—The NLU Engine recognizes phone numbers
that have seven or more digits (it can’t recognize any phone number with
fewer digits). All country codes need to be prefixed with a plus sign
(+), except for the United States of America (where the plus sign is
optional). The various parts of the phone number (the area code, prefix,
and line number), can be separated by dots (.), dashes (-), or spaces.
If there are multiple phone numbers entered in the user input, then the
NLU Engine can recognize them when they’re separated by commas. It can’t
recognize different phone numbers if they’re separated by dots, dashes
or spaces.
This entity is deprecated
in Version 22.08 and is unavailable to skills created on this
version of the platform. For skills created using prior versions,
consider using the DATE_TIME entity instead.
In some cases, for example, when the input is ambiguous, you may
need the TIME entity to resolve input consistently as a past or
future time, or approximate it by the nearest time. To do this,
apply an ambiguity resolution rule.
A URL—This entity can extract IPv4 addresses, Web URLs,
deep links (http://example.com/path/page), file paths,
and mailto URIs. If the user input specifies login
credentials, then it must also include the protocol. Otherwise, the
protocol isn’t required.
There are many ways that your skill might need to get date and time input. For example, you may need a simple date or time, a date and a time, or a one-time or recurring period. You can use the DATE_TIME entity to gather information for all of these scenarios.
With the DATE_TIME entity, you choose a specific subtype to define what information to gather. The following table shows which subtype to use for each possible scenario and links to information about the attributes for each subtype.
A regularly recurring period defined by, for example, the start and end of the first period, the interval between the recurring periods, and when the periods stop recurring.
the DATE_TIME entity supersedes the DATE, TIME, DURATION, and SET system entities, which have been deprecated and are not available in skills created in Release 22.08 and later. Existing skills upgraded to 22.08 will support these deprecated system entities, though there may be some behavior changes.
You can use the Date, Time, and Duration subtypes as standalone entities in
the dialog flow (where you declare separate variables for each), but you can only
utilize the Interval and Recurring subtypes by incorporating them into a composite bag entity.
Note
We recommend that all DATE_TIME
subtypes be managed within a composite bag entity.
In visual dialog mode, reference DATE_TIME subtypes using Resolve Entity and
Resolve Declarative Entity states.
Note
If you use the Date, Time, and Duration subtypes as standalone entities
in a YAML-based dialog flow, specify the subtype using dot notation:
DATE_TIME.DATE, DATE_TIME.TIME,
DATE_TIME.DURATION and for SET,
DATE_TIME.RECURRING. For
example:
In
the states node, you reference these variables using a
System.ResolveEntities component.
DATE_TIME values are representated as ISO 8601. For user-friendly output, use
the Apache FreeMarker .xsbuilt-in. For example, the Time subtype is
extracted using .value.value?time.xs?string['hh:mm a'] in the following
resource bundle
reference:
The
first value gets the content of the variable as an object. The second
value is an attribute of the DATE_TIME object that holds the time
value.
Attributes for Each DATE_TIME Subtype 🔗
Here are the attributes for each DATE_TIME subtype.
Note that, just like every other system entity, the subtypes also include the beginOffset, endOffset, and originalString properties.
DATE Subtype Attributes 🔗
The DATE subtype contains these attributes about a specific date:
Attribute
Type
Explanation
entityName
String
DATE_TIME
month
Integer
When DATE is an attribute of the RECURRING subtype, and the original string includes
the name of a month, such as "every Monday of July", this represents
the numeric representation ("7" in this example) of the
explicitly-specified month value .
movableDateValue
String
When DATE is an attribute of RECURRING and the slotted date doesn't represent a specific date (that is, it is a movable date such as July 4), this represents the explicitly-specified movable date value that's used by the RECURRING subtype's DATE attribute to differentiate between the resolved movable date and the resolved non-movable date. For example, if the slotted date is July 4, then this value is --07-04.
ordinal
Integer
When DATE is an attribute of the RECURRING subtype, and the original string specifies an ordinal value, such as first in "every first Monday", this represents the numeric value of the ordinal (in this example, "1").
ordinalReference
Enum
When DATE is an attribute of the RECURRING subtype, and the original string includes an ordinal that is qualified by the name of a month, such as July in "every first Monday of July", this represents the explicitly-specified qualifier ('M' for month).
subType
String
DATE
timezone
String
The time zone offset. For example: +07:00.
type
String
DATE_TIME
value
String
The resolved value in ISO 8601 format. For example 2022-08-05.
weekday
Enum
When DATE is an attribute of the RECURRING subtype, and the original string includes the name of a day, such as "every Monday", this represents the explicitly-specified weekday value using the iCalendar format, such as MO, TU, and WE.
year
Integer
When DATE is an attribute of the RECURRING subtype, and the original string includes the year, such as "every Monday of 2023", this represents the explicitly-specified year value.
Here's an example of the NLU response for the DATE subtype:
The INTERVAL subtype contains these attributes about a period that's defined by a beginning and ending date and time, or is defined by a date, start time, and length, such as 2 hours.
The RECURRING subtype contains these attributes about a regularly recurring period:
Attribute
Type
Explanation
entityName
String
DATE_TIME
recurrenceDates
Array of DATE
Included when multiple recurring dates are given. This object contains an array of DATE objects with the attributes described in DATE Subtype Attributes.
Included when multiple recurring times are given. This object contains an array of TIME objects with the attributes described in TIME Subtype Attributes.
recurrenceUntil
INTERVAL
Specifies the bounds of the repetition. Typically, only the end date is specified. This object contains the attributes described in INTERVAL Subtype Attributes.
Note that for RECURRING entities, the DATETIME's DATE sub-object may include the month. movevableDateValue, ordinal, ordinalReference, weekday, and year attributes.
Ambiguity Resolution Rules for
Time and Date Matches 🔗
Users can enter partial dates where the time is implied. For example:
"Schedule a meeting for Monday"
"Create an expense report for 7/11"
"Create an expense report for the 11th"
Some situations, like scheduling a meeting, imply a future time.
Others, like creating an expense report, refer to some time in the past. To
ensure that the DATE_TIME entity Time and Date subtypes can resolve
ambiguous input as the past, present, or as the closest approximation, you
can apply Ambiguity Resolution Rules. To set the temporal context for the
time resolution, for example, click the DATE_TIME entity and then apply a
rule.
Note
The
ambiguity resolution rules do not validate the user input. You can
validate the user input with custom validator that uses Apache
FreeMarker (which is not recommended) or in an Entity Event Handler (which is
recommended). This validator returns false
(validation fails) if a past date is given for a forward-looking use
case (for example, a meeting scheduler). For a backward-looking use
case like expense reporting, the validator returns
false if the user inputs a future date.
Note
If you're
referencing the same entity with two or more items within the same
composite bag, or if two or more composite bags reference the same
entity and are also associated with the same intent, upgrade to
Release 21.12 to ensure that the ambiguity resolution rules specific
each entity reference are handled separately and not overwritten by
the rules set for a previously resolved entity.
Resolution Rules for Matches to
the Date Subtype 🔗
Date resolves to the UTC date, not the server's date nor the browser's date. For
example, "today" uttered at 8 pm on July 8th from the Hawaii–Aleutian Time Zone
(UTC−10:00) is resolved as July 9th.
Rule
How it works
Examples
Past
Resolves the ambiguous input as the nearest day of
the week in the past.
If the utterance includes "Monday" and the
current day is also Monday, then "Monday" is resolved as
today.
If the utterance includes "Monday" and the
current day is Wednesday, the "Monday" is resolved as the
previous Monday.
Future
Resolves the ambiguous input as the nearest day in
the future
If the utterance includes "Monday" and the
current day is also Monday, then "Monday" is resolved as
today.
If the utterance includes "Monday", and the
current day is Tuesday, then "Monday" is resolved as the
following Monday.
If the utterance includes "Tuesday", and the
current day is Monday, then "Tuesday" is resolved as this
Tuesday.
Nearest
Resolves the ambiguous input as the nearest
day.
If the utterance includes "Monday"and the
current day is also Monday, the "Monday" is resolved as
today. If the utterance includes
"Monday" and the current day is Tuesday, then "Monday"
resolves as yesterday.
If the utterance includes "Monday", and the
current day is Sunday, the "Monday" resolves as
tomorrow.
Default
Resolves the ambiguous input as a future
date.
For example, if the input includes Wednesday, the
day is interpreted as next Wednesday, not the prior Wednesday or the
current day (if it's a Wednesday, that is).
Resolution Rules for Matches to
the Time Subtype 🔗
Rule
How it works
Examples
Past
Resolves the input to the nearest time in the past
relative to the current time in the UTC time zone.
If the utterance includes "9 am" and the current
time is 10:00 am, then the time is resolved as 9:00 am
today.
If the utterance includes "9 pm" and the
current time is 10:00 am, then the time is resolved as 9:00
pm yesterday.
If the utterance includes "9" and the current
time is 10:00 am, then the time is resolved as 9:00 am
today.
Future
Resolves the input to the nearest time in the future
relative to the current time in the UTC time zone.
If the utterance includes "9 am" and the
current time right now is 10:00 am, then the time is
resolved as 9:00 am tomorrow.
If the utterance includes "9 pm" and the
current time is 10:00 am, the time is resolved as 9 pm
today.
If the utterance includes "9" and the current
time is 10:00 am, then the time is resolved as 9:00 pm
today.
Nearest
Resolves the input as the nearest time relative to
the current time in the UTC time zone.
If the utterance includes "9 am" and the
current time is 10:00 am, then the time is resolved as today
9:00 am.
If the utterance includes "9 pm" and the current
time is 10:00 am, then the time is resolved as 9:00 pm
today.
If the utterance includes "9" and the current
time is 10:00 am, then the time is resolved as 9:00 am
today.
If the utterance includes "10:00" and the
current time is 1:00 am, then the time is resolved as 10:00
pm yesterday.
Default
Resolves the input by the method used in the
pre-21.06 releases of Oracle Digital Assistant.
If the utterance includes is "9 am" and the
current time is 10 am, then the time is resolved as 9 am
today.
If the utterance includes "9 pm" and the
current time is 10 am, then the time is resolved as 9 pm
today.
If the utterance includes "9" and the current
time is 10 am, then the time is resolved as 9 am today.
If the utterance includes "1:00 am" and the
current time is 2 pm, then the time is resolved as 1 am
tomorrow.
Locale-Based Entity Resolution 🔗
You can enable the CURRENCY, DATE and NUMBER entities to resolve to the user locale
by switching on Consider End User Locale.
Depending on the entity, this option has different applications:
DATE resolves to the locale-specific format: it can resolve 11/7 as
November 7 for en-US or July 11 for en-AU, for example. For non-supported
locales, you can apply a format and a temporal context, such as past or
future.
NUMBER resolves to the country-specific numeric format -- the
comma, period, or space used to separate groups of thousands and the decimal
point with or without a thin space that separates the fractional part of the
number. For example, the U.K. and U.S. both use a comma to separate groups of
thousands.
Note
When
Consider End User Locale is switched off, the
NUMBER entity resolves as COMMA_DOT (1,000.00).
CURRENCY uses locale to resolve to a specific $ or ¥ currency. When
no locale is detected, you can set the input to resolve as the $ or ¥ currency
that's set by the Ambiguity Resolution Rule.
Note
If you're referencing the same
entity with two more items within the same composite bag, or if two or more
composite bags reference the same entity and are also associated with the same
intent, upgrade to Release 21.12 to ensure that the locale customization specific to
each entity reference is handled separately and not overwritten by the locale
configuration of a previously resolved entity.
Locale-Based Date
Resolution 🔗
When the user's locale cannot be detected, the date is resolved as the selected
default date format.
For this Locale...
This input...
...Resolves as...
Format (Date-Month Sequence)
United States (en_US)
11/7
November 7
MONTH_DAY
Great Britain (en_GB)
11/7
July 11
DAY_MONTH
Canada - English (en_CA)
11/7
November 7
MONTH_DAY
Canada - French (fr_CA)
11/7
November 7
MONTH_DAY
Australia (en_AU)
11/7
July 11
DAY_MONTH
Mexico (es_MX)
11/7
July 11
DAY_MONTH
Singapore (zh_SG)
11/7
July 11
DAY_MONTH
United Arab Emirates
(ar_AE)
11/7
November 7
MONTH_DAY
Arabic (ar_AR)
11/7
November 7
MONTH_DAY
France (fr_FR)
11/7
July 11
DAY_MONTH
Netherlands (nl_NL)
11/7
July 11
DAY_MONTH
Germany (de_DE)
11/7
July 11
DAY_MONTH
Italy (it_IT)
11/7
July 11
DAY_MONTH
Portugal (pt_PT)
11/7
July 11
DAY_MONTH
Spain (en_ES)
11/7
July 11
DAY_MONTH
China (zh_CN)
11/7
November 7
MONTH_DAY
Japan (ja_JP)
11/7
November 7
MONTH_DAY
Locale-Based Currency
Resolution 🔗
For this Locale...
This input...
...Resolves as (Dollar Ambiguity)
This input...
...Resolves as (Yen Ambiguity)
United States (en_US)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Great Britain (en_GB)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Canada - English (en_CA)
20 dollars
20.0 CAD
20 ¥
20.0 JPY
Canada - French (fr_CA)
20 dollars
20.0 CAD
20 ¥
20.0 JPY
Australia (en_AU)
20 dollars
20.0 AUD
20 ¥
20.0 JPY
Mexico (es_MX)
20 dollars
20.0 MXN
20 ¥
20.0 CNY
Singapore (zh_SG)
20 dollars
20.0 SGD
20 ¥
20.0 JPY
United Arab Emirates
(ar_AE)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Arabic (ar_AR)
20 dollars
20.0 USD
20 ¥
20.0 JPY
France (fr_FR)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Netherlands (nl_NL)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Germany (de_DE)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Italy (it_IT)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Portugal (pt_PT)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Spain (en_ES)
20 dollars
20.0 USD
20 ¥
20.0 JPY
China (zh_CN)
20 dollars
20.0 USD
20 ¥
20.0 CNY
Japan (ja_JP)
20 dollars
20.0 USD
20 ¥
20.0 JPY
Locale-Based Number
Resolution 🔗
When Consider End User Locale is switched off, the number
format defaults to COMMA_DOT (1,000.00).