Got a survey today. Gives me a hint what Amazon expects for Alexa. Well it's very basic. It seems concerned attracting developers concerned about cost, where severs run, monetizing. But I think I'm not alone in saying I have no skill because it's too simplistic right now. I need long running requests (or push) and cards with links or direct deep linking to a browser. Echo can be a good starting point for an ecommerce app, but there is no path to conversion. That stub hub app can tell you what's playing but it can't really do a long search for seats and deep link to a purchase page. So I'm waiting. Wondering who else is?
Yup. I gave them an earful on the survey. If they just read the forum, they would have had a pretty good idea already. But now they have a survey where they can "analyze" the results. I did a blog entry noting a lot of points where I find their support of business partners lacking, but wrap it up with the explanation that they have adopted the business model of a "service provider". I.e. we're not partners, we're subscribers.
Minimally Amazon should enhance support for a formal grammar (with RegEx), IPA, Unicode. I'm surprised this wasn't in the first release. I assume Amazon will soon have to compete against intent APIs from Apple, Google and Microsoft. I don't see that Amazon is in a position to do that.
IPA and Unicode... that would be easy and awesome. RegEx... not going to happen. There is a common misunderstanding that Alexa's linguistic analysis starts with language recognition (converting sounds into words) and then matching those words against utterances. In that scenario, sure, it would be trivial to add in RexEx utterances. But if that is how they did it, the most error prone part of the analysis (converting sounds) would be operating only guided by what is generically true for English. If there were two possible interpretations that had a close confidence level, it would just pick the one with the higher confidence, no matter how close. It is standard practice, in both voice recognition and machine translation, to improve quality by restricting vocabulary. That way, when it builds its tree of interpretations, it can compare that against what has been declared to be the most common use cases, and make its selection against that. For examples, it might hear something that sounds more like "fishwife" than "fish knife", but if "fish knife" is in the set of utterances, then it knows that is the better interpretations. With that method, you really can't do regular expressions. At least not without shooting the complexity and compute time through the roof.
RegEx not in the sense of programming but a notation to facilitate the generation of static utterances. If you are going to have static utterances, you absolutely need a grammar notation that offers a way to express alternate forms, grouping, and repetition counts. This should have been implemented on release.