Creating Custom Types
If Star Port 75 Travel were a travel company specializing in international travel, then AMAZON.City would be the perfect type for the destination slot. But Star Port 75 has its sights set higher, so to speak, so a type that represents planetary destinations seems more fitting.
Although Amazon provides an impressive number of types to cover many cases, they do not offer a type that represents planets. But they do make it possible to define custom types in the interaction model as entries in the types property, a child of the languageModel property and a sibling of the intents property. For the purposes of our planet type, we’re going to define a new type called PLANETS, which will include all nine planets in Earth’s solar system (and yes, we’ll count Pluto as a planet). Here’s an excerpt from the interaction model showing the new PLANETS type, and where it fits in the interaction model:
| | { "interactionModel": { "languageModel": { "invocationName": "star port seventy five", "intents": [ ... ], "types": [ { "name": "PLANETS", "values": [ { "id": "MERCURY", "name": { "value": "Mercury" } }, { "id": "VENUS", "name": { "value": "Venus" } }, { "id": "EARTH", "name": { "value": "Earth" } }, { "id": "MARS", "name": { "value": "Mars" } }, ... ] } ] } } } |
The types property is an array where each entry represents a type. Each type has a name and an array of possible values. In this case, our custom type is named PLANETS and includes nine values in the array of values, one for each planet in our solar system. (For brevity’s sake, only the first four planets are shown here, but the entries for the remaining five follow a similar pattern.)
Each entry in the values property is known as an entity. In its simplest form, each entity has an ID and a name. The name is the word or phrase that the user might speak when saying that value in an utterance. The ID must uniquely identify the value and can be almost anything, not necessarily an actual word. For the list of planets, however, it is easy enough to just set the ID to the planet’s name in all uppercase lettering.
Now that we have defined our custom PLANETS type, we can use it instead of AMAZON.City in the ScheduleTripIntent’s destination slot:
| | "slots": [ |
| | { |
| | "name": "destination", |
| | "type": "PLANETS" |
| | } |
| | ] |
At this point the tests should still pass and our skill should still behave as it did before creating the custom type. The only difference it makes is more internal—in how Alexa’s natural language processing will interpret the values given when selecting the intent. While it makes little difference at the moment, it helps Alexa to know more definitively that “Jupiter” is a planet and not just the name of a city. If there were some ambiguity in selecting an intent, the one with a planet slot would win over one with cities.
The custom PLANETS type is perfect for space travel destinations. But you won’t always need to create a completely new type. Sometimes, it’s sufficient to extend one of Amazon’s built-in types with custom values.