Remove the requirement for a leading phrase with AMAZON.SearchQuery
We would like to use this, but can't because the rules are too restrictive.If a user is asked about what they want info about, they should not be forced to say "tell me about Point Defiance Zoo". They should be able to say "Point Defiance Zoo" with no leading phrase. Instead of forcing us to use a leading or trailing phrase, please allow the use of just {query} (without 'search for...' or other text around it as in the example below:
{
"name": "SearchIntent",
"samples": [
"search for {Query}",
"find out {Query}",
"search for {Query} near me"
],
"slots": [
{
"name": "Query",
"type": "AMAZON.SearchQuery"
}
]
}
Dana Young
shared this idea
-
Roshni Hirani
commented
There is any way to handle this problem so we can accept free form text from user by using Amazon.search_query without using any carrier phrase?
-
Tyler Burton
commented
this can also be handled, in some fashion, with auto-delegation
-
Anonymous
commented
This would be extremely useful for those of us who don't want to have to write out 1000 lines of code for no reason. Currently my bot has 30 useless intents: "What {message}", "where {message}", "Did {message}", "Can {message}", etc etc etc with pretty much every starting word that anybody has ever used with the skill.. This number will likely grow.. causing more processing on Amazon's side, and more work for me. I would be happy with just one Intent thats a catch all and nothing more.. perhaps a new type of skill.. called a "CatchAll Skill"??
-
Josh Broadhurst
commented
Try using the AMAZON.LocalBusiness slot. It's been broad enough for my use case to serve as an ad hoc search query slot without a carrier phrase.
-
Claudius Ellsel
commented
Also see: https://gitlab.com/clel/amazon-alexa-issue-tracker/issues/15 an issue on my unofficial issue tracker with more information and links to other posts with this problem.
-
David Bess
commented
This blog post specifically highlights the capability we are after. But the use case promised can not actually be done with the carrier phrase requirement in place.
"Another example would be a dialog where Alexa prompts the user with a question like “what events are you interested in?” You can then use AMAZON.SearchQuery to receive the user’s response to “outdoor concerts in Chicago this summer” as text. This new built-in slot is optimized to search terms and phrasing."
-
Dyung Ngo
commented
you simply can not have a natural multi-turn conversation with this limitation. people don't speak by forcing a leading phrase and really limits the potential of making the skill conversational.
-
Dan Greene
commented
I would totally be fine with the limitation that another developer (@Gregory Novak) described:
> "I could use this feature as well. However, with the way NLP works it would probably have some restrictions. Like only one intent allowed with the "catch all" SearchQuery slot. All other intents have priority, etc."
-
Gregory Novak
commented
I could use this feature as well. However, with the way NLP works it would probably have some restrictions. Like only one intent allowed with the "catch all" SearchQuery slot. All other intents have priority, etc.
-
Pint
commented
Possibly having a new argument in the response sent back from the endpoint would work, like 'trigIntent: CityResponseIntent' or something like that, so that the full response could be sent back. We could also have an option to have two intents, one for just the response, and one for all the other things (my city is <>, I live in <>, etc), so we can correctly parse the response.