I created an Amazon Alexa skill that has one intent (MyIntent) and two custom slot types (SlotA and SlotB). The intent schema looks like that:
{
"intents": [
{
"intent": "Foo",
"slots": [
{
"name": "CustomA",
"type": "CUSTOM_A"
},
{
"name": "CustomB",
"type": "CUSTOM_B"
}
]
}
]
}
Each slot has a couple of values, like SlotA having
865985
710000
927291
514000
and SlotB having
Photo
Car
Bed
Kitchen
My sample utterances look like that:
MyIntent foo bar {SlotA}
MyIntent bar baz {SlotB}
MyIntent {SlotA}
MyIntent {SlotB}
The problem is, that Alexa doesn't recognize some of my slot values, like "bed", but does recognize others like "kitchen". This applies to both slot types.
The interesting thing is, that all values get recognized, if I keep only the simple sample utterances and remove the ones including phrases and my sample utterances look like that:
MyIntent {SlotA}
MyIntent {SlotB}
The order of the values or the sample utterances is irrelevant. I tried every combination. Also having two slots (combining all slot values in one) does not make any difference.
Why are the sample utterances with phrases blocking the recognition of some of the slot values?
EDIT:
By "doesn't recognize" I mean the user's input is not mapped to MyIntent. While being in a dialog (session) I just get a SessionEndedRequest.
Amazon had a bug in their system, preventing the language recognition from being build correctly. After the bug was removed, everything is fine again. Here is the email from the Amazon support:
We recently made new tools available to help with the creation and
testing of skills. The new features inadvertently impacted a small
number of skills. We fixed the issue yesterday and all live skills
should work as expected. Please post here if you have any more issues
and we will monitor and provide assistance. For skills in development,
you can now resolve this issue by clicking ‘Save’ on the interaction
model tab or by clicking Build Model in Skill Builder (beta). We
apologize for the inconvenience.
Related
I'm trying to plan a rewrite of my website and I want to make it that I can login passwordless with just Windows Hello, TouchID, or FaceID using WebAuthn. All the examples online have a whole popup situation but I want it done like my mockup. I also want my website to detect the default biometric and have the biometric icon change to the icon representing the default one, for example, face icon for FaceID. This website will be done using python-flask, ReactJS, MySQL, CSS, and HTML.
There's a few different points to hit on here -
Pop-up/Modal
We'll start with this one. Unfortunately the pop-ups that appear during the WebAuthn ceremony are part of the browsers implementation. Every time the get()/create() methods are called the pop-ups will be invoked. There is some work coming out from Google/Apple in their passkey implementation where this will look more like an "autofill" experience, but you will still be required to use their pop-ups.
Defaulting to Windows Hello, Touch ID, etc..
I'll start by suggesting that you shouldn't constrain your users to only the platform authenticators. Security keys still play a big role in WebAuthn and work really well for signing in across devices. Relying on platform authenticators could limit your users to the device they initially registered with, or limit users who don't have a biometric sensor on their device.
With that being said, you can explicitly invoke the use of only platform authenticators using the PublicKeyCreationOptions. In the property authenticatorSelection there is a field authenticatorAttachment. If you set this field to "platform" then your platform authenticator will be invoked (if one is available).
Here's an example of the request sent by the relying party (note the property authenticatorSelection towards the bottom):
{
"publicKey": {
"rp": {
"name": "Example Inc",
"id": "example.com/"
},
"user": {
"name": "user",
"displayName": "user",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
},
"challenge": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"pubKeyCredParams": [***],
"excludeCredentials": [***],
"authenticatorSelection": {
"authenticatorAttachment": "platform"
"residentKey": "preferred",
"userVerification": "preferred"
},
"attestation": "direct",
"extensions": {}
}
}
Detecting default biometric
I have a React example here. Some things to note on this approach:
There are more elegant and accurate ways of determining what platform the user is on. This snippet will work a majority of the time, but there is a lot of assumption happening based only on the detected OS
There's no icons included, I would suggest adding an imgSrc field to the enums that includes a link to the source image
Hope this helps.
First off, I do not want to use AMAZON.Literal as it is for US only (I'm UK based) and I doubt it will be supported much longer.
I need a wildcard slot to allow users to say a place name (name of a shop for example), followed by the city.
City is easy, no problem.
The issue is the place name. I have a custom slot, but I can't list every shop in every city in the values.
I put a value of any in, which kind of works, but in my response, I'm only getting the last word if the user says a name that contains a few words e.g. Pound Land would just return Land.
Has anyone managed to do this?
As of 2018, you can use phrases to get user input that you may not be able to predefine.
{
"intents": [
{
"name": "SearchIntent",
"slots": [
{
"name": "Query",
"type": "AMAZON.SearchQuery"
},
{
"name": "CityList",
"type": "AMAZON.US_CITY"
}
],
"samples": [
"search for {Query} near me",
"find out {Query}",
"search for {Query}",
"give me details about {CityList}"
]
}
]
}
https://developer.amazon.com/blogs/alexa/post/a2716002-0f50-4587-b038-31ce631c0c07/enhance-speech-recognition-of-your-alexa-skills-with-phrase-slots-and-amazon-searchquery
When using custom slot types, AWS may return values from outside of the list yet it will try to map to the values. You can "hack" this behavior by providing a huge list of possible values. Maybe try to scrap a list of places and use that. I once tried with a list of 3000 landmarks and it was definitely returning slot values that were not in the list. The recognition was not great but I had an acoustic similarity function that allowed me to retrieve items from the list when needed. That was a while ago when they first talked about deprecating Amazon.LITERAL but eventually left it so I didn't have to worry about this.
Referencing this API tutorial/explanation:
https://thinkster.io/tutorials/design-a-robust-json-api/getting-and-setting-user-data
The tutorial explains that to 'follow a user', you would use:
POST /api/profiles/:username/follow.
In order to 'unfollow a user', you would use:
DELETE /api/profiles/:username/follow.
The user Profile initially possesses the field "following": false.
I don't understand why the "following" field is being created/deleted (POST/DELETE) instead of updated from true to false. I feel as though I'm not grasping what's actually going on - are we not simply toggling the value of "following" between true and false?
Thanks!
I think that the database layer have to be implemented in a slightly more complex way than just having a boolean column for "following".
Given that you have three users, what would it mean that one of the users has "following": true? Is that user following something? That alone cannot mean that the user is following all other users, right?
The database layer probably consists of (at least) two different concepts: users and followings; users contain information about the user, and followings specify what users follow one another.
Say that we have two users:
[
{"username": "jake"},
{"username": "jane"}
]
And we want to say that Jane is following Jake, but not the other way around.
Then we need something to represent that concept. Let's call that a following:
{"follower": "jane", "followee": "jake"}
When the API talks about creating or deleting followings, this is probably what they imagine is getting created. That is why they use POST/DELETE instead of just PUT. They don't modify the user object, they create other objects that represent followings.
The reason they have a "following": true/false part in their JSON API response is because when you ask for information about a specific user, as one of the other users, you want to know if you as a user follows that specific user.
So, given the example above, when jane would ask for information about jake, at GET /api/profiles/jake, she would receive something like this:
{
"profile": {
"username": "jake",
"bio": "...",
"image": "...",
"following": true
}
}
However, when jake would ask for the profile information about jane, he would instead get this response:
{
"profile": {
"username": "jane",
"bio": "...",
"image": "...",
"following": false
}
}
So, the info they list as the API response is not what is actually stored in the database about this specific user, it also contains some information that is calculated based on who asked the question.
Using a microPUT would certainly be a reasonable alternative. I don't think anybody is going to be able to tell you why a random API tutorial made certain design decisions. It may be that they just needed a contrived example to use POST/DELETE.
Unless the author sees this question, I expect it's unanswerable. It's conceivable that they want to store meta information, such as the timestamp of the follow state change, but that would be unaffected by POST/DELETE vs. PUT.
Taking the car dashboard example, I altered the initial #genre node to be #genre:classical. I also added a list to the contex
"choices":["Beethoven","Mahler 9","Brahms 3rd"]
and the Watson response is "I have 3 selections". The condition on the next node is $choices.contains(input.text). The "Found a match" response is just for testing. It looks like this:
When I test this in the api tool and type "Beethoven" both "Found a match" and "Great choice!..." appear. Same for the other two choices, but only if I type the exact choice, e.g., "Mahler 9". Typing "Mahler" or "mahler" doesn't get a match. I read through the SpEL documentation but couldn't see a way in a one-line condition to parse through the list looking for partial matches.
So my question is, is there an condition expression that would match partial user input, e.g., "Mahler"? I'll be using the Java SDK to code the app server, so alternatively I wondered if I could add a temporary #entity just for this sequence instead of using the context list then delete it when the conversation is done? Or is there a way to construct a more complex condition in the MessageRequest and will Watson recognize it? Or is this just not the right way to go about this? Any pointers, examples or docs much appreciated.
So my question is, is there an condition expression that would match partial user input
You can't add temporary entities or intents. As adding them forces Watson to start training itself (even if you could it through code).
You can however create quite complex regular expressions, pass them in as a context variable.
For example your advanced node can have:
{
"output": {
"text": "Please ask me a question."
},
"context": {
"rx": "fish|[0-9]+"
}
}
Then in you condition you would write.
input.text.matches(context.rx)
This will then trigger if the person mentions a number, or the word fish. So you can create your partial user input checking that way.
This should be simple and straightforward, but I am having a hard time getting it to work. So:
Using AMAZON.LITERAL for a number like below works fine:
IntentSchema:
{
"intent": "Group_Size",
"slots":[
{
"name": "GroupSize",
"type": "AMAZON.LITERAL"
}
]
}
Sample Utterance:
Group_Size {forty thousand|GroupSize}
BUT when I change the slot type to AMAZON.NUMBER (which is what it should be) and utter 'forty thousand' or 'three nine six seven four' it stops working. The returned intent is one that is intended for Help and not Group_Size anymore (in other words, an irrelevant/incorrect intent is returned).
Same issue when I use AMAZON.DATE for one of my other intents.
I am fairly new to A-S-K, so is there anything special I need to do to get these predefined types to work? I went through the documentation and some code samples, but didn't find any gotchas. Any pointers please?
Worked when I passed NUMBER instead of AMAZON.NUMBER.