I would like to have my watson assistant repeat the response that was given before.
I have an Intent that matches e.g. "Can you please repeat that?".
Then if that Intent is matched, the answer should be the same that was given before.
Is there a way to archieve that?
How can I access the answer from before in the expression language?
Unfortunately there's no easy way to do this within Watson Assistant itself. The most straightforward way would be to configure each dialog node to store the value of output.generic.text in a context variable, and then you could use that variable as needed. But if you have many dialog nodes, that could be a tedious task and pose some maintenance headaches.
Another approach would be to try to tackle this at the application layer, which would have some advantages. If your application could catch requests to repeat, then you could handle those (caching the previous turn's dialog response and just repeating it upon request). The advantage to this approach is that by not handling a repetition request within Watson Assistant itself, you won't be interfering with the current session state -- this could be especially useful if the user was in the middle of providing prompted information for a slot, for instance. You wouldn't need to manage this as a digression or anything like that.
But if you aren't able to handle this at the application layer, there aren't any really great options. I think it would be great if IBM considered adding a global response repeat function at the Assistant level (would be especially great for Voice Agent / Voice Gateway applications).
Related
I am working on an app which touches sensitive information, like money.
We have some calculators, and we want to prefill the values with whatever the user has entered last. Apart from increasing UX, we don't need those. But we cannot store it in web storage or cookie because of security.
We have
a JS frontend,
an API Gateway backend that is supposed to be "stupid", so it only handles authentication and sending messages to to corresponding services
some services that actually care about the business logic
These possibilities come to mind and I cannot decide which I should do (and foremost: why)
Add a table in backend, that is a catch all for implementing cookie-like functionality in backend
Add a specific table in the service it fits the most
Use a key value store in backend (don't know about this, a coworker put it out there)
As i read your requirements it seams that this is kind of a defaulting including some business logic (stupid or smart). Personally i see defaulting as part of business logic and based on this it's part of the service which cares about this functionality.
Add a table in backend, that is a catch all for implementing cookie-like functionality in backend
This sounds like a generic solution for a pretty generic requirement. what do you wanna achieve with this?
Add a specific table in the service it fits the most
Sounds reasonable especially because you put it there where it belongs. Does it have to be a table? why not calculate or copy the values on runtime?
Use a key value store in backend (don't know about this, a coworker put it out there)
This is maybe a technological decision but first you need a design decision.
My understanding is that Amazon ASK still does not provide:
The raw user input
An option for a fallback intent
An API to
dynamically add possible options from which Alexa can be better
informed to select an intent.
Is this right or am I missing out on knowing about some critical capabilities?
Actions on Google w/ Dialogflow provides:
raw user input for analysis: request.body.result.resolvedQuery
fallback intents:
https://dialogflow.com/docs/intents#fallback_intents
An APi to dynamically add user expressions (aka sample utterances): PUT
/intents/{id}
These tools provide devs with the ability to check to see if the identified intent is correct and if not fix it.
I know there have been a lot of questions asked previously, just a few here:
How to add slot values dynamically to alexa skill
Can Alexa skill handler receive full user input?
Amazon Alexa dynamic variables for intent
I have far more users on my Alexa skill than my AoG app simply because of Amazon's dominance to date in the market - but their experience falls short of a Google Assistant user experience because of these limitations. I've been waiting for almost a year for new Alexa capabilities here, thinking that after Amazon's guidance to not use AMAZON.LITERAL there would be improvements coming to custom slots. To date it still looks like this old blog post is still the only guidance given. With Google, I dynamically pull in utterance options from a db that are custom for a given user following account linking. By having the user's raw input, I can correct the choice of intent if necessary.
If you've wanted these capabilities but have had to move forward without them, what tricks do you have to get accurate intent handling with Amazon when you don't know what the user will say?
EDIT 11/21/17:
In September Amazon announced the Alexa Skill Management API (SMAPI) which does provide the 3rd bullet above.
Actually this should be better a comment but i write to less at stackoverflow to be able to comment. I am with you on all.
But Amazons Alexa has also a very big advance.
The intent Schema is seeming to directly influence the Voice to Text recognition. Btw. can someone confirm if this is correct?
At Google Home it seems not to be the case.
So matching of unusual names is even more complicated than at alexa.
And it sometimes just recognize absolute bullshit.
Not sure which I prefer currently.
My feeling is for small apps is Alexa much better, because it better match the Intent phrases when it has lesser choices.
But for large Intent schemas, it get really trouble and in my tests some of the intents were not matched at all correct.
Here the google home and action SDK wins, probably? Cause Speech to text seem to be done before and than a string pattern to intent schema matching is happening. So this is probably more robust for larger schemas?
To get something like an answer on your questions:
You can try to add as much as possible that can be said to a slot. And than match the result from the Alexa request to your database via Jaro winkler or some other string distance.
Was I tried for Alexa was to find phrases that are close to what the user say. And this i added as phrases to fill a slot.
So a module in our webpage was an intent in the schema. And Than I requested To say what exactly should be done in that module (this was the slot filling request). The Answer was the slot filling utterance.
For me that was slightly better working than the regulary intent schema. But it require more talking so i dont like it so much.
Let me go straight to answering your 3 questions:
1) Alexa does provide the raw input via the slot type AMAZON.Literal but it's now deprecated and you're advised to use AMAZON.SearchQuery for free form capture. However, if instead of using SearchQuery you define a custom slot type and provide samples (training data) the ASR will work better.
2) Alexa supports FallbackIntent since I believe May 2018. The way it work is by automatically generating a model for your skill where out-of-domain requests are routed through a fallback intent. It works well
3) Dynamically adding slot type values is not feasible since when you provide samples you're really providing training data for a model than will be able to then process similar values beyond the ones you defined. If you noticed when you provide a voice interaction model schema then you have to build the model (in this step the training data provided in the samples is used to create the model). One example, when you define a custom slot of type "Car" and you provide the samples "Toyota", "Jeep", "Chevrolet" and "Honda" then, the system will also go to the same intent if the user says "Ford"
Note: SMAPI does allow to get and update the interaction model, so technically you could download the model via API, modify it with new training data, upload it again and rebuild the model. This is kind of awkward though
This is not much a technical question but more a reflexion about the subject.
REST have democtratized a good way of serving resources using HTTP protocols and let developper do the cleanest project by splitting resources and user interface (back-end now really deals about back-end only with the use of REST APIs).
About those API, most of the time we use GET, PUT/PATCH (hmm meh ?), POST and DELETE, both mimic CRUD database.
But as time spent on our projects goes by, we feel the UX can be improved by adding tons of great features. For example, why should the user feel afraid of deleting a resource ? Why do not just put a recovery system (like we can see in Google Keep app that let us undo a deletion which I think is awesome in term of UX).
One of the practices that preventing unintentionnal deletion is the use of a column in the table that represents the resource. For example, I am about to delete a book, so by clicking the delete button I will only flag this row as "deleted = TRUE" in my database, and prevent displaying the rows that are deleted when browsing the list of resource (GET).
This last comes in conflict with our dear and loved REST pattern, as there is no distinction between DELETE and DESTROY "methods".
What I mean is, should we think about making REST evolving to our UX needs, so by that I mean also making HTTP protocols evolving, or should this stays as a puristic resource management and we should instead follow HTTP protocol without trying to bother it and just adapt to it using workaround (like using PATCH for soft deletion) ?
Personnaly I would like to see at least 4 new protocols as we are trying to qualify a resource as good as possible :
DELETE becomes a way to prevent others methods to have an impact on it
DESTROY becomes more dramatic by completely removing trace of this resource
RECOVER is a way to say to the other methods "hey guys, he is coming back, stay tuned"
TRASH is a GET like but only for the DELETED resources
What made me think about it is my research of a clean REST solution to deal with this resource behavior. I have seen some website posts including
https://www.pandastrike.com/posts/20161004-soft-deletes-http-api
https://philsturgeon.uk/rest/2014/05/25/restful-deletions-restorations-and-revisions/
...
That advice us to use PUT or PATCH to make soft deletion something usable but I kind of feel it does not sounds right, does not it ?
My thoughts about this problem :
Is there a big step between proposing new HTTP methods and update previous methods (I heard HTTP/2 is a thing, maybe we could ship those in ?)
Does it make sense outside the web developpement realm ? I mean does this changes could impact other domains that our ?
I'm not sure this makes sense even within the web development realm; the starting premises seem to be wrong.
RFC 7231 offers this explanation for POST
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
Riddle: if this is the official definition of POST, why do we need GET? Anything that the target can do with GET can also be done with POST.
The answer is that the additional constraints on GET allow participants to make intelligent decisions using only the information included in the message.
For example, because the header data informs the intermediary component that the method is GET, the intermediary knows that the action upon receiving the message is safe, so if a response is lost the message can be repeated.
The entire notion of crawling the web depends upon the fact that you can follow any safe links to discover new resources.
The browser can pre-fetch representations, because the information encoded in the link tells it that the message to do so is safe.
The way that Jim Webber describes it: "HTTP is an application, but it's not your application". What the HTTP specification does is define the semantics of messages, so that a generic client can be understood by a generic server.
To use your example; the API consumer may care about the distinction between delete and destroy, but the browser doesn't; the browser just wants to know what message to send, what the retry rules are, what the caching rules are, how to react to various error conditions, and so on.
That's the power of REST -- you can use any browser that understands the media-types of the representations, and get correct behavior, even though the browser is completely ignorant of the application semantics.
The browser doesn't know that it is talking to an internet message board or the control panel of a router.
In summary: your idea looks to me as though you are trying to achieve richer application semantics by changing the messaging semantics; which violates separation of concerns.
We are trying to use AngularJS with Breeze, with a .NET backend. We have gotten things hooked up working together. However, we are having trouble figuring out how to lock things down based on the user role and the user's own data.
Can anyone point us in the general direction? We couldn't find anything explicitly in Breeze's documention.
There is no reason why Breeze should be insecure. Security is orthogonal. My question remains: what are your concerns?
Update 2 March 2015
Thanks for the clarifying comment ... which reflects concerns that are widely share. I really am going to have to write about this at length in our documentation.
Fortunately, I believe I can ease your mind about the specific issues you raised.
BreezeJS, the client library, can only reach the data that your server allows the current user to access. It's the server's job to grant or refuse such requests.
This is fundamentally the same story for a client written with any technology talking to a server written with any technology. If the server has a "Customers" endpoint, than a client can request all of your customers and will receive them unless you guard that endpoint with logic on the server. This is true with or without Breeze.
You may be thinking that the metadata describes your entire database schema and therefore exposes the entire database to Breeze client requests. That statement is not true on a couple of counts.
First, even if the client knows about your entire database schema, it can't do anything with that knowledge unless you go to the trouble of exposing every table in your web api with unguarded endpoints. This is entirely within your control and its not something you can do by accident.
Second, there is no good reason to send metadata that describe your entire database. If you let the server generate the metadata based on the Entity Framework model, you can easily limit the size and shape of that model to the subset of the database that you want to expose in your client-facing api.
After you've narrowed the model and the web api to the size and shape appropriate for your application, you must take the next step ... the step you'd take for any web api imaginable ... which is to guard the endpoints.
At a minimum that means ensuring that the user is authenticated and authorized to make requests of each endpoint. But it also means preventing unwanted responses even to authorized user requests. For example, you might want to limit on the server the number of Customers that can be returned for any given customer query. You might want to throttle the number of requests that you'll process in a single interval of time. You might want to filter the customers down to just those few that the user is allowed to see.
The techniques for doing these things are all part of the ASP.NET Web API itself, having nothing to do with Breeze whatsoever. You'll want to investigate the options that Web API has to offer.
The update side of things is actually much easier to manage with Breeze components for ASP.NET Web API. The conventional Breeze update mechanism is a batch post to a single SaveChanges endpoint. In other words, the surface area of the attack can be limited to a single endpoint. The Breeze SaveChanges method for .NET offers two interception points for security and integrity checks:
BeforeSaveEntity where you can inspect and confirm every entity individually before it gets saved to the database.
BeforeSaveEntities where you can inspect the entire batch as a whole ... to ensure that the save request is cohesive and legitimate. This is something you can't do in a simple REST-ish api where PUT/POST/DELETE requests arrive as separate, autonomous events
The Breeze query language is highly expressive so it is possible that the client may query the server for something that you were not expecting. The expand clause is probably the most "dangerous" in this regard. Someone can query the Customer endpoint and get their related Orders, their related OrderDetails, the related Products, etc ... all at the same time.
That is a great power and with it comes responsibility. You may choose to withhold that power by refusing to allow expand queries. You can refuse select queries that can "expand" by selecting related entities. The ASP.NET Web API makes it easy to impose these restriction.
Alternatively, you can allow expand in some cases and not others. Or you can inspect the query request within the GET endpoint's implementation and refuse it if it fails your security checks.
You could decide that you don't want certain entity types to be "queryable" at all. You can create just the specialized GET endpoints you need to support safe access to those highly sensitive types. If the supporting methods don't return IQueryable, neither Breeze nor Web API will attempt to turn the OData query parameters into LINQ queries. These endpoints look and behave exactly like the traditional REST-ish apis that are familiar to you now. And the Breeze client will be happy to play along. When you compose a Breeze query, the client doesn't know whether the server will honor that request. With Breeze you can compose any request you want and send it to any HTTP endpoint you desire. You're not limited to OData-style queries.
You don't need ONE approach for querying. You decide what entity types are exposed, how, and under what conditions. You can and should write the guard logic to ensure that the proper data are returned by a query or updated by a save ... just as you would for any web api. Both Breeze and Web API give you a rich set of tools for writing such guard logic. Your options are unbounded.
Finally, I observe that Breeze-oriented apis tend to be much smaller than the typical RESTy api ... that is, they offer fewer endpoints and (in this sense) a smaller surface area. As a practical matter, that means you can concentrate your server-side security budget on fewer methods and potentially improve both the quality of that code and your capacity to scrutinize your api's security risks.
I'm just looking into Dreamfactory, and it seems to me that all permission-logic is to be done by the client.
I want to develop an app with documents, and not all users are allowed to edit all documents. If the logged in user has permissions to the database, how can I prevent that user from making false API calls that delete or modify someone elses document ?
While your observation is correct, the app must control access, we do offer a couple features that will solve your problem.
First off, the roles system is very flexible. You could create different roles, reader, writer, admin, etc. And assign them to the corresponding users. This can be done today.
Secondly, we will be releasing an update in the next few weeks that has several new features, one of which, will also solve your dilemma. I'm not 100% sure what it is going to be named, but it will allow you to have the system automatically inject runtime data (I.e. user ID) into REST service calls to the DSP. Very flexible and powerful.
More information and doc will be available with the release so hold on a tad and we'll get you there!
The upcoming release at the end of the month lets you do a server side filter, or use server side scripting to lock a user to modifying only their own records, or those you see fit.