Your Alexa Dashboards Settings

Define Synonyms and IDs for Slot Type Values (Entity Resolution)

Entity resolution improves the way Alexa matches possible slot values in a user’s utterance with the slots defined in your interaction model. You can define your custom slot type values as entities with fixed identifiers and synonyms. Then, when users make requests to your skill, Alexa attempts to match the possible slot values in the utterance with the values and synonyms in the entities you have defined. If there is a match, your skill gets the canonical value defined for the entity, the actual value that the user spoke, and the unique identifier.

Entity resolution takes place automatically, but to take full advantage of the feature, you need to define the synonyms and IDs for your slot values.

Slot Value Synonyms, Unique Identifiers, and Entity Resolution

Users often use different words to say the same thing. For instance, for a MEDIA_TYPE slot intended to collect a particular type of media, a user might say “song”, “track”, or “single”. In most cases, you would want your code to handle these three different values the same way.

To simplify this, define your slot type values as entities. An entity consists of:

  • A possible slot value (such as “song”). This is the canonical slot value.
  • An optional list of synonyms (such as “track” and “single”). These synonyms are tied to the canonical slot value.
  • A unique ID (such as SONG).

Alexa uses these entities to resolve the user’s utterance. The IntentRequest sent to your skill includes:

  • The actual value the user spoke. This might be the canonical value, one of the synonyms, or another matching value.
  • The canonical value defined for the matching entity.
  • The unique ID of the matching entity.

You can use the unique ID in your code directly and not worry about the specific word that the user said for the slot. For example, for a MEDIA_TYPE slot type, the slot value “song” could have the ID SONG and the synonyms “track” and “single.” When a user says “track” for this slot, your skill gets:

  • The value “track”
  • The canonical value “song”
  • The ID SONG

Also note that the IntentRequest can include multiple possible matches for a slot rather than just one.

Create Synonyms and Unique Identifiers for Custom Slot Type Values

You can define the synonyms and unique identifiers for any custom slot type or extensible built-in slot type. You must use the skill builder (beta) to create synonyms and identifiers.

Within the skill builder (beta), you can define the ID and synonyms for each slot value when editing the type. Alternatively, you can use the Code Editor to view and edit these values in JSON.

Edit Slot Type Values and Identifiers in the Skill Builder (Beta)

  1. In the skill builder, add or edit a custom slot type. Select the type from the Slot Types area in the left-hand navigation.
  2. Add slot values normally.
  3. Click in the ID column for a value to edit its ID.
  4. Click in the Synonyms column for a value to enter a synonym, then click the plus or press Enter to save it.

View or Edit Slot Type Values in the Code Editor

You can also use the Code Editor to edit the IDs and synonyms for the slot type values in the JSON. For example, the following JSON defines a custom slot type called MEDIA_TYPE with two values. Each value (“album” and “song”) has an ID and three synonyms:

{
  "types": [
    {
      "name": "MEDIA_TYPE",
      "values": [
        {
          "id": "ALBUM",
          "name": {
            "value": "album",
            "synonyms": ["cd","lp","record"]
          }
        },
        {
          "id": "SONG",
          "name": {
            "value": "song",
            "synonyms": ["track","single","tune"]
          }
        }
      ]
    }
  ]
}

See the JSON syntax shown below for definitions of these JSON properties.

After making any changes in the Code Editor, always click Apply Changes to apply the updates to your model. Then save and build before testing.

Custom Slot Type JSON Reference

The JSON format for custom slot types specifies the types property as an array of objects. Each object represents a custom slot type and includes a name and array of values. Each value consists of:

  • A unique identifier (id).
  • A string value (name.value).
  • An optional array of synonyms for that value (name.synonyms[]).

When a user’s utterance mentions either the value or one of the synonyms, Alexa resolves the utterance to the value and includes it in the IntentRequest sent to your skill.

Slot type definition syntax:

{
  "types": [
    {
      "name": "string",
      "values": [
        {
          "id": "string",
          "name": {
            "value": "string",
            "synonyms": [
              "string",
              "string"
            ]
          }
        }
      ]
    }
  ]
}

Parameter Description Type Required
name Name of the slot type. Can contain alphabetic characters only. The only special character allowed is the underscore (“_”). string Yes
values An array of objects defining the values for the slot type. array Yes
values[].id An identifier for the slot value. This identifier is included in the IntentRequest when Alexa recognizes a slot value or synonym in the user’s utterance. The ID cannot include spaces. string Yes
values[].name An object representing the name of this value. This object defines the text value and synonyms for the entity. object Yes
values[].name.synonyms An array of strings representing synonyms for this value. If Alexa recognizes the user’s utterance as one of these synonyms, Alexa resolves the utterance to this value and includes information for the value in the IntentRequest. array No
values[].name.value A string containing the canonical value associated with this slot type value. For example, for a MEDIA_TYPE slot type, one value might be “album”. string Yes

For an example, see Sample Slot Type Definition and IntentRequest, below.

Slot Value Resolutions in the IntentRequest

The IntentRequest sent to your skill includes additional information for the slot values. The additional properties are all within the slots object on the intent.

Continuing the earlier MEDIA_TYPE slot type example, an intent using this type for the MediaType slot might produce an IntentRequest like this:

{
  "type": "IntentRequest",
  "intent": {
    "name": "GetMediaIntent",
    "slots": {
      "MediaType": {
        "name": "MediaType",
        "value": "track",
        "resolutions": {
          "resolutionsPerAuthority": [
            {
              "authority": "amzn1.er-authority.echo-sdk.<skill_id>.MEDIA_TYPE",
              "status": {
                "code": "ER_SUCCESS_MATCH"
              },
              "values": [
                {
                  "value": {
                    "name": "song",
                    "id": "SONG"
                  }
                }
              ]
            }
          ]
        }
      }
    }
  }
}

In this request:

  • The value property for the slot object (MediaType) reflects the value the user spoke. In the above example, the user spoke one of the synonyms defined for the SONG value.
  • The resolutions property contains the results of entity resolution. These are organized by authority. An authority represents the source for the data provided for the slot. For a custom slot type, the authority is the slot type you defined.
  • The values array within resolutionsPerAuthority contains the possible matching slot values. This includes the canonical value (resolutionsPerAuthority[].values[].value.name) and unique ID (resolutionsPerAuthority[].values[].value.id) for each possible match.

See the standard IntentRequest definition for details about the IntentRequest properties.

For an example, see Sample Slot Type Definition and IntentRequest, below.

Entity Resolution for Built-in Slot Types

When using a built-in slot type as is, no entity resolution takes place. The slot type value spoken by the user is sent to your skill with just the name, value, and confirmationStatus properties. For instance, the toCity slot in this example uses the built-in type AMAZON.US_CITY (for brevity, these JSON examples show just the relevant slot in the IntentRequest):

User: Alexa, tell Plan My Trip that I’m going to Chicago

{
  "toCity": {
    "name": "toCity",
    "value": "Chicago",
    "confirmationStatus": "NONE"
  }
}

A subset of the built-in slot types can be extended with custom values. If you extend a slot type, entity resolution does take place and the resolutions property is included on all values for the slot. You can add synonyms and custom IDs for your values.

In this example, the AMAZON.US_CITY slot type has been extended. The value “chicago” was added, and given the synonym “the windy city” and the ID ORD:

User: Alexa, tell Plan My Trip that I’m going to the windy city

{
  "toCity": {
    "name": "toCity",
    "value": "the windy city",
    "resolutions": {
      "resolutionsPerAuthority": [
        {
          "authority": "amzn1.er-authority.echo-sdk.<skill_id>.AMAZON.US_CITY",
          "status": {
            "code": "ER_SUCCESS_MATCH"
          },
          "values": [
            {
              "value": {
                "name": "chicago",
                "id": "ORD"
              }
            }
          ]
        }
      ]
    },
    "confirmationStatus": "NONE"
  }
}

Note that you can add values that were already part of the built-in slot type data set and assign your own IDs and synonyms. In the above example, the value “chicago” was already a value in the AMAZON.US_CITY slot type. The version you add as a custom value overrides the original, so the resolutions property includes your custom ID for this utterance.

You can also add a value that was already part of the built-in type data set as a synonym to your own value. This also overrides the original. For example, you could add the custom value “the windy city” to AMAZON.US_CITY and give it the synonym “chicago”. In this case, the user’s utterance “chicago” would send your skill the value they spoke (“chicago”) and your custom canonical value “the windy city”:

User: Alexa, tell Plan My Trip that I’m going to Chicago

{
  "toCity": {
    "name": "toCity",
    "value": "Chicago",
    "resolutions": {
      "resolutionsPerAuthority": [
        {
          "authority": "amzn1.er-authority.echo-sdk.<skill-id>.AMAZON.US_CITY",
          "status": {
            "code": "ER_SUCCESS_MATCH"
          },
          "values": [
            {
              "value": {
                "name": "the windy city",
                "id": "ORD"
              }
            }
          ]
        }
      ]
    },
    "confirmationStatus": "NONE"
  }
}

Note the meaning of the the status code (resolutions.resolutionsPerAuthority[].status.code) for an extended built-in slot type:

  • If the user’s value matches one of your custom values or synonyms, the status code is ER_SUCCESS_MATCH.
  • If the user’s value matches anything else (such as the built-in data for the type), the code is ER_SUCCESS_NO_MATCH.

For more about how to extend a built-in slot type, see Extend a Built-in Slot Type with Additional Values. For the list of extensible types, see Slot Types You Can Extend.

Sample Slot Type Definition and IntentRequest

The following example shows the JSON defining two custom slot types: MEDIA_TYPE and MEDIA_TITLE.

[
  {
    "name": "MEDIA_TYPE",
    "version": 2,
    "values": [
      {
        "id": "ALBUM",
        "name": {
          "value": "album",
          "synonyms": ["cd","lp","record"]
        }
      },
      {
        "id": "SONG",
        "name": {
          "value": "song",
          "synonyms": ["track","single","tune"]
        }
      },
      {
        "id": "VIDEO",
        "name": {
          "value": "music video",
          "synonyms": ["video"]
        }
      }
    ]
  },
  {
    "name": "MEDIA_TITLE",
    "version": 2,
    "values": [
      {
        "id": "song_id_123",
        "name": {
          "value": "Ray of Light",
          "synonyms": ["Ray of the Ligh","Ray of lights","Ray"]
        }
      },
      {
        "id": "song_id_456",
        "name": {
          "value": "Rolling in the Deep",
          "synonyms": ["rolling deep","in the deep"]
        }
      }
    ]
  }
]

With the above slot definition, you could define an intent schema like this:

{
  "intents": [
    {
      "intent": "GetMediaIntent",
      "slots": [
        {
          "name": "MediaType",
          "type": "MEDIA_TYPE"
        },
        {
          "name": "MediaTitle",
          "type": "MEDIA_TITLE"
        }
      ]
    }
  ]
}

Your sample utterances for this intent would include the slot names normally:

GetMediaIntent  get the {MediaType} called {MediaTitle}
GetMediaIntent  tell me about the {MediaType} {MediaTitle}
(many more)

The user might interact with the skill like this:

User: Alexa, ask My Sample Skill to get the song rolling in the deep

This utterance mentions values for both slots (MediaType, MediaTitle). Alexa resolves these mentions using the data provided in your custom slot type and sends your skill the following IntentRequest:

{
  "type": "IntentRequest",
  "intent": {
    "name": "GetMediaIntent",
    "slots": {
      "MediaType": {
        "name": "MediaType",
        "value": "song",
        "resolutions": {
          "resolutionsPerAuthority": [
            {
              "authority": "amzn1.er-authority.echo-sdk.<skill_id>.MEDIA_TYPE",
              "status": {
                "code": "ER_SUCCESS_MATCH"
              },
              "values": [
                {
                  "value": {
                    "name": "song",
                    "id": "SONG"
                  }
                }
              ]
            }
          ]
        }
      },
      "MediaTitle": {
        "name": "MediaTitle",
        "value": "rolling in the deep",
        "resolutions": {
          "resolutionsPerAuthority": [
            {
              "authority": "amzn1.er-authority.echo-sdk.<skill_id>.MEDIA_TITLE",
              "status": {
                "code": "ER_SUCCESS_MATCH"
              },
              "values": [
                {
                  "value": {
                    "name": "Rolling in the Deep",
                    "id": "song_id_456"
                  }
                }
              ]
            }
          ]
        }
      }
    }
  }
}

Since the entity definitions include synonyms, your skill gets a similar result if the user uses slightly different wording:

User: Alexa, ask My Sample Skill to get the track rolling in the deep

Since track was defined as a synonym of song, Alexa can resolve this value and provide you with the same ID (for brevity, this example only shows the JSON for the MediaType slot):

{
  "MediaType": {
    "name": "MediaType",
    "value": "track",
    "resolutions": {
      "resolutionsPerAuthority": [
        {
          "authority": "amzn1.er-authority.echo-sdk.<skill_id>.MEDIA_TYPE",
          "status": {
            "code": "ER_SUCCESS_MATCH"
          },
          "values": [
            {
              "value": {
                "name": "song",
                "id": "SONG"
              }
            }
          ]
        }
      ]
    }
  }
}